Bug 100151 - Front buffer drawing mode shows black window with gallium software rasterizers
Summary: Front buffer drawing mode shows black window with gallium software rasterizers
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/swr (show other bugs)
Version: 17.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Bruce Cherniak
QA Contact: mesa-dev
Depends on:
Reported: 2017-03-10 19:00 UTC by Pradeep Yadav
Modified: 2019-09-18 18:24 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Standalone OpenGL program for reproducing this issue (2.86 KB, text/plain)
2017-03-10 19:00 UTC, Pradeep Yadav

Description Pradeep Yadav 2017-03-10 19:00:25 UTC
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.
Comment 1 Józef Kucia 2017-03-10 19:10:22 UTC
(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.
Comment 2 Pradeep Yadav 2017-03-10 20:48:57 UTC
Applied the patch attached with bug 99116 in Mesa 13.0.5 source code but can still reproduce the problem.
Comment 3 Józef Kucia 2017-03-10 21:05:24 UTC
(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).
Comment 4 Pradeep Yadav 2017-03-10 21:48:09 UTC
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:]: errno=Connection timed out
anongit.freedesktop.org[1: 2610:10:20:722:a800:ff:fe24:61cf]: errno=Network is unreachable
Comment 5 Anton Starikov 2017-03-11 18:37:22 UTC
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.
Comment 6 Anton Starikov 2017-03-11 18:44:03 UTC
BTW, patch from Bug 99116 doesn't help either.
Comment 7 Bruce Cherniak 2017-04-06 21:52:13 UTC
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.

Comment 8 Anton Starikov 2017-05-08 13:58:42 UTC
Actually, I build and installed 17.0.5 for Centos-7 and issue remains here.
Comment 9 Anton Starikov 2017-05-08 17:22:24 UTC
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.
Comment 10 Anton Starikov 2017-05-08 22:07:19 UTC
Addition: I made mistake during testing:
softpipe works, both llvm AND swr (aka OpenSWR) - don't.
Comment 11 Bruce Cherniak 2017-09-15 14:51:51 UTC
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?
Comment 12 Pradeep Yadav 2017-11-15 22:13:05 UTC
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?
Comment 13 Bruce Cherniak 2017-11-28 18:28:30 UTC
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.

Comment 14 GitLab Migration User 2019-09-18 18:24:13 UTC
-- 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.