Bug 99418

Please attach the corresponding Xorg log file and output of glxinfo.

Created attachment 128993 [details]
glxinfo

Created attachment 128994 [details]
Xorg.0

Created attachment 128995 [details]
Xorg.1

DRI2

(In reply to lei.pero from comment #2)
> Created attachment 128993 [details]
> glxinfo

(In reply to Michel Dänzer from comment #1)
> Please attach the corresponding Xorg log file and output of glxinfo.

Sure, files attached. To be more accurate, it's like "ghosting" when scrolling with DRI3 on most pages (google search results, phoronix forum etc.), even tho CRT displays do not ghost.

I can't seem to reproduce any unexpected behaviour with radeonsi. Can you create a video demonstrating the problem?

Sure, i will, it's like performace loss, I'm not sure if video would do the justice, I will do it in ~1 hour and attach (if possible, if not, youtube link or something). I think this is hardware specific onr adeon driver (only?).

Created attachment 129017 [details]
DRI2 video

DRI2

Created attachment 129018 [details]
DRI3 Video

DRI3

Videos are recorded @85FPS, I'm not sure how visivle would be on 60Hz display, you should view it on higher refresh rate probably.

Created attachment 129019 [details]
DRI2 this page

This webpage example DRI2

Created attachment 129020 [details]
DRI3 this page

This webpage example DRI3

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

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

Created attachment 129048 [details]
DRI2_EV1

DRI2 Chromium with EV

Created attachment 129049 [details]
DRI3_EV1

DRI3 Chromium with EV

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

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

Ok, i think I've found culprint to the problem, it's acceleration method, not DRI3 actually, so maybe i should change the title of the bug report?

Now, with DRI3 and Option "AccelMethod" "EXA", it's actually even better compared to DRI2 (one tearline, instead of two on DRI2), the problem is glamor actually (or something connected to it), since it is default on DRI3.

I assume it will act the same on nouveau driver (didn't tried yet), and I think it's worth investigating further.

Scrach post above, I didn't realized that EXA forces DRI2.

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

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

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

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

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

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

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

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

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

Thought it would be nice to inform you about that since .drirc configuration belongs here, still could be mutter/clutter problem tho.

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

(In reply to Michel Dänzer from comment #30)
> (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.

Yeah, I realized that, It's still odd behaviour, in both cases Chrome caps FPS to refresh rate (this case 85FPS), 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.

Just wanted to inform you guys on this, 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.

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

(In reply to Michel Dänzer from comment #32)
> (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. :)

You might be very right about unfortunate interaction between Chrome (and Chromium) and mutter frame timings, since I did tried "CLUTTER_DEFAULT_FPS=85" (and 84) env. value and it made 0 difference.

Yeah, but by setting 1 and using any other WM results in Chromium/Chrome being VSYNC-ed, or at least it looks like it is, there's no tear line and picture is smooth as it can be (while on mutter/clutter there's tear line), so for the sake of standardisation i would call it mutter/clutter configuration bug that will probably stay unresolved, plus it doesn't explain DRI2 behavior that follows same standard :).

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

(In reply to Michel Dänzer from comment #34)
> (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.
> 
Well, whatever it is, it affects only mutter/mutter based WM's, for now, workaround is to use vblank_mode value "1".
> 
> > 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.

Or unhappy accident for DRI3 :).