| Summary: | Front buffer drawing mode shows black window with gallium software rasterizers | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Pradeep Yadav <pradeep.yadav> |
| Component: | Drivers/Gallium/swr | Assignee: | Bruce Cherniak <bruce.cherniak> |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | major | ||
| Priority: | medium | CC: | enapanuri-j-scholar, joseph.kucia |
| Version: | 17.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Standalone OpenGL program for reproducing this issue | ||
(In reply to Pradeep Yadav from comment #0) > When front buffer drawing mode is enabled using glDrawBuffer(GL_FRONT); the > window becomes black after glFlush() call. This is likely a duplicate of bug 99116. Please check if the patch attached to bug 99116 helps. Applied the patch attached with bug 99116 in Mesa 13.0.5 source code but can still reproduce the problem. (In reply to Pradeep Yadav from comment #2) > Applied the patch attached with bug 99116 in Mesa 13.0.5 source code but can > still reproduce the problem. FWIW, your OpenGL program seems to work correctly here with llvmpipe in Mesa from git (17.0-branchpoint-1291-gb19caec). Not able to clone mesa repository using git clone git://anongit.freedesktop.org/git/mesa/mesa . anongit.freedesktop.org is not responding. $ git clone git://anongit.freedesktop.org/git/mesa/mesa Cloning into 'mesa'... fatal: unable to connect to anongit.freedesktop.org: anongit.freedesktop.org[0: 131.252.210.161]: errno=Connection timed out anongit.freedesktop.org[1: 2610:10:20:722:a800:ff:fe24:61cf]: errno=Network is unreachable I can confirm that I experience the same bug on Centos-7 with mesa 11.2 I tried to compile and run with 17.0.1 (confirmed by glxinfo), the same result. GALLIUM_DRIVER=softpipe and GALLIUM_DRIVER=swr have the same impact as for Pradeep. It was commented that this works for llvmpipe on 17.0 (17.0-branchpoint-1291-gb19caec). I tried it on mesa-master with swr and it appears to work. We haven't had a chance to go back to 13.0 to root cause. Any chance that you can move forward to mesa 17 until we can look for a 13.0 fix? This also doesn't sound like a swr specific bug, from the previous comments. Thanks. Actually, I build and installed 17.0.5 for Centos-7 and issue remains here. OK, short summary. So far tried 11.2, 17.0, 17.0.1, 17.0.5, with LLVM 3.8 and 4.0 (just in case!), and with and without patch from Bug 99116 Result is the same: black screen with standalone program attached above. With swr and softpipe it works. I wanted to check also master and/or 17.1, but this is more work (I have to replace quite few libs on Centos-7 then, while with 17.0.x I can compile as simple drop-in replacement instead of default 11.2. Addition: I made mistake during testing: softpipe works, both llvm AND swr (aka OpenSWR) - don't. I tried this again, and can only get the failure as you describe on CentOS. Seems to work on other OSs. It also appears fixed in 17.1 and 17.2 mesa releases. At this point, I do not see a fix coming for 17.0 or older. A recently updated CentOS 7 seems to have the correct dependencies to build. What trouble are you having? As I mentioned while filing this defect that Mesa's classic software rasterizer has no such black window issue. So we have potential temporary solution for our customers who are using older Linux versions. So for a CentOS version, like 6.x, I downloaded Mesa 13.0.5 sources and built swrast_dri.so (the classic software rasterizer) and it works (Need to set LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to swrast_dri.so path). But our customers/users cannot build Mesa on their systems. They don't have the expertise and sometimes their IT support are also not willing to do so. We cannot provide a pre-built swrast_dri.so to them as it might be incompatible with the other libraries (dependencies) on customer's system. For example a customer may be facing this issue on their CentOS 7.x system and if we provide Mesa 13.0.5 swrast_dri.so, then it might not work. My questions: - Is there a way (probably like an environment variable) to activate Mesa's classic software rasterizer? - Do we have a documentation of which Mesa version is compatible with which Linux kernel version? - On installing CentOS version V, a Mesa version M is installed. How and who decides Mesa version M corresponding to CentOS version V? Your most recent response indicates that you are running with dri drivers. This is not something I was aware of. And, I just tried the demo app, and sure enough, it fails with dri driver -- either llvmpipe or OpenSWR. We're finally on the same page. :) However, most of our customers require only the standalone GLX drivers, eliminating the need to install dri or disturb other configurations; only the few libraries that build in .../lib/gallium (libGL.so, libswrAVX.so, libswrAVX2.so) are required and LD_LIBRARY_PATH is the only environment change necessary. We regularly build mesa with OpenSWR on CentOS 6 and 7, so I see no reason to stick with mesa 13. And, several of our customers build and supply specific release libraries with their binary release, so there is no additional install. Using the classic software rasterizer would be a very last resort and unless there is a specific reason to install/run dri, there is no hard/fast kernel requirement and no specific version of (older) mesa that must be run on CentOS 6. The developer toolchain needs to be updated, but this is quite doable. We can follow up with a phone call, if that would be more convenient, to understand your specific requirements. In the meantime, I'll try to look into the dri failure on both llvmpipe and OpenSWR. But this doesn't appear to be an OpenSWR specific issue. Thanks, Bruce -- 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/191. |
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.
Created attachment 130157 [details] Standalone OpenGL program for reproducing this issue When front buffer drawing mode is enabled using glDrawBuffer(GL_FRONT); the window becomes black after glFlush() call. Attached program OpenGLXORApp.cpp demonstrates it. Follow these steps to reproduce: 1. Compile the program using: g++ -I/usr/include -lglut -lGLU -lGL OpenGLXORApp.cpp -o OpenGLXORApp 2. Run the program: ./OpenGLXORApp 3. Using mouse start drawing a rectangle, i.e., click left mouse button anywhere inside the window and drag the mouse while the left mouse button is depressed. Expected Result: A blue triangle on the white background is seen while a green rectangle is being drawn over it. Actual Result: A black window with green rectangle being drawn over it. Tried with: 1. GALLIUM_DRIVER=softpipe <-- Black window on Mesa 10.x.x BUT not on Mesa 11+ releases. But in our complex application where rotation is involved, after front buffer drawing, when we switch to double buffer drawing, the background remains static. The attached program cannot be used to reproduce this last issue because it doesn't have rotation functionality. 2. GALLIUM_DRIVER=llvmpipe <-- Black window on Mesa 10.x.x, 11.2.2 and Mesa 13.0.5 3. Mesa classic software rasterizer <-- NO ISSUES! 4. LIBGL_DEBUG=verbose and MESA_DEBUG=1 didn't print out any errors or warnings, except this warning: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable. Note: Specific Mesa versions were mentioned above because those are the versions I have built and tested against.