[Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

Roland Scheidegger sroland at vmware.com
Mon Mar 12 05:26:50 PDT 2012


Hmm actually I think these new pipe formats are a mistake.
Why do you need them and don't just use the existing R8G8_B8G8 and
G8R8_G8B8?
Do you really care if Y ends up in G channel instead of R? And if you do
why don't you just use a sampler swizzle?
The R8G8_B8G8 and G8R8_G8B8 formats are there because these correspond
to the subsampled DX10 formats. I just see absolutely no point in
introducing similar formats which just have different channel mapping -
we generally don't have arbitrary swizzled formats, with the exception
of "old" ones which can be used for legacy purposes. But no such case
can be made for these new formats.
(I just checked the i965 docs which doesn't support sampler swizzling,
and in fact these new formats wouldn't help you there neither, since all
4 subsampled ycbcr format map Y to the green channel. So with hw
supporting sampler swizzling, these formats don't buy you anything, and
with hw not supporting it they don't help neither as no hardware out
there supports them anyway.)
Or is there another reason why you need these formats I'm missing?

Roland

Am 07.03.2012 15:10, schrieb Christian König:
> v2: simplify implementation by using correct swizzle
> 
> Signed-off-by: Christian König <deathsimple at vodafone.de>
> --- a/src/gallium/include/pipe/p_format.h
> +++ b/src/gallium/include/pipe/p_format.h
> @@ -311,6 +311,9 @@ enum pipe_format {
>  
>     PIPE_FORMAT_ETC1_RGB8               = 226,
>  
> +   PIPE_FORMAT_R8G8_R8B8_UNORM         = 227,
> +   PIPE_FORMAT_G8R8_B8R8_UNORM         = 228,
> +
>     PIPE_FORMAT_COUNT
>  };
>  



More information about the mesa-dev mailing list