[Bug 95200] IOQuake is jerky

[bugzilla-daemon at freedesktop.org]

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

--- Comment #16 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to Sitsofe Wheeler from comment #15)
> The patch from comment #14 (which can be found in
> https://lists.x.org/archives/xorg-commit/2016-April/039124.html or on
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/
> ?id=e4ef6e9e5b2c8b637356621c60b28d064d40d29c ) alone resolves the issue.

That at least explains it.

> The patch from comment #13 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160501/9ff17d7c/attachment.html>