On Thu, Apr 1, 2010 at 1:32 AM, Luca Barbieri <luca.barbi...@gmail.com> wrote: >> 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.
Is it really so surprising that an API designed to expose a generic, programmable, shaderful pipeline (Gallium) fits well to multiple APIs based on the same concept (D3D10, OGL 2.x)? -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
