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

[Neil Roberts]

Ilia Mirkin <imirkin at alum.mit.edu> writes:

> 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;
>     }

Thanks for the suggestion. I assume you didn't want to make this into a
proper patch yourself so I went ahead and did it here:

http://patchwork.freedesktop.org/patch/67844/

Along with the other two patches it doesn't cause any regressions in our
CI system.

I left the 565 format alone because there is no enum for
MESA_FORMAT_B5G6R5_SRGB and it seemed like it's better treated as a
separate issue.

We should also fix the fact that the visuals aren't marked as
sRGB-capable even though they are, but again I think that is a separate
issue.

Regards,
- Neil