Wine 1.1.23 Released With Various Fixes

[blindfrog]

As of 1.1.23 we enable the use of framebuffer objects (FBOs) by default. This tends to be relatively buggy on ATI. Set the OffscreenRenderingMethod option to backbuffer to restore the old behavior. We don't intend to add a ATI check and fall back to backbuffer. FBOs are critical for supporting all D3D9 features and they are also critical for performance. The ATI drivers need heavy improvements in this area. Adding a ATI fallback would delay this only.

Well with wine 1.1.21, Fedora 10 (KDE 4.3b1 DE's on), Radeon HD 4850, catalyst 9.5. Half-Life 2 episode 2 works great with 1680x1050 Fullscreen, OffScreenRenderingMode=fbo and VideoRam=512(for some reason it's unstable without this).
No artifacts or anything! All the DX9 effects works (HDR...) and the performance is also very good (Everything is at their highest). Only thing that doesn't work is AA. Hopefully someday it'll work too, but all in i never thought this day would come and I am pretty happy now ...Catalyst 9.5 and wine 1.1.20 sure brought lot's of improvements here

Team Fortress 2 works horribly though (slow and some gfx glitches here and there) and locks up after 10-15 mins of playing. Weird...Shouldn't it be more "lightweight" than HL2EP2?

Odd but with 1.1.23 Steam games doesn't start anymore...I have to keep on running HL2 and HL2EP2 with 1.1.21.

[Henri]

Perhaps, but it looks like Wine's doing something a bit iffy. It appears to be attaching textures to FBOs with formats the specification explicitly forbids, apparently in the process of blindly trying all possible texture formats to see which can be attached. Something that fglrx should handle without crashing, certainly, but not exactly a normal or sane thing to do.

It's certainly the simplest way to figure out which formats are attachable. Granted, we can skip checking some formats because we already know the result, but it's not in itself a weird thing to do. That said, I do have a patch that avoids checking the formats in question. I expect it to go in in the next few days.

Also, if this was an NVidia driver bug, I really doubt Wine would do a release in the current state. They've broken all D3D apps under fglrx, since this test is done during D3D initialization. However, since fglrx is a second-class citizen in the Wine world...

I wouldn't have submitted that patch in that form if I'd known about the fglrx bug, of course. Fact is simply that I don't currently have an AMD card to test this stuff on, so typically I only hear about it once someone else runs into it. Also note that the "stabilization period" for the bi-weekly releases is really just a couple of hours between pushing the last commits and tagging the release. Wine running into this fglrx bug is unfortunate of course, but it's really not a matter of somehow caring more about nvidia users.

(Slightly OT, I have actually been thinking about getting one of the HD 48xx cards. Might be fun to have a go at the r700 driver now that the documentation is released.)

[mirv]

I agree in that on one hand, wine shouldn't be doing things out of spec to see what's handled and what's not, but then the fglrx driver shouldn't crash everything either.
Naturally, a fix in wine is useful, but in this case wine is also proving to be a good test bed. I doubt any wine devs would have patched & released things if they'd known it would break fglrx; same goes if they knew it would break nvidia drivers but not fglrx. As this bug in question has been found and worked around, then cheers to the fix!

[Henri]

I agree in that on one hand, wine shouldn't be doing things out of spec to see what's handled and what's not, but then the fglrx driver shouldn't crash everything either.

Just for the record (it doesn't matter much to the thread as a whole), but what Wine's doing is completely within the spec. The way EXT_framebuffer_object works is that you're always supposed to be able to attach a texture or renderbuffer to an FBO, but any specific configuration may not be "framebuffer complete" due to implementation specific restrictions. CheckFramebufferStatus() is the only way to determine if a configuration is valid (see also issue 12 in the EXT_framebuffer_object spec). It's true that section 4.4.4 specifies that depth formats and compressed formats are never color-renderable, but there's no reason you shouldn't be allowed to attach them to an FBO and call CheckFramebufferStatus(). The spec just guarantees that CheckFramebufferStatus() returns FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT if you do.

[mirv]

Ah, you're right, my apologies.