| Bug ID | 99418 |
|---|---|
| Summary | DRI3 Stuttering while scrolling in Chromium/Chrome with VBLAN= K off |
| Product | DRI |
| Version | XOrg git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | lei.pero@gmail.com |
Not sure where to report this issue, as title says, problem is= not present with VBLANK enabled. Vblank is disabled in both xorg configuration and .drirc profile (and clutt= er when using GNOME). Expected behaviour (DRI2): When scrolling pages (with smooth scroll) in Chromium for example, it defau= lts at FPS=3Drefresh rate (my case 85Hz), there is just tearline present, every= thing else is smooth and fine (as with vblank enabled, except tearline). On DRI3 however, even on simple forums/text based pages, there is stuttering/choppy scrolling. GPU is HD 6770, Xorg server version is 1.19.1, if you need more information/testing, would be happy to do it.
Please attach the corresponding Xorg log file and output of gl= xinfo.
Created attachment 128993 [details]<=
/a>
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<= /a> [details] > glxinfo (In reply to Michel D=C3=A4nzer from comment #1) > Please attach the corresponding Xorg log file an= d output of glxinfo. Sure, files attached. To be more accurate, it's like "ghosting" w= hen scrolling with DRI3 on most pages (google search results, phoronix forum etc.), even = tho CRT displays do not ghost.
| What | Removed | Added |
|---|---|---|
| Attachment #128995 mime type | text/x-log | text/plain |
| What | Removed | Added |
|---|---|---|
| Attachment #128994 mime type | text/x-log | text/plain |
I can't seem to reproduce any unexpected behaviour with radeon= si. 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 l=
ink
or something). I think this is hardware specific onr adeon driver (only?).<=
/pre>
Created attachment 129017 [det=
ails]
DRI2 video
DRI2
Created attachment 129018 [det=
ails]
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 s= eem slightly smoother. Can you create another comparison video with the environment variable GALLIUM_HUD=3D.dfps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,cpu+t= emperature+GPU-load,.dnum-bytes-moved,.dbuffer-wait-time,.dnum-compilations= +num-shaders-created set when starting chromium? It should overlay some graphs showing the frame= rate and other performance related values. > I think this is hardware specific onr adeon driv= er (only?). Does it not happen using the modesetting driver instead of radeon?
(In reply to Michel D=C3=A4nzer 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 wo= uld do the > > justice, >=20 > Indeed, I'm afraid I can't see much difference, though the DRI2 videos= do > seem slightly smoother. >=20 > Can you create another comparison video with the environment variable > GALLIUM_HUD=3D.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. >=20 >=20 > > I think this is hardware specific onr adeon driver (only?). >=20 > 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 scrolli= ng, but I can also notice it in standard GNOME-shell animations (for example, a= fter logging in startup animation is not smooth as it should be/as it is on rade= on DRI2), hope this information helps a bit. I'm very positive i can notice sa= me behaviour in games also (I'm not a gamer, so just a few I play).
Created attachment 129048 [detai=
ls]
DRI2_EV1
DRI2 Chromium with EV
Created attachment 129049 [detai=
ls]
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=3D1 . 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 al= lows 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=C3=A4nzer from comment #17) > (In reply to lei.pero from comment #14) > > It does happen on modesetting driver regardless of DRI version, s= trange. >=20 > 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=3D1 . >=20 > 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 DR= I3 > allows triple buffering, and might be at least partially an application > issue. It would be interesting though if it also happens with a non-AM= D GPU. >=20 > BTW, is there any particular reason why you're disabling sync-to-vblan= k? It > is the intended mechanism for smooth animation... I didn't know that about modesetting driver, anyway, even with LIBGL_DRI3_DISABLE=3D1 same thing happens. I don't how to disable tripple buffering to test it and if it's possible, m= an 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.0GH= z 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 codi= ng or PC CPU power) CHromium/Firefox can't keep up with 85FPS, while drop happ= ens, 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 =3D = 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 accelerat= ion method, not DRI3 actually, so maybe i should change the title of the bug report? Now, with DRI3 and Option "AccelMethod" "EXA", it's act= ually even better compared to DRI2 (one tearline, instead of two on DRI2), the problem is gla= mor 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 t= hink 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, any= way, even with > LIBGL_DRI3_DISABLE=3D1 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_b= ack =3D 1 in the else case.