[Mesa-stable] [Mesa-dev] [PATCH] i965: handle stencil_bits parameter for MESA_FORMAT_B8G8R8X8_UNORM format.

[Ilia Mirkin]

On Wed, Dec 9, 2015 at 2:15 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Wed, Dec 9, 2015 at 11:23 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Wed, Dec 9, 2015 at 11:18 AM, Deve <deveee at gmail.com> wrote:
>>> This patch indeed seems to not have a sense. I just added it to the bug
>>> report as a suggestion that it works for me after this modification. Emil
>>> Velikov said that I should send it to the mailing list.
>>>
>>> Here is how it works in Supertuxkart:
>>> We create rtt with following parameters:
>>>
>>> DepthStencilTexture = generateRTT(res, GL_DEPTH24_STENCIL8,
>>> GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8);
>>>
>>> Then, during rendering scene, we do:
>>>
>>>     glEnable(GL_FRAMEBUFFER_SRGB);
>>>     glBindFramebuffer(GL_FRAMEBUFFER, 0);
>>
>> OK, so this is the "winsys" framebuffer (GL has some term for it,
>> sorry, I don't remember what it is... perhaps it's even winsys). This
>> is created based on parameters of your selected GLX visual. For
>> example, when I run glxinfo, I see (on nouveau; the list on intel will
>> be different but comparable):
>>
>> 480 GLX Visuals
>>     visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
>>   id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
>> ----------------------------------------------------------------------------
>> 0x021 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
>> 0x022 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
>> ...
>> 0x343 24 tc  0  32  0 r  . .   8  8  8  8 .  s  0  0  0  0  0  0  0  0 0 None
>> 0x344 24 tc  0  32  0 r  . .   8  8  8  8 .  s  0  0  0 16 16 16 16  0 0 Slow
>> 0x345 24 tc  0  32  0 r  y .   8  8  8  8 .  s  0  0  0  0  0  0  0  0 0 None
>> 0x346 24 tc  0  32  0 r  y .   8  8  8  8 .  s  0  0  0 16 16 16 16  0 0 Slow
>>
>> Note how some of them have srgb, others don't (and have various
>> differences in their various other properties). EGL has something
>> similar I believe, but tbh I don't remember the specifics. That's the
>> mesaVis->sRGBCapable bit below. If you need an sRGB-capable visual,
>> are you sure you're picking one? This would be somewhere well before
>> any actual rendering takes place.
>>
>> If you're not sure whether you need an sRGB-capable visual or not, try
>> making sure you pick a *non-srgb* visual in a working configuration
>> and see if it breaks.
>
> Right, so looking at your code with in more detail, you probably just
> require a stencil visual, which, in combination with this patch, makes
> you skip this one.
>
> However I noticed that i965/hsw and probably others don't expose *any*
> sRGB-capable GLX visuals/fb configs! Pretty sure that's not good...
> but GLX, sRGB, and visuals are not exactly my strong point, hopefully
> someone a bit more clued in can comment.

I suspect that something like this may be the right thing for the
intel driver... no reason not to expose sRGB-capable visuals when it
so happens that alpha == 0. Also probably the same treatment should be
done for BGR565... sRGB encoding will matter even more there, and from
the looks of it, all gens support that.

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index cc90efe..75f2cce 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1003,9 +1003,10 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
       rgbFormat = MESA_FORMAT_B5G6R5_UNORM;
    else if (mesaVis->sRGBCapable)
       rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
-   else if (mesaVis->alphaBits == 0)
-      rgbFormat = MESA_FORMAT_B8G8R8X8_UNORM;
-   else {
+   else if (mesaVis->alphaBits == 0) {
+      rgbFormat = MESA_FORMAT_B8G8R8X8_SRGB;
+      fb->Visual.sRGBCapable = true;
+   } else {
       rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
       fb->Visual.sRGBCapable = true;
    }