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

[Ilia Mirkin]

On Fri, Nov 14, 2014 at 11:15 AM, 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.)

Dave Airlie's virgl work is creating a gallium "driver" which actually
uses OpenGL for "hardware". I'm not sure how far he is, but I believe
he has enough for GL3. This could be a way forward towards *only*
using gallium (since otherwise you'd still have to have an
OpenGL-based backend for the hw/platforms that don't have gallium
drivers). However gallium will never support fixed-function hardware,
so that may still not work for you.

>
> 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.

While I don't have this justification, I always just assumed this was
due to mismatches between how d3d wanted to do things and how OpenGL
let you do things, so you ended up having to do some fairly
heavy-handed things in OpenGL solely due to the silliness of the API.
Let's say that all such things could be identified and extensions
created for, you'd still end up effectively managing 2 backends -- one
that assumes that the various d3d-helper extensions are there, and one
that doesn't. I strongly doubt that the performance increases are due
to better d3d9 bytecode -> TGSI conversion than -> glsl -> tgsi
conversion -- most serious backends (r600, radeonsi, nouveau) have
optimizing compilers that should take care of such issues. They won't,
however, take care of issues where you had to change the way resources
are managed, the data passed to the GPU, etc.

Anyways, from your comments it sounds like the only way forward and
given the current capabilities of nine/st would be to create some sort
of out-of-tree solution that plugs into wine, providing "native"
d3d9.dll or whatever it's called. That way you guys aren't stuck
maintaining 2 backends, and people can get improved performance on
d3d9 games on linux.

Henri, if you take the fact that people want to use nine/st in its
~current form on linux as a given, is there a different, simpler
approach that I'm overlooking?

Cheers,

  -ilia