Re: [Mesa3d-dev] Mystery of u_format.csv
On 06.01.2010 08:36, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. It looks like I always thought how to interpret the formats now. Which means the vertex element formats in mesa/state_tracker/st_draw.c should be corrected - the R8G8B8A8 and R8G8 vertex elements should be reversed, and the BGRA format should be A8R8G8B8. At least this would fix my (gallium/drivers/nv50/nv50.vbo) if (desc-swizzle[0] == UTIL_FORMAT_SWIZZLE_Z) /* BGRA */ check. Christoph -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Jose -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
José Fonseca wrote on 2010-01-06 15:03: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. I did this because in the other thread you defined arith layout to apply to 32-or-less-bit formats. Since I still believe arith and array layout are somewhat redundant, we can go the other way round and convert other arith layouts to array, save for 16-or-less-bit formats. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
Christoph Bumiller wrote on 2010-01-06 12:08: On 06.01.2010 08:36, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. It looks like I always thought how to interpret the formats now. Which means the vertex element formats in mesa/state_tracker/st_draw.c should be corrected - the R8G8B8A8 and R8G8 vertex elements should be reversed, and the BGRA format should be A8R8G8B8. At least this would fix my (gallium/drivers/nv50/nv50.vbo) if (desc-swizzle[0] == UTIL_FORMAT_SWIZZLE_Z) /* BGRA */ check. I'm affraid you will also need to check desc-layout field, and if it is array, compare against desc-swizzle[3]. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, and IMO 'arith' formats should be defined in the CPU endianness. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:11 -0800, michal wrote: José Fonseca wrote on 2010-01-06 15:03: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. I did this because in the other thread you defined arith layout to apply to 32-or-less-bit formats. Since I still believe arith and array layout are somewhat redundant, we can go the other way round and convert other arith layouts to array, save for 16-or-less-bit formats. Indeed arith applies to 32-or-less-bit formats, but I never meant to say that all 32-or-less-bit formats must be in arith. They are indeed redundant, but array is/will be more efficient and when code generation is more robust and big-endian-safe all x8, x8x8, x8x8x8, x8x8x8x8x8 formats will be likely in array layout. Jose -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
José Fonseca wrote on 2010-01-06 15:26: On Wed, 2010-01-06 at 06:11 -0800, michal wrote: José Fonseca wrote on 2010-01-06 15:03: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. I did this because in the other thread you defined arith layout to apply to 32-or-less-bit formats. Since I still believe arith and array layout are somewhat redundant, we can go the other way round and convert other arith layouts to array, save for 16-or-less-bit formats. Indeed arith applies to 32-or-less-bit formats, but I never meant to say that all 32-or-less-bit formats must be in arith. Understood. They are indeed redundant, but array is/will be more efficient and when code generation is more robust and big-endian-safe all x8, x8x8, x8x8x8, x8x8x8x8x8 formats will be likely in array layout. That is okay, we agree on that part. The question is what is the reason we treat PIPE_FORMAT_R8G8B8A8_UNORM as having array layout (before my patch), and e.g. PIPE_FORMAT_B8G8R8A8_UNORM as having arith layout? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
Michel Dänzer wrote on 2010-01-06 15:23: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, and IMO 'arith' formats should be defined in the CPU endianness. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Interesting. Is there any reference that would say which formats are 'array', and which are not? Or is it a simple rule that when every component's bitsize is greater-or-equal to, say, 16, then it's an array format? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:32 -0800, michal wrote: Michel Dänzer wrote on 2010-01-06 15:23: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, and IMO 'arith' formats should be defined in the CPU endianness. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Interesting. Is there any reference that would say which formats are 'array', and which are not? Or is it a simple rule that when every component's bitsize is greater-or-equal to, say, 16, then it's an array format? There isn't really a rule, and I haven't profiled code enough to tell which algorithm is faster for swizzling -- bit shifting arithmetic or byte/word/dword indexation. My expectation is that byte/word/dword indexation will be faster for n x 8bit formats. In particular there is sse3 instruction PSHUFB can swizzle any n x 8bit format, 16 channels at a time. Where as bit SSE2 bit shift arithmetic instructions can only do 4 or 8 channels at a time, for 32bit and 16bit formats respectively. Again, this is only relevant for the generating CPU routines that will do pixel translation. GPU drivers should behave identically regardless of this layout. Jose -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some) formats in CPU endianness. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 15:51 +0100, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. ... and at least for some others, e.g. 16 bit 565 or 1555 formats, 'always little endian' would mean that some API formats couldn't be represented by Gallium formats on big endian CPUs. So there would have to be a 'reverse byte order' bit at least. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some) formats in CPU endianness. OK. We agree then. I don't know how you envision this auxiliary functionality. I don't think it is actually necessary to define a bunch of PIPE_FORMAT__REV formats, given that no hardware will ever support them. Instead code generate a variation of u_format_access.py which reads formats in native endianness should suffice. That is void util_format_read_4f_native(...);
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 07:03 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 15:51 +0100, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. ... and at least for some others, e.g. 16 bit 565 or 1555 formats, 'always little endian' would mean that some API formats couldn't be represented by Gallium formats on big endian CPUs. So there would have to be a 'reverse byte order' bit at least. Just to see if I have the right facts here: does ATI NVIDIA hardware only support little endian 565 and 1555 formats, or do they also support the big endian formats too? Jose -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 07:13 -0800, José Fonseca wrote: On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some) formats in CPU endianness. OK. We agree then. I don't know how you envision this auxiliary functionality. I don't think it is actually necessary to define a bunch of PIPE_FORMAT__REV
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 15:13 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some) formats in CPU endianness. OK. We agree then. I don't know how you envision this auxiliary functionality. I don't really have a clear vision yet how it's going to work. :} I don't think it
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 15:18 +, Keith Whitwell wrote: On Wed, 2010-01-06 at 07:13 -0800, José Fonseca wrote: On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define
Re: [Mesa3d-dev] Mystery of u_format.csv
2010/1/6 Michel Dänzer mic...@daenzer.net: On Wed, 2010-01-06 at 15:18 +, Keith Whitwell wrote: On Wed, 2010-01-06 at 07:13 -0800, José Fonseca wrote: On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM , arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM , arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM , arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some)
Re: [Mesa3d-dev] Mystery of u_format.csv
Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Thanks. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
The data in u_format.csv was migrated from p_format which was full of inconsistencies. I've fixed some of these but there are others which I haven't. Read the pipe_format lookup table thread of mesa3d-dev if you want to know the background. I'll add more documentation to u_format.h. The gist is source channels come in a vector ordered from least significant bit - highest significant bit. Jose On Mon, 2009-12-21 at 23:40 -0800, Marek Olšák wrote: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
