Launchpad has imported 48 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=85064.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2014-10-15T15:04:25+00:00 Michael Catanzaro wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/0 ------------------------------------------------------------------------ On 2014-10-16T10:13:47+00:00 Eero-t-tamminen wrote: 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)? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/1 ------------------------------------------------------------------------ On 2014-10-16T14:34:20+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/2 ------------------------------------------------------------------------ On 2014-10-31T14:55:13+00:00 Michael Catanzaro wrote: (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. :/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/3 ------------------------------------------------------------------------ On 2014-11-05T14:39:54+00:00 Eero-t-tamminen wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/4 ------------------------------------------------------------------------ On 2014-11-05T16:34:18+00:00 Michael Catanzaro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/5 ------------------------------------------------------------------------ On 2014-11-13T17:03:49+00:00 Michael Catanzaro wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/6 ------------------------------------------------------------------------ On 2014-11-14T20:49:18+00:00 Matthew Hessel wrote: Created attachment 109481 xorg log after backing off to Oct 1 commit Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/7 ------------------------------------------------------------------------ On 2014-11-14T20:52:22+00:00 Matthew Hessel wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/8 ------------------------------------------------------------------------ On 2014-11-17T22:15:13+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/9 ------------------------------------------------------------------------ On 2014-11-18T21:14:56+00:00 Matthew Hessel wrote: 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.. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/10 ------------------------------------------------------------------------ On 2014-11-19T09:16:16+00:00 Eero-t-tamminen wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/11 ------------------------------------------------------------------------ On 2016-01-14T03:27:16+00:00 Michel Dänzer wrote: Does this still happen with current versions of the graphics stack, in particular libxcb 1.11.1 or newer? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/12 ------------------------------------------------------------------------ On 2016-01-14T04:41:55+00:00 Michael Catanzaro wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/13 ------------------------------------------------------------------------ On 2016-02-04T09:17:03+00:00 Martin-peres-n wrote: Created attachment 121508 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/14 ------------------------------------------------------------------------ On 2016-02-04T17:44:06+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/15 ------------------------------------------------------------------------ On 2016-02-04T17:50:49+00:00 Martin-peres-n wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/16 ------------------------------------------------------------------------ On 2016-02-04T20:04:01+00:00 Bastianilso wrote: Created attachment 121528 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/17 ------------------------------------------------------------------------ On 2016-02-04T20:04:31+00:00 Bastianilso wrote: Created attachment 121529 glxinfo from bastianilso ..and here's my glxinfo. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/18 ------------------------------------------------------------------------ On 2016-02-04T20:09:30+00:00 Bastianilso wrote: Created attachment 121530 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/19 ------------------------------------------------------------------------ On 2016-02-04T22:30:16+00:00 Martin-peres-n wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/20 ------------------------------------------------------------------------ On 2016-02-05T00:06:25+00:00 Martin-peres-n wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/21 ------------------------------------------------------------------------ On 2016-02-05T01:59:30+00:00 Michel Dänzer wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/22 ------------------------------------------------------------------------ On 2016-02-05T07:39:48+00:00 Martin-peres-n wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/23 ------------------------------------------------------------------------ On 2016-02-05T08:26:42+00:00 Martin-peres-n wrote: (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 :) Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/24 ------------------------------------------------------------------------ On 2016-02-05T08:30:21+00:00 Bastianilso wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/25 ------------------------------------------------------------------------ On 2016-02-05T14:20:01+00:00 Michael Catanzaro wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/26 ------------------------------------------------------------------------ On 2016-02-05T15:11:05+00:00 Martin-peres-n wrote: (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/. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/27 ------------------------------------------------------------------------ On 2016-02-05T15:15:01+00:00 Martin-peres-n wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/28 ------------------------------------------------------------------------ On 2016-03-02T09:53:37+00:00 Leho Kraav wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/29 ------------------------------------------------------------------------ On 2016-03-02T10:23:26+00:00 Martin-peres-n wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/30 ------------------------------------------------------------------------ On 2016-03-02T11:41:15+00:00 Michael Catanzaro wrote: Note that Chrome does not use WebKitGTK+ and has a completely different graphics architecture; might be worth reporting a second bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/31 ------------------------------------------------------------------------ On 2016-07-27T10:15:36+00:00 Fakefur wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/32 ------------------------------------------------------------------------ On 2016-07-27T14:28:43+00:00 Michael Catanzaro wrote: (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/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/33 ------------------------------------------------------------------------ On 2016-07-27T14:32:25+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/34 ------------------------------------------------------------------------ On 2016-07-28T13:07:25+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/35 ------------------------------------------------------------------------ On 2016-08-03T00:24:42+00:00 Airlied-freedesktop wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/36 ------------------------------------------------------------------------ On 2016-08-03T00:54:43+00:00 Airlied-freedesktop wrote: 00:46 < airlied> keithp: dri3/present question 00:46 -!- ofourdan [~ofour...@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 [~ofour...@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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/37 ------------------------------------------------------------------------ On 2016-08-03T01:07:50+00:00 Michel Dänzer wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/38 ------------------------------------------------------------------------ On 2016-08-03T01:30:20+00:00 Airlied-freedesktop wrote: 01:24 < Kayden> seems like they could have also used the swap control extensions to stop vsync'ing themselves... :/ Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/39 ------------------------------------------------------------------------ On 2016-08-03T06:44:05+00:00 Carlos Garcia Campos wrote: (In reply to Dave Airlie from comment #37) > 00:46 < airlied> keithp: dri3/present question > 00:46 -!- ofourdan [~ofour...@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 [~ofour...@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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/40 ------------------------------------------------------------------------ On 2016-08-03T07:15:56+00:00 Michel Dänzer wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/43 ------------------------------------------------------------------------ On 2016-08-03T08:29:34+00:00 Carlos Garcia Campos wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/46 ------------------------------------------------------------------------ On 2016-08-06T10:55:55+00:00 N. W. wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/51 ------------------------------------------------------------------------ On 2016-08-06T10:57:49+00:00 N. W. wrote: Correction, actually meant: Product: xorg Component: Driver/modesetting https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=Driver%2Fmodesetting&list_id=588477&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=xorg&query_format=advanced&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=MOVED&resolution=NOTABUG&resolution=NOTOURBUG Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/52 ------------------------------------------------------------------------ On 2016-08-06T14:46:04+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/53 ------------------------------------------------------------------------ On 2017-01-12T18:53:39+00:00 Michael Catanzaro wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/60 ------------------------------------------------------------------------ On 2018-08-24T07:43:20+00:00 Michel Dänzer wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1615871/comments/64 -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1615871 Title: Poor performance with WebKit on yakkety with Intel modesetting enabled To manage notifications about this bug go to: https://bugs.launchpad.net/webkit-open-source/+bug/1615871/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
