Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
Consistency between different formats is not always a good metric here, as there are all sort of historical reasons which make the used set of formats out of all possible quite asymmetric. PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. But I think you stumbled on something: PIPE_FORMAT_R8G8B8X8_SNORM might not be needed. It's not used anywhere, nor can I find mention of such format in D3D9/10. I'll remove it if nobody opposes. Jose From: Luca Barbieri [luca.barbi...@gmail.com] Sent: Tuesday, March 02, 2010 22:16 To: Jose Fonseca Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles) Shouldn't PIPE_FORMAT_X8B8G8R8_UNORM= 68, be instead R8G8B8X8_UNORM, which is currently missing, for consistency with: PIPE_FORMAT_R8G8B8X8_SNORM= 81, with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote: PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. Yes, you're right. BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are indeed missing. Neither of the mentioned formats is required for D3D9 conformance, but we could add them to gallium. D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the best way to support it would be to treat it as a 8x1 macro pixel, 8bits, similarly to compressed formats. D3DFMT_CxV8U8 too as special semantics. Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On 03.03.2010 14:07, José Fonseca wrote: On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote: PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. Yes, you're right. BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are indeed missing. Neither of the mentioned formats is required for D3D9 conformance, but we could add them to gallium. D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the best way to support it would be to treat it as a 8x1 macro pixel, 8bits, similarly to compressed formats. D3DFMT_CxV8U8 too as special semantics. And not only are those formats optional, some would be completely pointless in gallium (D15S1, D24X4S4). There's simply no modern hardware which supports 1 bit stencil (I think pretty much the only chip supporting that was savage3d), nor 4 bit stencil (can't remember off-hand any chip supporting that, maybe some of the then professional chips did). The others sound a bit more plausible and hardware may support them, but I'm not sure they are really missed (A4L4, X4R4G4B4, X1R5G5B5). As José said, CxV8U8 isn't really a format only, and we'll need to add 1-bit format for DX10. Roland -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote:
On Tue, 2010-02-23 at 09:20 -0800, José Fonseca wrote:
On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every
texture format except SCALED ones, a few regressions have showed up.
This patch resolves all issues I had, especially with the SRGB formats
but I decided to clean it up all. git log:
util: fix swizzles in the format table for 8-bits-per-channel
formats
The 8-bits-per-channel formats having the same channel order had
completely
different swizzles, and at the same time, the same swizzles were
used for
completely different channel orders of 8bpc formats.
This made the whole table self-contradicting, caused headaches,
and last
but not least, incorrent rendering for the drivers relying on
these swizzles.
I hope I got it right. I didn't make a special distinction between the
array and arith layouts. All I did was to make sure that if I grep
e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
ones.
Hi Marek,
I'll need a bit more time to investigate this.
One problem is that the interpretation of the swizzle varies with array
vs arith. The ordering for array is the lowest significant word to the
highest significant word (where word for 8bit formats is a byte), where
for arith it goes from least significant bit to the highest significant
bit. This is the same difference as array indexation and bit shifts.
There is also the problem of byte order which affects the bit shift
interpretation...
I admit thet the current format description table is terribly
underdocumented/confusing and likely broken in several ways. I wrote it
to be able to code generate pixel format translation (which is wroking
reasonably) and never expected people to use it for hardware drivers as
well, although it is perfectly legitimate use.
I have my own interpretation of these concepts, you and others hw driver
writers have their own different interpretation. Furthermore in
draw/translate/util modules there are some inconsistencies in these
interpretations too. So I need to read the GL and DX10 specs very well,
see how current drivers are using the descriptions, and come up with
something that makes sense for everybody.
So please hold on to your patch for a couple of days.
I'd appreciate if the interested parties could take a good look to
u_format.h comments, and summarize what they think the format semantics
should be.
Jose
There are two inconsistencies in formats ATM:
a) the notation used in PIPE_FORMAT_xxx, and
b) the values in util_format_description::swizzles .
There's a D3D9 - D3D10 format conversion table in
http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content
and D3D9 - GL format table in
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD
.
D3D10 dropped all arithmetically encoded formats, and inverted the
swizzle notation (e.g., D3DFMT_A2B10G10R10 and DXGI_FORMAT_R10G10B10A2
are equivalent).
Gallium has to represent both kinds and mixes both notations (the
MSB-LSB notation traditionally used for texture formats, the LSB-MSB
for vertex declarations). So instead of the current inconsistencies,
both on p_format.h and u_format.csv, I suggest we all normalize on one
notation, lets say MSB-LSB for pixel/vertex formats.
For example, the vertex format
struct vertex {
float x;
float y;
};
should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
- D3D9's D3DFMT_G32R32F texture format
- D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
- D3D10's DXGI_FORMAT_R32G32_FLOAT
- OpenGL's GL_RG32F format
- OpenGL's glVertexAttrib2f attribute
- OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
- etc.
For the util_format_description::swizzles I suggest we always refer the
swizzles from LSB-MSB.
Leaving the interface change aside for now (Keith is away this week),
unless somebody has a better suggestion I'll update at least the meaning
of util_format_description::swizzles and u_format.csv to be consistent
with this.
I'm finished with my u_format* cleanups for now.
We have no unit tests for pixel formats yet so there might be some
regressions. Let me know.
As said in the bottom of u_format.csv, there are the formats with
unclear / inconsistent semantics:
# Ambiguous formats
# FIXME: They are used
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On Tue, 2010-03-02 at 02:44 -0800, José Fonseca wrote:
On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote:
On Tue, 2010-02-23 at 09:20 -0800, José Fonseca wrote:
On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every
texture format except SCALED ones, a few regressions have showed up.
This patch resolves all issues I had, especially with the SRGB formats
but I decided to clean it up all. git log:
util: fix swizzles in the format table for 8-bits-per-channel
formats
The 8-bits-per-channel formats having the same channel order had
completely
different swizzles, and at the same time, the same swizzles were
used for
completely different channel orders of 8bpc formats.
This made the whole table self-contradicting, caused headaches,
and last
but not least, incorrent rendering for the drivers relying on
these swizzles.
I hope I got it right. I didn't make a special distinction between the
array and arith layouts. All I did was to make sure that if I grep
e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
ones.
Hi Marek,
I'll need a bit more time to investigate this.
One problem is that the interpretation of the swizzle varies with array
vs arith. The ordering for array is the lowest significant word to the
highest significant word (where word for 8bit formats is a byte), where
for arith it goes from least significant bit to the highest significant
bit. This is the same difference as array indexation and bit shifts.
There is also the problem of byte order which affects the bit shift
interpretation...
I admit thet the current format description table is terribly
underdocumented/confusing and likely broken in several ways. I wrote it
to be able to code generate pixel format translation (which is wroking
reasonably) and never expected people to use it for hardware drivers as
well, although it is perfectly legitimate use.
I have my own interpretation of these concepts, you and others hw driver
writers have their own different interpretation. Furthermore in
draw/translate/util modules there are some inconsistencies in these
interpretations too. So I need to read the GL and DX10 specs very well,
see how current drivers are using the descriptions, and come up with
something that makes sense for everybody.
So please hold on to your patch for a couple of days.
I'd appreciate if the interested parties could take a good look to
u_format.h comments, and summarize what they think the format semantics
should be.
Jose
There are two inconsistencies in formats ATM:
a) the notation used in PIPE_FORMAT_xxx, and
b) the values in util_format_description::swizzles .
There's a D3D9 - D3D10 format conversion table in
http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content
and D3D9 - GL format table in
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD
.
D3D10 dropped all arithmetically encoded formats, and inverted the
swizzle notation (e.g., D3DFMT_A2B10G10R10 and DXGI_FORMAT_R10G10B10A2
are equivalent).
Gallium has to represent both kinds and mixes both notations (the
MSB-LSB notation traditionally used for texture formats, the LSB-MSB
for vertex declarations). So instead of the current inconsistencies,
both on p_format.h and u_format.csv, I suggest we all normalize on one
notation, lets say MSB-LSB for pixel/vertex formats.
For example, the vertex format
struct vertex {
float x;
float y;
};
should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
- D3D9's D3DFMT_G32R32F texture format
- D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
- D3D10's DXGI_FORMAT_R32G32_FLOAT
- OpenGL's GL_RG32F format
- OpenGL's glVertexAttrib2f attribute
- OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
- etc.
For the util_format_description::swizzles I suggest we always refer the
swizzles from LSB-MSB.
Leaving the interface change aside for now (Keith is away this week),
unless somebody has a better suggestion I'll update at least the meaning
of util_format_description::swizzles and u_format.csv to be consistent
with this.
I'm finished with my u_format* cleanups for now.
We have no unit tests for pixel formats yet so there might be some
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
Shouldn't PIPE_FORMAT_X8B8G8R8_UNORM= 68, be instead R8G8B8X8_UNORM, which is currently missing, for consistency with: PIPE_FORMAT_R8G8B8X8_SNORM= 81, with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
