On 15 November 2014 03:25, Henri Verbeet <hverb...@gmail.com> wrote: > On 14 November 2014 17:37, Ilia Mirkin <imir...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
