http://bugs.winehq.org/show_bug.cgi?id=12453
--- Comment #20 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-02-18 08:09:18 --- A build of GIT head (bd69c2e) produces a continuous output of the following (with different addresses) from Warhammer Online
fixme:d3d_surface:IWineD3DSurfaceImpl_LoadLocation 0x6831818: Downloading rgb texture to reload it as srgb
I also see: fixme:d3d_surface:surface_load_ds_location (0x162860) Not supported with fixed up depth stencil occasionally, followed by a few GL_OUT_OF_MEMORY errors, every time a certain address reports the first error in this comment.
Reducing available texture memory to 128MB doesn't fix the GL_OUT_OF_MEMORY errors, but switching OffScreenRenderingMode from fbo to backbuffer did make the latter error disappear. In all combinations of these two changes the first error in this comment occurred a lot.
I can't speak for its performance compared to before the patch either.
If I'm skimming the code correctly, the issue causing this is that the texture has been uploaded as an RGB texture and removed from system memory (or was never there... I don't know if that can happen under Direct3D) and now is being asked for an an SRGB texture, so has to pull the RGB texture down into system memory and upload it again as SRGB.
I'm not sure that this is not due to Warhammer Online shuffling textures around due to low video memory availability (256MB card) since the only other machine I have access to for Warhammer Online under Wine dereferences a NULL inside WAR.exe (chasing that up with EA support separately) before getting as far as rendering. That would mean that the patch is fine as it is, but the minimum video card memory for games that use textures in both RGB and SRGB from the same sampler turns out to be much higher under Wine than Windows. That's prolly worth noting somewhere.
It might be useful to also have an updated patch that disables changing the SRGB-ness of a sampler after the texture is loaded. (Which is what the patch on the Warhammer AppDB page effectively does) Bizarrely, as I recall that looked correct under Warhammer Online, suggesting that all the textures were being loaded correctly the first time, and then having their state switched repeatedly but were only ever rendered in the right state.
I wonder if it's possible to delay the re-upload of a texture until closer to rendering, to catch what I'm guessing is a sampler change that happens twice per frame... (I really should test this)