[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #8 from Michel D?nzer 2011-12-06 09:19:44 PST --- (In reply to comment #7) > Now the performance thing seems solved. Great, resolving. > Should I rename this report or start a new one for the laggyness due to the > high variance of fps? The latter, if anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #8 from Michel Dänzer 2011-12-06 09:19:44 PST --- (In reply to comment #7) > Now the performance thing seems solved. Great, resolving. > Should I rename this report or start a new one for the laggyness due to the > high variance of fps? The latter, if anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #7 from almos 2011-11-18 07:51:26 PST --- (In reply to comment #6) > (In reply to comment #5) > > 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??) > > If so, the environment variable vblank_mode=0 should disable it. Numbers for 7.12-dev with vblank_mode=0: nvidia logo 100-300fps, menu 74-120fps, torlan 25-94 avg 57fps Now the performance thing seems solved. Should I rename this report or start a new one for the laggyness due to the high variance of fps? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #6 from Michel D?nzer 2011-11-18 07:25:27 PST --- (In reply to comment #5) > 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??) If so, the environment variable vblank_mode=0 should disable it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #5 from almos 2011-11-18 07:00:34 PST --- Now I compiled a 32bit r600g from mesa git on a 32 bit machine. The ad hoc benchmark results now with swapbufferwait disabled: 7.11: nvidia logo 200-300fps, menu 70-200fps, ons-torlan looking at tower 20-80 avg 50fps (all with high variance) 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??), menu 58fps, ons-torlan looking at tower 20-50 avg 30fps (high variance, but periodically sticks to 20fps for a couple of seconds) I can't do a proper benchmark run, as it needs a run config file, and the config reader code segfaults :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #4 from almos 2011-11-18 05:25:58 PST --- OK, now I found out the reason: I still haven't got used to my new 64bit system. ut2004 is 32 bit, and when I set LIBGL_DRIVERS_PATH libGL.so reverts to indirect rendering. Ouch. What's worse, crosscompiling to 32bit is currently FUBAR on debian. The linker doesn't find /usr/lib32/libstdc++.so.6, I have to manually symlink it to /usr/lib32/libstdc++.so. The things in ia32-libs package are ancient (like mesa 7.7, I had to get a 7.11 from the libgl1-mesa-dri i386 package). I couldn't compile wine, because something is wrong with unistd_32.h, and compiling mesa stops with this: /usr/bin/ld: skipping incompatible ../../auxiliary//libgallium.a when searching for -lgallium /usr/bin/ld: cannot find -lgallium collect2: ld returned 1 exit status I can't imagine what the problem could be, because all the object files in that archive are 32bit, so they should be compatible. Back to the topic: I turned off SwapbuffersWait, which raised the fps with mesa 7.11, but the high vairance remained. I'll try compiling a 32bit version of current mesa git somehow, and see if this problem still exists. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #7 from almos 2011-11-18 07:51:26 PST --- (In reply to comment #6) > (In reply to comment #5) > > 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??) > > If so, the environment variable vblank_mode=0 should disable it. Numbers for 7.12-dev with vblank_mode=0: nvidia logo 100-300fps, menu 74-120fps, torlan 25-94 avg 57fps Now the performance thing seems solved. Should I rename this report or start a new one for the laggyness due to the high variance of fps? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #6 from Michel Dänzer 2011-11-18 07:25:27 PST --- (In reply to comment #5) > 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??) If so, the environment variable vblank_mode=0 should disable it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #5 from almos 2011-11-18 07:00:34 PST --- Now I compiled a 32bit r600g from mesa git on a 32 bit machine. The ad hoc benchmark results now with swapbufferwait disabled: 7.11: nvidia logo 200-300fps, menu 70-200fps, ons-torlan looking at tower 20-80 avg 50fps (all with high variance) 7.12-dev git-08b288b: nvidia logo 60fps (capped at refresh rate??), menu 58fps, ons-torlan looking at tower 20-50 avg 30fps (high variance, but periodically sticks to 20fps for a couple of seconds) I can't do a proper benchmark run, as it needs a run config file, and the config reader code segfaults :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #4 from almos 2011-11-18 05:25:58 PST --- OK, now I found out the reason: I still haven't got used to my new 64bit system. ut2004 is 32 bit, and when I set LIBGL_DRIVERS_PATH libGL.so reverts to indirect rendering. Ouch. What's worse, crosscompiling to 32bit is currently FUBAR on debian. The linker doesn't find /usr/lib32/libstdc++.so.6, I have to manually symlink it to /usr/lib32/libstdc++.so. The things in ia32-libs package are ancient (like mesa 7.7, I had to get a 7.11 from the libgl1-mesa-dri i386 package). I couldn't compile wine, because something is wrong with unistd_32.h, and compiling mesa stops with this: /usr/bin/ld: skipping incompatible ../../auxiliary//libgallium.a when searching for -lgallium /usr/bin/ld: cannot find -lgallium collect2: ld returned 1 exit status I can't imagine what the problem could be, because all the object files in that archive are 32bit, so they should be compatible. Back to the topic: I turned off SwapbuffersWait, which raised the fps with mesa 7.11, but the high vairance remained. I'll try compiling a 32bit version of current mesa git somehow, and see if this problem still exists. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #3 from Ian Romanick 2011-11-16 14:25:23 PST --- If this was a recent change, I'll guess that it will bisect to my changes to the way uniforms are handled. I pushed a patch today that may restore previous performance: commit 010dc29283cfc7791a29ba8a0570d8f7f9edef05 Author: Ian Romanick Date: Thu Nov 10 12:32:35 2011 -0800 mesa: Only update sampler uniforms that are used by the shader stage Previously a vertex shader that used no samplers would get updated (by calling the driver's ProgramStringNotify) when a sampler in the fragment shader was updated. This was discovered while investigating some spurious code generation for shaders in Cogs. The behavior in Cogs is especially pessimal because it ping-pongs sampler uniform settings: glUniform1i(sampler1, 0); glUniform1i(sampler2, 1); draw(); glUniform1i(sampler1, 1); glUniform1i(sampler2, 0); draw(); glUniform1i(sampler1, 0); glUniform1i(sampler2, 1); draw(); // etc. ProgramStringNotify is still too big of a hammer. Applications like Cogs will still defeat the shader cache. A lighter-weight mechanism that can work with the shader cache is needed. However, this patch at least restores the previous behavior. Signed-off-by: Ian Romanick Reviewed-by: Kenneth Graunke -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #2 from almos 2011-11-16 11:52:30 PST --- The hw is barts pro (hd6850). The only part changed is mesa: 7.11 is installed (debian unstable), and I compiled one from git. In the latter case I start programs as LD_LIBRARY_PATH=/home/almos/SRC/mesa/lib/ LIBGL_DRIVERS_PATH=/home/almos/SRC/mesa/lib/gallium "$@" I'll try to bisect later. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #1 from Alex Deucher 2011-11-16 11:42:52 PST --- What hardware are you using? Is mesa the only part that changed or did you also update your kernel and/or ddx? If it's just mesa, can you bisect? If it's multiple parts that you upgraded can you track down what component caused the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #3 from Ian Romanick 2011-11-16 14:25:23 PST --- If this was a recent change, I'll guess that it will bisect to my changes to the way uniforms are handled. I pushed a patch today that may restore previous performance: commit 010dc29283cfc7791a29ba8a0570d8f7f9edef05 Author: Ian Romanick Date: Thu Nov 10 12:32:35 2011 -0800 mesa: Only update sampler uniforms that are used by the shader stage Previously a vertex shader that used no samplers would get updated (by calling the driver's ProgramStringNotify) when a sampler in the fragment shader was updated. This was discovered while investigating some spurious code generation for shaders in Cogs. The behavior in Cogs is especially pessimal because it ping-pongs sampler uniform settings: glUniform1i(sampler1, 0); glUniform1i(sampler2, 1); draw(); glUniform1i(sampler1, 1); glUniform1i(sampler2, 0); draw(); glUniform1i(sampler1, 0); glUniform1i(sampler2, 1); draw(); // etc. ProgramStringNotify is still too big of a hammer. Applications like Cogs will still defeat the shader cache. A lighter-weight mechanism that can work with the shader cache is needed. However, this patch at least restores the previous behavior. Signed-off-by: Ian Romanick Reviewed-by: Kenneth Graunke -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #2 from almos 2011-11-16 11:52:30 PST --- The hw is barts pro (hd6850). The only part changed is mesa: 7.11 is installed (debian unstable), and I compiled one from git. In the latter case I start programs as LD_LIBRARY_PATH=/home/almos/SRC/mesa/lib/ LIBGL_DRIVERS_PATH=/home/almos/SRC/mesa/lib/gallium "$@" I'll try to bisect later. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #1 from Alex Deucher 2011-11-16 11:42:52 PST --- What hardware are you using? Is mesa the only part that changed or did you also update your kernel and/or ddx? If it's just mesa, can you bisect? If it's multiple parts that you upgraded can you track down what component caused the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
