Created attachment 101003 [details] invisible 3D graphics on openSUSE 13.1 with kernel 3.11.10-11-desktop and after upgrade to xf86-video-intel-2.99.912-125.1.x86_64 3D graphics from the software Mathematica stopped to display. This is the 1st time ever I had this with intel graphics in openSUSE. The graphics from Mathematica can be grabbed, rotated, and scaled by the user. If the user grabs the graphics it re-shows. Once the user drops the graphics it disappears again. The attachment show the effect in a screenshot: 1) 3D graphics in its original form = invisible 2) 3D graphics upon user acting on it
Created attachment 101004 [details] 3D graphics when interacting with it
Can you please attach you Xorg.0.log?
Created attachment 101008 [details] Xorg.0.log
anything else
Can you try disabling DRI3? echo -e 'Section "Device"\n\tIdentifier "Intel"\n\tOption "DRI" "2"\nEndSection' >> /etc/X11/xorg.conf.d/intel.conf
Ok. Did that. No change. Xorg.0.log.1 attached to show changes w.r.t. DRI2. (Maybe I should mention, that the system I'm referring to had Mathematica running with the previous versions of the intel driver also here and Mathematica was displaying 3D graphics. So the problem started only with the new driver.)
Created attachment 101016 [details] Xorg after disabling DRI3
Hmm, so not DRI3 related. Can you please first checkout xf86-video-intel.git and check. If it still fails, can you please run a bisect?
Sorry, I'm just user "John average". Like most openSUSE users I get xf86-video-intel automatically from their update repos http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_13.1/x86_64/xf86-video-intel-2.99.912-125.1.x86_64.rpm I'd be happy to do what I can to spare at least the rest of these users from this issue with this driver - but compiling kernel modules into my system is beyond me and I'd probably break (at least) my distro's rpm data base. Hopefully some guru from this list has Mathematica running on her system and could step in.
I'll pick up a demo copy of Mathematica 9. Can you give me the newbie's guide to how to reproduce the example?
Hm, I bisected this to 8369166 "sna/dri2: Enable immediate buffer exchanges". I can reproduce this on both a Xeon E3 1235 and an old GMA900. The rotation of the plot seems to happen in an extra window above the location of the plot. Chris, to reproduce: Create a new notebook and enter e.g. Plot3D[Sin[x + y^2], {x, -3, 3}, {y, -2, 2}] Then press Shift+Return.
Ok. so I'm 'glad' that it seems that Leo has also observed this bug. Since he has already explained how to make a 3D plot with Mathematica, let me give one more piece of information - although I don't know if it is of any help: If you invoke Mathematica on the command line, then it allows you to switch to Mesa libraries, 'circumventing' whatever(?) part of the openGL system: ~> mathematica -mesa I realized today that when you do this, the behavior described in this bug report goes away (...and Mathematica graphics gets real-nice'n-slow...). Early Mathematica versions, like version 6.x or so, where known to crash on linux systems with Intel 945 cards and I remember that Wolfram Inc. was claiming that this had to do with 'limitations of open source drivers'. I also remember, that whenever in those times you filed them a graphics bug report, letting them know that you were using linux, they would tell you to use the '-mesa' option. I filed a bug report with them today. I'll let you know when they got back to me.
Ok, can you try diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c index efc790f..3d3c50d 100644 --- a/src/sna/sna_dri2.c +++ b/src/sna/sna_dri2.c @@ -1485,6 +1485,8 @@ can_xchg(struct sna * sna, WindowPtr win = (WindowPtr)draw; PixmapPtr pixmap; + return false; + if (draw->type == DRAWABLE_PIXMAP) return false; to see if it using xchg swaps or if it is a side-effect of that patch on the regular code that broke Mathematica?
Yes, that behaves as it should. (In reply to comment #13) > Ok, can you try > > diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c > index efc790f..3d3c50d 100644 > --- a/src/sna/sna_dri2.c > +++ b/src/sna/sna_dri2.c > @@ -1485,6 +1485,8 @@ can_xchg(struct sna * sna, > WindowPtr win = (WindowPtr)draw; > PixmapPtr pixmap; > > + return false; > + > if (draw->type == DRAWABLE_PIXMAP) > return false; > > to see if it using xchg swaps or if it is a side-effect of that patch on the > regular code that broke Mathematica?
I'm sorry, I had software rendering on. It does in fact not work with your patch. (In reply to comment #14) > Yes, that behaves as it should.
sorry to enter here once more: I just checked out this drivers repository and now it seems to me, that xf86-video-intel is no 'kernel module' in the sense that on built it needs not to include kernel headers from a configured kernel built directory. Instead one just needs to do a usual ./autogen.sh --prefix=/usr make sudo make install is that all?
(In reply to comment #16) > ./autogen.sh --prefix=/usr > make > sudo make install > > is that all? Yes. It should tell you what packages it needs (if any), though you may need to translate those to whatever they are called on your distro.
(In reply to comment #11) > Hm, I bisected this to 8369166 "sna/dri2: Enable immediate buffer exchanges". > I can reproduce this on both a Xeon E3 1235 and an old GMA900. > > The rotation of the plot seems to happen in an extra window above the > location of the plot. > > Chris, to reproduce: Create a new notebook and enter e.g. > > Plot3D[Sin[x + y^2], {x, -3, 3}, {y, -2, 2}] > > Then press Shift+Return. Gotcha.
The issue is: diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c index a8b0db4..ba7b429 100644 --- a/src/sna/sna_dri2.c +++ b/src/sna/sna_dri2.c @@ -341,6 +341,8 @@ static struct kgem_bo *sna_pixmap_set_dri(struct sna *sna, if (priv->gpu_bo->tiling != tiling) sna_pixmap_change_tiling(pixmap, tiling); + priv->clear = false; + priv->cpu = false; return priv->gpu_bo; } But I need to actually worry about this a little more.
commit 243bd26ad31776b2dc45563107e669cf7b45fd91 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jun 15 21:42:10 2014 +0100 sna: Clear our private hints about front rendering exported bo Unlike GLXWindows, GLXPixmaps are rendered directly into, without a staging copy. Therefore we must treat those carefully when exported and clear our hints everytime control passes back to the Client. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79999 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.