Can you please attach Xorg.0.log and glxinfo? Any clue if this is a regression in any specific component?

Created attachment 123353 [details]
Xorg log

Created attachment 123354 [details]
glxinfo

I can't say for sure which component is the likely culprit (the switch to SNA?) or even when this issue was introduced (I know it worked back with Ubuntu 10.04...). I have feeling this problem turned up some time ago but that something about the system meant I didn't want to file a report...

First guess is that it is frame throttling (since that will be hidden behind tearfree). You could try and see whether Option "NoSwapBuffersWait" (or just in case the magic isn't working Option "SwapBuffersWait" "False") gives the same effect.

Your suggestion of "SwapBuffersWait" "False" resolved the problem. Are there any further clues as to why the throttling is kicking in so aggressively?

The throttling is:

batch = do swap copy
on each vblank after:
  if idle(batch): report swap done

Within mesa there is also (or should be) equivalent swap throttling. So this shouldn't be substantially different, yet it is. If you have the time and patience, compiling the xf86-video-intel with --enable-debug=full (and the resultant Xorg.0.log) should confirm what I've just said.

Hmm, good, there is also an
  Option "NoVSync"
could you try that? That will keep the swap buffer throttling, but disable the synchronous update on screen (presuming it is currently). That may be causing a huge delay and backlog.

Removing all other options and using NoVsync doesn't help - things are still jerky. Based on what you've been saying I've come across https://bugzilla.kernel.org/show_bug.cgi?id=13713 which mentioned you can have IOquake limit its FPS to 50 using com_maxfps. Doing this did indeed improve the smoothness.

Created attachment 123357 [details]
Xorg log from --enable-debug=full build

How did it feel while recording? I can see a few isolated spots where it missed the vblank but it was never stalled (i.e. it didn't miss 2 vblanks and so run dry of buffers). From a glance at several seconds worth of frames at odd places, it looks like it is running smoothly. I should write something to find the anomalies in these logs!

Note that it is using XVidMode to change resolution which fails to change the screen size and is preventing flips. What happens to the ux if you run "xrandr --output LVDS1 --mode 800x600"?

So the bits I've looked at so far in the log appear as I would expect, so either I'm missing something or the client is not throttling to the presentation (swapbuffers).

While recording you generally see a burst of frames then a pause then another burst etc.

Switching the res using xrandr before running ioquake fixed it! So this is just a bug in the client app? If so perhaps it's a bug in SDL...

Created attachment 123365 [details] [review]
Resize screen for XVidMode changes

This should be enough to adjust the screen size automatically for XVidMode. It only applies for single monitors, or similarly restricted setups (but that's XVidMode for you)

Created attachment 123367 [details] [review]
Resize screen for XVidMode changes

Found something that I didn't like, that would have caused a stutter for a few frames.

commit e4ef6e9e5b2c8b637356621c60b28d064d40d29c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Apr 30 14:09:05 2016 +0100

    sna/dri2: Free the pending back buffer after use
    
    The pending back buffer is only the pending copy, the actual info->back
    stores the client's view of the current back buffer which may be more
    recent than the pending copy. So store the current back buffer, swap in
    the pending to do the normal swap, then free the resultant back (which
    may have been exchanged with the front), before restoring the client's
    current back buffer.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=95200
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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.

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:

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

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.

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

Created attachment 123401 [details]
Xorg logverbose 6 log, --enable-debug=full with XVidMode changes build

Annoyingly further investigation shows that NoVSync was still in the xorg.conf and that seems directly linked to the capped frame rate seen when using xrand -s 800x600 prior to running the benchmark. Removing NoVSync and restarting X restored the regular FPS no matter the initial resolution.

The log in comment #17 was taken without any additional options in empty xorg.conf so the outcome of that still holds.

Getting closer. Looks like the resize to 800x600 is successful, but we don't attempt to undo the mode change later. That suggests that it is the XVidMode layer crying foul after all.

However, even though the screen is resized the Client window is still 1024x600 and we don't want to flip then as the back and front buffers are different sizes. Argh. It feels like the resize-in-driver approach is a dead end.

Created attachment 123422 [details] [review]
Resize screen for XVidMode changes

This should be closer still to running the xrandr command by hand. Not sure if this will allow XVidMode to restore the mode afterwards, but it should enable flipping after the resolution change.

Constructing a test case for XVidMode switches which also sadly fails after a few switches for no apparent reason...

XVidMode is beyond my ability to workaround the damage in the driver. It is currently hardcoded to prevent setting a mode larger than the current screen size (pre-KMS restriction). I could replace it with a correct SwitchMode, but the VidMode extension is private to Xorg and not exported to the driver. We've gone as far as we can without fixing Xorg.