Bug 98833

Which compositor is this? I wouldn't be at all surprised if this was Weston being broken, but I'm happy to give it a closer look. If you can reproduce this with something (anything) publicly available as well, that would obviously also be a massive help ...

(In reply to Eero Tamminen from comment #0)
> Test suite has options for using single, double or triple buffering and
> toggling Vsync, but these didn't have any effect.

Just curious, how do you actually choose between single, double or triple buffering? I thought EGL didn't give any explicit control on buffering to the app, and setting EGL_RENDER_BUFFER to EGL_SINGLE_BUFFER makes no sense on Wayland. How do you control Vsync? We don't have any API on Wayland to turn vsync off, as in, enable visible tearing.

I could understand better if you explained what you use in EGL API terms instead, since AFAIK there is no way to explicitly choose a "buffering scheme", EGL made sure to abstract that away from the app.

Before checking other things, I'm going to try whether this happens also with latest kernel and on something else than SKL.


(In reply to Daniel Stone from comment #1)
> Which compositor is this? I wouldn't be at all surprised if this was Weston
> being broken, but I'm happy to give it a closer look.

This was with Weston, both the 1.9 version in Ubuntu 16.04 and version I built from git.

Could you propose what else I should test besides Weston?  It should be something that can be tested with reasonable effort on Ubuntu (16.04).

(Gnome on Wayland option in lightdm just crashes, I'll check whether things work better with Gdm.)


> If you can reproduce this with something (anything) publicly available as well, that would obviously also be a massive help ...

I guess this isn't something that would show up with just normal desktop 2D usage of 3D driver, as otherwise somebody would already have done a bug about it.

Are there other 3D tests than Glmark2 which work on Wayland?   Preferably something made for GLES 3.x, GL 3.x or GL 4.x, not old GL / GLES 2.0 stuff like Glmark2, and preferably something already available on Ubuntu so that they can be checked quickly...


(In reply to Pekka Paalanen from comment #2)
> (In reply to Eero Tamminen from comment #0)
> > Test suite has options for using single, double or triple buffering and
> > toggling Vsync, but these didn't have any effect.
[...]
> I could understand better if you explained what you use in EGL API terms
> instead, since AFAIK there is no way to explicitly choose a "buffering
> scheme", EGL made sure to abstract that away from the app.

They were just options in the test-suite, I'll check whether they actually should do something on EGL/Wayland (test-suite supports also other APIs &  OSes, so it's possible that all options aren't supported on all platforms).


Apitrace replay didn't work on a trace, do I need to do something specific to get Apitrace to replay traces on Wayland?

(Apitrace changes some things, so I don't trust trace dump to be reliable in telling how program works until I've seen issue also on trace replay.)

> (In reply to Pekka Paalanen from comment #2)
> > (In reply to Eero Tamminen from comment #0)
> > > Test suite has options for using single, double or triple buffering and
> > > toggling Vsync, but these didn't have any effect.
> [...]
> > I could understand better if you explained what you use in EGL API terms
> > instead, since AFAIK there is no way to explicitly choose a "buffering
> > scheme", EGL made sure to abstract that away from the app.
> 
> They were just options in the test-suite, I'll check whether they actually
> should do something on EGL/Wayland (test-suite supports also other APIs & 
> OSes, so it's possible that all options aren't supported on all platforms).
> 
> 
> Apitrace replay didn't work on a trace, do I need to do something specific
> to get Apitrace to replay traces on Wayland?
> 
> (Apitrace changes some things, so I don't trust trace dump to be reliable in
> telling how program works until I've seen issue also on trace replay.)

Sorry, no idea about apitrace.

Since it's a buffer posting issue instead of a rendering issue, I thought it might be fairly easy to write a minimal program reproducing the problem if we knew how your test suite uses EGL. It shouldn't matter at all which flavour of GL was used, except for portability. I'm not aware of an existing test program like that, so Weston repository could probably use one similar to presentation-shm which can run in one of several different operating modes and report timings.

Happens both on BDW & SKL, both with Ubuntu 16.04 kernel & latest kernel from drm nightly git.

Not sure whether I have time to write test program, but at least I can provide EGL/GL API calls from apitrace dump.

Wrong frame ordering issue doesn't happen with (Ubuntu 16.04 version of) Gnome Wayland, only with Weston.

The difference between them is that gnome-shell does seem to do compositing as gnome-shell is doing buffer swaps while the tests are running, and Weston doesn't (there are no GL draw calls either).  I.e. (Ubuntu 16.04 version of) Gnome Wayland is NOT a valid test-case for this bug.

(In the worst case, for one test gnome-shell managed to do updates only at 15 FPS while test minimum was >120 FPS.  That was very visible and another reason why I looked into frame updates.)

(In reply to Eero Tamminen from comment #3)
> They were just options in the test-suite, I'll check whether they actually
> should do something on EGL/Wayland (test-suite supports also other APIs & 
> OSes, so it's possible that all options aren't supported on all platforms).

-> Frame buffer count option has no effect at all in EGL/Wayland, VSync option maps to eglSwapInterval() call.


Is there something minimal like glxgears for Wayland, which sources I could easily modify to do screen updates similarly to the test-suite I'm using?

(In reply to Eero Tamminen from comment #7)
> -> Frame buffer count option has no effect at all in EGL/Wayland, VSync
> option maps to eglSwapInterval() call.

That makes sense.

> Is there something minimal like glxgears for Wayland, which sources I could
> easily modify to do screen updates similarly to the test-suite I'm using?

Yup, there is
https://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c
It's a whole program almost in one source file.

You might want to change the redraw() function to not use a clock but rather a frame counter to advance the animation, otherwise racing at high rates the difference between consecutive frames might be too small to notice.

Maybe it can already reproduce the problem when you run it fullscreen, opaque, and swapinterval=0?

I see there are some left-overs of frame callback handling, but it does not actually use frame callbacks manually. I was going to say you'd need to remove that logic, but it's already gone. All throttling is left for eglSwapBuffers().

Created attachment 128240 [details] [review]
Patch to add frame swap delay option to weston-simple-egl

(In reply to Pekka Paalanen from comment #8)
> Maybe it can already reproduce the problem when you run it fullscreen,
> opaque, and swapinterval=0?

That wasn't enough, nor was making exactly the same (E)GL calls.

What was needed, was just using slower frame update rate.  The problem is quite visible when the test goes 60-100 FPS.

Attached patch adds delay option to weston-simple-egl.  To see the problem, try with something like:
  ./weston-simple-egl -b -f -o -d 15500

Ping... Were you able to reproduce the issue with patched weston-simple-egl?

Hi, sorry, just back from holidays. The patch looks fine so would be nice to have that on wayland-devel@ mailing list if you didn't send it already. I think it'd be an ok addition to simple-egl.

Does it matter if the delay is before or after swapbuffers? I would slightly prefer it before swapbuffers so it would emulate time spent in drawing. That could be the rationale in the commit message, too.

I haven't had a chance to test yet.

Created attachment 128981 [details]
Patch to add frame swap delay option to weston-simple-egl

(In reply to Pekka Paalanen from comment #11)
> Hi, sorry, just back from holidays. The patch looks fine so would be nice to
> have that on wayland-devel@ mailing list if you didn't send it already. I
> think it'd be an ok addition to simple-egl.

I'm not on wayland list, and rather not subscribe on one more.  I don't need attributions, so feel free to apply it as you see fit.


> Does it matter if the delay is before or after swapbuffers? I would slightly
> prefer it before swapbuffers so it would emulate time spent in drawing.

As expected, it doesn't matter.  Attached is updated patch.

(In reply to Eero Tamminen from comment #9)
> Created attachment 128240 [details] [review] [review]
> Patch to add frame swap delay option to weston-simple-egl
> 
> That wasn't enough, nor was making exactly the same (E)GL calls.
> 
> What was needed, was just using slower frame update rate.  The problem is
> quite visible when the test goes 60-100 FPS.
> 
> Attached patch adds delay option to weston-simple-egl.  To see the problem,
> try with something like:
>   ./weston-simple-egl -b -f -o -d 15500

Yes! I just installed Mesa git master and using Weston git master with your delay patch, and it produces a mighty glitchy animation indeed.

I am on "GL renderer: Mesa DRI Intel(R) Haswell Desktop".

Ok, as it happens on HSW, BDW & SKL, I would say that it's a generic problem.  

Is there any Mesa driver which non-vsynched frame updates are not broken by the indicated Mesa commit?

(In reply to Pekka Paalanen from comment #14)
> Yes! I just installed Mesa git master and using Weston git master with your
> delay patch, and it produces a mighty glitchy animation indeed.
> 
> I am on "GL renderer: Mesa DRI Intel(R) Haswell Desktop".

(In reply to Eero Tamminen from comment #15)
> Ok, as it happens at least on HSW, BDW & SKL, I would say that it's a generic
> problem.  
> 
> Is there any Mesa driver which non-vsynched frame updates are not broken by
> the indicated Mesa commit?

I.e. is there any reason why Daniel's revert should not be reverted?

I've been looking at this over the past couple of days, but haven't quite been able to figure it out. Hopefully I can crack it today.

Right, here we are:
https://lists.freedesktop.org/archives/mesa-dev/2017-May/155791.html

(In reply to Daniel Stone from comment #18)
> Right, here we are:
> https://lists.freedesktop.org/archives/mesa-dev/2017-May/155791.html

Eero, are you able to test this?

(In reply to Daniel Stone from comment #19)
> (In reply to Daniel Stone from comment #18)
> > Right, here we are:
> > https://lists.freedesktop.org/archives/mesa-dev/2017-May/155791.html
> 
> Eero, are you able to test this?

I may have again time for this next month, not currently.

No problem, I've pushed with Pekka's ack in the meantime. Please reopen if this is still broken for you later. Thanks for the really detailed report!