Bug 76388 - upgrade from 10.0.3 to 10.1.0 causes all composited windows (texture from pixmap) to become black
Summary: upgrade from 10.0.3 to 10.1.0 causes all composited windows (texture from pix...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.1
Hardware: x86-64 (AMD64) Linux (All)
: lowest trivial
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-20 10:09 UTC by Carsten Haitzler
Modified: 2015-01-02 11:37 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Haitzler 2014-03-20 10:09:41 UTC
after an upgrade from mesa 10.0.3 to 10.1.0 all my windows that used to work fine are now black. a downgrade back to 10.0.3 fixes it.

this is with enlightenment git:

  git clone http://git.enlightenment.org/core/enlightenment.git

or install enlightenment-git from AUR packages (eg on arch).

it likely happens with earlier versions too i imagine. many users affected:

  https://bbs.archlinux.org/viewtopic.php?id=178350

  http://sourceforge.net/p/enlightenment/mailman/message/32102607/
Comment 1 Tapani Pälli 2014-04-01 07:51:21 UTC
Does e17 handle the Y correctly like discussed in #73371 ? My simple test for tfp seems to work fine though. Also the test 'opengles1/texture_from_pixmap' in mesa demos repository works just fine with Mesa master (if you do sed s/EXTURE_EXTERNAL_OES/TEXTURE_2D/ for the source).

Could you attach a test case that does not work?
Comment 2 Carsten Haitzler 2014-04-01 11:03:34 UTC
it's not e that handles y invert - it's evas (library e relies on) and it does handle it - correctly. it was actually our added support of yinvert extension for egl/gles that caught the bug in #73371. since we started handling it on egl/gles on intel drivers pixmaps are inverted.

in this case pixmaps are just plain all black - no pixel data at all. everything blank. a downgrade to 10.0.3 fixes that. in fact it seems to vary from machine to machine. on some intel gfx systems it is 100% of the time black. on others its intermittent - depends on boot. reboot and then it works just fine, until randomly a boot later it's black again. i think sandybridge is always black, ivybridge is "sometimes black".

nb - this problem we currently see happening with glx+opengl (not egl/gles). i haven't tried egl/gles as i don't normally need/want it).
Comment 3 Tapani Pälli 2014-04-03 14:55:58 UTC
(In reply to comment #2)
> it's not e that handles y invert - it's evas (library e relies on) and it
> does handle it - correctly. it was actually our added support of yinvert
> extension for egl/gles that caught the bug in #73371. since we started
> handling it on egl/gles on intel drivers pixmaps are inverted.
> 
> in this case pixmaps are just plain all black - no pixel data at all.
> everything blank. a downgrade to 10.0.3 fixes that. in fact it seems to vary
> from machine to machine. on some intel gfx systems it is 100% of the time
> black. on others its intermittent - depends on boot. reboot and then it
> works just fine, until randomly a boot later it's black again. i think
> sandybridge is always black, ivybridge is "sometimes black".
> 
> nb - this problem we currently see happening with glx+opengl (not egl/gles).
> i haven't tried egl/gles as i don't normally need/want it).

Based on this I think the bug might be also in glx or x (?) I will debug some more with my test cases, will also check what is the difference between EGL and GLX in this case. Could you run evas/e17 against egl and gles2 and see if that works, just to confirm that we have same result there?
Comment 4 Ian Romanick 2014-04-03 21:34:29 UTC
(In reply to comment #2)
> in this case pixmaps are just plain all black - no pixel data at all.

Can you bisect?  That should help things along...
Comment 5 Carsten Haitzler 2014-04-14 10:20:32 UTC
i have been trying to reproduce this reliably. the problem is now - suddenly its not reproducible. well not reliably. i've reproduced it twice - total, out of maybe 50 reboots. given a know broken install version it now only happens rarely and that makes it impossible to find. it may even be a kernel bug as i have upgraded kernel since, (but not mesa so i can avoid the bug - i upgraded and no bug, i have tried everything... but it's too unreliable to reproduce.

at least for now i can't reliably reproduce and thus can't bisect. :(

same story for egl/gles
Comment 6 Kenneth Graunke 2014-04-16 04:29:24 UTC
You might want to try using X server 1.15.1 or 1.14.6 and see if it helps.  xserver commit 96a28e9c914d7ae9b269f73a27b99cbd3c465ac8 (glx: Clear new FBConfig attributes to 0 by default.) fixed a bug where you could get random GLX configs.
Comment 7 Carsten Haitzler 2014-04-16 10:21:08 UTC
i am on 1.15.1 now. i tried going back to 1.14.4 with no luck on repro. :(
Comment 8 Eero Tamminen 2014-12-29 15:51:49 UTC
(In reply to Carsten Haitzler from comment #7)
> i am on 1.15.1 now. i tried going back to 1.14.4 with no luck on repro. :(

Are you still encountering this?  On what intel GPU, Mesa and X intel driver versions?
Comment 9 Carsten Haitzler 2015-01-02 11:36:29 UTC
nope - can't reproduce anymore. it seems to have been a transient problem between mesa, kernel etc. and has been cleared up.
Comment 10 Carsten Haitzler 2015-01-02 11:37:40 UTC
seems to have fixed itself...


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.