[Mesa3d-dev] [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Attached.
From c91abe0b58abc69743c162fd55f7461a716b9141 Mon Sep 17 00:00:00 2001
From: Michal Krol mic...@vmware.com
Date: Wed, 6 Jan 2010 09:48:41 +0100
Subject: [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Seems to be the only way to stay fully portable.
---
src/gallium/drivers/svga/svga_tgsi.h | 18 +-
.../dri/r300/compiler/radeon_pair_regalloc.c |2 +-
.../drivers/dri/r300/compiler/radeon_program.h | 14 +++---
.../dri/r300/compiler/radeon_program_pair.h| 10 +-
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 896c90a..d132525 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -39,24 +39,24 @@ struct tgsi_token;
struct svga_vs_compile_key
{
- ubyte need_prescale:1;
- ubyte allow_psiz:1;
unsigned zero_stride_vertex_elements;
- ubyte num_zero_stride_vertex_elements:6;
+ unsigned need_prescale:1;
+ unsigned allow_psiz:1;
+ unsigned num_zero_stride_vertex_elements:6;
};
struct svga_fs_compile_key
{
- boolean light_twoside:1;
- boolean front_cw:1;
+ unsigned light_twoside:1;
+ unsigned front_cw:1;
ubyte num_textures;
ubyte num_unnormalized_coords;
struct {
- ubyte compare_mode : 1;
- ubyte compare_func : 3;
- ubyte unnormalized : 1;
+ unsigned compare_mode : 1;
+ unsigned compare_func : 3;
+ unsigned unnormalized : 1;
- ubyte width_height_idx : 7;
+ unsigned width_height_idx : 7;
ubyte texture_target;
} tex[PIPE_MAX_SAMPLERS];
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
b/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
index 828d0c8..b2fe7f7 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
@@ -49,7 +49,7 @@ struct register_info {
unsigned int Used:1;
unsigned int Allocated:1;
- rc_register_file File:3;
+ unsigned int File:3;
unsigned int Index:RC_REGISTER_INDEX_BITS;
};
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program.h
b/src/mesa/drivers/dri/r300/compiler/radeon_program.h
index 0359288..e318867 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_program.h
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_program.h
@@ -39,7 +39,7 @@
struct radeon_compiler;
struct rc_src_register {
- rc_register_file File:3;
+ unsigned int File:3;
/** Negative values may be used for relative addressing. */
signed int Index:(RC_REGISTER_INDEX_BITS+1);
@@ -55,7 +55,7 @@ struct rc_src_register {
};
struct rc_dst_register {
- rc_register_file File:3;
+ unsigned int File:3;
/** Negative values may be used for relative addressing. */
signed int Index:(RC_REGISTER_INDEX_BITS+1);
@@ -79,20 +79,20 @@ struct rc_sub_instruction {
/**
* Opcode of this instruction, according to \ref rc_opcode enums.
*/
- rc_opcode Opcode:8;
+ unsigned int Opcode:8;
/**
* Saturate each value of the result to the range [0,1] or [-1,1],
* according to \ref rc_saturate_mode enums.
*/
- rc_saturate_mode SaturateMode:2;
+ unsigned int SaturateMode:2;
/**
* Writing to the special register RC_SPECIAL_ALU_RESULT
*/
/*...@{*/
- rc_write_aluresult WriteALUResult:2;
- rc_compare_func ALUResultCompare:3;
+ unsigned int WriteALUResult:2;
+ unsigned int ALUResultCompare:3;
/*...@}*/
/**
@@ -103,7 +103,7 @@ struct rc_sub_instruction {
unsigned int TexSrcUnit:5;
/** Source texture target, one of the \ref rc_texture_target enums */
- rc_texture_target TexSrcTarget:3;
+ unsigned int TexSrcTarget:3;
/** True if tex instruction should do shadow comparison */
unsigned int TexShadow:1;
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h
b/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h
index 1600598..6685ade 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h
@@ -52,12 +52,12 @@ struct r300_fragment_program_compiler;
struct radeon_pair_instruction_source {
unsigned int Used:1;
- rc_register_file File:3;
+ unsigned int File:3;
unsigned int Index:RC_REGISTER_INDEX_BITS;
};
struct radeon_pair_instruction_rgb {
- rc_opcode Opcode:8;
+ unsigned int Opcode:8;
unsigned int DestIndex:RC_REGISTER_INDEX_BITS;
unsigned int WriteMask:3;
unsigned int OutputWriteMask:3;
@@ -74,7 +74,7 @@ struct radeon_pair_instruction_rgb {
};
struct radeon_pair_instruction_alpha {
-
Re: [Mesa3d-dev] [PATCH] Make sure we use only signed/unsigned ints with bitfields.
On Wed, 2010-01-06 at 00:50 -0800, michal wrote:
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 896c90a..d132525 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -39,24 +39,24 @@ struct tgsi_token;
struct svga_vs_compile_key
{
- ubyte need_prescale:1;
- ubyte allow_psiz:1;
unsigned zero_stride_vertex_elements;
- ubyte num_zero_stride_vertex_elements:6;
+ unsigned need_prescale:1;
+ unsigned allow_psiz:1;
+ unsigned num_zero_stride_vertex_elements:6;
};
struct svga_fs_compile_key
{
- boolean light_twoside:1;
- boolean front_cw:1;
+ unsigned light_twoside:1;
+ unsigned front_cw:1;
ubyte num_textures;
ubyte num_unnormalized_coords;
struct {
- ubyte compare_mode : 1;
- ubyte compare_func : 3;
- ubyte unnormalized : 1;
+ unsigned compare_mode : 1;
+ unsigned compare_func : 3;
+ unsigned unnormalized : 1;
- ubyte width_height_idx : 7;
+ unsigned width_height_idx : 7;
ubyte texture_target;
} tex[PIPE_MAX_SAMPLERS];
Michal, these two structs should be kept as small as possible. It looks
like there has been some drift away from well-packed fields anyway, but
if you're making this change can you please take a moment to repack the
fields as a result and get these down to as small as possible?
In particular, it looks like fs_compile_key::tex array has probably
doubled in size - could you repack it by changing texture_target to, eg:
unsigned texture_target:8;
or similar?
The same would apply for the other ubyte fields that are now probably no
longer tightly packed.
Keith
--
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] [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Keith Whitwell wrote on 2010-01-06 10:43:
On Wed, 2010-01-06 at 00:50 -0800, michal wrote:
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 896c90a..d132525 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -39,24 +39,24 @@ struct tgsi_token;
struct svga_vs_compile_key
{
- ubyte need_prescale:1;
- ubyte allow_psiz:1;
unsigned zero_stride_vertex_elements;
- ubyte num_zero_stride_vertex_elements:6;
+ unsigned need_prescale:1;
+ unsigned allow_psiz:1;
+ unsigned num_zero_stride_vertex_elements:6;
};
struct svga_fs_compile_key
{
- boolean light_twoside:1;
- boolean front_cw:1;
+ unsigned light_twoside:1;
+ unsigned front_cw:1;
ubyte num_textures;
ubyte num_unnormalized_coords;
struct {
- ubyte compare_mode : 1;
- ubyte compare_func : 3;
- ubyte unnormalized : 1;
+ unsigned compare_mode : 1;
+ unsigned compare_func : 3;
+ unsigned unnormalized : 1;
- ubyte width_height_idx : 7;
+ unsigned width_height_idx : 7;
ubyte texture_target;
} tex[PIPE_MAX_SAMPLERS];
Michal, these two structs should be kept as small as possible. It looks
like there has been some drift away from well-packed fields anyway, but
if you're making this change can you please take a moment to repack the
fields as a result and get these down to as small as possible?
In particular, it looks like fs_compile_key::tex array has probably
doubled in size - could you repack it by changing texture_target to, eg:
unsigned texture_target:8;
or similar?
The same would apply for the other ubyte fields that are now probably no
longer tightly packed.
Attached an update.
There was nothing more I could do to svga_vs_compile_key, though, as the
zero_stride_vertex_elements field is being fully used.
From af7c95dd2539e6b5d64ad62c30ef6952e83fcf98 Mon Sep 17 00:00:00 2001
From: Michal Krol mic...@vmware.com
Date: Wed, 6 Jan 2010 11:23:43 +0100
Subject: [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Seems to be the only way to stay fully portable.
---
src/gallium/drivers/svga/svga_tgsi.h | 26 +--
.../dri/r300/compiler/radeon_pair_regalloc.c |2 +-
.../drivers/dri/r300/compiler/radeon_program.h | 14 +-
.../dri/r300/compiler/radeon_program_pair.h| 10
4 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 896c90a..1309c33 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -39,26 +39,24 @@ struct tgsi_token;
struct svga_vs_compile_key
{
- ubyte need_prescale:1;
- ubyte allow_psiz:1;
unsigned zero_stride_vertex_elements;
- ubyte num_zero_stride_vertex_elements:6;
+ unsigned need_prescale:1;
+ unsigned allow_psiz:1;
+ unsigned num_zero_stride_vertex_elements:6;
};
struct svga_fs_compile_key
{
- boolean light_twoside:1;
- boolean front_cw:1;
- ubyte num_textures;
- ubyte num_unnormalized_coords;
+ unsigned light_twoside:1;
+ unsigned front_cw:1;
+ unsigned num_textures:8;
+ unsigned num_unnormalized_coords:8;
struct {
- ubyte compare_mode : 1;
- ubyte compare_func : 3;
- ubyte unnormalized : 1;
-
- ubyte width_height_idx : 7;
-
- ubyte texture_target;
+ unsigned compare_mode:1;
+ unsigned compare_func:3;
+ unsigned unnormalized:1;
+ unsigned width_height_idx:7;
+ unsigned texture_target:8;
} tex[PIPE_MAX_SAMPLERS];
};
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
b/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
index 828d0c8..b2fe7f7 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_pair_regalloc.c
@@ -49,7 +49,7 @@ struct register_info {
unsigned int Used:1;
unsigned int Allocated:1;
- rc_register_file File:3;
+ unsigned int File:3;
unsigned int Index:RC_REGISTER_INDEX_BITS;
};
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program.h
b/src/mesa/drivers/dri/r300/compiler/radeon_program.h
index 0359288..e318867 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_program.h
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_program.h
@@ -39,7 +39,7 @@
struct radeon_compiler;
struct rc_src_register {
- rc_register_file File:3;
+ unsigned int File:3;
/** Negative values may be used for relative addressing. */
signed int Index:(RC_REGISTER_INDEX_BITS+1);
@@ -55,7 +55,7 @@ struct rc_src_register {
};
struct rc_dst_register {
- rc_register_file File:3;
+ unsigned int File:3;
/** Negative values may be used for relative addressing. */
signed int
Re: [Mesa3d-dev] [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Looks good to me Michal.
Keith
On Wed, 2010-01-06 at 02:26 -0800, michal wrote:
Keith Whitwell wrote on 2010-01-06 10:43:
On Wed, 2010-01-06 at 00:50 -0800, michal wrote:
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 896c90a..d132525 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -39,24 +39,24 @@ struct tgsi_token;
struct svga_vs_compile_key
{
- ubyte need_prescale:1;
- ubyte allow_psiz:1;
unsigned zero_stride_vertex_elements;
- ubyte num_zero_stride_vertex_elements:6;
+ unsigned need_prescale:1;
+ unsigned allow_psiz:1;
+ unsigned num_zero_stride_vertex_elements:6;
};
struct svga_fs_compile_key
{
- boolean light_twoside:1;
- boolean front_cw:1;
+ unsigned light_twoside:1;
+ unsigned front_cw:1;
ubyte num_textures;
ubyte num_unnormalized_coords;
struct {
- ubyte compare_mode : 1;
- ubyte compare_func : 3;
- ubyte unnormalized : 1;
+ unsigned compare_mode : 1;
+ unsigned compare_func : 3;
+ unsigned unnormalized : 1;
- ubyte width_height_idx : 7;
+ unsigned width_height_idx : 7;
ubyte texture_target;
} tex[PIPE_MAX_SAMPLERS];
Michal, these two structs should be kept as small as possible. It looks
like there has been some drift away from well-packed fields anyway, but
if you're making this change can you please take a moment to repack the
fields as a result and get these down to as small as possible?
In particular, it looks like fs_compile_key::tex array has probably
doubled in size - could you repack it by changing texture_target to, eg:
unsigned texture_target:8;
or similar?
The same would apply for the other ubyte fields that are now probably no
longer tightly packed.
Attached an update.
There was nothing more I could do to svga_vs_compile_key, though, as the
zero_stride_vertex_elements field is being fully used.
--
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 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] [PATCH] condition always evaluates to false
On Tue, Jan 5, 2010 at 11:51 PM, Brian Paul bri...@vmware.com wrote:
Roel Kluin wrote:
These can never be true.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/gallium/drivers/i965/brw_wm_emit.c | 2 +-
src/mesa/drivers/dri/i915/intel_tris.c | 2 +-
src/mesa/drivers/dri/i965/brw_wm_emit.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
@@ -691,7 +691,7 @@ static void emit_xpd( struct brw_compile *p,
{
GLuint i;
- assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_X);
+ assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
@@ -692,7 +692,7 @@ void emit_xpd(struct brw_compile *p,
{
GLuint i;
- assert(!(mask WRITEMASK_W) == WRITEMASK_X);
+ assert((mask WRITEMASK_W) != WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
.
I believe the first and third assertions should read:
assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_W);
I'll fix those.
I think you mean
assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_W);
You probably know this: `!' has a higher precedence than `==' so
the `!(mask BRW_WRITEMASK_W)' part evaluates either to 0 or 1
and can never be BRW_WRITEMASK_W (defined 0x8).
-Brian
thanks,
Roel
--
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] [PATCH] condition always evaluates to false
On Wed, Jan 6, 2010 at 5:54 AM, roel kluin roel.kl...@gmail.com wrote:
On Tue, Jan 5, 2010 at 11:51 PM, Brian Paul bri...@vmware.com wrote:
Roel Kluin wrote:
These can never be true.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/gallium/drivers/i965/brw_wm_emit.c | 2 +-
src/mesa/drivers/dri/i915/intel_tris.c | 2 +-
src/mesa/drivers/dri/i965/brw_wm_emit.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
@@ -691,7 +691,7 @@ static void emit_xpd( struct brw_compile *p,
{
GLuint i;
- assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_X);
+ assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
@@ -692,7 +692,7 @@ void emit_xpd(struct brw_compile *p,
{
GLuint i;
- assert(!(mask WRITEMASK_W) == WRITEMASK_X);
+ assert((mask WRITEMASK_W) != WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
.
I believe the first and third assertions should read:
assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_W);
I'll fix those.
I think you mean
assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_W);
You probably know this: `!' has a higher precedence than `==' so
the `!(mask BRW_WRITEMASK_W)' part evaluates either to 0 or 1
and can never be BRW_WRITEMASK_W (defined 0x8).
Oops, yes. I'll fix that (again). Thanks.
-Brian
--
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
[Mesa3d-dev] [PATCH] nv50: add missing parentheses in nv50_query_result()
NOUVEAU_BO_RD is defined (1 2), and `|' has higher precedence than `?'
so the second argument of nouveau_bo_map was always 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/gallium/drivers/nv50/nv50_query.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_query.c
b/src/gallium/drivers/nv50/nv50_query.c
index 5d9e182..5a4ab35 100644
--- a/src/gallium/drivers/nv50/nv50_query.c
+++ b/src/gallium/drivers/nv50/nv50_query.c
@@ -111,7 +111,7 @@ nv50_query_result(struct pipe_context *pipe, struct
pipe_query *pq,
if (!q-ready) {
ret = nouveau_bo_map(q-bo, NOUVEAU_BO_RD |
-wait ? 0 : NOUVEAU_BO_NOWAIT);
+(wait ? 0 : NOUVEAU_BO_NOWAIT));
if (ret)
return false;
q-result = ((uint32_t *)q-bo-map)[1];
--
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
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] [PATCH] Make sure we use only signed/unsigned ints with bitfields.
Keith Whitwell wrote on 2010-01-06 11:31: Looks good to me Michal. Thanks, commited. -- 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
[Mesa3d-dev] [PATCH] win32_menu: add missing parentheses in mapMenu()
`|' has higher precedence than `?'.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/glut/glx/win32_menu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glut/glx/win32_menu.c b/src/glut/glx/win32_menu.c
index 5ce264d..d8e336c 100644
--- a/src/glut/glx/win32_menu.c
+++ b/src/glut/glx/win32_menu.c
@@ -97,7 +97,7 @@ static void
mapMenu(GLUTmenu * menu, int x, int y)
{
TrackPopupMenu((HMENU) menu-win, TPM_LEFTALIGN |
-(__glutMenuButton == TPM_RIGHTBUTTON) ? TPM_RIGHTBUTTON : TPM_LEFTBUTTON,
+((__glutMenuButton == TPM_RIGHTBUTTON) ? TPM_RIGHTBUTTON : TPM_LEFTBUTTON),
x, y, 0, __glutCurrentWindow-win, NULL);
}
--
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
[Mesa3d-dev] [PATCH] test index bounds before array element
Check whether the index is within bounds before accessing the array.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/mesa/drivers/dri/tdfx/tdfx_dd.c |2 +-
src/mesa/shader/nvfragparse.c |2 +-
src/mesa/shader/prog_optimize.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/tdfx/tdfx_dd.c
b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
index 8472df6..ed8a331 100644
--- a/src/mesa/drivers/dri/tdfx/tdfx_dd.c
+++ b/src/mesa/drivers/dri/tdfx/tdfx_dd.c
@@ -91,7 +91,7 @@ static const GLubyte *tdfxDDGetString( GLcontext *ctx, GLenum
name )
else {
/* unexpected result: replace spaces with hyphens */
int i;
-for (i = 0; hardware[i] (i sizeof(hardware)); i++) {
+for (i = 0; i sizeof(hardware) hardware[i]; i++) {
if (hardware[i] == ' ' || hardware[i] == '\t') {
hardware[i] = '-';
}
diff --git a/src/mesa/shader/nvfragparse.c b/src/mesa/shader/nvfragparse.c
index b739a6a..8ee7c93 100644
--- a/src/mesa/shader/nvfragparse.c
+++ b/src/mesa/shader/nvfragparse.c
@@ -642,7 +642,7 @@ Parse_SwizzleSuffix(const GLubyte *token, GLuint swizzle[4])
else {
/* 4-component swizzle (vector) */
GLint k;
- for (k = 0; token[k] k 4; k++) {
+ for (k = 0; k 4 token[k]; k++) {
if (token[k] == 'x')
swizzle[k] = 0;
else if (token[k] == 'y')
diff --git a/src/mesa/shader/prog_optimize.c b/src/mesa/shader/prog_optimize.c
index 83d119e..ce41173 100644
--- a/src/mesa/shader/prog_optimize.c
+++ b/src/mesa/shader/prog_optimize.c
@@ -577,7 +577,7 @@ _mesa_remove_extra_moves(struct gl_program *prog)
/* get pointer to previous instruction */
prevI = i - 1;
-while (removeInst[prevI] prevI 0)
+while (prevI 0 removeInst[prevI])
prevI--;
prevInst = prog-Instructions + prevI;
--
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] [PATCH] nv50: add missing parentheses in nv50_query_result()
Roel Kluin wrote: NOUVEAU_BO_RD is defined (1 2), and `|' has higher precedence than `?' so the second argument of nouveau_bo_map was always 0. Applied to 7.7 branch. Thanks. -Brian -- 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] [PATCH] win32_menu: add missing parentheses in mapMenu()
Roel Kluin wrote: `|' has higher precedence than `?'. Signed-off-by: Roel Kluin roel.kl...@gmail.com Applied to 7.7 branch. Thanks. -Brian -- 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] [PATCH] test index bounds before array element
Roel Kluin wrote: Check whether the index is within bounds before accessing the array. Applied to 7.7 branch. -Brian -- 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] [PATCH] test index bounds before array element
On Wed, Jan 6, 2010 at 5:49 PM, Brian Paul bri...@vmware.com wrote: Roel Kluin wrote: Check whether the index is within bounds before accessing the array. Applied to 7.7 branch. -Brian I just realized the last one (affecting src/mesa/shader/prog_optimize.c) is wrong. Should I resend it without that hunk? Roel -- 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
[Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - From 856679477f7350553ee983f9b2bd4ff73e86f1ac Mon Sep 17 00:00:00 2001 From: Sedat Dilek sedat.di...@gmail.com Date: Wed, 6 Jan 2010 17:22:14 +0100 Subject: [PATCH] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h From build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 --- src/gallium/drivers/svga/svga_tgsi.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/svga/svga_tgsi.h b/src/gallium/drivers/svga/svga_tgsi.h index 1309c33..d49920d 100644 --- a/src/gallium/drivers/svga/svga_tgsi.h +++ b/src/gallium/drivers/svga/svga_tgsi.h @@ -56,7 +56,7 @@ struct svga_fs_compile_key unsigned compare_func:3; unsigned unnormalized:1; unsigned width_height_idx:7; - unsigned texture_target:8; + unsigned texture_target; } tex[PIPE_MAX_SAMPLERS]; }; -- 1.6.6 -- 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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- 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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul bri...@vmware.com wrote: Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- 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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
This looks like my fault. It would be nice to have the r300 and nvidia drivers building by default (eg on linux-debug builds), even if they don't create full drivers, so that a single build can get greater coverage. Keith On Wed, 2010-01-06 at 09:09 -0800, Sedat Dilek wrote: OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul bri...@vmware.com wrote: Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- 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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
r300_translate_tex_filters() was missing the is_anisotropic parameter. I fixed that, but there may be other issues. Looks like some of the r300 code isn't c99. -Brian Sedat Dilek wrote: OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul bri...@vmware.com wrote: Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- 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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Brian Paul wrote on 2010-01-06 18:07:
Sedat Dilek wrote:
Hi,
this patch fixes a build-error in mesa GIT master after...
commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch)
configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster
From my build-log:
...
In file included from svga_pipe_fs.c:37:
svga_tgsi.h: In function 'svga_fs_key_size':
svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target'
make[4]: *** [svga_pipe_fs.o] Error 1
Might be introduced in...
commit 955f51270bb60ad77dba049799587dc7c0fb4dda
Make sure we use only signed/unsigned ints with bitfields.
Kind Regars,
- Sedat -
I just fixed that.
Actually, we could go back to bitfields and fix broken svga_fs_key_size().
Attached a patch.
Can somebody review, test-build and commit?
From 7321aef0dfc5bb160ec8a33d1d4e686419f2ed3d Mon Sep 17 00:00:00 2001
From: Michal Krol mic...@vmware.com
Date: Wed, 6 Jan 2010 18:36:45 +0100
Subject: [PATCH] svga: Fix fs key size computation and key comparison.
This also allows us to have texture_target
back as a bitfield and save us a few bytes.
---
src/gallium/drivers/svga/svga_state_fs.c |9 +++--
src/gallium/drivers/svga/svga_tgsi.h |5 ++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 272d1dd..bba80a9 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -40,8 +40,13 @@
static INLINE int compare_fs_keys( const struct svga_fs_compile_key *a,
const struct svga_fs_compile_key *b )
{
- unsigned keysize = svga_fs_key_size( a );
- return memcmp( a, b, keysize );
+ unsigned keysize_a = svga_fs_key_size( a );
+ unsigned keysize_b = svga_fs_key_size( b );
+
+ if (keysize_a != keysize_b) {
+ return (int)(keysize_a - keysize_b);
+ }
+ return memcmp( a, b, keysize_a );
}
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 043b991..737a221 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -56,7 +56,7 @@ struct svga_fs_compile_key
unsigned compare_func:3;
unsigned unnormalized:1;
unsigned width_height_idx:7;
- ubyte texture_target;
+ unsigned texture_target:8;
} tex[PIPE_MAX_SAMPLERS];
};
@@ -119,8 +119,7 @@ static INLINE unsigned svga_vs_key_size( const struct
svga_vs_compile_key *key )
static INLINE unsigned svga_fs_key_size( const struct svga_fs_compile_key *key
)
{
- return (const char *)key-tex[key-num_textures].texture_target -
- (const char *)key;
+ return (const char *)key-tex[key-num_textures] - (const char *)key;
}
struct svga_shader_result *
--
1.6.4.msysgit.0
--
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] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Compile-tested OK.
- Sedat -
On Wed, Jan 6, 2010 at 6:39 PM, michal mic...@vmware.com wrote:
Brian Paul wrote on 2010-01-06 18:07:
Sedat Dilek wrote:
Hi,
this patch fixes a build-error in mesa GIT master after...
commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch)
configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster
From my build-log:
...
In file included from svga_pipe_fs.c:37:
svga_tgsi.h: In function 'svga_fs_key_size':
svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target'
make[4]: *** [svga_pipe_fs.o] Error 1
Might be introduced in...
commit 955f51270bb60ad77dba049799587dc7c0fb4dda
Make sure we use only signed/unsigned ints with bitfields.
Kind Regars,
- Sedat -
I just fixed that.
Actually, we could go back to bitfields and fix broken svga_fs_key_size().
Attached a patch.
Can somebody review, test-build and commit?
From 7321aef0dfc5bb160ec8a33d1d4e686419f2ed3d Mon Sep 17 00:00:00 2001
From: Michal Krol mic...@vmware.com
Date: Wed, 6 Jan 2010 18:36:45 +0100
Subject: [PATCH] svga: Fix fs key size computation and key comparison.
This also allows us to have texture_target
back as a bitfield and save us a few bytes.
---
src/gallium/drivers/svga/svga_state_fs.c | 9 +++--
src/gallium/drivers/svga/svga_tgsi.h | 5 ++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 272d1dd..bba80a9 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -40,8 +40,13 @@
static INLINE int compare_fs_keys( const struct svga_fs_compile_key *a,
const struct svga_fs_compile_key *b )
{
- unsigned keysize = svga_fs_key_size( a );
- return memcmp( a, b, keysize );
+ unsigned keysize_a = svga_fs_key_size( a );
+ unsigned keysize_b = svga_fs_key_size( b );
+
+ if (keysize_a != keysize_b) {
+ return (int)(keysize_a - keysize_b);
+ }
+ return memcmp( a, b, keysize_a );
}
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 043b991..737a221 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -56,7 +56,7 @@ struct svga_fs_compile_key
unsigned compare_func:3;
unsigned unnormalized:1;
unsigned width_height_idx:7;
- ubyte texture_target;
+ unsigned texture_target:8;
} tex[PIPE_MAX_SAMPLERS];
};
@@ -119,8 +119,7 @@ static INLINE unsigned svga_vs_key_size( const struct
svga_vs_compile_key *key )
static INLINE unsigned svga_fs_key_size( const struct svga_fs_compile_key
*key )
{
- return (const char *)key-tex[key-num_textures].texture_target -
- (const char *)key;
+ return (const char *)key-tex[key-num_textures] - (const char *)key;
}
struct svga_shader_result *
--
1.6.4.msysgit.0
--
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
[Mesa3d-dev] Redundant assertions: unsigned = 0, remove?
I also found several tests on unsigned variables which do
nothing. should they be removed or changed otherwise?
Roel
backref 3: src_x
---[ vi src/gallium/auxiliary/util/u_rect.c +30 ]---
void
util_copy_rect(ubyte * dst,
enum pipe_format format,
unsigned dst_stride,
unsigned dst_x,
unsigned dst_y,
unsigned width,
unsigned height,
const ubyte * src,
int src_stride,
unsigned src_x,
int src_y)
{
unsigned i;
int src_stride_pos = src_stride 0 ? -src_stride : src_stride;
int blocksize = util_format_get_blocksize(format);
int blockwidth = util_format_get_blockwidth(format);
int blockheight = util_format_get_blockheight(format);
assert(blocksize 0);
assert(blockwidth 0);
assert(blockheight 0);
assert(src_x = 0);
assert(src_y = 0);
assert(dst_x = 0);
assert(dst_y = 0);
backref 3: dst_y
---[ vi src/gallium/auxiliary/util/u_rect.c +96 ]---
void
util_fill_rect(ubyte * dst,
enum pipe_format format,
unsigned dst_stride,
unsigned dst_x,
unsigned dst_y,
unsigned width,
unsigned height,
uint32_t value)
{
unsigned i, j;
unsigned width_size;
int blocksize = util_format_get_blocksize(format);
int blockwidth = util_format_get_blockwidth(format);
int blockheight = util_format_get_blockheight(format);
assert(blocksize 0);
assert(blockwidth 0);
assert(blockheight 0);
assert(dst_x = 0);
assert(dst_y = 0);
backref 3: min_lod
---[ vi src/gallium/drivers/svga/svga_screen_texture.c +905 ]---
struct svga_sampler_view *
svga_get_tex_sampler_view(struct pipe_context *pipe, struct pipe_texture *pt,
unsigned min_lod, unsigned max_lod)
{
struct svga_screen *ss = svga_screen(pt-screen);
struct svga_texture *tex = svga_texture(pt);
struct svga_sampler_view *sv = NULL;
SVGA3dSurfaceFormat format = svga_translate_format(pt-format);
boolean view = TRUE;
assert(pt);
assert(min_lod = 0);
backref 3: num
---[ vi src/glx/x11/indirect.c +9268 ]---
void
__indirect_glProgramParameters4dvNV(GLenum target, GLuint index, GLuint num,
const GLdouble * params)
{
__GLXcontext *const gc = __glXGetCurrentContext();
const GLuint cmdlen = 16 + __GLX_PAD((num * 32));
if (num 0) {
__glXSetError(gc, GL_INVALID_VALUE);
return;
}
if (__builtin_expect(num = 0, 1)) {
backref 3: num
---[ vi src/glx/x11/indirect.c +9292 ]---
#define X_GLrop_ProgramParameters4fvNV 4186
void
__indirect_glProgramParameters4fvNV(GLenum target, GLuint index, GLuint num,
const GLfloat * params)
{
__GLXcontext *const gc = __glXGetCurrentContext();
const GLuint cmdlen = 16 + __GLX_PAD((num * 16));
if (num 0) {
__glXSetError(gc, GL_INVALID_VALUE);
return;
}
if (__builtin_expect(num = 0, 1)) {
--
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
[Mesa3d-dev] [RFC] add support to double opcodes
Hi,
the patches add support to double opcodes in gallium/tgsi.
It just implement some opcodes i like to know if someone has
suggestion about the patches.
Igor
From e856e2aa3b801fc6f386a88df646a396c27d8ee8 Mon Sep 17 00:00:00 2001
From: Igor Oliveira igor.olive...@openbossa.org
Date: Wed, 6 Jan 2010 15:50:00 -0400
Subject: [PATCH 1/2] gallium: Add double opcodes
---
src/gallium/include/pipe/p_shader_tokens.h | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
index 550e2ab..efbbafe 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -319,7 +319,15 @@ struct tgsi_property_data {
#define TGSI_OPCODE_CASE142
#define TGSI_OPCODE_DEFAULT 143
#define TGSI_OPCODE_ENDSWITCH 144
-#define TGSI_OPCODE_LAST145
+
+#define TGSI_OPCODE_MOVD145
+#define TGSI_OPCODE_DDIV146
+#define TGSI_OPCODE_DMAX147
+#define TGSI_OPCODE_DMIN148
+#define TGSI_OPCODE_DNEG149
+#define TGSI_OPCODE_DSGE150
+#define TGSI_OPCODE_DSLT151
+#define TGSI_OPCODE_LAST152
#define TGSI_SAT_NONE0 /* do not saturate */
#define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
--
1.6.3.3
From 8be48c41cfc988279832d60f02c2cf496590e162 Mon Sep 17 00:00:00 2001
From: Igor Oliveira igor.olive...@openbossa.org
Date: Wed, 6 Jan 2010 15:51:09 -0400
Subject: [PATCH 2/2] tgsi: implement double opcodes
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 113 +-
src/gallium/auxiliary/tgsi/tgsi_exec.h |1 +
src/gallium/auxiliary/tgsi/tgsi_info.c |7 ++
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h |7 ++
4 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index f43233b..ddcc829 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -380,6 +380,85 @@ micro_trunc(union tgsi_exec_channel *dst,
dst-f[3] = (float)(int)src-f[3];
}
+static void
+micro_movd(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src)
+{
+ dst-d[0] = src-d[0];
+ dst-d[1] = src-d[1];
+ dst-d[2] = src-d[2];
+ dst-d[3] = src-d[3];
+}
+
+static void
+micro_ddiv(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src0,
+ const union tgsi_exec_channel *src1)
+{
+ if (src1-d[0] != 0)
+ dst-d[0] = src0-d[0]/src1-d[0];
+ if (src1-d[1] != 0)
+ dst-d[1] = src0-d[1]/src1-d[1];
+ if (src1-d[2] != 0)
+ dst-d[2] = src0-d[2]/src1-d[2];
+ if (src1-d[3] != 0)
+ dst-d[3] = src0-d[3]/src1-d[3];
+}
+
+static void
+micro_dmax(
+ union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src0,
+ const union tgsi_exec_channel *src1)
+{
+ dst-d[0] = src0-d[0] src1-d[0] ? src0-d[0] : src1-d[0];
+ dst-d[1] = src0-d[1] src1-d[1] ? src0-d[1] : src1-d[1];
+ dst-d[2] = src0-d[2] src1-d[2] ? src0-d[2] : src1-d[2];
+ dst-d[3] = src0-d[3] src1-d[3] ? src0-d[3] : src1-d[3];
+}
+
+static void
+micro_dmin(
+ union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src0,
+ const union tgsi_exec_channel *src1)
+{
+ dst-d[0] = src0-d[0] src1-d[0] ? src0-d[0] : src1-d[0];
+ dst-d[1] = src0-d[1] src1-d[1] ? src0-d[1] : src1-d[1];
+ dst-d[2] = src0-d[2] src1-d[2] ? src0-d[2] : src1-d[2];
+ dst-d[3] = src0-d[3] src1-d[3] ? src0-d[3] : src1-d[3];
+}
+
+static void
+micro_dneg(
+ union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src )
+{
+ dst-d[0] = -src-d[0];
+ dst-d[1] = -src-d[1];
+ dst-d[2] = -src-d[2];
+ dst-d[3] = -src-d[3];
+}
+
+static void
+micro_dsge(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src)
+{
+ dst-d[0] = src[0].d[0] = src[1].d[0] ? 1.0f : 0.0f;
+ dst-d[1] = src[0].d[1] = src[1].d[1] ? 1.0f : 0.0f;
+ dst-d[2] = src[0].d[2] = src[1].d[2] ? 1.0f : 0.0f;
+ dst-d[3] = src[0].d[3] = src[1].d[3] ? 1.0f : 0.0f;
+}
+
+static void
+micro_dslt(union tgsi_exec_channel *dst,
+ const union tgsi_exec_channel *src)
+{
+ dst-d[0] = src[0].d[0] src[1].d[0] ? 1.0f : 0.0f;
+ dst-d[1] = src[0].d[1] src[1].d[1] ? 1.0f : 0.0f;
+ dst-d[2] = src[0].d[2] src[1].d[2] ? 1.0f : 0.0f;
+ dst-d[3] = src[0].d[3] src[1].d[3] ? 1.0f : 0.0f;
+}
#define CHAN_X 0
#define CHAN_Y 1
@@ -389,7 +468,8 @@ micro_trunc(union tgsi_exec_channel *dst,
enum tgsi_exec_datatype {
TGSI_EXEC_DATA_FLOAT,
TGSI_EXEC_DATA_INT,
- TGSI_EXEC_DATA_UINT
+ TGSI_EXEC_DATA_UINT,
+ TGSI_EXEC_DATA_DOUBLE
};
/*
@@ -3491,6 +3571,34 @@ exec_instruction(
exec_vector_binary(mach, inst, micro_usne, TGSI_EXEC_DATA_UINT, TGSI_EXEC_DATA_UINT);
break;
+ case TGSI_OPCODE_MOVD:
+
Re: [Mesa3d-dev] [PATCH] condition always evaluates to false
On Tue, 05 Jan 2010 23:13:54 +0100, Roel Kluin roel.kl...@gmail.com wrote:
These can never be true.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/gallium/drivers/i965/brw_wm_emit.c |2 +-
src/mesa/drivers/dri/i915/intel_tris.c |2 +-
src/mesa/drivers/dri/i965/brw_wm_emit.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
see commit f67748038935e609aa85450b20d550b4813c9429 for
the change in src/mesa/drivers/dri/i915/intel_tris.c
diff --git a/src/gallium/drivers/i965/brw_wm_emit.c
b/src/gallium/drivers/i965/brw_wm_emit.c
index 7e57d03..7e35ee1 100644
--- a/src/gallium/drivers/i965/brw_wm_emit.c
+++ b/src/gallium/drivers/i965/brw_wm_emit.c
@@ -691,7 +691,7 @@ static void emit_xpd( struct brw_compile *p,
{
GLuint i;
- assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_X);
+ assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index 63c5ae9..a182f68 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -221,7 +221,7 @@ void intel_flush_prim(struct intel_context *intel)
intel-prim.count = 0;
offset = intel-prim.start_offset;
intel-prim.start_offset = intel-prim.current_offset;
- if (!intel-gen = 3)
+ if (intel-gen 3)
intel-prim.start_offset = ALIGN(intel-prim.start_offset, 128);
intel-prim.flush = NULL;
diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c
b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index cc1052f..91ac37c 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -692,7 +692,7 @@ void emit_xpd(struct brw_compile *p,
{
GLuint i;
- assert(!(mask WRITEMASK_W) == WRITEMASK_X);
+ assert((mask WRITEMASK_W) != WRITEMASK_X);
I think this one actually meant:
assert(!(mask WRITEMASK_W));
The other fix looks good though.
pgpTWyc8Izkm7.pgp
Description: PGP signature
--
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
[Mesa3d-dev] [PATCH] Fix Viewport in _mesa_meta_GenerateMipmap
Hi list,
the first of these two patches fixes _mesa_meta_GenerateMipmap to update
the viewport and projection matrix after changing the destination mipmap
level. Before, pixels would get clipped to the boundaries of the
original DrawBuffer, which may be smaller than the second mipmap level.
The second patch just pulls projection matrix and vertex array setup out
of the main loop.
The other way to fix this i can think of is to disable clipping to
viewport. I could not figure out if that is even possible.
Tested with swrast and i965.
Regards,
Pierre
From 493e1fe00e902723c0b20cc75d83fbbca107b90e Mon Sep 17 00:00:00 2001
From: Pierre Willenbrock pie...@pirsoft.de
Date: Wed, 6 Jan 2010 22:37:18 +0100
Subject: [PATCH 1/2] Setup viewport and Projection Matrix in _mesa_meta_GenerateMipmap
This fixes mipmap levels being clipped to the last viewport.
Signed-off-by: Pierre Willenbrock pie...@pirsoft.de
---
src/mesa/drivers/common/meta.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index c4dbfa6..51dd5e0 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2430,7 +2430,7 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
texObj-Name,
dstLevel);
}
-
+
_mesa_DrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
/* sanity check */
@@ -2440,6 +2440,15 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
break;
}
+ /* setup viewport and matching projection matrix */
+ _mesa_set_viewport(ctx, 0, 0,
+ ctx-DrawBuffer-Width, ctx-DrawBuffer-Height);
+ _mesa_MatrixMode(GL_PROJECTION);
+ _mesa_LoadIdentity();
+ _mesa_Ortho(0.0F, ctx-DrawBuffer-Width,
+ 0.0F, ctx-DrawBuffer-Height,
+ -1.0F, 1.0F);
+
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
--
1.6.6.rc4
From 258f82377d39888040d297fe11b0c17d1a0a55c4 Mon Sep 17 00:00:00 2001
From: Pierre Willenbrock pie...@pirsoft.de
Date: Wed, 6 Jan 2010 22:37:32 +0100
Subject: [PATCH 2/2] Move destination vertex/projection setup out of _mesa_meta_GenerateMipmap
Signed-off-by: Pierre Willenbrock pie...@pirsoft.de
---
src/mesa/drivers/common/meta.c | 44 ---
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 51dd5e0..25234d9 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2321,6 +2321,28 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
_mesa_set_enable(ctx, target, GL_TRUE);
+ /* setup vertex positions */
+ {
+ verts[0].x = 0.0F;
+ verts[0].y = 0.0F;
+ verts[1].x = 1.0F;
+ verts[1].y = 0.0F;
+ verts[2].x = 1.0F;
+ verts[2].y = 1.0F;
+ verts[3].x = 0.0F;
+ verts[3].y = 1.0F;
+
+ /* upload new vertex data */
+ _mesa_BufferSubDataARB(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+ }
+
+ /* setup projection matrix */
+ _mesa_MatrixMode(GL_PROJECTION);
+ _mesa_LoadIdentity();
+ _mesa_Ortho(0.0F, 1.0F,
+ 0.0F, 1.0F,
+ -1.0F, 1.0F);
+
/* texture is already locked, unlock now */
_mesa_unlock_texture(ctx, texObj);
@@ -2387,21 +2409,6 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
}
}
- /* setup vertex positions */
- {
- verts[0].x = 0.0F;
- verts[0].y = 0.0F;
- verts[1].x = (GLfloat) dstWidth;
- verts[1].y = 0.0F;
- verts[2].x = (GLfloat) dstWidth;
- verts[2].y = (GLfloat) dstHeight;
- verts[3].x = 0.0F;
- verts[3].y = (GLfloat) dstHeight;
-
- /* upload new vertex data */
- _mesa_BufferSubDataARB(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
- }
-
/* limit sampling to src level */
_mesa_TexParameteri(target, GL_TEXTURE_BASE_LEVEL, srcLevel);
_mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL, srcLevel);
@@ -2440,14 +2447,9 @@ _mesa_meta_GenerateMipmap(GLcontext *ctx, GLenum target,
break;
}
- /* setup viewport and matching projection matrix */
+ /* setup viewport */
_mesa_set_viewport(ctx, 0, 0,
ctx-DrawBuffer-Width, ctx-DrawBuffer-Height);
- _mesa_MatrixMode(GL_PROJECTION);
- _mesa_LoadIdentity();
- _mesa_Ortho(0.0F, ctx-DrawBuffer-Width,
- 0.0F, ctx-DrawBuffer-Height,
- -1.0F, 1.0F);
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
--
1.6.6.rc4
--
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
Re: [Mesa3d-dev] [RFC] add support to double opcodes
On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote: Hi, the patches add support to double opcodes in gallium/tgsi. It just implement some opcodes i like to know if someone has suggestion about the patches. Hi Igor, first of all this should probably go into a feature branch because it'll be a bit of work before it's usable. The patches that you've proposed are unlikely what we'll want for double's. Keith, Michal and I discussed this on the phone a few days back and the biggest issue with doubles is that unlike the switch between the integers and floats they actually need bigger registers to accomodate them. Given that the registers in TGSI are untyped and its up to instructions to define the type it becomes hard for drivers to figure out the size of the registers beforehand. The solution that I personally like and what seems to becoming the facto standard when dealing with double support is having double precision values represented by a pair of registers. Outputs are either the pair yx or to the pair wz, where the msb is stored in y/w. For example: Idata 3.0 = (0x4008) in register r looks like: r.w =0x4008 ;high dword r.z = 0x ;low dword Or: r.y =0x4008 ;high dword r.x =0x ;low dword All source double inputs must be in xy (after swizzle operations). For example: d_add r1.xy, r2.xy, r2.xy Or d_add r1.zw, r2.xy, r2.xy Each computes twice the value in r2.xy, and places the result in either xy or zw. This assures that the register size stays constant. Of course the instruction semantics are different to the typical 4-component wide TGSI instructions, but that, I think, is a lot less of an issue. z -- 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] [PATCH] Fix Viewport in _mesa_meta_GenerateMipmap
On Wed, 06 Jan 2010 23:30:46 +0100, Pierre Willenbrock pie...@pirsoft.de wrote: Hi list, the first of these two patches fixes _mesa_meta_GenerateMipmap to update the viewport and projection matrix after changing the destination mipmap level. Before, pixels would get clipped to the boundaries of the original DrawBuffer, which may be smaller than the second mipmap level. The second patch just pulls projection matrix and vertex array setup out of the main loop. The other way to fix this i can think of is to disable clipping to viewport. I could not figure out if that is even possible. Tested with swrast and i965. Pushed a testcase for this into piglit. pgpozsg4H6Ygi.pgp Description: PGP signature -- 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] [PATCH] Fix Viewport in _mesa_meta_GenerateMipmap
Pierre Willenbrock wrote: Hi list, the first of these two patches fixes _mesa_meta_GenerateMipmap to update the viewport and projection matrix after changing the destination mipmap level. Before, pixels would get clipped to the boundaries of the original DrawBuffer, which may be smaller than the second mipmap level. The second patch just pulls projection matrix and vertex array setup out of the main loop. The other way to fix this i can think of is to disable clipping to viewport. I could not figure out if that is even possible. Tested with swrast and i965. Thanks. These look good but I might make a few little tweaks and add a couple assertions... -Brian -- 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
[Mesa3d-dev] A patch to get rbug-gui working with recent util_format and libgallium.a
Hello folks. I started at LunarG this week and have been getting more familiar with the gallium code. I noticed that rbug-gui has not been updated to match the recent changes to the util_format. Here is a patch that switches from the pr_* functions to util_format functions. (It also adds several new icons for the many formats.) I replaced the 'action-block' field with just one 'action-block_height' field. That is the only part of action-block that is needed if util_format_get_nblocksx is called instead of pf_get_nblocksy. I don't know if there is a better way to extract block height from format instead keeping it as a separate field. Do these changes look good? Mike Stroyan, m...@lunarg.com patch Description: Binary data new_icons.tar Description: Unix tar archive -- 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
[Mesa3d-dev] gallium: add overlapping blit support to u_blitter
This makes the r300g + X.org state tracker work a bit better, I can
start X + xterm + metacity and drag a window around now at least.
A full gnome session seems to have other issuess.
Dave.From b8f1d1cf45aa23c74b2d150058506a6a27737d25 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Thu, 7 Jan 2010 11:45:48 +1000
Subject: [PATCH] gallium: u_blitter add overlapping blit support.
the xorg state tracker really wants the driver to handle overlapping
blits, and r300 uses u_blitter for blits. This patch adds overlapping
blit support via a temporary surface when its required.
---
src/gallium/auxiliary/util/u_blitter.c | 158 +---
1 files changed, 124 insertions(+), 34 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util/u_blitter.c
index 1f794d3..58f0b6d 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -560,45 +560,30 @@ void util_blitter_clear(struct blitter_context *blitter,
blitter_restore_CSOs(ctx);
}
-void util_blitter_copy(struct blitter_context *blitter,
- struct pipe_surface *dst,
- unsigned dstx, unsigned dsty,
- struct pipe_surface *src,
- unsigned srcx, unsigned srcy,
- unsigned width, unsigned height,
- boolean ignore_stencil)
+static boolean
+is_overlap(int sx1, int sx2, int sy1, int sy2, int dx1, int dx2, int dy1, int dy2)
+{
+if (((sx1 = dx1) (sx1 = dx2) (sy1 = dy1) (sy1 = dy2)) || /* TL x1, y1 */
+ ((sx2 = dx1) (sx2 = dx2) (sy1 = dy1) (sy1 = dy2)) || /* TR x2, y1 */
+ ((sx1 = dx1) (sx1 = dx2) (sy2 = dy1) (sy2 = dy2)) || /* BL x1, y2 */
+ ((sx2 = dx1) (sx2 = dx2) (sy2 = dy1) (sy2 = dy2))) /* BR x2, y2 */
+ return TRUE;
+else
+ return FALSE;
+}
+
+static void util_blitter_do_copy(struct blitter_context *blitter,
+ struct pipe_surface *dst,
+ unsigned dstx, unsigned dsty,
+ struct pipe_surface *src,
+ unsigned srcx, unsigned srcy,
+ unsigned width, unsigned height,
+ boolean is_depth)
{
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
struct pipe_context *pipe = ctx-pipe;
- struct pipe_screen *screen = pipe-screen;
struct pipe_framebuffer_state fb_state;
- boolean is_stencil, is_depth;
- unsigned dst_tex_usage;
-
- /* give up if textures are not set */
- assert(dst-texture src-texture);
- if (!dst-texture || !src-texture)
- return;
-
- is_depth = util_format_get_component_bits(src-format, UTIL_FORMAT_COLORSPACE_ZS, 0) != 0;
- is_stencil = util_format_get_component_bits(src-format, UTIL_FORMAT_COLORSPACE_ZS, 1) != 0;
- dst_tex_usage = is_depth || is_stencil ? PIPE_TEXTURE_USAGE_DEPTH_STENCIL :
-PIPE_TEXTURE_USAGE_RENDER_TARGET;
-
- /* check if we can sample from and render to the surfaces */
- /* (assuming copying a stencil buffer is not possible) */
- if ((!ignore_stencil is_stencil) ||
- !screen-is_format_supported(screen, dst-format, dst-texture-target,
-dst_tex_usage, 0) ||
- !screen-is_format_supported(screen, src-format, src-texture-target,
-PIPE_TEXTURE_USAGE_SAMPLER, 0)) {
- util_surface_copy(pipe, FALSE, dst, dstx, dsty, src, srcx, srcy,
-width, height);
- return;
- }
- /* check whether the states are properly saved */
- blitter_check_saved_CSOs(ctx);
assert(blitter-saved_fb_state.nr_cbufs != ~0);
assert(blitter-saved_num_textures != ~0);
assert(blitter-saved_num_sampler_states != ~0);
@@ -656,6 +641,111 @@ void util_blitter_copy(struct blitter_context *blitter,
blitter_set_rectangle(ctx, dstx, dsty, dstx+width, dsty+height, 0);
blitter_draw_quad(ctx);
+
+}
+
+static void util_blitter_overlap_copy(struct blitter_context *blitter,
+ struct pipe_surface *dst,
+ unsigned dstx, unsigned dsty,
+ struct pipe_surface *src,
+ unsigned srcx, unsigned srcy,
+ unsigned width, unsigned height)
+{
+ struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
+ struct pipe_context *pipe = ctx-pipe;
+ struct pipe_screen *screen = pipe-screen;
+
+ struct pipe_texture texTemp;
+ struct pipe_texture *texture;
+ struct pipe_surface *tex_surf;
+ uint level;
+
+ /* check whether the states are properly saved */
+ blitter_check_saved_CSOs(ctx);
+
+ memset(texTemp, 0, sizeof(texTemp));
+ texTemp.target = PIPE_TEXTURE_2D;
+ texTemp.format = dst-texture-format; /* XXX verify supported by driver! */
+ texTemp.last_level = 0;
+ texTemp.width0 = width;
+ texTemp.height0 = height;
+ texTemp.depth0 = 1;
+
+ texture = screen-texture_create(screen, texTemp);
+ if (!texture)
+ return;
+
+ tex_surf = screen-get_tex_surface(screen, texture, 0,
Re: [Mesa3d-dev] Redundant assertions: unsigned = 0, remove?
Roel Kluin wrote:
I also found several tests on unsigned variables which do
nothing. should they be removed or changed otherwise?
I think they could be removed.
However, note that src/glx/x11/indirect.c is generated by a python
script. The generator would have to be changed. I'd rather not do
that though if it's ugly.
One other comment below (for Michel):
Roel
backref 3: src_x
---[ vi src/gallium/auxiliary/util/u_rect.c +30 ]---
void
util_copy_rect(ubyte * dst,
enum pipe_format format,
unsigned dst_stride,
unsigned dst_x,
unsigned dst_y,
unsigned width,
unsigned height,
const ubyte * src,
int src_stride,
unsigned src_x,
int src_y)
It's kind of weird that src_x is unsigned but src_y is signed.
Looks like Michel made the last change there (commit
e922adbe1d6c1764968377658ea92ae6de0585db). Michel?
{
unsigned i;
int src_stride_pos = src_stride 0 ? -src_stride : src_stride;
int blocksize = util_format_get_blocksize(format);
int blockwidth = util_format_get_blockwidth(format);
int blockheight = util_format_get_blockheight(format);
assert(blocksize 0);
assert(blockwidth 0);
assert(blockheight 0);
assert(src_x = 0);
assert(src_y = 0);
assert(dst_x = 0);
assert(dst_y = 0);
backref 3: dst_y
---[ vi src/gallium/auxiliary/util/u_rect.c +96 ]---
void
util_fill_rect(ubyte * dst,
enum pipe_format format,
unsigned dst_stride,
unsigned dst_x,
unsigned dst_y,
unsigned width,
unsigned height,
uint32_t value)
{
unsigned i, j;
unsigned width_size;
int blocksize = util_format_get_blocksize(format);
int blockwidth = util_format_get_blockwidth(format);
int blockheight = util_format_get_blockheight(format);
assert(blocksize 0);
assert(blockwidth 0);
assert(blockheight 0);
assert(dst_x = 0);
assert(dst_y = 0);
backref 3: min_lod
---[ vi src/gallium/drivers/svga/svga_screen_texture.c +905 ]---
struct svga_sampler_view *
svga_get_tex_sampler_view(struct pipe_context *pipe, struct pipe_texture *pt,
unsigned min_lod, unsigned max_lod)
{
struct svga_screen *ss = svga_screen(pt-screen);
struct svga_texture *tex = svga_texture(pt);
struct svga_sampler_view *sv = NULL;
SVGA3dSurfaceFormat format = svga_translate_format(pt-format);
boolean view = TRUE;
assert(pt);
assert(min_lod = 0);
backref 3: num
---[ vi src/glx/x11/indirect.c +9268 ]---
void
__indirect_glProgramParameters4dvNV(GLenum target, GLuint index, GLuint num,
const GLdouble * params)
{
__GLXcontext *const gc = __glXGetCurrentContext();
const GLuint cmdlen = 16 + __GLX_PAD((num * 32));
if (num 0) {
__glXSetError(gc, GL_INVALID_VALUE);
return;
}
if (__builtin_expect(num = 0, 1)) {
backref 3: num
---[ vi src/glx/x11/indirect.c +9292 ]---
#define X_GLrop_ProgramParameters4fvNV 4186
void
__indirect_glProgramParameters4fvNV(GLenum target, GLuint index, GLuint num,
const GLfloat * params)
{
__GLXcontext *const gc = __glXGetCurrentContext();
const GLuint cmdlen = 16 + __GLX_PAD((num * 16));
if (num 0) {
__glXSetError(gc, GL_INVALID_VALUE);
return;
}
if (__builtin_expect(num = 0, 1)) {
.
--
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] [PATCH] test index bounds before array element
roel kluin wrote: On Wed, Jan 6, 2010 at 5:49 PM, Brian Paul bri...@vmware.com wrote: Roel Kluin wrote: Check whether the index is within bounds before accessing the array. Applied to 7.7 branch. -Brian I just realized the last one (affecting src/mesa/shader/prog_optimize.c) is wrong. Should I resend it without that hunk? I don't think it makes a difference in this case. Are you sure? -Brian -- 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] gallium: add overlapping blit support to u_blitter
On Wed, Jan 6, 2010 at 6:50 PM, Dave Airlie airl...@linux.ie wrote:
This makes the r300g + X.org state tracker work a bit better, I can
start X + xterm + metacity and drag a window around now at least.
A full gnome session seems to have other issuess.
Hi Dave, a couple comments on your patch...
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 1f794d3..58f0b6d 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -560,10 +560,14 @@ void util_blitter_clear(struct blitter_context *blitter,
blitter_restore_CSOs(ctx);
}
-void util_blitter_copy(struct blitter_context *blitter,
- struct pipe_surface *dst,
- unsigned dstx, unsigned dsty,
- struct pipe_surface *src,
- unsigned srcx, unsigned srcy,
- unsigned width, unsigned height,
- boolean ignore_stencil)
+static boolean
+is_overlap(int sx1, int sx2, int sy1, int sy2, int dx1, int dx2, int
dy1, int dy2)
+{
+if (((sx1 = dx1) (sx1 = dx2) (sy1 = dy1) (sy1 =
dy2)) || /* TL x1, y1 */
+ ((sx2 = dx1) (sx2 = dx2) (sy1 = dy1) (sy1 = dy2)) || /*
TR x2, y1 */
+ ((sx1 = dx1) (sx1 = dx2) (sy2 = dy1) (sy2 = dy2)) || /*
BL x1, y2 */
+ ((sx2 = dx1) (sx2 = dx2) (sy2 = dy1) (sy2 = dy2))) /*
BR x2, y2 */
+ return TRUE;
+else
+ return FALSE;
+}
If we know that sx1sx2, sy1sy2, dx1dx2, dy1dy2, then I think you can do this
instead:
static boolean
is_overlap(int sx1, int sx2, int sy1, int sy2, int dx1, int dx2, int
dy1, int dy2)
{
return !(sx2 dx1 || sx1 dx2 || sy2 dy1 || sy1 dy2);
}
And if the -1 terms are removed from the call below, the
inequalities can be changed to = and =.
+
+static void util_blitter_do_copy(struct blitter_context *blitter,
+struct pipe_surface *dst,
+unsigned dstx, unsigned dsty,
+struct pipe_surface *src,
+unsigned srcx, unsigned srcy,
+unsigned width, unsigned height,
+boolean is_depth)
{
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
struct pipe_context *pipe = ctx-pipe;
- struct pipe_screen *screen = pipe-screen;
struct pipe_framebuffer_state fb_state;
- boolean is_stencil, is_depth;
- unsigned dst_tex_usage;
-
- /* give up if textures are not set */
- assert(dst-texture src-texture);
- if (!dst-texture || !src-texture)
- return;
-
- is_depth = util_format_get_component_bits(src-format,
UTIL_FORMAT_COLORSPACE_ZS, 0) != 0;
- is_stencil = util_format_get_component_bits(src-format,
UTIL_FORMAT_COLORSPACE_ZS, 1) != 0;
- dst_tex_usage = is_depth || is_stencil ? PIPE_TEXTURE_USAGE_DEPTH_STENCIL :
-PIPE_TEXTURE_USAGE_RENDER_TARGET;
-
- /* check if we can sample from and render to the surfaces */
- /* (assuming copying a stencil buffer is not possible) */
- if ((!ignore_stencil is_stencil) ||
- !screen-is_format_supported(screen, dst-format, dst-texture-target,
-dst_tex_usage, 0) ||
- !screen-is_format_supported(screen, src-format, src-texture-target,
-PIPE_TEXTURE_USAGE_SAMPLER, 0)) {
- util_surface_copy(pipe, FALSE, dst, dstx, dsty, src, srcx, srcy,
-width, height);
- return;
- }
- /* check whether the states are properly saved */
- blitter_check_saved_CSOs(ctx);
assert(blitter-saved_fb_state.nr_cbufs != ~0);
assert(blitter-saved_num_textures != ~0);
assert(blitter-saved_num_sampler_states != ~0);
@@ -656,3 +641,79 @@ void util_blitter_copy(struct blitter_context *blitter,
blitter_set_rectangle(ctx, dstx, dsty, dstx+width, dsty+height, 0);
blitter_draw_quad(ctx);
+
+}
+
+static void util_blitter_overlap_copy(struct blitter_context *blitter,
+ struct pipe_surface *dst,
+ unsigned dstx, unsigned dsty,
+ struct pipe_surface *src,
+ unsigned srcx, unsigned srcy,
+ unsigned width, unsigned height)
+{
+ struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
+ struct pipe_context *pipe = ctx-pipe;
+ struct pipe_screen *screen = pipe-screen;
+
+ struct pipe_texture texTemp;
+ struct pipe_texture *texture;
+ struct pipe_surface *tex_surf;
+ uint level;
+
+ /* check whether the states are properly saved */
+ blitter_check_saved_CSOs(ctx);
+
+ memset(texTemp, 0, sizeof(texTemp));
+ texTemp.target = PIPE_TEXTURE_2D;
+ texTemp.format = dst-texture-format; /* XXX verify supported by driver! */
+
[Mesa3d-dev] Build failure on AIX/xlc with current master
I'm getting a build failure on AIX --with-driver=xlib via the autoconf build system. It appears as if creating libglslpp.a libglslcl.a and then merging them into the single libmesa.a is not supported. Is there a compelling reason for the build to be this way (other than convenience)? Would something like the attached diff be an acceptable approach for a fix (note -- untested, even on Linux, and it might need to git rm glsl/Makefile* or similar)? `make tarballs' also creates broken tarballs because they are missing src/glsl/Makefile.template. Another patch attached to fix that, but depending on the answer above Makefile.template might go away completely anyway. Thanks, -tom gmake[4]: Entering directory `/u0/fogal1/mesa/src/mesa/drivers/x11' nm: ../../../../src/mesa/libmesa.a[libglslpp.a]: 0654-203 Specify an XCOFF object module. nm: ../../../../src/mesa/libmesa.a[libglslcl.a]: 0654-203 Specify an XCOFF object module. ld: 0711-230 WARNING: Nested archives are not supported. Archive member ../../../../src/mesa/libmesa.a[libglslpp.a] is being ignored. ld: 0711-230 WARNING: Nested archives are not supported. Archive member ../../../../src/mesa/libmesa.a[libglslcl.a] is being ignored. ld: 0711-317 ERROR: Undefined symbol: .sl_pp_context_create ld: 0711-317 ERROR: Undefined symbol: .sl_pp_version ld: 0711-317 ERROR: Undefined symbol: .sl_pp_context_error_message ld: 0711-317 ERROR: Undefined symbol: .sl_pp_context_destroy ld: 0711-317 ERROR: Undefined symbol: .sl_pp_context_add_extension ld: 0711-317 ERROR: Undefined symbol: .sl_cl_compile ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. ar: Creating an archive file libGL.a. ar: A file or directory in the path name does not exist. ar: 0707-117 The fopen system call failed on file shr.o. mklib: Installing libGL.a in ../../../../lib mv: cannot stat `libGL.a': A file or directory in the path name does not exist. gmake[4]: *** [../../../../lib/libGL.a] Error 1 diff --git a/configs/darwin b/configs/darwin index 7556688..336b54e 100644 --- a/configs/darwin +++ b/configs/darwin @@ -49,7 +49,7 @@ GLW_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_DIR)/$(LIB_DIR) -L$(X APP_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GLUT_LIB) -l$(GLU_LIB) -l$(GL_LIB) -L$(INSTALL_DIR)/$(LIB_DIR) -L$(X11_DIR)/$(LIB_DIR) -lX11 -lXmu -lXt -lXi -lm # omit glw lib for now: -SRC_DIRS = glsl glx/x11 mesa gallium glu glut/glx glew +SRC_DIRS = glx/x11 mesa gallium glu glut/glx glew GLU_DIRS = sgi DRIVER_DIRS = osmesa #DRIVER_DIRS = dri diff --git a/configs/default b/configs/default index 94beca4..b19fa90 100644 --- a/configs/default +++ b/configs/default @@ -83,11 +83,11 @@ MOTIF_CFLAGS = -I/usr/include/Motif1.2 # Directories to build LIB_DIR = lib -SRC_DIRS = glsl mesa gallium egl gallium/winsys glu glut/glx glew glw +SRC_DIRS = mesa gallium egl gallium/winsys glu glut/glx glew glw GLU_DIRS = sgi DRIVER_DIRS = x11 osmesa # Which subdirs under $(TOP)/progs/ to enter: -PROGRAM_DIRS = demos redbook samples glsl objviewer xdemos +PROGRAM_DIRS = demos redbook samples objviewer xdemos # EGL directories EGL_DRIVERS_DIRS = demo diff --git a/configs/linux-cell b/configs/linux-cell index 221655c..e9e796e 100644 --- a/configs/linux-cell +++ b/configs/linux-cell @@ -33,7 +33,7 @@ CFLAGS = $(OPT_FLAGS) -Wall -Winline -Wmissing-prototypes \ CXXFLAGS = $(CFLAGS) # Omitting glw here: -SRC_DIRS = glsl mesa gallium gallium/winsys glu glut/glx glew +SRC_DIRS = mesa gallium gallium/winsys glu glut/glx glew # Build no traditional Mesa drivers: DRIVER_DIRS = diff --git a/configure.ac b/configure.ac index d3fbd02..3f8afe0 100644 --- a/configure.ac +++ b/configure.ac @@ -414,7 +414,7 @@ esac dnl dnl Driver specific build directories dnl -SRC_DIRS=glsl mesa glew +SRC_DIRS=mesa glew GLU_DIRS=sgi WINDOW_SYSTEM= GALLIUM_DIRS=auxiliary drivers state_trackers @@ -1081,7 +1081,7 @@ if test x$enable_glut = xyes; then # If glut is available, we can build most programs if test $with_demos = yes; then -PROGRAM_DIRS=$PROGRAM_DIRS demos redbook samples glsl +PROGRAM_DIRS=$PROGRAM_DIRS demos redbook samples fi # If static, empty GLUT_LIB_DEPS and add libs for programs to link diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index c42f61a..94bcb99 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -314,6 +314,26 @@ COMMON_DRIVER_SOURCES = \ drivers/common/driverfuncs.c \ drivers/common/meta.c +GLSL_PP_SOURCES = \ + glsl/pp/sl_pp_context.c \ + glsl/pp/sl_pp_define.c \ + glsl/pp/sl_pp_dict.c \ + glsl/pp/sl_pp_error.c \ + glsl/pp/sl_pp_expression.c \ + glsl/pp/sl_pp_extension.c \ + glsl/pp/sl_pp_if.c \ + glsl/pp/sl_pp_line.c \ + glsl/pp/sl_pp_macro.c \ + glsl/pp/sl_pp_pragma.c \ + glsl/pp/sl_pp_process.c \ + glsl/pp/sl_pp_purify.c \ + glsl/pp/sl_pp_token.c \ + glsl/pp/sl_pp_token_util.c \ + glsl/pp/sl_pp_version.c + +GLSL_CL_SOURCES = \ +
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Thanks, your patch fixed the problem. - Sedat - On Wed, Jan 6, 2010 at 6:38 PM, Brian Paul bri...@vmware.com wrote: r300_translate_tex_filters() was missing the is_anisotropic parameter. I fixed that, but there may be other issues. Looks like some of the r300 code isn't c99. -Brian Sedat Dilek wrote: OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul bri...@vmware.com wrote: Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- 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
