Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

[MuPuF]

It's been a while since we switched to 1.20 shaders, but IIRC we use some array features that aren't in 1.10, and since making that switch we've also started to depend on gl_FragData[] being available regardless of ARB_draw_buffers.

My impression from the list of changes between 1.10 and 1.20 is that most (all?) of the changes are grammar changes that shouldn't have all that much impact on the resulting TGSI. Since Mesa's GLSL parser seems to understand 1.20 it's not entirely clear to me why r600/radeon doesn't support it. I did ask about that in #radeon, but didn't get anything more concrete than something along the lines of "the driver doesn't support it".

I'm not sure if using GLSL with Wine on r600/r700 would be an advantage at this point though. For reasons mostly related to the way d3d9 works, wined3d creates shaders that declare more uniforms than the GL implementation reports as supported, and then depends on the GLSL compiler to be smart enough to figure out which ones are actually used. AFAIK this work for both fglrx and nvidia, but not so much for Mesa. What's perhaps worse is that instead of failing to compile the shader r600/r700 seems to silently drop any uniforms past the supported ones. Typically that results in things being either misrendered or not rendered at all, without much to go on in terms of GL errors or GLSL infolog contents.

I also ran across some memory corruption when using GLSL, I think due to pAsm->starting_export_register_number being larger than pAsm->D.dst.reg somewhere, resulting in writing to pAsm->pucOutMask[-1], which then corrupts internal glibc memory management structures. Unfortunately I haven't gotten around to properly tracking that down yet, due to other priorities/responsibilities.

For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.

I thought wine developers wouldn't care about mesa but I was obviously wrong.
I hope mesa & wine developers would work hand-in-hand towards useful graphic drivers.
Wine developers obviously know which functions are pretty useful, mesa developers may be interested in a top lacking-feature list.

Doing this could also allow performance-enthusiasts people to actually try the open source driver.

[whizse]

I have been able to run quite a few games with Wine with the i965 driver, which supports GLSL 1.20. Not sure what's the best testcase for d3d9, but it's possible to run 3DMark 06.

Performance is unsurprisingly a major problem, but that's something I hope ATIs hardware can address

[PsynoKhi0]

For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.

I might as well take the opportunity to ask:
To what extent are wine development releases tested on ATI hardware with fglrx?

It might be a communication issue but I get the feeling Radeon owners are pretty much treated as second-rate users and served the "It's a fglrx problem" copy/paste as a way to avoid investigating the actual cause of the hickups.

I understand that a few years ago ATI's binary driver was too much a hassle to bother with, so I wonder if the "screw this" mindset is still influencing wine devs without a second thought.

Personally I've had problems with anything 3D past 1.1.37 in apps listed in the platinum top 10, problems which nature makes me wonder how this could even get pushed out of the door in that state.

Of course regression testing is welcome and encouraged by the wine team, and I understand development releases are prone to breakage, however the obviousness of the graphical glitches combined with that nagging feeling of "blame fglrx" being a reflex makes the whole process daunting.

Again, it's a feeling I get so you're more than welcome to prove me wrong.

[V!NCENT]

Wine has always been a bloody pain in the back.

No matter what game I run (I have an entire book 'clouset' filled with them) it never, ever, ever works out of the box with Wine. The same goes for desktop apps, except for WinRAR, which you need for cracks.

It isn't that the Wine devs aren't doing a great job; on the contrary; when something works it work with the most complex 3D tech and shaders and all that, but it's always these tiny problems that screw the entire use of Wine in most cases.

For example: allmost all gamers that play online games have a headset. In the Windows world, almost everyone uses Ventrilo, which is a low latency group VOIP client. It works for 100% correctly, but there is one tiny stupid bug that renders the entire app useless: the hotkey push-to-talk doesn't work when it is out of focus. And guess what? When your playing a game, Ventrilo is always out of focus.

Another example: Carmageddon TDR2000 aka the Death Race works completely out of the box, even with copy protection (and it doesn't work on Windows anymore starting with Windows XP) and it works for 100% correctly on Wine, but the config app that runs before TDR2000 runs cannot detect the presence of a graphics card so it makes the game run software only with the most uglhy graphics that you have ever seen! There is a workaround where you can just manually edit the config file so it thinks it has already detected a Direct3D compatible graphics card and it runs like a charm (yay!), but it doesn't do that for newbies.

If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.

And that's the point anyways...

If only all Wine devs got together and decided

[Adriano ML]

man, stop whining! this is open source software, you know, people develop things as they see fit. And most wine developers are already occupied implementing a handful of windows functions. Also, codeweavers can't support every game/app. Wine will stay pretty much unstalbe until version 2.0.

But, if you're a geek like me, you can fiddle with every wine release, every wine tweak and have a lot of windows games work with little flaws.

[Adriano ML]

it's really cool to do this by using q4wine, creating your own separate wine bottles for each game, compiling your own patched wine, and making then breakable, unlike windows

[Joe Sixpack]

If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.

And that's the point anyways...

If only all Wine devs got together and decided

Sounds like pretty much every other OSS project to be honest. The question is what's considered to be a papercut and what's a serious problem? I'm guessing they are focusing mostly on D3D and DX9 related things. People get tired of papercuts because of the low level of excitement. So they'll switch to something more interesting just to keep from getting burned out.

Me personally - I'd much rather play an older game flawlessly (say Counter-Strike) than to have a new game that kinda works.

And for the love of God can they PLEASE fix this bug.

[Hephasteus]

wine do not support the radeon opensource driver (mesa7.7/7.8)

"wined3d: Don't use GLSL if the supported version isn't at least 1.20. "

yes very nice wine packages... (ironic)

If you think end of year linux releases will be using mesa 7.7 then you are living in a cave.

[Remco]

If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.

Another major release is coming up, so now would be the perfect time to suggest a "100 papercuts" on the Wine mailing list. I think it's a great idea.

[Remco]

I knew such a project was already in place: http://wiki.winehq.org/WineReleaseCriteria

You can nominate "small but embarassing" bugs as release criteria of Wine 1.2 (I wish they'd just call it Wine 2.0).