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

[Jose Fonseca]

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

Yes, I don't recommend gallium for that.

It sounds you want to design a WINE D3D9 DDI pretty much along the lines of the WDDM D3D9 DDI: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927(v=vs.85).aspx

Basically, the runtime is one, but there would be two implementations of that DDI. Runtime would do validation, keep copy of current state for application state queries, etc.

Jose

________________________________________
From: mesa-dev <mesa-dev-bounces at lists.freedesktop.org> on behalf of Henri Verbeet <hverbeet at gmail.com>
Sent: 14 November 2014 16:15
To: Ilia Mirkin
Cc: mesa-dev at lists.freedesktop.org; Emil Velikov; David Heidelberg
Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine

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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=o3EpupCH7razLQXx0J0R5qQH6tzqk37RKYUG-_pJTl0&s=35b52J3rqlzw27gT9LOmvCEHU8Vau408cZeCj5kRU1A&e=