http://bugs.winehq.org/show_bug.cgi?id=19412
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #16 from Stefan Dösinger stefandoesinger@gmx.at 2009-07-29 05:19:07 --- Disabling client storage is not that easy either, I originally added it to work around bugs in the Mac GL driver, and to gain a few megabytes of address space.
The problem is that I don't know enough about the nature of the bugs worked around with client storage. When I added it 2 or 3 years ago, the symptom was random texture loss. By now I have broken down the texture loss bug into a few separate issues that cause the same symptoms and reported them to Apple. Apple might have fixed some problems too, but I don't know how many remain.
Since Radar reports are not publically accessible I'll dump a few details here:
6965386: glGetCompressedTexImage fails on srgb compressed textures Reproduced on a GMA X3100 and Radeon X1600, so probably a bug in the general framework. Wine by default releases resource->HeapMemory after loading the GL texture, and loads the GL texture back if it needs it(unless this happens all the time, then wine keeps the copy). The client storage code happens to work around this bug because the heapMemory copy is never released. The use of the GL extension doesn't have anything to do with the workaround, its just a different behavior of the wine code that does this.
???????: glTexImage2D with NULL pointers fails. Maybe that's the bug I worked around originally with client storage, but I am not entirely sure. Its also a by luck workaround, since just always passing a valid pointer to glTexImage2D is enough, you don't have to use client storage. I think I reported this to apple, but I can't find it in my radar list atm. (No sRGB textures or compression involved here, fwiw)
6958082: glCompressedTexSubImage2D fails with sRGB compressed textures Only partially related, but that's one of the reasons why we can't use compressedTexSubImage. Reproduced on a GMA X3100, but maybe affects other cards too.
???????: compressed sRGB textures fail with client storage. That one was reported by Ken, so I can't look up the number. It is fixed in Snow Leopard, and actually an argument against using client storage. Just including it here for completeness. The bug results in a div by zero exception in the GL code.
The phantom menace bug is a random texture loss without actually doing anything with the texture. You load it, it works for a while, and boom, it is random garbage. My suspicion is that this happens when the texture is not used for a while, paged out of video memory and reloaded. Either OSX mismanages the backup copy, or fails to download it due to VM pressure, I don't know. People from Transgaming also say they see this bug, so I am not hallucinating. It is possible that this was fixed in Leopard. I saw it in Tiger, but TG claims it still exists even in Snow Leopard. The real-life symptom is that e.g. in HL2, you look at a scene, it looks fine. You turn around, shoot a few zombies, everything's ok. You turn around again, look at the original scene, and walls are complete garbage. Textures can turn into garbage while you look at them too, but that's comparably rare. The garbage can look like this for example: http://stud4.tuwien.ac.at/~e0526822/hl2_texture_1.jpg
Using client storage works around this issue.
The other reason for using client storage is to move the backup copy into VM areas managed by Wine, thus reducing the pressure in the small address space areas Wine does not have to block. However, we probably have enough leeway to disable client storage for selected textures.
There are a few PBO related bugs too, but those should be fixed by now. One of those bugs affected geforce 8 cards(texture uploads just fail with PBOs - the extension was just broken). This bug was fixed I think in 10.5.4. Then there was 5829994 - glRasterPos and glPixelZoom were ignored with PBos in glDrawPixels. Unrelated to client storage, and fixed a while ago as well. I think both bugs are still present in Tiger though, but I don't care about Tiger any longer.
I think we should find out more about this issue, for example where the heap errors come from. I prefer to disable PBOs on compressed textures if client storage is used, rather than the other way around. And what's also worth testing is where the error exactly comes from. Ie, does it happen just by using PBOs+Client storage, or is it the NULL pointer that's passed in if a PBO is used? glTexImage2D + Client storage + NULL pointer -> error, even though the extension specifically says that no additional errors should be generated, and if the driver can't use client storage it should just not use it, even if enabled.
I recommend to touch OSX only with a hazmat suit, and if I wasn't paid by codeweavers to care for it I probably wouldn't care for it at all. There are a few more workarounds for OSX bugs in CrossOver Games. If you're interested in them you can download the cxgames wine tree source and diff it against the Wine version it was branched from.