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

[Emil Velikov]

On 14/11/14 14:14, Emil Velikov wrote:
> On 02/11/14 18:27, David Heidelberg wrote:
>> Hello everyone!
>>
>> First I'd like thank you for great feedback.
>> Sending third Gallium Nine merge request. We reduced number of commits
>> to necessary minimum. I hope all proposed changes are incorporated in v3.
>>
>> Thank you
>>

To summarise:


 - Interface
Afaict reusing gallium or wined3d internal interface is not an option
for either project.


 - Two implementations
On 14/11/14 16:15, Henri Verbeet wrote:
> The main issue is probably that we'd really like to avoid having two
> parallel implementations of the high-level d3d9 stuff.
>
Indeed yet I don't think that anyone will be too happy to remove the
existing one, and with nine using a completely different approach it
only makes sense to have it alongside the more mature wine d3d.


 - Performance
While I'm not an OpenGL/Direct3D expert, the idea of jumping over one
hurdle (d3d > hardware) as opposed to two (D3D > OpenGL > hardware) is
always a win. I believe Marek nicely pointed the technical reasons.


 - GL extensions
I feel that it's a bit too much to shoot the project down, because it
does not introduce GL extensions that will be useful. After all the it
aims to tackle the whole topic from a completely different angle. If you
would like to propose new extensions, I don't think mesa devs will object.


 - Nine vs wine's d3d
While not explicitly stated, there is a concern about using nine over
wine's d3d library.
Note that one has to _explicitly_ opt-in to use nine, with a fall-back
to wine and also it does not hinder wine's d3d9,10,11... in any way.


Henri,

Considering the interface note able, would you say that any new
implementation towards handling D3D9 in wine is acceptable ? Please note
that I'm not talking about improving the existing one be that via GL
extensions or otherwise.

How about if such an implementation is disabled by default in the build,
and people have to explicitly opt to (via regedit) use it ? A one that
falls back to wine, when it does not work (missing driver or otherwise)
and does not hinder your d3d10/d3d11 efforts ?

If you're concerned about it's maintenance, I'm pretty sure that one of
the guys can step in. If it's about wine <> mesa(nine) interface I would
assume that the guys would love to hear your feedback (within reason of
course).

Lastly let's point out that there is a reason why we keep on talking
about this - significant performance improvement [1] [2]. One that
surpasses wine+CSMT and in some cases even the official/binary drivers
on top of it.


Can we work together so that both project benefit from this effort ?


Thanks
Emil


[1]
http://www.linuxsystems.it/2014/09/wine-vanilla-vs-csmt-d3dstream-vs-gallium-nine-vs-catalyst/
[2] https://www.youtube.com/playlist?list=PLfaZPGij0wwI69Bce1sbjLlcwRMWINYNy