Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such as
src/mesa/main/format_{un}pack.c you'll see that these formats are
treated as packed formats, not arrays.
Changing these formats from packed to array would cause even more
big/little-endian grief, right?
Same comment on some of the other patches.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul bri...@vmware.com wrote:
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such as
src/mesa/main/format_{un}pack.c you'll see that these formats are treated
as packed formats, not arrays.
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
So the naming convention would be a derivation of
MESA_FORMAT_R8G8B8A8_UNORM for these.
Mark
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
Incorrect. You have to manually check if the pack and unpack functions
access the components using bitwise operations or arrays.
Consider char pix[]. The array formats use arrays for accessing, for example:
char *p = pix[(y*width+x)*4];
p[0] = r;
p[1] = g;
p[2] = b;
p[3] = a;
Packed formats use bitwise operators for accessing, for example:
uint32_t *p = pix[(y*width+x)*4];
*p = r | (g 8) | (b 16) | (a 24);
It's okay to have both RGBA8 array and packed formats. For example,
Gallium has these array formats:
PIPE_FORMAT_R8G8B8A8_UNORM
PIPE_FORMAT_B8G8R8A8_UNORM
PIPE_FORMAT_A8R8G8B8_UNORM
PIPE_FORMAT_A8B8G8R8_UNORM
And it defines these packed formats by using the array formats
according to the CPU architecture:
#if defined(PIPE_ARCH_LITTLE_ENDIAN)
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#elif defined(PIPE_ARCH_BIG_ENDIAN)
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#endif
This way, Gallium has all the possible RGBA8 array formats and also
the possible RGBA8 packed formats, so we can use whatever we want.
Marek
On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller markkmuel...@gmail.com wrote:
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul bri...@vmware.com wrote:
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such as
src/mesa/main/format_{un}pack.c you'll see that these formats are treated as
packed formats, not arrays.
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
So the naming convention would be a derivation of MESA_FORMAT_R8G8B8A8_UNORM
for these.
Mark
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On 01/17/2014 12:41 PM, Mark Mueller wrote:
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul bri...@vmware.com
mailto:bri...@vmware.com wrote:
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA___FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/__MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA___FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/__MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA___FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/__MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA___FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/__MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such
as src/mesa/main/format_{un}pack.__c you'll see that these formats
are treated as packed formats, not arrays.
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
For the time being, I think the mesa formats which are packed should
stay packed and arrays stay as arrays. Otherwise, the
format_{un}pack.c, texstore, and s_texfetch.c code would need to be
changed accordingly.
Over time, we could probably migrate some of the packed formats to being
array formats.
So the naming convention would be a derivation of
MESA_FORMAT_R8G8B8A8_UNORM for these.
For the packed formats, yes. I believe that was the consensus from the
thread 3 days ago.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák mar...@gmail.com wrote:
Incorrect. You have to manually check if the pack and unpack functions
access the components using bitwise operations or arrays.
Consider char pix[]. The array formats use arrays for accessing, for
example:
char *p = pix[(y*width+x)*4];
p[0] = r;
p[1] = g;
p[2] = b;
p[3] = a;
Packed formats use bitwise operators for accessing, for example:
uint32_t *p = pix[(y*width+x)*4];
*p = r | (g 8) | (b 16) | (a 24);
Hang on, that's precisely what I did and when I tallied up the results from
the manual inspection, the rule I provided below fit. For example, in
format_pack.c, any pack_ubyte function that does not use a PACK_COLOR_
macro is either 32 bits per component, or an odd number of components with
8 or 16 bits: MESA_FORMAT_R_UNORM8, MESA_FORMAT_RGB_UNORM8. I admit that I
messed one, which is 16 bit floats - those are arrays too.
It's okay to have both RGBA8 array and packed formats. For example,
Gallium has these array formats:
PIPE_FORMAT_R8G8B8A8_UNORM
PIPE_FORMAT_B8G8R8A8_UNORM
PIPE_FORMAT_A8R8G8B8_UNORM
PIPE_FORMAT_A8B8G8R8_UNORM
And it defines these packed formats by using the array formats
according to the CPU architecture:
#if defined(PIPE_ARCH_LITTLE_ENDIAN)
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#elif defined(PIPE_ARCH_BIG_ENDIAN)
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM
#define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#endif
This way, Gallium has all the possible RGBA8 array formats and also
the possible RGBA8 packed formats, so we can use whatever we want.
The MESA_FORMATs are used to literally tag the application's Internal
formats such that the driver can better know the application's intention
(admittedly I'm also looking beyond _mesa_choose_tex_format, but that is
for another time). The Array Type formats were proposed to indicate that
the component order is independent of endianess, whereas Packed Type
component orders _do_ depend on endianess. Acknowledging these Types is an
attempt to eradicate the confusion. I have no input about mixing types
within Gallium, but within Mesa my preference is to adhere to that
distinction. I find Francisco's method to be less confusing then Gallium's
(not just because of the helpful comment). Here it is with P Type formats:
/*
* Define endian-invariant aliases for some mesa formats that are
* defined in terms of their channel layout from LSB to MSB in a
* 32-bit word. The actual byte offsets matter here because the user
* is allowed to bit-cast one format into another and get predictable
* results.
*/
#ifdef MESA_BIG_ENDIAN
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM
#else
# define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM
# define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM
# define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM
# define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM
# define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM
# define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM
#endif
Mark
Marek
On Fri, Jan 17, 2014 at 9:41 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Fri, Jan 17, 2014 at 8:58 AM, Brian Paul bri...@vmware.com wrote:
On 01/17/2014 03:45 AM, Mark Mueller wrote:
Change all 4 color component unsigned byte formats to meet spec:
s/MESA_FORMAT_RGBA\b/MESA_FORMAT_ABGR_UNORM8/g
s/MESA_FORMAT_RGBA_REV\b/MESA_FORMAT_RGBA_UNORM8/g
s/MESA_FORMAT_ARGB\b/MESA_FORMAT_BGRA_UNORM8/g
s/MESA_FORMAT_ARGB_REV\b/MESA_FORMAT_ARGB_UNORM8/g
s/MESA_FORMAT_RGBX\b/MESA_FORMAT_XBGR_UNORM8/g
s/MESA_FORMAT_RGBX_REV\b/MESA_FORMAT_RGBX_UNORM8/g
s/MESA_FORMAT_XRGB\b/MESA_FORMAT_BGRX_UNORM8/g
s/MESA_FORMAT_XRGB_REV\b/MESA_FORMAT_XRGB_UNORM8/g
I'm not sure this is right. If you look at the existing code such as
src/mesa/main/format_{un}pack.c you'll see that these formats are
treated as
packed formats, not arrays.
Ah. Array formats are really rare with OGL, that was unexpected but now
really ancient issues with memory throughput optimization are surfacing.
Those were the days.
Thus Array Types would only include the much smaller group of all 32
bit-per-component formats, and formats with an odd number of 8 or 16 bit
components. Right?
So the naming convention
Re: [Mesa-dev] [V3 PATCH 2/8] mesa: Change 4 color component ubyte formats
On Sat, Jan 18, 2014 at 12:45 AM, Mark Mueller markkmuel...@gmail.com wrote: On Fri, Jan 17, 2014 at 1:24 PM, Marek Olšák mar...@gmail.com wrote: Incorrect. You have to manually check if the pack and unpack functions access the components using bitwise operations or arrays. Consider char pix[]. The array formats use arrays for accessing, for example: char *p = pix[(y*width+x)*4]; p[0] = r; p[1] = g; p[2] = b; p[3] = a; Packed formats use bitwise operators for accessing, for example: uint32_t *p = pix[(y*width+x)*4]; *p = r | (g 8) | (b 16) | (a 24); Hang on, that's precisely what I did and when I tallied up the results from I thought you hadn't. Nevermind then. the manual inspection, the rule I provided below fit. For example, in format_pack.c, any pack_ubyte function that does not use a PACK_COLOR_ macro is either 32 bits per component, or an odd number of components with 8 or 16 bits: MESA_FORMAT_R_UNORM8, MESA_FORMAT_RGB_UNORM8. I admit that I messed one, which is 16 bit floats - those are arrays too. It's okay to have both RGBA8 array and packed formats. For example, Gallium has these array formats: PIPE_FORMAT_R8G8B8A8_UNORM PIPE_FORMAT_B8G8R8A8_UNORM PIPE_FORMAT_A8R8G8B8_UNORM PIPE_FORMAT_A8B8G8R8_UNORM And it defines these packed formats by using the array formats according to the CPU architecture: #if defined(PIPE_ARCH_LITTLE_ENDIAN) #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_R8G8B8A8_UNORM #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_B8G8R8A8_UNORM #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_A8R8G8B8_UNORM #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM #elif defined(PIPE_ARCH_BIG_ENDIAN) #define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM #define PIPE_FORMAT_ARGB_UNORM PIPE_FORMAT_B8G8R8A8_UNORM #define PIPE_FORMAT_BGRA_UNORM PIPE_FORMAT_A8R8G8B8_UNORM #define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM #endif This way, Gallium has all the possible RGBA8 array formats and also the possible RGBA8 packed formats, so we can use whatever we want. The MESA_FORMATs are used to literally tag the application's Internal formats such that the driver can better know the application's intention (admittedly I'm also looking beyond _mesa_choose_tex_format, but that is for another time). The Array Type formats were proposed to indicate that the component order is independent of endianess, whereas Packed Type component orders _do_ depend on endianess. Acknowledging these Types is an attempt to eradicate the confusion. I have no input about mixing types within Gallium, but within Mesa my preference is to adhere to that distinction. I find Francisco's method to be less confusing then Gallium's (not just because of the helpful comment). Here it is with P Type formats: /* * Define endian-invariant aliases for some mesa formats that are * defined in terms of their channel layout from LSB to MSB in a * 32-bit word. The actual byte offsets matter here because the user * is allowed to bit-cast one format into another and get predictable * results. */ #ifdef MESA_BIG_ENDIAN # define MESA_FORMAT_RGBA_8 MESA_FORMAT_A8B8G8R8_UNORM # define MESA_FORMAT_RG_16 MESA_FORMAT_G16R16_UNORM # define MESA_FORMAT_RG_8 MESA_FORMAT_G8R8_UNORM # define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_A8B8G8R8_SNORM # define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_G16R16_SNORM # define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_G8R8_SNORM #else # define MESA_FORMAT_RGBA_8 MESA_FORMAT_R8G8B8A8_UNORM # define MESA_FORMAT_RG_16 MESA_FORMAT_R16G16_UNORM # define MESA_FORMAT_RG_8 MESA_FORMAT_R8G8_UNORM # define MESA_FORMAT_SIGNED_RGBA_8 MESA_FORMAT_R8G8B8A8_SNORM # define MESA_FORMAT_SIGNED_RG_16 MESA_FORMAT_R16G16_SNORM # define MESA_FORMAT_SIGNED_RG_8 MESA_FORMAT_R8G8_SNORM #endif I'm not sure what you're trying to say here. It looks the same as gallium, except that it's the other way around (array formats defined using packed formats). Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
