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

[marek]

Regarding nVidia, people have reported higher performance with GalliumNine+nouveau than with wined3d+proprietary driver, so I don't think the proprietary driver will always be the best choice from now on.

GalliumNine is for D3D9 only. Other D3D versions use the standard wine code. If GalliumNine cannot be used for some reason (missing driver etc.), wined3d is used as a fallback. The Wine modifications are harmless for people who don't have a Gallium driver.

With all respect to wined3d developers, I think OpenGL isn't a good middle-API for D3D gaming because of technical reasons.

[zanny]

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.

All the free software ARM GPU drivers use Gallium. There is a third party Intel driver based on Gallium. Really, the entirety of free software video drivers is coalescing behind gallium.

The thing with Intels driver is that a lot of it is 2d acceleration - once Wayland is firmly entrenched as the dominant display server, depreciating all the SNA etc code makes more sense since glamor makes more sense then, and the low level stuff is portable to Gallium, they just have to implement it in terms of winsys rather than opengl.

I mean yeah its a lot of work, but it is not impossible, especially with the community version already out and about.

[You-]

All the free software ARM GPU drivers use Gallium. There is a third party Intel driver based on Gallium. Really, the entirety of free software video drivers is coalescing behind gallium.

Useless for x86 unless there is an x86 to arm translator? (I am not sure how modern apps work)

I mean yeah its a lot of work, but it is not impossible, especially with the community version already out and about.

Having everyone work on one interface and making that the best evarrr is always good. unfortunately til now intel has stuck to classic and I wont make any guesses if/when they will change.

Anyway my main point was that when Gallium Nine does not work in all the places where the other code does, it is understandable why the wine devs dont want to jump ship. At the same time, while it increases complexity, allowing its use could result in good things (I can imaging a future linux with sandboxed apps - each app choosing its own sandbox runtime - gnome, androi or windows, and just working... via systemd)

[philcostin]

With all respect to wined3d developers, I think OpenGL isn't a good middle-API for D3D gaming because of technical reasons.

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.

[dungeon]

Some statistics:

In June we had 500 games on steam, now are just 5 less to be 800 games that is nearly 2 games per day rate, so in Feb next year we will probably have 1K games there, etc...

We have 60% games now!!! compared to number of games for Mac on steam .

Soray for offtopic, just friendly reminder i just prefer native games +- preferably 64bit ones if i can choose, just because of the bright future for this platform

[DMJC]

I'm still waiting on Directx 4/5 to be implemented in wine. Forget DirectX 9/10/11/12. The reality is DX9 runs fast enough for gaming already. If people want to write their own DX9/10/11/12 implementation for wine, they should fork and start writing the ifdef functions, and modifying winecfg to have options to turn it on/off. The code can then be merged back into wine's main branch. That is how Direct3D 9 support was originally added to wine and it worked really well. Demanding the wine developers do something is not going to make it happen. Stefan the project head likes to receive small incremental patches that add infrastructure by components and builds up to implementing major changes. Not just dumping a massive patch in that could have stolen Windows code or untested/broken codepaths which don't work, or only satisfy a few test cases. Wine is a serious engineering project.

[dungeon]

Some statistics:

In June we had 500 games on steam, now are just 5 less to be 800 games that is nearly 2 games per day rate, so in Feb next year we will probably have 1K games there, etc...

We have 60% games now!!! compared to number of games for Mac on steam .

Soray for offtopic, just friendly reminder i just prefer native games +- preferably 64bit ones if i can choose, just because of the bright future for this platform

If no one understood what i say there, this means according to that progressing rate there is high probability that Linux native games on steam will exceed number of games for Mac probably this time next year

So yeah there is no doubt to me people are completely wrong about this nine thingy, opensource drivers goes in wrong direction with it

[mike4]

Even in FSX FPS is no problem but many other things like clickable instruments etc.
Integrating Gallium probably opens another can of bugs...
MS should opensource also DirectX like they did with net.

[philcostin]

people are completely wrong about this nine thingy, opensource drivers goes in wrong direction with it

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.

[crispy]

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.

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