Re: Mesa 18.3 swrast

Have you considered trying using LLVMpipe instead of swrast?  LLVMpipe is much better from a performance standpoint, and may not have this bug.  You could also look into OpenSWR.

On 1/30/19 11:42 AM, Michael Saunders wrote:
Brian  and Daniel,

Thank you for your very helpful suggestions. It turns out that our software calls glClearColor with 0.0 for alpha. I'm not sure what glxgears does but presumably it calls glClearColor(1,1,1,0). Changing alpha to 1.0 makes the call to glClear(GL_COLOR_BUFFER_BIT) fill the background with the fully opaque color without any bleed-through from the underlying window contents. Our translucent primitives, however, still blend with the underlying window contents. When we render translucent primitives we set glColor4f with a specific alpha value that is dependent on the desired translucency and we use glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). Is there a more appropriate blend function for src or dst?

It is worthy to note that the native NVidia OpenGL drivers or the default Mesa OpenGL library backed with Nouveau drivers do not exhibit this issue. It is only the swrast driver in the Mesa OpenGL library that I built from source.

I did find a workaround online. Apparently by exporting the following environment variable assignment, XLIB_SKIP_ARGB_VISUALS=1, the issues no longer manifest. If there is a better solution to get blending to work or a bug fix to Mesa I would prefer that over the environment variable, nevertheless, I appreciate the suggestions given.

Thanks,
Michael

On Wed, Jan 30, 2019 at 3:57 AM Daniel Trstenjak <[email protected]<mailto:[email protected]>> wrote:
> IIRC, this is something that the window manager is doing.
>
> Which window manager are you using?  Maybe you need to change some
> compositing setting.

I had similar issues with an older Mesa version.

And yes, disabling the compositing in the window manager
solved the issue.

But it's still not clear to me why I'm only having the
issue with Mesa, but not with a NVIDIA driver. With
the NVIDIA driver I hadn't to disable the compositing.

So there seems to be some kind of application specific setting
which causes the different behavior with Mesa and the
NVIDIA driver.

In our cases additionally Qt5 is involved, which complicates
the case a little further.

Greetings,
Daniel
_______________________________________________
mesa-users mailing list
[email protected]<mailto:[email protected]>
https://lists.freedesktop.org/mailman/listinfo/mesa-users



_______________________________________________
mesa-users mailing list
[email protected]<mailto:[email protected]>
https://lists.freedesktop.org/mailman/listinfo/mesa-users

_______________________________________________
mesa-users mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-users