[Bug 12453] Bad performance in Source based games

[wine-bugs at winehq.org]

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





--- Comment #20 from Paul "TBBle" Hampson <Paul.Hampson at 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)


-- 
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.