Bug 89760

That's not a full description of the software stack. What browser, what desktop environment, what window manager? Is it running fullscreen or in an window?

Used gfx sw stack:
2015-03-25 Kernel:(drm-intel-nightly)877605d94cb0260cb05a110b8a1ec3871a8477ea 
Others used 2015 Q1 release package driver: 
Mesa = 10.5.1
libdrm = 2.4.59
Cairo = 1.14.2
Xserver = 1.17.1

Browser: Google Chrome 33.0.1750.152
Desktop environment: gnome-session
Run the case with this command, not special set to full screen or windows mode:  ./google-chrome --enable-webgl --ignore-gpu-blacklist --user-data-dir "http://tinderbox.sh.intel.com/webglsamples.googlecode.com/hg/toon-shading/toon-shading.html"

Wendy, I think you need to list also versions of X libraries, e.g. ones for xcb dri & present extensions.  driproto version used to build things can also be important.


Chris, from looking at the performance numbers, the issue isn't performance drop, but WebGL tests getting Vsynched.

This change seems to have affected only HSW, but it could also affect BYT (FullHD tests on that go below 60 FPS, so Vsync changes don't show on it).  IVB and BDW seem to have *already* earlier been running tests as Vsynched.

Eero, thanks a lot! The existing DRI2 swap-interval=0 code is not vsynced, and a quick review of the code (and glxgears) confirms that.

So I wonder if there is some other effect at play?

Wendy, what I could do with is an xtrace of both good/bad behaviour - could you extract such a debug log from your test setup?

On ChromeOS, Chrome is limiting WebGL to 60 FPS regardless of vblank_mode=0 setting, so it could be even browser.  What's the best way to debug what Mesa and X think is the Vsync value?

Under GL, the swap-interval is exposed b glXGetSwapIntervalMesa (and glXSetSwapIntervalMesa) that corresponds to the vblank_mode. The vrefresh rate is glXGetMscRateOML (though at the moment that is bugged and doesn't track mode changes).

I've also updated xf86-video-intel/tools/dri3info to print the refresh rate:
commit 2f047c62783a187067921e1aaf5572fb8647bd84
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Apr 1 12:39:48 2015 +0100

    tools/dri3info: Query refresh rate on Primary monitor

(In reply to Chris Wilson from comment #6)
> Under GL, the swap-interval is exposed b glXGetSwapIntervalMesa (and
> glXSetSwapIntervalMesa) that corresponds to the vblank_mode. The vrefresh
> rate is glXGetMscRateOML (though at the moment that is bugged and doesn't
> track mode changes).
> 
> I've also updated xf86-video-intel/tools/dri3info to print the refresh rate:
> commit 2f047c62783a187067921e1aaf5572fb8647bd84
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Apr 1 12:39:48 2015 +0100
> 
>     tools/dri3info: Query refresh rate on Primary monitor

Tested this xf86-video-intel commit based on 2015-04-06 GFX SW stack with HSW HW:
commit 2f047c62783a187067921e1aaf5572fb8647bd84
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Apr 1 12:39:48 2015 +0100

  tools/dri3info: Query refresh rate on Primary monitor

Four WebGL cases:
 Google Auqarium/Google Dynamic Cubemap/Earthscreen/Google Toon-Shading cases performance value all recovered to good values: 75 FPS around.

Created attachment 114908 [details]
Xorg.0_commit_2f047c.log

Hmm, nothing obviously changed, so worksforme.