Bug 55396

Is the CPU busy?  If so, using sysprof may help point out where the problem is.  (more generally: http://dri.freedesktop.org/wiki/IntelPerformanceTuning).

The main problem we know of with wine on that hardware is how it likes to blit depth and stencil buffers -- it'll be hard for us to improve that without porting the blorp code back to older hw.

CPU is busy. In attachment logs from top and sysprof, using:

sysprof-cli filename

when game is running.

I still have the same problem with:
mesa 9.1~git20121020 from xorg-edgers repository
xserver-xorg-video-intel 2.20.9
kernel 3.5.5
libdrm 2.4.33

Created attachment 68991 [details]
top.log

Created attachment 68992 [details]
sysprof.log

Oh, sysprof isn't useful if you don't have debug symbols for the libraries where the time is being spent :)

I have in repositories dbg packages, which are installed in /usr/lib/debug/usr/lib/i386-linux-gnu/

How to run mesa in debug mode? Should I use any environment variables?

Created attachment 69388 [details]
sysprof with debug

I compiled manually mesa 8.0.5 with --enable-debug and use LIBGL_DRIVERS_PATH variable.

In attachment is tar.bz2 archive with several attempts to create sysprof log.

I hope it will be useful to you.

Still exist in 9.1~git20121110

Do you need other info in addition to sysprof?

Still not getting callgraphs, which is weird.  Maybe wine angers it somehow, I dunno.  You're in some sort of sw fallback code, and you're unpacking (reading) color values, so it's not the depth/stencil issue I knew of.  Just breakpointing on that function if possible may tell.

I tried run game with LIBGL_DEBUG=verbose and MESA_DEBUG=verbose but I got only information about missing /etc/drirc file.

Somebody is writing about this bug in Counter Strike:
http://people.freedesktop.org/~cbrill/dri-log//dri-devel-2012-03-17.log
"14:53 #dri-devel: < mattst88> why would my profile of counter strike source in wine show that wine was spending 30% of its time in unpack_ARGB8888?"

I also have it in Need for Speed Most Wanted and Star Wars JK Jedi Academy in multiplayer mode - also unpack_ARGB8888 is near to 100% in sysprof.

I'm open to do other tests, but I'm not experienced programmer. If you would like to get other iformation, I will be happy if you write more or less how to do it.

Btw. first verion working badly was probably mesa 8.0. Maybe I will try git bisect?

git bisect good mesa-7.11.2
git bisect bad mesa-8.0-rc1



9e9a76eea17bc92c8ac74323c99e10b9480ee583 is the first bad commit
commit 9e9a76eea17bc92c8ac74323c99e10b9480ee583
Author: Brian Paul <brianp@vmware.com>
Date:   Wed Sep 21 18:54:53 2011 -0600

    mesa: remove support for GL_APPLE_client_storage extension
    
    AFAIK, there are few users of this extension and I can see a couple
    reasons why this is probably broken in Mesa anyway.
    
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

:040000 040000 7e235da32324236030c2596dc1b0ae20688962b2 00f04a5d8bc981a0deb00164b40858ba6aac432a M      docs
:040000 040000 e5d82f8a7bffe93c4b040c299e4ac821d4f7fef7 cd764dd5ea1e87c7dc3a72a99fa64b151a1665d1 M      src

After reverse changes from this commit, it works smoothly. I really don't know what have APPLE function to Linux system, but it's needed in my case. Now I have mesa 9.0.1 with changes as in attached file.

Created attachment 70313 [details] [review]
Patch to mesa 9.0.1

Other problem is with Star Wars Jedi Academy, so I created new bug:
https://bugs.freedesktop.org/show_bug.cgi?id=57338

Note how that commit doesn't actually do anything different based on client storage.  So it must be that wine is doing something painful when the extension isn't exposed... except the Henri Verbeet (wine dev) says that they don't really rely on client storage for performance because nobody but apple exposes it (it was never a good idea).

Created attachment 73719 [details]
sysprof.log

I created probably more useful sysprof.log. 

Also after use MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode", game runs smoothly (thanks for Henri Verbeet).

Created attachment 73720 [details] [review]
Also match sRGB formats in _mesa_format_matches_format_and_type().

Does this patch also help? I think it should be correct, but I didn't really test it or review it very carefully.

I have the same like without patches. Anything better.

(In reply to comment #19)
> I have the same like without patches. Anything better.

I'm not sure what you're saying here, although I suspect you mean the patch doesn't help. It's a bit hard to write patches blindly, but perhaps it can be a useful hint for someone else.

Yes, patches don't help. Run games with and without patches have the same effect.

Does _mesa_GetTexImage show up in the profile before Brian's change?  If not, then it really looks like wine is doing something wrong to start calling glGetTexImage -- GetTexImage is really slow on that chipset, and there's not much we can do.  (We can get some win with a bunch of work if you have a core2 cpu, but performance will never be actually "good" while it's being called)

Created attachment 74338 [details]
sysprof-7.11.2.log

Sysprof from mesa 7.11.2, where everything is ok. To create log I used wine 1.5.21. I don't see GetTexImage there.


Mesa compiled with:
./configure --with-dri-drivers=i965 --with-gallium-drivers="" --enable-debug

Then,
export LIBGL_DRIVERS_PATH=/home/Dokumenty/linux/mesa-7.11.2/lib
export LD_LIBRARY_PATH=/home/Dokumenty/linux/mesa-7.11.2/lib
export LIBGL_DEBUG=1

That's short messages, so I'm not adding attachments.

After this debug patch:

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..679646d 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -664,6 +664,8 @@ _mesa_get_teximage(struct gl_context *ctx,
       get_tex_ycbcr(ctx, dimensions, format, type, pixels, texImage);
    }
    else {
+      fprintf(stderr, "Using slow texture readback for format %#x, type %#x, and internal format %#x.\n",
+            format, type, texImage->TexFormat);
       get_tex_rgba(ctx, dimensions, format, type, pixels, texImage);
    }



I got this messages in Sims 3 intro:

Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.
Using slow texture readback for format 0x1909, type 0x1401, and internal format 0x30.



mesa 9.2-devel

(In reply to comment #24)
> Using slow texture readback for format 0x1909, type 0x1401, and internal
> format 0x30.

I suppose that makes sense at least. If I'm reading that correctly it's reading back a GL_SLUMINANCE8_EXT texture that using MESA_FORMAT_SARGB8 as internal format instead of MESA_FORMAT_SL8. And if I'm reading the i965 source correctly that's because BRW_SURFACEFORMAT_L8_UNORM_SRGB isn't supported on your hardware.

After run Sims 3, wine shows these lines in logs:

fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified.
fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified.

Maybe there is a problem? It's shown also in Star Wars Jedi Academy (bug 57338).


Mesa from git c95177ea8897f80f153660119abb1750cb3eca70

Does INTEL_DEBUG=perf say anything interesting during the slow part?  I may have been thrown off the trail by the lack of callgraphcs.  Also, make sure you're using the AlwaysOffscreen flag, which was apparently enabled by default in recent wine and massively improves performance.

Dear Reporter,

This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested.

Thank you.