Gallium3D's Direct3D 9 Support Is Coming Along Well

[Dukenukemx]

Gallium Nine works great on AMD hardware. On Nvidia hardware it's hard to tell if it's even working.

I recently told someone about the magic of Wine-Nine and directed them towards the Sarnex/Oibaf PPA's but only has Intel for graphics. I think he can install ilo for Intel graphics but would it work? Don't have Intel graphics lying around.

[stefandoesinger]

First thanks for your work

Do you know if wine 1.8 release candidate phase begins in somewhere in 2015????

I cannot predict it yet. I certainly hope so. It depends on how fast Matteo and Henri come along with Direct2D and Direct3D10 or if the internal interfaces change so that I can start sending the CSMT patches. Whichever is finished first will trigger the release.

[duby229]

Their own implementation works decent over everything, GalliumD3D9 only works on Nouveau and Radeon. That cuts out all of us that run things of Intel GPU's or catalyst or want the full power of our Nvidia cards. They also know which parts work and on what systems other parts may not. Because this is a key piece of what Wine is used for, to default and rely on a set of software that is both out of their control programming wise and also out of their control as to what version an individual user might have is a little worrying. If the version the user needs is in Mesa 11.2 (to pick a future release) but the user only has mesa 11.0 then all they are going to see is wine not working and thus blame wine. The more power users will try and debug that stuff but speaking from experience it can take a while sometimes to figure out if a problem is part of wine or an external package.

what you're talking about is package management. Most Linux distro's do have good, well tested systems in place. If the packages have a competent maintainer that won't be a problem. It sounds like an excuse to me.

[duby229]

http://xkcd.com/285/

Can you point me to the code where we are doing special handling?

There are 3 pieces of vendor specific code in wine:

• dlls/wined3d/ati_fragment_shader.c: A fixed function fragment pipeline implementation based on GL_ATI_fragment_shader, ATI's version of Shader Model 1 shaders. Used on r200 cards.
• dlls/wined3d/nvidia_texture_shader.c: The Nvidia counterpart for Geforce 3/4 cards.
• dlls/wined3d/arb_program_shader.c: Has shader model 3 support via GL_NV_*_program. Disabled by default. Used to be ~10% faster than GLSL. Nvidia appears to have fixed their GLSL implementation, ARB's advantage is mostly gone. Can be used on AMD GPUs too, but has only Shader Model 2 support.

Nothing in there that explains the factor of 3 performance difference that also affect Linux native games between equal Nvidia and AMD GPUs on Linux, or the factor of 3 performance difference between AMD on Linux and AMD on Windows.

Writing your code on nvidia systems only, testing your code on nvidia systems only, using functions that only work on nvidia systems......

You can deny that, but it's what's been happening for years. The fact is, if you wanted to improve mesa performance, then you would. But you don't. You exclude those capabilities that do. because they only help mesa. If that isn't nvidia bias.

[duby229]

I don't get it... If other people are doing the work, and all you have to do is let it happen, why not let it happen?

EDIT: At this point, I don't think there is any choice but to advocate a fork. It's obvious that opinions aren't going to come to a middle ground. There isn't going to be a conclusion here. A fork is the only answer unfortunately.

[degasus]

Not that many of games are CPU-bound currently as they're mainly made for consoles with crappy CPUs.

To be fair it's a lot more interesting how Nine is perform against Windows. Sadly nobody made any proper benchmarking in that area yet.

Sorry, but you're wrong in both assumptions.
First, CPU bound doesn't mean that the game use much CPU internally. For graphics, it usually means that the a game is bottlenecked by the CPU overhead of the GPU driver. Especially for console ports where low level APIs are available and much slower GPUS compared to desktop are used. This happens very often in some years old games, especially if not the MS Direct3D stack is used. Both wine and nine D3D stack are slower compared to the original MS one.

And there was a benchmark in the wine presentation. They did agree that nine was faster than wine using the same gallium3d driver, but compared to both windows native and wine + nvidia blob, both are just slow as hell. In CPU bound games of course.

For heavily GPU bottlenecked games, it doesn't matter at all. There is no need for a fast API any more at all, only the shader performance does matter. So all of them has the same performance, or should have at least. If not, it's imo only the shader compiler to blame...


EDIT: @all those guys who just cry "fork": Who of you is going to develop wine itself? I don't see why the wine devs should care about random users at all. Welcome at Open Source. They care first about their needs, and they likely do know better what's better for them (and so also for all other users) in a long term. It's just mutation and selection. Do you think your fork will be more attractive for new developers? The one which is less attrative for them will just die.

[duby229]

EDIT: @all those guys who just cry "fork": Who of you is going to develop wine itself? I don't see why the wine devs should care about random users at all. Welcome at Open Source. They care first about their needs, and they likely do know better what's better for them (and so also for all other users) in a long term. It's just mutation and selection. Do you think your fork will be more attractive for new developers? The one which is less attrative for them will just die.

I really do completely understand where you're coming from. To be perfectly honest with you, I don't have the skills to do it. It won't be me, but I'd be willing to contribute to such a project if a competent person took it upon themself to do what needed done. That's why I'm advocating a fork. My hope is that enough other folks see the bias that I see and agree with me.

My point is, maybe there is enough people to accomplish such a thing.

[log0]

First, CPU bound doesn't mean that the game use much CPU internally. For graphics, it usually means that the a game is bottlenecked by the CPU overhead of the GPU driver.

A game can be perfectly CPU bound on its own. Not sure where you have this weird idea from that only the graphics driver part matters.

[duby229]

A game can be perfectly CPU bound on its own. Not sure where you have this weird idea from that only the graphics driver part matters.

Sins of a solar empire. Single threaded game, and very cpu bound. CSMT makes it unplayable, but it's too slow without it. Either way.

[degasus]

A game can be perfectly CPU bound on its own. Not sure where you have this weird idea from that only the graphics driver part matters.

Yeah, of course everyone is free to add more bottlenecks But regular CPU usage which is not within some emulated MS librarys does run with 100% speed on wine. And for the emulated APIs, I guess anything but graphics doesn't mind at all, at least for games. Sound, network, filesystem, ... are all just too easy to emulate.