[Bug 19412] Red Alert 3: fails to render a character

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=19412


Stefan Dösinger <stefandoesinger at gmx.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




--- Comment #16 from Stefan Dösinger <stefandoesinger at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.