[Mesa-users] Mesa 18.3 swrast

Thu Jan 31 00:04:39 UTC 2019

Qwerty,

Thanks for the suggestion. I tried both swrast and LLVMpipe. Both displayed
the same problem.

I did, however, find a solution. There are two that were required:

   1. I modified my calls to glClearColor() per Brian Paul's suggestion and
   passed an alpha value of 1.0 as the fourth argument to the function. That
   solved the problem with the window contents bleeding through areas that I
   cleared via calls to glClear(GL_COLOR_BUFFER_BIT). Previous to this I was
   passing glClearColor() an alpha value of 0.0 which should have been fine
   because blending was not enabled. An alpha value of zero worked fine with
   NVidia drivers but not with Mesa.
   2. To fix transparency rendering issue where the underlying window
   contents were being blended with my translucent primitives, I updated my
   calls to use glBlendFuncSeparate() instead of glBlendFunc():
   Wherever I used:
       glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
   I replaced it with:
       glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ZERO,
   GL_ONE);
   This allowed me to ignore any existing alpha values while blending.

For reference, I found this information online about composite visuals on
Linux Desktops: https://www.x.org/archive/X11R7.5/doc/RELNOTES.txt

When the Composite extension is enabled via xorg.conf or the command line,
> a new visual is created. This visual is different from the other visuals
> used by X applications in that it includes an alpha component. It is used
> by the compositing manager and other Composite aware applications. Most X
> applications ignore this visual since it is not useful to them; however
> some applications mistakenly try to use it, which will cause them to fail.
> An environment variable, XLIB_SKIP_ARGB_VISUALS, was added to the X11
> library to hide this visual from applications that mistakenly try to use
> it. If an application fails only when the Composite is enabled, try setting
> this environment variable before starting the application.

Since Composite is not enabled by default, it is not expected that this
> issue will be visible to most users.

Presumably, the NVidia drivers are composite aware with regard to visuals
selected by GLX. Setting this environment variable to 1 and exporting it
for my application (or glxgears) also fixed the issue without having to
make the code changes to glClearColor or glBlendFunc mentioned above.

Thanks again to Brian and Daniel for their help with this issue.
Michael

On Wed, Jan 30, 2019 at 2:01 PM Qwerty Chouskie <asdfghrbljzmkd at outlook.com>
wrote:

> 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 <
> daniel.trstenjak at gmail.com> 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
>> mesa-users at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-users
>>
>
> _______________________________________________
> mesa-users mailing listmesa-users at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-users
>
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-users/attachments/20190130/d601a752/attachment-0001.html>