Created attachment 122086 [details] the source code of the program (.tar,xz) Here's the source code of a simple program, that reproduces incorrect behavior of PRIME. I actually wanted to try something different, but then I discovered this bug. The program generates noise textures and displays them on a quad using OpenGL 3.3. You can specify the size of the noise textures with the program's first parameter. The program runs fine on my Intel Ivy Bridge gpu and it also runs on my GeForce GT 640M (Kepler) with nouveau and DRI_PRIME=1. When I increase the texture size to 128 or something larger, the program's window sometimes (>= 50% chance) becomes transparent (see attached screenshot) when using DRI_PRIME=1. This *never* happens with texture sizes of 64 or less. If I remove the use of textures completely from the program, it always runs fine as well. DRI_PRIME=1 glxgears always works as expected. My system is Arch Linux with mesa 11.1.2-1 and kernel 4.4.1-2. I'm sorry that I cannot install mesa-git since this is my computer for productive work. Hopefully, someone else can reproduce the issue. Steps to build the program: - make sure you have SDL2 installed - ./build.sh - DRI_PRIME=1 ./a.out 512 <- might not work - DRI_PRIME=1 ./a.out 64 <- always works for me
Created attachment 122087 [details] screenshot of the transparent window
It doesn't seem to be transparted (check the window border of the window in the background. The new window simply contains the the background as the buffer and moving around won't update the content ;)
Yes, you are right. It's not true transparency. But the window doesn't show the image rendered by OpenGL.
well it works for me
Hm, did you try it multiple times with increasing texture sizes? Is there any other potentially useful information I could provide?
I even tried with 2048 multiple times and it always worked (though I had to wait a little with >=1024). Otherwise I have no idea how to debug such an issue. I also have kepler gpu, but a GK106, and you a GK107, but that shouldn't change much.
I can reproduce the same error, but with Intel and AMD hardware. This is what happens when I run DRI_PRIME=1 steam, and I found this bug report when I searched for the symptoms. As I said, in my case it is not related to nouveau, as I use a laptop with an Intel/AMD combination. My system: The hardware is a HP Pavillion with mux-less hybrid graphics: Intel Sandy Bridge and AMD Radeon HD 6770 Kubuntu 15.10 with KDE backports Mesa 11.0.2 My symptoms: DRI_PRIME=1 glxgears --> works DRI_PRIME=1 ./a.out 64 --> works DRI_PRIME=1 ./a.out 512 --> transparent window DRI_PRIME=1 steam --> transparent window If I can provide any additional information, please let me know (I have now idea about debugging graphical bugs, so I don't really know what to provide).
For reasons not related to this bug I had to replace the HDD, and have installed the current nightly image of Kubuntu 16.04 instead of the previously used 15.10. On the newly installed system, I cannot reproduce this bug, neither with steam nor with the provided gpu memory test program: DRI_PRIME=1 ./a.out 4096 runs fine This system now uses Mesa 11.1.2.
Mesa 11.2.0-1 just rolled out on Arch. The issue is still the same for me.
This bug appears to be fixed. I know it was still present about a week ago with Mesa 12.0.1, but today xf86-video-intel got upgraded (from 1:2.99.917+676+g26f8ab5-1 to 1:2.99.917+684+g6988b87-3, whatever these strange version numbers are). Now I can no longer reproduce the issue. Since the upgrade, the driver uses DRI3 by default. But even when I switch back to DRI2 manually, this is no longer an issue. I'm closing this issue now, until it happens again.
* For note - Get the same issue at Ubuntu 16.04 LTS 64-bit. - Intel Ivy-bridge & AMD HD 7650M Hybrid graphics - DRI2 for default - Kernel 4.4.0-53 - Mesa 11.2.0 It happened with texture sizes over than 256, but when I use DRI3, it never happens anymore.
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.