System Environment: -------------------------- Platform: Ivybridge Libdrm: (master)libdrm-2.4.54-9-g8fc62ca8ac010659023bb63c4759eb683de4f9af Mesa: (master)328e9593173bc69352e1707f119a7aca9d540cf9 Xserver: (master)xorg-server-1.15.99.902-117-g7ca458493aa2f0aa091c989ea0768611e0730bf5 Xf86_video_intel: (master)2.99.911-250-g4cafd1fbb1a2441a9ba5dac7f2a0e1b3f5957c62 Kernel: (drm-intel-nightly)455a8f Bug detailed description: ----------------------------- It fails on all platform. Piglit spec_OpenGL_1.0_gl-1.0-swapbuffers-behavior also fails. Bisect find it is regression on xf86_video_intel. I unable to bisect the culprit commit becasue some commit build failure. Anyway, it shows the first bad commit could be any of: 0fbe8995d51b4643f1cf06c07da8b4b5ac5ae7c3 67b37332bd45dd4cea297107bfdc9df21984fdcd 9cf6cd9726ed5ba73bb8c38c06f7b5c78706309b d8eb87f84f88ad2df42c6fed1d93df76589a14e3 975b9798be77b30cbed485583d0ccb48318708f7 Reproduce steps: ---------------------------- 1. xinit 2. bin/glx-create-context-current-no-framebuffer -fbo -auto
Fix you build bot.
The bisected commits also cause bug 79623.
set xorg.conf as below, it works well. Section "Device" Identifier "Intel" Option "DRI" "2" EndSection
Created attachment 101740 [details] build.log Build failure is due to "dri3.c:46:9: error: 'NullPixmap' undeclared". NullPixmap was removed in commit dd6db82680b05cde4a47116b7096c054f3837e20, and xf86 build passes from that.
(In reply to comment #1) > Fix you build bot. Hi, with the patch would fix build issue: -------------------- diff --git a/test/dri3.c b/test/dri3.c index b5eb4ba..45f3285 100644 --- a/test/dri3.c +++ b/test/dri3.c @@ -43,7 +43,7 @@ Pixmap dri3_create_pixmap(Display *dpy, xcb_dri3_pixmap_from_buffer(c, pixmap, draw, size, width, height, stride, depth, bpp, fd); return pixmap; } - return NullPixmap; + return 0; } Then bisect again, find the first bad commit is : commit d8eb87f84f88ad2df42c6fed1d93df76589a14e3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 8 16:25:32 2014 +0100 sna: Add support for DRI3
Hi Chris, would you pls take a look at this bug which blocked WebGL performance testing. Bug will disable WebGL in chrome(Firefox is OK)
DRI3 is still being developed/stabilized and its interaction with fences poorly specified. Mesa does not yet utilize the explicit fences implied in the spec. Chris will disable DRI3 by default in the ddx because there are a number of trivial-to-hit bugs that cause X or the compositor to stop updating. You should cross-reference https://bugs.freedesktop.org/show_bug.cgi?id=81551 for the patch that will identify the issue as being the explicit-vs-implicit fencing issue or something new.
(In reply to comment #7) > DRI3 is still being developed/stabilized and its interaction with fences > poorly specified. Mesa does not yet utilize the explicit fences implied in > the spec. > > Chris will disable DRI3 by default in the ddx because there are a number of > trivial-to-hit bugs that cause X or the compositor to stop updating. > > You should cross-reference > https://bugs.freedesktop.org/show_bug.cgi?id=81551 for the patch that will > identify the issue as being the explicit-vs-implicit fencing issue or > something new. It still fails on haswell, broadwell and baytrail with the patch. NOTE: It passes on ivybridge on latest driver now.
Created attachment 113030 [details] it should fix this issue
It passes on latest mesa master branch.
Verified it on haswell, broadwell and baytrail.
Do you mind reconfirming that you actually tested with DRI3 since the proposed patch is not yet included?
(In reply to Chris Wilson from comment #12) > Do you mind reconfirming that you actually tested with DRI3 since the > proposed patch is not yet included? Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add --enable-dri3 option. Without the proposed patch, I could easily reproduce this issue. And adding "DRI 2" option to Xorg.conf, this issue disappear.
(In reply to XiongZhang from comment #13) > Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add > --enable-dri3 option. > Without the proposed patch, I could easily reproduce this issue. And adding > "DRI 2" option to Xorg.conf, this issue disappear. I assume you refer to the original bug and versions of SW at that time. In the meanwhile X intel driver defaulted back to DRI2 from DRI3. I think you need now to set DRI to version 3 specifically in xorg.conf. Chris?
(In reply to Eero Tamminen from comment #14) > (In reply to XiongZhang from comment #13) > > Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add > > --enable-dri3 option. > > Without the proposed patch, I could easily reproduce this issue. And adding > > "DRI 2" option to Xorg.conf, this issue disappear. > > I assume you refer to the original bug and versions of SW at that time. > > In the meanwhile X intel driver defaulted back to DRI2 from DRI3. I think > you need now to set DRI to version 3 specifically in xorg.conf. Chris? I use last week's mesa and xf86-video-intel. I set DRI to version 3 in xorg.conf, the proposed patch fix this issue also.
(In reply to Chris Wilson from comment #12) > Do you mind reconfirming that you actually tested with DRI3 since the > proposed patch is not yet included? Sorry, I tested with DRI2, not DRI3. It still fails on DRI3(build with --enable-dri3,set DRI to version 3 in xorg.conf). It passes with attached patch on DRI3.
(In reply to Eero Tamminen from comment #14) > (In reply to XiongZhang from comment #13) > > Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add > > --enable-dri3 option. > > Without the proposed patch, I could easily reproduce this issue. And adding > > "DRI 2" option to Xorg.conf, this issue disappear. > > I assume you refer to the original bug and versions of SW at that time. > > In the meanwhile X intel driver defaulted back to DRI2 from DRI3. I think > you need now to set DRI to version 3 specifically in xorg.conf. Chris? Yes. You also needed to manually --enable-dri3. I've just fixed it that so we build DRI3 (if available) and just limit to DRI2 at runtime (and so allow selection of DRI3 with a normal build). commit db629a38342883176d58357fa014176c9e45115d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Feb 4 09:34:14 2015 +0000 Allow runtime selection between DRI levels Rather than imposing a maximum DRI level at compile time by compiling out unwanted protocol handlers, default to limiting it at runtime so that we can switch between any level. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
*** Bug 89050 has been marked as a duplicate of this bug. ***
The proposed patch doesn't seem to have been merged to mesa. XiongZhang: can you send it to ml ?
(In reply to Axel Davy from comment #19) > The proposed patch doesn't seem to have been merged to mesa. > > XiongZhang: can you send it to ml ? It's already there but people may have missed it. http://patchwork.freedesktop.org/patch/41638/
The patch is fine, except spacing.
-- 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/mesa/mesa/issues/95.
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.