Vertical synchronization

[neilstockbridge]

Thank you so much for primsrun. Although optirun glxspheres went from 130fps to 110fps with primusrun, Xonotic went from ~50fps ( optirun) to ~130fps ( primusrun), both with the experimental-310 driver. When limited to 60 fps, Xonotic runs cooler and quieter.

Even without the vblank_mode variable though and with "Wait for GPU to finish.." checked in Xonotic, I still see tearing on each frame even it's clearly pegged at 60 fps.

EDIT: Sorry for the noise. The correct setting in Xonotic is not "Wait for GPU to finish.." but "Vertical synchronization". There is no tearing with "Vertical synchronization" checked.

[amonakov]

This is odd. In-game vsync setting should have no effect. What are your CPU and GPU models?

[neilstockbridge]

The CPU is i7-2617M and the GPU is GF108 [GeForce GT 540M]. I might have been too hasty with the edit and have seen tearing since. What are the valid values for the vblank_mode variable and what do they do?

[amonakov]

What are the valid values for the vblank_mode variable and what do they do?

See here, or alternatively run xdriinfo or driconf.

At this moment primus does not provide any swap control whatsoever, so the only way to control vblank synchronization is to do it via Mesa configuration (hence, via vblank_mode variable). That said, it should not tear either when Intel drivers do not; it probably indicates a bug or misconfiguration somewhere. If you see tearing in other circumstances when primus is not involved, you may need to update or tune your driver for the Intel chip.

[neilstockbridge]

Thank-you! For others who might read this:

• vblank_mode=0: Never synchronize with vertical refresh, ignore application's choice
• vblank_mode=1: Initial swap interval 0, obey application's choice
• vblank_mode=2: Initial swap interval 1, obey application's choice
• vblank_mode=3: Always synchronize with vertical refresh, application chooses the minimum swap interval

[neilstockbridge]

This is weird, but I get proper tearing when I use values of 2 or 3 for vblank_mode and not for values of 0 or 1 ( tested with quakespasm). The "tearing" that I was referring to with my initial post is still there but not nearly as noticeable as real tearing so it must be something else.

[amonakov]

What do you mean by 'proper tearing'? Does PRIMUS_SYNC=1 primusrun behave differently? Are you running under active compositing manager?

[neilstockbridge]

I tried for m in 0 1 2 3; do PRIMUS_SYNC=1 vblank_mode=$m primusrun quake; done, started a game and strafed left and right while looking at a column well-lit by a brazier. With vblank modes 2 or 3 the column looks sheared in two about 40% of the way down the screen with the top part of the column quite far left or right ( depending on which way I was strafing) of the bottom part ( what I meant by proper tearing) but curiously fps is consistently 60. With vblank mode 0 or 1, fps is ~94, the column appears straight and the overall effect is much better than with modes 2 or 3 but there is a subtle flickering about 25% and 50% of the way down the screen that is hard to describe but unpleasant. This is what I first took to be tearing. I'm running Unity2D but don't know if it's compositing. primus, primus-lib and primus-lib:i386 are all 201302241855git~precise1. In case it matters, the Intel Xorg log says:

[   865.283] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)
[   865.283] (--) intel(0): Chipset: "Sandybridge Mobile (GT2)"
[   865.283] (**) intel(0): Relaxed fencing enabled
[   865.283] (**) intel(0): Wait on SwapBuffers? enabled
[   865.283] (**) intel(0): Triple buffering? enabled
[   865.283] (**) intel(0): Framebuffer tiled
[   865.283] (**) intel(0): Pixmaps tiled
[   865.283] (**) intel(0): 3D buffers tiled
[   865.283] (**) intel(0): SwapBuffers wait enabled

[neilstockbridge]

If I start a session with Unity ( I guess this is compositing?) instead of Unity2D the issue goes away. I swear I am not making this up.

[amonakov]

I think you're seeing this problem with synchronization in Intel drivers: https://bugs.freedesktop.org/show_bug.cgi?id=37686, which was just recently fixed.

[ArchangeGabriel]

Also, please purge primus and its lib, remove Zhurikin ppa, update your package list and reinstall primus.