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

[Dave Airlie]

On 15 November 2014 03:25, Henri Verbeet <hverbeet at gmail.com> wrote:
> 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.

It seems like a bad example, maybe someone could actually figure out
why wine is slower,


>From my experience, its rarely been compiler optimisations that make
a single massive difference, its probably something more architectural
with having mismatches at other levels in the APIs and overheads
of recompiling shaders.

Dave.