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

[philcostin]

Yep, it can be annoying when someone puts thousands of hours into a project which gets destroyed by another, smaller project (in terms of compability and performance).

If they don't want to merge GalliumNine, fuck them, like someone has said, time to fork

Look at it this way:

WineD3D: D3D7, D3D8, D3D9, D3D10 (almost) D3D11 (some of, I think)

GalliumNine: D3D9 only.

I mean sure, it's fast and sure, people saw it coming - but it's not reasonable to expect the devs to drop their tools on the floor before they're done (don't forget, while some are paid by codeweavers, for others it is a hobby and they've got a plan in mind. When a developer has a plan in-mind, you can't just tap him on the shoulder and offer him a working, fast, good-enough-for-you "thing". A: He's busy. B: Just getting his head around what you've put under his nose will require dropping what he's already doing, when he's almost there anyway.)

They will adopt it, I'm sure, but just because it works with a few patches, don't assume the wine devs will want to chuck their plans straight out the window and focus on ONLY D3D9.

[mannerov]

I can use nine for d3d9 and use wine for everything else...

[philcostin]

As an extension to my other post, although I mentioned that it's not easy for that kind of an inbound change when you're already invested in something, I don't want to put across the idea that the wined3d developers really are desperate to hang on to old code - good developers (like them) will already know that "you are not your code" - but want to clarify that I was empathizing with the situation.

And sure - while patches continue to be available for wine, why not just apply them yourself? Sounds like a fine solution to me, and when the wine devs feel they are ready, maybe they'll merge bits of it as necessary as time goes by.

[zanny]

WineD3D: D3D7, D3D8, D3D9, D3D10 (almost) D3D11 (some of, I think)

GalliumNine: D3D9 only.

Maybe they could look at some of the gstreamer plugin code. The way hardware decoding can be used when available but there is an entire cascade of fallbacks when needed. You could just gall galliumnine the "hardware acceleration" of Wine.

The way it should work is: Try the Gallium Native Call -> doesn't exist / didn't work? -> translate to OpenGL. And that should apply in general, it is the same class of problem as software fallback when an OGL function does not work or is not provided with driver support.

[Azrael5]

Excellent.... DirectX 9 implementation!!!

[Commander]

When, like 3 years from now? They've been working on CSMT for years now and its been in CrossOver for a while now. Didn't they say they plan to scrap CSMT and make a new improved something?

Yea no I'm going to continue to use patched versions of wine that have gallium and CSMT in it.

They are waiting on CSMT because they are rethinking how the implementation should be with d3d10 etc.. Give them time to make it work correctly and not be a hack like it currently is.

[You-]

GalliumNine... would be used outside AMD graphics cards?

With nVidia I suspect for performance people use the proprietory driver.

intel doesnt use gallium at all.

While I would want them to create integration points for this state tracker, I dont think they can move over to it totally - just allow it as an option.

It wont reduce their work and those asking for a fork in thsi thread should go ahead and make a fork if they want it that badly.

[eydee]

They are waiting on CSMT because they are rethinking how the implementation should be with d3d10 etc.. Give them time to make it work correctly and not be a hack like it currently is.

Give them time? DX10 games are already outdated. The whole thing will end up like reactos, where you can run a win95 clone in 2014...

[geearf]

GalliumNine... would be used outside AMD graphics cards?

With nVidia I suspect for performance people use the proprietory driver.

intel doesnt use gallium at all.

While I would want them to create integration points for this state tracker, I dont think they can move over to it totally - just allow it as an option.

It wont reduce their work and those asking for a fork in thsi thread should go ahead and make a fork if they want it that badly.

Non AMD (or nouveau) based could use this:

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.

[liam]

They are waiting on CSMT because they are rethinking how the implementation should be with d3d10 etc.. Give them time to make it work correctly and not be a hack like it currently is.

My understanding is that they've been working on command streams for a long time. The concern, I think, is that gallium seems to have demonstrated a new solution path for a certain class of users (to me, that is the only serious criticism of employing g3d9). Said path appears to have outstripped the wine devs efforts but with far less effort (I understand that g3d9 doesn't have nearly the coverage as wine's, but at this stage that's fine).
It appears that gallium is the proper part of the stack to handle this problem, even though it only handles a subset of cards. The amount of code the wine developers could drop as a result of this would be substantial, but they'd lose their solution's more generic features.

IMHO, gd3d9 needs to fully track d3d9, and a proof of concept for gd3d10 should be written to verify that the solution provides similar gains there. If that succeeds THEN the wine devs should seriously consider incorporating the work, even if it means two d3d solutions need be maintained (the gallium solution, I'd imagine would need little maintenance from their end aside from keeping up with the changes made).