[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

GitLab Migration User  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #7 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/413.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #6 from almos  ---
Now I took a new look at the issue with GALLIUM_HUD=fps, and there is
definitely a serious problem with cpufreq. I have a few scripts to switch
cpufreq governor between performance and ondemand (Phenom II x4), and to switch
between high and low gpu power profiles (HD6850). When ondemand is selected, it
seriously limits performance, and causes noticeable variance in fps. Some
examples:

Psychonauts, main menu (Raz standing on top of the giant brain)
ondemand/low 20 fps
ondemand/high 40-50 fps
performance/low 29 fps
performance/high 104 fps

SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon
Hawk
ondemand/low 20-30 fps
ondemand/high 20-30 fps
performance/low 55-60 fps
performance/high 68 fps

The difference between ondemand and performance makes a huge difference in
native games as well. Quake Wars, Team Fortress 2, and UT2004 are all
borderline playable with ondemand, but run perfectly with performance. It's not
just a drop in fps, but a very noticeable laggyness, that kills the games.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #6 from almos aaalmo...@gmail.com ---
Now I took a new look at the issue with GALLIUM_HUD=fps, and there is
definitely a serious problem with cpufreq. I have a few scripts to switch
cpufreq governor between performance and ondemand (Phenom II x4), and to switch
between high and low gpu power profiles (HD6850). When ondemand is selected, it
seriously limits performance, and causes noticeable variance in fps. Some
examples:

Psychonauts, main menu (Raz standing on top of the giant brain)
ondemand/low 20 fps
ondemand/high 40-50 fps
performance/low 29 fps
performance/high 104 fps

SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon
Hawk
ondemand/low 20-30 fps
ondemand/high 20-30 fps
performance/low 55-60 fps
performance/high 68 fps

The difference between ondemand and performance makes a huge difference in
native games as well. Quake Wars, Team Fortress 2, and UT2004 are all
borderline playable with ondemand, but run perfectly with performance. It's not
just a drop in fps, but a very noticeable laggyness, that kills the games.

-- 
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 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #5 from almos  ---
(In reply to comment #4)
> This is not related to cpufreq. I've fixed my governor to the highest
> frequency and still experience these massive lags.

Since I cerated a startup script for ut2004 that does 'set all cores to
performance ; ut2004 ; set all cores to ondemand' the game runs smoothly
without any lag.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #4 from Tobias Jakobi  ---
This is not related to cpufreq. I've fixed my governor to the highest frequency
and still experience these massive lags.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #3 from Andy Furniss  2012-08-02 
22:32:43 UTC ---
(In reply to comment #2)
> It might not help in fixing this, but I found that the framerate is much more
> consistent if I load all cpu cores with something while playing ut2004.
> Normally, the framerate counter is green, but flashes into yellow and purple,
> which makes movements very choppy. When something is running in the 
> background,
> the framerate counter stays green, and all movements are smooth.

Maybe cpufreq is causing this here's what I get on the demo on an HD4890 +
4x3.4GHz phenom II.

R600_LLVM=0 ut2004
as-convoy?spectatoronly=1?numbots=8?quickstart=1?attractcam=1 -benchmark
-seconds=120 -nosound

cpufreq ondemand - 

30.027578 / 76.497787 / 162.457611 fps

cpufreq set to performance

37.627441 / 93.523949 / 197.051376 fps

> 
> With the llvm compiler the game is unplayable either way.

I see the stalling in the demo benchmark.

2.030273 / 70.589706 / 196.047073 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 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #2 from almos  2012-08-02 22:04:09 UTC ---
It might not help in fixing this, but I found that the framerate is much more
consistent if I load all cpu cores with something while playing ut2004.
Normally, the framerate counter is green, but flashes into yellow and purple,
which makes movements very choppy. When something is running in the background,
the framerate counter stays green, and all movements are smooth.

With the llvm compiler the game is unplayable either way.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #2 from almos aaalmo...@gmail.com 2012-08-02 22:04:09 UTC ---
It might not help in fixing this, but I found that the framerate is much more
consistent if I load all cpu cores with something while playing ut2004.
Normally, the framerate counter is green, but flashes into yellow and purple,
which makes movements very choppy. When something is running in the background,
the framerate counter stays green, and all movements are smooth.

With the llvm compiler the game is unplayable either way.

-- 
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 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2012-08-02 
22:32:43 UTC ---
(In reply to comment #2)
 It might not help in fixing this, but I found that the framerate is much more
 consistent if I load all cpu cores with something while playing ut2004.
 Normally, the framerate counter is green, but flashes into yellow and purple,
 which makes movements very choppy. When something is running in the 
 background,
 the framerate counter stays green, and all movements are smooth.

Maybe cpufreq is causing this here's what I get on the demo on an HD4890 +
4x3.4GHz phenom II.

R600_LLVM=0 ut2004
as-convoy?spectatoronly=1?numbots=8?quickstart=1?attractcam=1 -benchmark
-seconds=120 -nosound

cpufreq ondemand - 

30.027578 / 76.497787 / 162.457611 fps

cpufreq set to performance

37.627441 / 93.523949 / 197.051376 fps

 
 With the llvm compiler the game is unplayable either way.

I see the stalling in the demo benchmark.

2.030273 / 70.589706 / 196.047073 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 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #1 from Michel D?nzer  2012-07-06 08:25:03 
PDT ---
FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex
shaders. Possibly related to constantly changing fixed-function emulation
shaders, UT2004 seems to burn through those quickly (this also caused slowdowns
with fglrx's shader cache when the game was new). Just an idea, maybe this is
different.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 51787] performance regression with llvm shader compiler in ut2004

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-07-06 08:25:03 PDT 
---
FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex
shaders. Possibly related to constantly changing fixed-function emulation
shaders, UT2004 seems to burn through those quickly (this also caused slowdowns
with fglrx's shader cache when the game was new). Just an idea, maybe this is
different.

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