<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - IOQuake is jerky" href="https://bugs.freedesktop.org/show_bug.cgi?id=95200#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - IOQuake is jerky" href="https://bugs.freedesktop.org/show_bug.cgi?id=95200">bug 95200</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to Sitsofe Wheeler from <a href="show_bug.cgi?id=95200#c15">comment #15</a>) > The patch from <a href="show_bug.cgi?id=95200#c14">comment #14</a> (which can be found in > <a href="https://lists.x.org/archives/xorg-commit/2016-April/039124.html">https://lists.x.org/archives/xorg-commit/2016-April/039124.html</a> or on > <a href="https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/">https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/</a> > ?id=e4ef6e9e5b2c8b637356621c60b28d064d40d29c ) alone resolves the issue. That at least explains it. > The patch from <a href="show_bug.cgi?id=95200#c13">comment #13</a> alone doesn't resolve the problem (stuttering > still occurs) and introduces a failure after ioquake is quit where the old > resolution isn't restored and instead an error message is printed: Hmm, stuttering still present - would imply that it didn't have the same effect as the xrandr command I thought I was emulating. That it didn't end up with the screen the right size :( > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 151 (XFree86-VidModeExtension) > Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) > Value in failed request: 0x300000e > Serial number of failed request: 192 > Current serial number in output stream: 194 That either means the mode change failed or it didn't find a matching mode. I can't believe the later, so probably changing back failed. If you don't mind sending me a debug log with this failure (and even running X with -logverbose) should help me understand what I did wrong. > Further, I've just noticed that when running without any patches and doing > xrand -s 800x600 before starting ioquake then using timedemo 1 when playing > back a demo only yields 33fps. This is lower than the 43fps seen when > starting in 1024x600 and letting ioquake do the switching to 800x600. Hmm. Odd. We have triple buffering for both window and fullscreen modes, so it shouldn't be locked to 30fps, and avoiding the 800x600 copy should have a noticeable impact. Would be interesting again to have a look at the full debug log. My first suspect would be that we aren't keeping the back buffer cache and so trip over clflushing a new buffer every frame (or two), that would be enough to slow the framerate.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>