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

[Henri Verbeet]

On 14 November 2014 17:37, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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.
>
Fixed-function hardware is becoming less and less relevant, but on the
other hand we try to avoid breaking things that currently work. But
yes, that's certainly something that's interesting to see how it turns
out.

>> 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.
Well yes, but the issues tend to be things like those solved by
ARB_clip_control, ARB_vertex_array_bgra, ARB_provoking_vertex, etc.

> 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.
Yes, but that's much more limited in scope than replacing all of OpenGL.

> 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.
It was just an example, but at least in the past I've seen for example
the translation for D3D cnd and cmp result in pretty sub-optimal code
in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps
make it easier for the driver to end up with something reasonable. But
not knowing where the actual differences/advantages are is a large
part of what makes it hard to discuss st/nine in concrete terms from a
Wine perspective.

> 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?
>
Probably not. For what it's worth, while I think the approach of doing
the analysis mentioned above will ultimately have better results both
for Wine and other GL applications, I realise very well that that's
real work and not necessarily a lot of fun.