Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

[asdfblah]

Wasn't there also a DX10/11 state tracker? What if someone updates that? We would have complete support...

[dungeon]

It won't be a long term thing - but medium term, I can see some existing engines maybe using nine as part of the porting process - but only if Gallium3D becomes pretty much standard - I guess it depends on whichever happens first.

No one will use that for porting process if it is maded somewhat good, game developers will just stop porting anything...

...............

BTW, i see all wrong reasons about it and all reasons i can imagine... yeah even performance is unconvincing to me And even if wine developers starts to be convinced by it and somehow happily accepted it... that is again all wrong for linux.

Of course i understand people like performance in some tested games, that is only thing that looks good because overall it is good to see somewhat better performance when anything else does not matter, blah, blah... but when anything or just something *does* matter, even that and all other reasons are mad reasons someone wants to do for the platform, it simply works against it

[log0]

Correct me if I am wrong, but from my understanding, nobody is asking Wine guys to drop their current d3d code. They can keep fiddling with it until the hell freezes over. The request is to merge optional support for this Nine stuff.

[mannerov]

yeah even performance is unconvincing to me

Can you share examples ?

Correct me if I am wrong, but from my understanding, nobody is asking Wine guys to drop their current d3d code. They can keep fiddling with it until the hell freezes over. The request is to merge optional support for this Nine stuff.

Yes, and they wouldn't have to maintain it.

[darkbasic]

I'm curious what kind of performance gain you'll realize by using native Direct3D as oppsed to the Command Stream patchset, which is something I've used in my Crossover 14 and patched versions of Wine 1.7.24 via PlayOnLinux.

Nine beats CSMT: http://www.linuxsystems.it/2014/09/w...e-vs-catalyst/

[V10lator]

What if there is a D3D10 state tracker that comes along? How would /that/ then fit into the picture.. etc, etc.

Wasn't there a d3d10/11 state tracker but it was unmaintained and as a result broken and removed from mesa? Found it: https://github.com/skeggsb/Mesa/tree...trackers/d3d1x

while patches continue to be available for wine, why not just apply them yourself? Sounds like a fine solution to me

So you tell us to take the source and patch it, but we shouldn't fork?

Aren't the patched PPAs technically forks? Why do you want thousands of private (end-user and PPA) forks instead of a single repository? What would be so bad about forking? When the mesa guys decide to merge the Gallium3D patches it would be a merge between mesa and the fork, as a result the fork would die anyway (if it hasn't any other advantages than using gallium nine).

Except its the same issue as with using it in wine - not all graphics configurations can use GalliumNine, so the developers will have to make some OpenGL code instead...

Yea, native games should avoid it. But for games already ported it could be a good thing. For example Valve games are using togl which I'm sure could benefit from gallium nine, another examples is eON (the Withcher 2, eON may be the worst wrapper we've ever seen, even using the Winows version in Wine is faster, so gallium nine might give it a huge FPS boost). I'm sure there are other games using a d3d to opengl wrapper.

No one will use that for porting process if it is maded somewhat good, game developers will just stop porting anything...

So why are they porting right now? Why aren't they using things like Wine and (except for the Witcher 2) eON? Also: Did you realize that many(most?) ports are using a d3d9 to OpenGL wrapper? I'm not sure about that, so correct me if I'm wrong, but IIRC even the Unity engine is using a wrapper for non-Windows (or Windows with -force-opengl) platforms.

[souenzzo]

1- Gallium developers have a hard work to implement DX9
2- Wine USES DX9
3- Mesa and propritetary developers have a easy work to read gallium code and implement DX9
4- Everybody is happy

[marek]

There's no doubt that you are right there - and GalliumNine is a step in the right direction. However, I can see it being used more for native Linux games ported from windows than wine (at the moment) although no doubt wine will eventually plumb their layer down into TGSI instructions using GalliumNine as a partial reference, eventually.

I don't think so. Adding TGSI into OpenGL doesn't fix other problems with OpenGL.

[artivision]

I don't think so. Adding TGSI into OpenGL doesn't fix other problems with OpenGL.

I think he means instead of HLSL to GLSL, HLSL to TGSI (like HLSL to NV_GL_Assembly). Anyway my Radeon-6870 with Nine rocks.

[philcostin]

So you tell us to take the source and patch it, but we shouldn't fork?

Whoa, whoa whoa!

I didn't say that nobody should fork.

Why do people assume that other people are "taking a side in the debate" or something? This isn't a two-sided argument, you know. It's not BSD vs GPL. It's not systemd-vs-init.

Chill.

Fork it if you like. You'll have to look after keeping it up to date yourself, though.