[Mesa-dev] [PATCH v3 0/9] Gallium Nine

[Marek Olšák]

While I agree it would be useful to have some D3D features in OpenGL
as extensions to facilitate porting D3D apps to GL, I don't think the
features would be very useful for playing Windows D3D games on Linux,
because I don't believe that translating D3D to GL is even an option
if you want performance. As a fallback, sure why not, but not as a
solution that everybody should use. We should take the shortest route
from D3D to hardware, skip all these useless translations between APIs
and driver interfaces which only add more cruft into shaders and
constant buffers and more state changes, resulting in more work for
the CPU and the GPU in the end, skip all the useless shader IRs
because D3D shaders are actually optimized to a certain degree by the
D3D shader compiler from the beginning and only need a hw-specific
shader backend.

No useless layers and shader IRs, no fallbacks, no workarounds for
missing features, no shader variants outside of the hw-specific code,
and straight to hardware, please.

Marek


On Fri, Nov 14, 2014 at 5:15 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> On 14 November 2014 16:36, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Is there a different form that you believe would be more likely to be merged?
>>
> The main issue is probably that we'd really like to avoid having two
> parallel implementations of the high-level d3d9 stuff. I.e., anything
> dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd
> potentially be open to using something closer to the Gallium interface
> instead of OpenGL on the backend in wined3d. In that scenario wined3d
> would essentially be the statetracker. The main issue with that
> approach has always been that the Gallium statetracker/driver
> interface isn't meant to be stable, and neither is the internal
> interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g.
> move wined3d into the Mesa tree either.)
>
> Another consideration is that while the Gallium interface is a better
> match than OpenGL for Direct3D in some places, I'm not necessarily
> convinced that that's something that couldn't be fixed with
> appropriate GL extensions. To give an example, it's possible that
> translating D3D bytecode to TGSI instead of GLSL ends up with better
> shader code for the hardware. Unfortunately that kind of analysis is
> completely missing as far as I'm aware, but if that were the case, it
> would probably be fixable by making some improvements to the GLSL
> compiler. If that's not possible for some reason we could consider
> adding an extension for authoring shaders in TGSI instead of GLSL, and
> so on. I guess the basic point is that replacing OpenGL is a pretty
> big hammer, that would need corresponding amounts of analysis and
> justification.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev