Bug 34626 - Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
Summary: Mesa-Gallium with R600 - Framerate limited to 60 fps after suspend-cycle
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-23 08:18 UTC by Peter Weber
Modified: 2019-11-19 08:18 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
output of dmesg (53.75 KB, text/plain)
2011-02-23 08:18 UTC, Peter Weber
no flags Details
output of glxinfo (23.62 KB, text/plain)
2011-02-23 08:19 UTC, Peter Weber
no flags Details
.config of kernel-2.6.38-rc6 (63.65 KB, application/octet-stream)
2011-02-23 08:19 UTC, Peter Weber
no flags Details
output of lspci (2.11 KB, text/plain)
2011-02-23 08:20 UTC, Peter Weber
no flags Details
output of complete package-list (13.15 KB, text/plain)
2011-02-23 08:20 UTC, Peter Weber
no flags Details

Description Peter Weber 2011-02-23 08:18:30 UTC
Hello,
I past I thought this is a bug of IOQuake3, but during switching between Mesa-Classic and Mesa-Gallium I recognized, that the problem only exists with Mesa-Gallium!

Reproduce:
1. $export vblank_mode=0 // switching of vsync
2. Launch an IOQuake3 based game (Quake3 Arena, OpenArena, World of Padman...)
3. check that VSYNC in IOQuake3 is also disabled!
4. Start a game and set "cg_drawpfs 1", know you should have at the top right corner a display with your current framerate which is hopefully over 60 fps
5. switch to a tty during playing (should be no problem with Kernel-Mode-Setting)
6. #pm-suspend (as root)
7. resume from suspend
8. switch back to X11/IOQuake3 -> framerate is limited to 60 fps

To fix this you have to relaunch IOQuake3 or simply type into quake-console "vid_restart".
With Mesa-Classic and the R600-Driver this is not necessary, it displays always the maximum possible framerate.

Maybe Gallium doesn't read or forget the environment-variable export_vblank during resume from suspend?
Comment 1 Peter Weber 2011-02-23 08:18:54 UTC
Created attachment 43710 [details]
output of dmesg
Comment 2 Peter Weber 2011-02-23 08:19:28 UTC
Created attachment 43711 [details]
output of glxinfo
Comment 3 Peter Weber 2011-02-23 08:19:56 UTC
Created attachment 43712 [details]
.config of kernel-2.6.38-rc6
Comment 4 Peter Weber 2011-02-23 08:20:14 UTC
Created attachment 43713 [details]
output of lspci
Comment 5 Peter Weber 2011-02-23 08:20:49 UTC
Created attachment 43714 [details]
output of complete package-list
Comment 6 Peter Weber 2011-02-23 08:21:20 UTC
Environment-Variables:

export R600_ENABLE_S3TC=1
export vblank_mode=0
Comment 7 Michel Dänzer 2011-02-23 08:45:26 UTC
(In reply to comment #7)
> 5. switch to a tty during playing (should be no problem with
> Kernel-Mode-Setting)
> 6. #pm-suspend (as root)
> 7. resume from suspend
> 8. switch back to X11/IOQuake3 -> framerate is limited to 60 fps

Does the problem also occur if you switch to console and back to X without a suspend/resume cycle in between?


> Maybe Gallium doesn't read or forget the environment-variable export_vblank
> during resume from suspend?

No, the 3D driver is blissfully unaware of the suspend/resume cycle. The problem is more likely in the X server/driver or kernel.
Comment 8 Peter Weber 2011-02-23 09:08:40 UTC
If I only switch between console and X everything keeps fine.
Comment 9 Peter Weber 2011-11-19 09:40:14 UTC
I've tested this in the meantime also with a Intel based grapcis solution (Ironlake), it is not affected. But the Intel driver doesn't need the var vblank_mode for switching vsync off (only SwapbuffersWait). Maybe the setting of the var gets "lost" during suspend cycle?
Comment 10 Martin Peres 2019-11-19 08:18:20 UTC
-- 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/drm/amd/issues/180.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.