Re: [Pixman] [PATCH 1/2] pixman: Add support for argb/xrgb float formats, v3.
I think an indicator for float can double as indicating the size is multiplied by 8. All float formats I am familiar with take a mulitple of 8 bits, including an 8-bit format that is sometimes used in CG. On Mon, Oct 29, 2018 at 2:18 AM Maarten Lankhorst < maarten.lankho...@linux.intel.com> wrote: > Op 29-10-18 om 09:16 schreef Siarhei Siamashka: > > On Wed, 03 Oct 2018 10:11:46 +0100 > > Chris Wilson 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)) > I would use 2 bits then, 6 is still plenty for the rest of the type. > > Perhaps make a separate PIXMAN_FORMAT_TYPE_RGBA_FLOAT and > PIXMAN_FORMAT_TYPE_RGB_FLOAT? > > > #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) ) & 0x) > > #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? > > > Doubt it, pixman doesn't have that accuracy currently, but F16 might be > interesting at some point.. > > ~Maarten > > ___ > Pixman mailing list > Pixman@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pixman > ___ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 1/2] pixman: Add support for argb/xrgb float formats, v3.
Op 29-10-18 om 09:16 schreef Siarhei Siamashka: > On Wed, 03 Oct 2018 10:11:46 +0100 > Chris Wilson 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)) I would use 2 bits then, 6 is still plenty for the rest of the type. Perhaps make a separate PIXMAN_FORMAT_TYPE_RGBA_FLOAT and PIXMAN_FORMAT_TYPE_RGB_FLOAT? > #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) ) & 0x) > #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? > Doubt it, pixman doesn't have that accuracy currently, but F16 might be interesting at some point.. ~Maarten ___ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] [PATCH 1/2] pixman: Add support for argb/xrgb float formats, v3.
On Wed, 03 Oct 2018 10:11:46 +0100 Chris Wilson 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) ) & 0x) #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 ___ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman