> Once MS changes interfaces, then there's _no advantage_ to using DX10 > internally, regardless of what WINE does, and one might as well use > OpenGL. Wine doesn't change that.
[resent to ML, inadvertently replied only to Miles] Note that my proposal was not to use DirectX 10 internally, but rather to expose DirectX 10 and promote it initially as an API to test Gallium and later as the preferred Linux graphics API instead of OpenGL, for the technical reason that a DirectX 10 over Gallium implementation carries much less performance overhead than an OpenGL implementation and is much simpler, due to the superior design of DirectX 10. Using an extended version of DirectX 10 internally could also be an option, but I don't think it's worth doing that right now and likely it's not worth at all. Also note that Microsoft does not use DirectX 10 or 11 internally either, but rather uses the "DirectX 10 DDI" or "DirectX 10 Device Driver Interface", which is also publicly documented. The last time Microsoft did an incompatible interface change (DX10), it was to move away from fixed pipeline support with scattered state towards a shader-only pipeline with constant state objects. Exactly the same change was achieved by the move from the classic Mesa architecture to the Gallium architecture: you could think of the move to Gallium as switching to something like DX10 internally, done purely for technical reasons, partially the same as the ones that prompted Microsoft to make the transition. Actually, while this is not generally explicitly stated by Gallium designers, Gallium itself is generally evolving towards being closer to DirectX 10. The biggest deviations are additional features needed to support OpenGL features not included in DirectX 10. For instance, looking at recent changes: - Vertex element CSOs, recently added, are equivalent to DX10 input layouts - Sampler views, also recently added, are equivalent to DX10 shared resource views - Doing transfers per-context (recent work by Keith Whitwell) is what DX10 does - Having a "resource" concept (also recent work by Keith Whitwell) is what DX10 does - Gallium format values where changed from self-describing to a set of stock values like DX10 - Gallium format names where later changed and made identical to DX10 ones (except for the fact that the names of the former start with PIPE_FORMAT_ and the ones of the latter with DXGI_FORMAT_, and the enumerated values are different) - It has been decided to follow the DX9 SM3/DX10 model for shader semantic linkage as opposed to the OpenGL one I recently systematically compared Gallium and DirectX 10, and found them to be mostly equivalent, where the exceptions were usually either additional features Gallium had for the sake of OpenGL, or Gallium misdesigns that are being changed or looked into. This is not likely for the sake of imitating Microsoft, but just because they made a good design, having had made the decision to redesign the whole API from scratch when making DirectX 10. It's also probably because VMWare is apparently funding DirectX 10 support over Gallium, which obviously makes all discrepancies evident for people working on that, and those are generally because DirectX 10 is better, leading those people to improve the Gallium design taking inspiration from DirectX 10. Presumably if Microsoft were to change interfaces incompatibly again (notice that DX11 is a compatible change), Mesa would probably benefit from introducing a further abstraction layer similar to new Microsoft interface and have a Gallium->NewLayer module, since such a change would most likely be a result of a paradigm shift in graphics hardware itself (e.g. a switch to fully software-based GPUs like Larrabee). Also, unless Microsoft holds patents to DirectX 10 (which would be a showstopper, even though Gallium may violate them anyway), I don't see any difference from having to implement DirectX 10 or OpenGL, or any difference in "openness" of the APIs. It is indeed possible to participate in the ARB standardization process and some Mesa contributors/leaders do, but I'm not sure whether this is particularly advantageous: decisions that work well for Microsoft and Windows are also likely to work well for Linux/Mesa since the hardware is the same and the software works mostly equivalently. And should some decisions not work well, it is technically trivial to provide an alternative API. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
