Bug 85064 - modesetting driver plus DRI3 causes extremely slow scrolling with WebKitGTK+ in accelerated compositing mode
Summary: modesetting driver plus DRI3 causes extremely slow scrolling with WebKitGTK+ ...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/modesetting (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-15 15:04 UTC by Michael Catanzaro
Modified: 2018-12-13 18:12 UTC (History)
23 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log after backing off to Oct 1 commit (21.87 KB, text/plain)
2014-11-14 20:49 UTC, Matt Hessel
no flags Details
Envdump of epiphany on an up-to-date ArchLinux (2016-02-04), not showing the problem (30.25 KB, text/plain)
2016-02-04 09:17 UTC, Martin Peres
no flags Details
output of running epiphany with LIBGL_DEBUG=verbose (879 bytes, text/plain)
2016-02-04 20:04 UTC, Bastian Ilso
no flags Details
glxinfo from bastianilso (23.82 KB, text/plain)
2016-02-04 20:04 UTC, Bastian Ilso
no flags Details
bastianilso's Xorg.0.log from February 4th (26.14 KB, text/plain)
2016-02-04 20:09 UTC, Bastian Ilso
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2014-10-15 15:04:25 UTC
With Epiphany/WebKitGTK+, scrolling on many pages (such as any search results page on duckduckgo.com) is extremely slow and choppy. Launching epiphany with LIBGL_DRI3_DISABLE=1 causes these pages to work perfectly.

This is a critical bug for us since DuckDuckGo is our default search engine.

mesa-dri-drivers-10.3-1.20140927.fc21.x86_64
kernel-3.17.0-300.fc21.x86_64
Comment 1 Eero Tamminen 2014-10-16 10:13:47 UTC
Does Mesa commit f7a355556ef5fe23056299a77414f9ad8b5e5a1d help?

(It works around DRI3 sync slowdown, but there are also other slowdown bugs for DRI3 here in FDO bugtracker, just search for "DRI3".)

Does Epiphany/WebKitGTK+ uses GL for something else besides WebGL, or do these problematic pages use WebGL?  Or how Mesa is involved in this (DRI3 is mainly X server side thing)?
Comment 2 Michael Catanzaro 2014-10-16 14:34:20 UTC
(In reply to Eero Tamminen from comment #1)
> Does Mesa commit f7a355556ef5fe23056299a77414f9ad8b5e5a1d help?

I'll try to test this as soon as I can. Sorry for the delay.

> (It works around DRI3 sync slowdown, but there are also other slowdown bugs
> for DRI3 here in FDO bugtracker, just search for "DRI3".)
> 
> Does Epiphany/WebKitGTK+ uses GL for something else besides WebGL

Yes, most notably for accelerated compositing:

"alex:  I mean, accelerated compositing is activated by default and probably is creating some graphic layers that are composited using GL in that webpage"

> , or do
> these problematic pages use WebGL?  

We actually have WebGL disabled by default.

> Or how Mesa is involved in this (DRI3 is
> mainly X server side thing)?

It might not be a mesa bug; I just filed against mesa because bug #81623 was filed against mesa.
Comment 3 Michael Catanzaro 2014-10-31 14:55:13 UTC
(In reply to Michael Catanzaro from comment #2)
> (In reply to Eero Tamminen from comment #1)
> > Does Mesa commit f7a355556ef5fe23056299a77414f9ad8b5e5a1d help?
> 
> I'll try to test this as soon as I can. Sorry for the delay.

Ah drat. This won't happen anytime soon, sorry. :/
Comment 4 Eero Tamminen 2014-11-05 14:39:54 UTC
(In reply to Michael Catanzaro from comment #3)
> > I'll try to test this as soon as I can. Sorry for the delay.
> 
> Ah drat. This won't happen anytime soon, sorry. :/

Ok.  What are your X server and X Intel driver versions?
Comment 5 Michael Catanzaro 2014-11-05 16:34:18 UTC
xorg-x11-server-Xorg-1.16.1-1.fc21
xorg-x11-drv-intel-2.99.916-2.fc21

I've also just now tested mesa-dri-drivers-10.3.2-1.20141028.fc21, which surely includes the commit you asked me to test. Unfortunately the issue is still present.
Comment 6 Michael Catanzaro 2014-11-13 17:03:49 UTC
We're also getting reports that YouTube videos are extremely choppy unless LIBGL_DRI3_DISABLE is used.

For the sanity of anyone trying to debug this: I'm pushing out a new version of Epiphany for Fedora that sets this environment variable at the beginning of main, since we really have no other choice at this point, so don't use Fedora Epiphany for testing this bug.
Comment 7 Matt Hessel 2014-11-14 20:49:18 UTC
Created attachment 109481 [details]
xorg log after backing off to Oct 1 commit
Comment 8 Matt Hessel 2014-11-14 20:52:22 UTC
looks to me like it is something with the xf86-video-intel code.

I re-compiled the driver to commit de7185bbf48ca2f617466b98328d0fdae4df1b44  from October 1st, and the issue for me is gone.

I think something happened between that one and 9a5ca59d2b7b209e6f56dd3f94d4ae6f06e1ecdc on the 15th of October -- that is when I started having this issue on my SNB Intel chip.
Comment 9 Michael Catanzaro 2014-11-17 22:15:13 UTC
(In reply to Matt Hessel from comment #8)
> looks to me like it is something with the xf86-video-intel code.
> 
> I re-compiled the driver to commit de7185bbf48ca2f617466b98328d0fdae4df1b44 
> from October 1st, and the issue for me is gone.
> 
> I think something happened between that one and
> 9a5ca59d2b7b209e6f56dd3f94d4ae6f06e1ecdc on the 15th of October -- that is
> when I started having this issue on my SNB Intel chip.

Hm, I'm not sure, since I first noticed the issue in Fedora 21 on September 13. That's not to say that the issue was introduced around that time: that was just the date I first tested Fedora 21.
Comment 10 Matt Hessel 2014-11-18 21:14:56 UTC
I think there are multiple issues regarding DRI3, not limited to the sandboxing stuff in Chrome (which has been an issue for me longer than this.)  But I started having screen update issues with Guake in a terminal in October.  When typing it would update the cursor and the letters similar to running Wordperfect on my old PC in 1989. (type 4 digits, and it shows them to you after the third or fourth)

On top of that, I wasn't able to get chrome or chromium to run in Gnome3 at all at that point.

Backing the driver out to this version eliminates these issues for me.  Other way I could get it working was to disable dri3 in xorg.conf.

Terminal acts normal again, and chrome will run without (too much) stupidity..
Comment 11 Eero Tamminen 2014-11-19 09:16:16 UTC
(In reply to Matt Hessel from comment #10)
> I think there are multiple issues regarding DRI3, not limited to the
> sandboxing stuff in Chrome (which has been an issue for me longer than
> this.)  But I started having screen update issues with Guake in a terminal
> in October.  When typing it would update the cursor and the letters similar
> to running Wordperfect on my old PC in 1989. (type 4 digits, and it shows
> them to you after the third or fourth)

Does your X server use latest X intel driver and latest of the related extensions (e.g. present)?  Is your compositor also using latest versions?
Comment 12 Michel Dänzer 2016-01-14 03:27:16 UTC
Does this still happen with current versions of the graphics stack, in particular libxcb 1.11.1 or newer?
Comment 13 Michael Catanzaro 2016-01-14 04:41:55 UTC
(In reply to Michel Dänzer from comment #12)
> Does this still happen with current versions of the graphics stack, in
> particular libxcb 1.11.1 or newer?

An Arch user complained to me about this bug just last month, and the LIBGL_DRI3_DISABLE=1 trick "fixed" the issue for him. I see libxcb 1.11.1 has been in Arch since September, so it seems extremely likely that he was using it at the time.

The issue is 100% reproducible on any DuckDuckGo search results page (e.g. [1]) when DRI3 is enabled on a wide variety of hardware. However, my distro of choice, Fedora, has disabled DRI3, and therefore I am personally no longer able to easily reproduce.

[1] https://duckduckgo.com/?q=freedesktop&t=epiphany&ia=about
Comment 14 Martin Peres 2016-02-04 09:17:03 UTC
Created attachment 121508 [details]
Envdump of epiphany on an up-to-date ArchLinux (2016-02-04), not showing the problem

Hello Michael,

Sorry for the long delay. I just installed gnome and epiphany on my machine and failed to reproduce any slow scrolling, even with the linked page. I confirmed that I am using DRI3 using env_dump (will attach the full report). How can I get in touch with the user who reported this issue?

Also, as I was trying to reproduce the choppiness of youtube videos, I only managed to get black videos on both Youtube and Vimeo. When displaying the "stats for nerds", it says the resolution is 0x0. The sound was playing perfectly and the preview in the progress bar also worked as expected. Is this a known bug?
Comment 15 Michael Catanzaro 2016-02-04 17:44:06 UTC
(In reply to Martin Peres from comment #14)
> How can I get in touch with the user who reported this issue?

I've responded with contact info via email.

> Also, as I was trying to reproduce the choppiness of youtube videos, I only
> managed to get black videos on both Youtube and Vimeo. When displaying the
> "stats for nerds", it says the resolution is 0x0. The sound was playing
> perfectly and the preview in the progress bar also worked as expected. Is
> this a known bug?

No, that is not a known bug. YouTube works fine for me (on Fedora 23 with DRI2). Bug reports on bugzilla.webkit.org would be welcome (prefix the title with [GStreamer] and select component: Media Elements).

I have never seen Vimeo work before though; it seems to require an encumbered codec.
Comment 16 Martin Peres 2016-02-04 17:50:49 UTC
(In reply to Michael Catanzaro from comment #15)
> (In reply to Martin Peres from comment #14)
> > How can I get in touch with the user who reported this issue?
> 
> I've responded with contact info via email.

Thanks, but why not continue here? If there is a privacy issue, I guess I can just keep people up to date.

> 
> > Also, as I was trying to reproduce the choppiness of youtube videos, I only
> > managed to get black videos on both Youtube and Vimeo. When displaying the
> > "stats for nerds", it says the resolution is 0x0. The sound was playing
> > perfectly and the preview in the progress bar also worked as expected. Is
> > this a known bug?
> 
> No, that is not a known bug. YouTube works fine for me (on Fedora 23 with
> DRI2). Bug reports on bugzilla.webkit.org would be welcome (prefix the title
> with [GStreamer] and select component: Media Elements).

Thanks! I will try again tomorrow morning and have a closer look at the logs, there may be something wrong with my setup. If I cannot find anything, I will report the bug.

> 
> I have never seen Vimeo work before though; it seems to require an
> encumbered codec.

Ok, I should have tried dailymotion then.
Comment 17 Bastian Ilso 2016-02-04 20:04:01 UTC
Created attachment 121528 [details]
output of running epiphany with LIBGL_DEBUG=verbose

I believe I am that arch linux user. Here's the logs from running: 

LIBGL_DEBUG=verbose epiphany
Comment 18 Bastian Ilso 2016-02-04 20:04:31 UTC
Created attachment 121529 [details]
glxinfo from bastianilso

..and here's my glxinfo.
Comment 19 Bastian Ilso 2016-02-04 20:09:30 UTC
Created attachment 121530 [details]
bastianilso's Xorg.0.log from February 4th

..and finally my Xorg.0.log (found in ~/.local/share/xorg/).

Before testing, I made a full system update.
Comment 20 Martin Peres 2016-02-04 22:30:16 UTC
Thanks Bastian! I have easy access to a Broadwell GT2, let's hope I can reproduce the issue.

In the mean time, could you try installing xf86-video-intel and try to reproduce the issue with it? Right now, you are using the modesetting driver.
Comment 21 Martin Peres 2016-02-05 00:06:25 UTC
(In reply to Martin Peres from comment #20)
> Thanks Bastian! I have easy access to a Broadwell GT2, let's hope I can
> reproduce the issue.
> 
> In the mean time, could you try installing xf86-video-intel and try to
> reproduce the issue with it? Right now, you are using the modesetting driver.

Well, look no further, this is your issue. I tried using the modesetting driver and got absolute garbage out. Stale rendering, extreme slowness. Why didn't I think of this before...

Anyway, will try to see if I can fix this issue. Seems like I will have a happy time in glamor and mesa's code tomorrow.

Thanks, because you are the first one who finally answered me and provided me with real information.
Comment 22 Michel Dänzer 2016-02-05 01:59:30 UTC
(In reply to Martin Peres from comment #21)
> I tried using the modesetting driver and got absolute garbage out. Stale
> rendering, extreme slowness. Why didn't I think of this before...
> 
> Anyway, will try to see if I can fix this issue. Seems like I will have a
> happy time in glamor and mesa's code tomorrow.

Note that I couldn't reproduce this problem with xf86-video-ati using glamor. I guess the problem could be in the Mesa driver, but the modesetting driver seems more likely.
Comment 23 Martin Peres 2016-02-05 07:39:48 UTC
(In reply to Michel Dänzer from comment #22)
> (In reply to Martin Peres from comment #21)
> > I tried using the modesetting driver and got absolute garbage out. Stale
> > rendering, extreme slowness. Why didn't I think of this before...
> > 
> > Anyway, will try to see if I can fix this issue. Seems like I will have a
> > happy time in glamor and mesa's code tomorrow.
> 
> Note that I couldn't reproduce this problem with xf86-video-ati using
> glamor. I guess the problem could be in the Mesa driver, but the modesetting
> driver seems more likely.

Well, the problem is likely limited to Intel. We will likely need a patch like this one[1] until we get explicit fencing.

[1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=fc984e8953d61901b255422c8f56eb79a2dd2a28
Comment 24 Martin Peres 2016-02-05 08:26:42 UTC
(In reply to Michel Dänzer from comment #22)
> (In reply to Martin Peres from comment #21)
> > I tried using the modesetting driver and got absolute garbage out. Stale
> > rendering, extreme slowness. Why didn't I think of this before...
> > 
> > Anyway, will try to see if I can fix this issue. Seems like I will have a
> > happy time in glamor and mesa's code tomorrow.
> 
> Note that I couldn't reproduce this problem with xf86-video-ati using
> glamor. I guess the problem could be in the Mesa driver, but the modesetting
> driver seems more likely.

So, since the NVIDIA GTX 750 is not supported by Nouveau and the modesetting driver is used instead, I decided to try it out only to find out it has the exact same issue as Intel.

So, it not exactly rules out the possibility of a bug in mesa, but it is more likely to be a bug in the modesetting driver. Time to check out its code, but at least it is super easy to reproduce :)
Comment 25 Bastian Ilso 2016-02-05 08:30:21 UTC
(In reply to Martin Peres from comment #20)
> Thanks Bastian! I have easy access to a Broadwell GT2, let's hope I can
> reproduce the issue.
> 
> In the mean time, could you try installing xf86-video-intel and try to
> reproduce the issue with it? Right now, you are using the modesetting driver.

I do have xf86-video-intel installed. Perhaps I need to do some manual intervention to disable using the modesetting driver?
Comment 26 Michael Catanzaro 2016-02-05 14:20:01 UTC
I've seen this bug on several Linux distros (including Fedora and, I believe, openSUSE and Ubuntu) and I fear it's quite unlikely I was using the modesetting driver in those cases. But looking at the time I reported this bug compared to the time of the xf86-video-intel commit in comment #23, perhaps the bug used to affect xf86-video-intel but no longer does?
Comment 27 Martin Peres 2016-02-05 15:11:05 UTC
(In reply to Bastian Ilso from comment #25)
> (In reply to Martin Peres from comment #20)
> > Thanks Bastian! I have easy access to a Broadwell GT2, let's hope I can
> > reproduce the issue.
> > 
> > In the mean time, could you try installing xf86-video-intel and try to
> > reproduce the issue with it? Right now, you are using the modesetting driver.
> 
> I do have xf86-video-intel installed. Perhaps I need to do some manual
> intervention to disable using the modesetting driver?

I would suggest reviewing your configuration in /etc/X11/xorg.conf.d/ and /usr/share/X11/xorg.conf.d/.
Comment 28 Martin Peres 2016-02-05 15:15:01 UTC
(In reply to Michael Catanzaro from comment #26)
> I've seen this bug on several Linux distros (including Fedora and, I
> believe, openSUSE and Ubuntu) and I fear it's quite unlikely I was using the
> modesetting driver in those cases. But looking at the time I reported this
> bug compared to the time of the xf86-video-intel commit in comment #23,
> perhaps the bug used to affect xf86-video-intel but no longer does?

For sure, Intel was affected. I will try to revert the patch and see if I can reproduce the same behaviour as the modesetting driver. If so, that will make it clear what I need to do for the modesetting driver.

I started reading the code of glamor and the modesetting driver, let's hope I can pull this off. Otherwise, I will contact its original developers for help.
Comment 29 Leho Kraav (:macmaN :lkraav) 2016-03-02 09:53:37 UTC
I think I bumped into this today. Running gentoo and this package set:

x11-drivers/xf86-video-intel-2.99.917_p20160218 USE="dri3 uxa" (so GLAMOR, not SNA)
media-libs/mesa-11.0.6 USE=dri3
www-client/google-chrome-48.0.2564.116_p1
x11-base/xorg-server-1.18.1 USE=glamor
x11-wm/i3-4.11

Hardware: DELL E7440 Haswell, with HDMI monitor directly connected, DP monitor connected through dock port.

Strange thing compared to previous comments is that Chrome slows down to a crawl *only* when moved to the third, DP monitor. Everything works OK when chrome is sent to laptop eDP panel, or HDMI monitor.

Launching with

$ LIBGL_DRI3_DISABLE=1 google-chrome-stable

successfully works around the problem, so seems to indicate this bug is the right place to be. Let me know if there's another, possibly more accurate bug available.

What's the possible next step here?
Comment 30 Martin Peres 2016-03-02 10:23:26 UTC
(In reply to Leho Kraav (:macmaN :lkraav) from comment #29)
> I think I bumped into this today. Running gentoo and this package set:
> 
> x11-drivers/xf86-video-intel-2.99.917_p20160218 USE="dri3 uxa" (so GLAMOR,
> not SNA)
> media-libs/mesa-11.0.6 USE=dri3
> www-client/google-chrome-48.0.2564.116_p1
> x11-base/xorg-server-1.18.1 USE=glamor
> x11-wm/i3-4.11
> 
> Hardware: DELL E7440 Haswell, with HDMI monitor directly connected, DP
> monitor connected through dock port.
> 
> Strange thing compared to previous comments is that Chrome slows down to a
> crawl *only* when moved to the third, DP monitor. Everything works OK when
> chrome is sent to laptop eDP panel, or HDMI monitor.
> 
> Launching with
> 
> $ LIBGL_DRI3_DISABLE=1 google-chrome-stable
> 
> successfully works around the problem, so seems to indicate this bug is the
> right place to be. Let me know if there's another, possibly more accurate
> bug available.
> 
> What's the possible next step here?

Please send me your Xorg logs. I want to make sure you really are using the intel driver and not the modesetting driver.
Comment 31 Michael Catanzaro 2016-03-02 11:41:15 UTC
Note that Chrome does not use WebKitGTK+ and has a completely different graphics architecture; might be worth reporting a second bug.
Comment 32 fakefur 2016-07-27 10:15:36 UTC
hi guys

i just wanted to add that this happened to me in the last few days after an intel driver update on debian testing (stretch) running the current gnome 3.20 desktop

if i log out and switch to a wayland session the bug completely disappears and life is back to normal fast scrolly land

this is on a thinkpad t420 with intel graphics (3000 series i believe)
Comment 33 Michael Catanzaro 2016-07-27 14:28:43 UTC
(In reply to fakefur from comment #32)
> hi guys
> 
> i just wanted to add that this happened to me in the last few days after an
> intel driver update on debian testing (stretch) running the current gnome
> 3.20 desktop

Yeah, it's due to https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/
Comment 34 Michael Catanzaro 2016-07-27 14:32:25 UTC
(In reply to Michael Catanzaro from comment #31)
> Note that Chrome does not use WebKitGTK+ and has a completely different
> graphics architecture; might be worth reporting a second bug.

Oh and to complicate matters further, we're switching to a new graphics architecture in WebKitGTK+ 2.14.0, which is available now for testing in WebKitGTK+ 2.13.4. It might cause this bug to occur all of the time (because accelerated compositing mode is now used always), or never (who knows!), but it should definitely no longer occur on a small subset of web pages anymore.
Comment 35 Michael Catanzaro 2016-07-28 13:07:25 UTC
(In reply to Michael Catanzaro from comment #34)
> Oh and to complicate matters further, we're switching to a new graphics
> architecture in WebKitGTK+ 2.14.0, which is available now for testing in
> WebKitGTK+ 2.13.4. It might cause this bug to occur all of the time (because
> accelerated compositing mode is now used always), or never (who knows!)

It now occurs all of the time.
Comment 36 Dave Airlie 2016-08-03 00:24:42 UTC
I've posted a possible fix to xorg-devel, this is due to the offscreen rendering getting throttle due to the driver not being able to link it to a crtc.

I'm not sure if the fix I posted is the full answer.
Comment 37 Dave Airlie 2016-08-03 00:54:43 UTC
00:46 < airlied> keithp: dri3/present question
00:46 -!- ofourdan [~ofourdan@107-2.ar.fundp.ac.be] has quit [Ping timeout: 260 seconds]
00:46 < airlied> keithp: epiphany/webkit appears to be drawing offscreen
00:46 < keithp> a fine plan
00:46 < airlied> and currently -modeseting returned no crtc for that
00:46 -!- ofourdan [~ofourdan@107-2.ar.fundp.ac.be] has joined #xorg-devel
00:46 < airlied> so we ended up throttling to the 1s fake crtc
00:47 < keithp> oh, 'offscreen' and not to a pixmap?
00:47 < airlied> yup offscreen not a pixmap
00:47 < keithp> wtf?
00:47 < airlied> I can say bong :)
00:47 < keithp> well, sucks to do something stupid?
00:47 < airlied> yes appears to be a window at +2000 or something
00:47 < keithp> and so what would they like us to do?
00:48 < airlied> "x = 2881, 
00:48 < airlied>     y = 0, width = 2910, height = 1783"
00:48 < airlied> well -amdgpu didn't hit the problem I think by accident, as it alwasys picked the primary crtc no matter what
00:48 < airlied> if nothing else fit
00:48 < keithp> are they doing they're own compositing or something?
00:49 < airlied> it's one of those multi-process rendering things
00:49 < airlied> web browser and per-process web renderer
00:49 < keithp> sure, which is obviously a fine plan
00:49 < keithp> how are they capturing those pixels then?
00:49 < airlied> not sure, how they get them into the final image
00:49 < airlied> must be compositing them somehow I suppose
00:50 < keithp> I assume it's a deeply nested child window and they're doing their own compositing
00:50 < keithp> So, they can't use a pixmap because GL sucks, I assume
00:50 < airlied> yeah most likely a GL suckage
00:50 < airlied> as they are defintely swapbuffersing
00:52 < airlied> but yeah I'd just think we need to standardise the response to this behaviour :)
00:52 < keithp> I already did
00:52 < airlied> rather than luck of the driver maintainer draw
00:52 < keithp> anyone using DRI3 will get one frame per second
00:53 < airlied> so that's likely a big change from DRI2 behaviour
00:53 < keithp> DRI2 behaviour used to be unthrottled entirely
00:53 < keithp> you'd get infinite FPS
00:54 < keithp> which kinda sucked when the screen saver fired and your CPU/GPU utilization went to 100%
00:54 < airlied> I suppose GLX specifies nothing useful either
Comment 38 Michel Dänzer 2016-08-03 01:07:50 UTC
(In reply to Dave Airlie from comment #37)
> 00:50 < keithp> So, they can't use a pixmap because GL sucks, I assume
> 00:50 < airlied> yeah most likely a GL suckage

[Citation needed]

Why exactly can't they use pixmaps for this?


> 00:53 < keithp> DRI2 behaviour used to be unthrottled entirely
> 00:53 < keithp> you'd get infinite FPS
> 00:54 < keithp> which kinda sucked when the screen saver fired and your
> CPU/GPU utilization went to 100%

Actually, the DRI2 behaviour depends on the driver. The -ati/amdgpu drivers probably synchronize to the same CRTC as with DRI3, and extrapolate the refresh timings using timers while the CRTC is off.
Comment 39 Dave Airlie 2016-08-03 01:30:20 UTC
01:24 < Kayden> seems like they could have also used the swap control extensions to stop vsync'ing themselves... :/
Comment 40 Carlos Garcia Campos 2016-08-03 06:44:05 UTC
(In reply to Dave Airlie from comment #37)
> 00:46 < airlied> keithp: dri3/present question
> 00:46 -!- ofourdan [~ofourdan@107-2.ar.fundp.ac.be] has quit [Ping timeout:
> 260 seconds]
> 00:46 < airlied> keithp: epiphany/webkit appears to be drawing offscreen
> 00:46 < keithp> a fine plan
> 00:46 < airlied> and currently -modeseting returned no crtc for that
> 00:46 -!- ofourdan [~ofourdan@107-2.ar.fundp.ac.be] has joined #xorg-devel
> 00:46 < airlied> so we ended up throttling to the 1s fake crtc
> 00:47 < keithp> oh, 'offscreen' and not to a pixmap?
> 00:47 < airlied> yup offscreen not a pixmap
> 00:47 < keithp> wtf?
> 00:47 < airlied> I can say bong :)
> 00:47 < keithp> well, sucks to do something stupid?
> 00:47 < airlied> yes appears to be a window at +2000 or something
> 00:47 < keithp> and so what would they like us to do?
> 00:48 < airlied> "x = 2881, 
> 00:48 < airlied>     y = 0, width = 2910, height = 1783"

Yes, this is because we use the screen width + 1 to position our window offscreen:

WidthOfScreen(screen) + 1, 0, 1, 1,

and it turns out that simply using -1, -1 as coordinates fixes the problem.
Comment 41 Michel Dänzer 2016-08-03 07:15:56 UTC
(In reply to Carlos Garcia Campos from comment #40)
> Yes, this is because we use the screen width + 1 to position our window
> offscreen:
> 
> WidthOfScreen(screen) + 1, 0, 1, 1,

FWIW, WidthOfScreen is bad anyway because that's just how wide the screen happened to be when the X11 display connection was established. The screen can be widened after that via the RandR extension, in which case the window would become visible.

> and it turns out that simply using -1, -1 as coordinates fixes the problem.

Weird, not sure why that avoids the problem; maybe there's an off-by-one bug somewhere which causes the window to be incorrectly considered on-screen. I wouldn't recommend relying on that. Also, again I'm not sure that negative coordinates can never be visible.


So, why does this code use a window instead of a pixmap?

Assuming a window is really the only possibility, (why) can't it set the swap interval to 0 via one of the GLX extensions for this, to prevent SwapBuffers operations from getting throttled?
Comment 42 Carlos Garcia Campos 2016-08-03 08:29:34 UTC
(In reply to Michel Dänzer from comment #41)
> (In reply to Carlos Garcia Campos from comment #40)
> > Yes, this is because we use the screen width + 1 to position our window
> > offscreen:
> > 
> > WidthOfScreen(screen) + 1, 0, 1, 1,
> 
> FWIW, WidthOfScreen is bad anyway because that's just how wide the screen
> happened to be when the X11 display connection was established. The screen
> can be widened after that via the RandR extension, in which case the window
> would become visible.

So, I guess using -1, -1 is still a good idea even if it fixes the problem by casuality.

> > and it turns out that simply using -1, -1 as coordinates fixes the problem.
> 
> Weird, not sure why that avoids the problem; maybe there's an off-by-one bug
> somewhere which causes the window to be incorrectly considered on-screen. I
> wouldn't recommend relying on that. Also, again I'm not sure that negative
> coordinates can never be visible.

Not sure it's off by one, using -100, -100 also works. Yes, that's more a workaround to make WebKitGTK+ usable again while we find the right solution.

> 
> So, why does this code use a window instead of a pixmap?

I don't really know it, I'm not a graphics expert.

> Assuming a window is really the only possibility, (why) can't it set the
> swap interval to 0 via one of the GLX extensions for this, to prevent
> SwapBuffers operations from getting throttled?

I tried using glXSwapIntervalSGI(0); after glXMakeCurrent but didn't help.
Comment 43 N. W. 2016-08-06 10:55:55 UTC
Question:

Why are such things not being discussed in

Component: xorg
Product: Driver/modesetting

?

Also:

Why was xf86-video-modesetting implemented into xorg-server?

Now that Debian and Ubuntu are using xf86-video-modesetting instead of xf86-video-intel, it's no longer possible to upgrade the DDX driver without upgrading xorg-server, since xf86-video-modesetting no longer is a separate package.

Oibaf has already said that he will not include updates for xorg-server in his PPA:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/24959-updated-and-optimized-ubuntu-free-graphics-drivers/page168

Regards
Comment 45 Michael Catanzaro 2016-08-06 14:46:04 UTC
(In reply to nw9165-3201 from comment #43)
> Question:
> 
> Why are such things not being discussed in
> 
> Component: xorg
> Product: Driver/modesetting
> 
> ?

Seems like a better place indeed. I just copied the product/component from bug #81623. Originally it was an Intel driver issue anyway; it wasn't until earlier this year that Martin realized the Intel driver had been fixed and only the modesetting driver was still affected.
Comment 46 Michael Catanzaro 2017-01-12 18:53:39 UTC
(In reply to Carlos Garcia Campos from comment #42) 
> So, I guess using -1, -1 is still a good idea even if it fixes the problem
> by casuality.

Note that Carlos "fixed" this issue in WebKit last summer by taking this approach, so it should no longer be possible to reproduce this issue in WebKit. It feels like a workaround, though, so I don't know whether this issue should be closed.
Comment 47 Michel Dänzer 2018-08-24 07:43:20 UTC
(In reply to Carlos Garcia Campos from comment #42)
> I tried using glXSwapIntervalSGI(0); after glXMakeCurrent but didn't help.

glXSwapIntervalSGI doesn't support 0, try glXSwapIntervalMESA instead.
Comment 48 GitLab Migration User 2018-12-13 18:12:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/59.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.