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

--- Comment #2 from lei.pero@gmail.com --- Created attachment 128993 --> https://bugs.freedesktop.org/attachment.cgi?id=128993&action=edit glxinfo

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

--- Comment #4 from lei.pero@gmail.com --- Created attachment 128995 --> https://bugs.freedesktop.org/attachment.cgi?id=128995&action=edit Xorg.1

DRI2

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

Michel Dänzer michel@daenzer.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #128994|text/x-log |text/plain mime type| |

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

--- Comment #6 from Michel Dänzer michel@daenzer.net --- I can't seem to reproduce any unexpected behaviour with radeonsi. Can you create a video demonstrating the problem?

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

--- Comment #8 from lei.pero@gmail.com --- Created attachment 129017 --> https://bugs.freedesktop.org/attachment.cgi?id=129017&action=edit DRI2 video

DRI2

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

--- Comment #10 from lei.pero@gmail.com --- Videos are recorded @85FPS, I'm not sure how visivle would be on 60Hz display, you should view it on higher refresh rate probably.

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

--- Comment #12 from lei.pero@gmail.com --- Created attachment 129020 --> https://bugs.freedesktop.org/attachment.cgi?id=129020&action=edit DRI3 this page

This webpage example DRI3

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

--- Comment #14 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #13)

(In reply to lei.pero from comment #7)

...

Sure, i will, it's like performace loss, I'm not sure if video would do the justice,

Indeed, I'm afraid I can't see much difference, though the DRI2 videos do seem slightly smoother.

Can you create another comparison video with the environment variable GALLIUM_HUD=.dfps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage, cpu+temperature+GPU-load,.dnum-bytes-moved,.dbuffer-wait-time,.dnum- compilations+num-shaders-created set when starting chromium? It should overlay some graphs showing the framerate and other performance related values.

...

I think this is hardware specific onr adeon driver (only?).

Does it not happen using the modesetting driver instead of radeon?

Sure, I did it, will upload now. It does happen on modesetting driver regardless of DRI version, strange. It's most visible on Chrome/ium scrolling, but I can also notice it in standard GNOME-shell animations (for example, after logging in startup animation is not smooth as it should be/as it is on radeon DRI2), hope this information helps a bit. I'm very positive i can notice same behaviour in games also (I'm not a gamer, so just a few I play).

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

--- Comment #16 from lei.pero@gmail.com --- Created attachment 129049 --> https://bugs.freedesktop.org/attachment.cgi?id=129049&action=edit DRI3_EV1

DRI3 Chromium with EV

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

--- Comment #18 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #17)

(In reply to lei.pero from comment #14)

...

It does happen on modesetting driver regardless of DRI version, strange.

The modesetting driver doesn't allow disabling DRI3 on the server side. You can always disable it on the client side though with the environment variable LIBGL_DRI3_DISABLE=1 .

The fps graph shows the same framerate in both videos, so the problem seems rather about animation timing. It might be related to the fact that DRI3 allows triple buffering, and might be at least partially an application issue. It would be interesting though if it also happens with a non-AMD GPU.

BTW, is there any particular reason why you're disabling sync-to-vblank? It is the intended mechanism for smooth animation...

I didn't know that about modesetting driver, anyway, even with LIBGL_DRI3_DISABLE=1 same thing happens.

I don't how to disable tripple buffering to test it and if it's possible, man pages do not show anything about it. I've also tested on nouveau, same thing happens, architecture is completely different with Intel C2D CPU @3.0GHz and GT-210 (on this PC it's AMD FX-4100 CPU stock), both modesetting driver and nouveau with DRI3 act the same, while nouveau with DRI2 works well same as radeon with DRI2. If you have any idea where to look for further testing, I can do it.

Yes, there are reasons, on some webpages (it is probably fault of page coding or PC CPU power) CHromium/Firefox can't keep up with 85FPS, while drop happens, when VBLANK is enabled, I'm getting less responsive mouse wheel (lag), while with VBLANK disabled FPS drop is less severe, and there are is no input lag on wheel or anything. That is main reason, among others that can be solved with scripts (too alzy to type command when starting application without it = game or something), also, videos do seem smoother (VLC, youtube etc.) with VBLANK disables, so there are multiple reasons why I do it.

So, any way to disable tripple buffer? Or if you have idea what might be the cause of the problem?

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

--- Comment #20 from lei.pero@gmail.com --- Scrach post above, I didn't realized that EXA forces DRI2.

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

--- Comment #22 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #21)

(In reply to lei.pero from comment #18)

...

I didn't know that about modesetting driver, anyway, even with LIBGL_DRI3_DISABLE=1 same thing happens.

Maybe chromium doesn't pass on the environment variable to its GPU helper process, or maybe there was still a chromium process around.

...

I don't how to disable tripple buffering to test it and if it's possible,

Only by changing the code, mesa/src/loader/loader_dri3_helper.c:dri3_update_num_back(). E.g. set num_back = 1 in the else case.

Ok, I've built mesa with that parameter changed and installed, same behavior. I've cloned just "git://anongit.freedesktop.org/git/mesa/mesa" , it should be enough.

On the side note, if default is glamor, EXA definitively works better on my config (not huge difference, but there is difference). I will try to investiate more, but I'm really not sure where to look.

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

--- Comment #24 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #23)

(In reply to lei.pero from comment #22)

...

Ok, I've built mesa with that parameter changed and installed, same behavior. I've cloned just "git://anongit.freedesktop.org/git/mesa/mesa" , it should be enough.

Did you verify that it's hitting the path you modified? E.g. if chromium is fullscreen and there's no compositor, it may hit the if case instead of the else case. Maybe try changing the if case to 2 buffers as well.

Yeah, it is the same, but, it might be that it is not a bug with mesa at all(?).

Long story short, after investigating further, it turns out that DRI3 works quite well with compiz, marco and in lxde, lxqt. The actual problem happens only when mutter is window manager (still, it doesn't explain why it works well with DRI2), I've tried MATE DE with different WM and as expected, all others work well except mutter.

Hope this new info helps, and if it turns out it is mutter bug and not DRI3 (doesn't make sense), I apologize for wasting your time (should have done this earlier...), and we can close/delete this bug report. It still doesn't make any sense why it would work well with DRI2 but not DRI3 on mutter.

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

--- Comment #26 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #25)

So maybe it actually depends on whether mutter uses DRI3 or DRI2? You can test this by enabling DRI3 on the server side but (re-)starting mutter with

LIBGL_DRI3_DISABLE=1 mutter --replace

Yeah, result is smooth experience (and broken gnome-shell lol), I was convinced that same bahviour happens with other WM's, I remmember when using Ubuntu that there was same problem, but i was using custom gnome-flashback session, still was convinced same thing happened with compiz and metacity, obviously i should have tested it, not concluding from (erroneous) memory.

So, this is connected with mutter, and probably does not belong here but on gnome project bug report? Latter i will try some environment variables for clutter to investigate it further.

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

--- Comment #28 from lei.pero@gmail.com --- (In reply to Michel Dänzer from comment #27)

Yeah, sounds like a mutter bug then. Anyway, thanks for the report and cooperation in narrowing it down.

Yeah, will report it on GNOME project, sorry again, I should have tested it more in depth before reporting, and thanks for the assistance.

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

--- Comment #30 from Michel Dänzer michel@daenzer.net --- (In reply to lei.pero from comment #29)

Just want to add few things, did reported bug to gnome project, but, problem does not happen when "vblank_mode" value in .drirc configuration file is set to 1 (instead of 0 I've used before).

1 means sync-to-vblank is disabled by default, but the application can enable it explicitly. 0 means sync-to-vblank is disabled regardless of what the application wants. So this could actually be considered a configuration issue instead of a bug anywhere.

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

--- Comment #32 from Michel Dänzer michel@daenzer.net --- (In reply to lei.pero from comment #31)

It's still odd behaviour, in both cases Chrome caps FPS to refresh rate (this case 85FPS),

Sounds like Chrome just has its own framerate throttling which works independently from sync-to-vblank.

but using DRI3 using mutter/clutter, for some reason it creates continuous stutters, even tho FPS is the same and all other parameters are equal. It really looks (when viewed live) as if FPS is not equal to refresh rate.

It's possible that the mutter framerate doesn't match the refresh rate (you can check by setting GALLIUM_HUD=fps for the mutter process), but it's also possible it's simply due to unfortunate interaction between the Chrome and mutter frame timings.

[...] it is still probably mutter/clutter configuration problem in the code (since it happens only there), it doesn't follow configuration in .drirc as other WM's.

Not really. By setting vblank_mode=0, you're forcing mutter to run in a way it doesn't intend. If doing so breaks something, that can hardly be considered a mutter bug, and you get to keep all the pieces. :)

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

--- Comment #34 from Michel Dänzer michel@daenzer.net --- (In reply to lei.pero from comment #33)

Yeah, but by setting 1 and using any other WM results in Chromium/Chrome being VSYNC-ed, [...]

With a compositing manager, tearing or not is up to that.

[...] i would call it mutter/clutter configuration bug [...]

vblank_mode is Mesa configuration overriding mutter's intent, so it cannot reasonably be called that.

plus it doesn't explain DRI2 behavior that follows same standard :).

It's probably just a happy accident that it works better according to your criteria with DRI2.