[Pixman] [PATCH 1/2] pixman: Add support for argb/xrgb float formats, v3.

[Siarhei Siamashka]

On Wed, 03 Oct 2018 10:11:46 +0100
Chris Wilson <chris at chris-wilson.co.uk> wrote:

> Quoting Maarten Lankhorst (2018-08-01 13:41:33)
> > diff --git a/pixman/pixman.h b/pixman/pixman.h
> > index 509ba5e534a8..c9bf4faa80d4 100644
> > --- a/pixman/pixman.h
> > +++ b/pixman/pixman.h
> > @@ -647,19 +647,24 @@ struct pixman_indexed
> >   * sample implementation allows only packed RGB and GBR
> >   * representations for data to simplify software rendering,
> >   */
> > -#define PIXMAN_FORMAT(bpp,type,a,r,g,b)        (((bpp) << 24) |  \
> > +#define PIXMAN_FORMAT_PACKC(val) ((val) <= 10 ? (val) : \
> > +                                (val) == 32 ? 11 : 0)
> > +#define PIXMAN_FORMAT_UNPACKC(val) ((val) <= 10 ? (val) : \
> > +                                   (val) == 11 ? 32 : 0)  
> 
> We have 4bits, why not reserve 0xf for float32? Certainly you
> want space for
> 
> #define PIXMAN_FORMAT_PACKED_FLOAT16 0xb
> #define PIXMAN_FORMAT_PACKED_FLOAT32 0xc
> #define PIXMAN_FORMAT_PACKED_FLOAT64 0xd
> 
> I just wonder if we may have 12bpc one day as well, so leaving 0xc clear
> has some some appeal.

We could probably also try to do something like this:

/*
 * While the protocol is generous in format support, the
 * sample implementation allows only packed RGB and GBR
 * representations for data to simplify software rendering,
 *
 * Bit 23 selects the granularity of channel color depth
 *  0: 1-bit granularity (allows up to 15 bits per channel)
 *  1: 1-byte granularity (allows up to 120 bits per channel)
 */
#define PIXMAN_FORMAT(bpp,type,a,r,g,b)	\
	(((bpp) << 24) |  \
	((type) << 16) | \
	(((a) < 16) ? ((a) << 12) : (((a / 8) << 12) | (1 << 23))) | \
	(((r) < 16) ? ((r) << 8)  : (((r / 8) << 8)  | (1 << 23))) | \
	(((g) < 16) ? ((g) << 4)  : (((g / 8) << 4)  | (1 << 23))) | \
	(((b) < 16) ? ((b))       : (((b / 8))       | (1 << 23))))

/* 0 for 1-bit granularity and 3 for 1-byte granularity */
#define PIXMAN_FORMAT_CHANDEPTH_SHIFT(f) \
	((((f) >> 23) & 1) | ((((f) >> 23) & 1) << 1))

#define PIXMAN_FORMAT_A(f) \
	((((f) >> 12) & 0x0f) << PIXMAN_FORMAT_CHANDEPTH_SHIFT(f))
#define PIXMAN_FORMAT_R(f) \
	((((f) >>  8) & 0x0f) << PIXMAN_FORMAT_CHANDEPTH_SHIFT(f))
#define PIXMAN_FORMAT_G(f) \
	((((f) >>  4) & 0x0f) << PIXMAN_FORMAT_CHANDEPTH_SHIFT(f))
#define PIXMAN_FORMAT_B(f) \
	((((f)      ) & 0x0f) << PIXMAN_FORMAT_CHANDEPTH_SHIFT(f))

#define PIXMAN_FORMAT_BPP(f)	(((uint32_t)(f)) >> 24)
#define PIXMAN_FORMAT_TYPE(f)	(((f) >> 16) & 0x7f)
#define PIXMAN_FORMAT_RGB(f)	(((f)      ) & 0xfff)
#define PIXMAN_FORMAT_VIS(f)	(((f)      ) & 0xffff)
#define PIXMAN_FORMAT_DEPTH(f)	(PIXMAN_FORMAT_A(f) +	\
				 PIXMAN_FORMAT_R(f) +	\
				 PIXMAN_FORMAT_G(f) +	\
				 PIXMAN_FORMAT_B(f))


Right now the format type occupies 8 bits. The highest bit could be
repurposed as a flag for storing channel depth as bytes instead
of bits. This way 16-bit and 64-bit per color component will be
also supported. The limitation of this approach is that the depth
of every color component has to be a multiple of 8 bits if any of
them is 16 bits or larger.

I don't feel very comfortable about the fact that some applications
are using the PIXMAN_FORMAT_A/R/G/B macros and this code gets compiled
as part of these application binaries.

Are there any other interesting >32bpp formats that we may need
to support in the future?

-- 
Best regards,
Siarhei Siamashka