Re: [Mesa-dev] [PATCH 1/2] mesa, gallium: add a cap for GPUs without unified color+generic varying slots
On 12/13/2011 04:32 PM, Marek Olšák wrote:
---
src/gallium/drivers/r300/r300_screen.c |3 ++-
src/gallium/include/pipe/p_defines.h |3 ++-
src/glsl/linker.cpp|6 ++
src/mesa/main/mtypes.h |9 +
src/mesa/state_tracker/st_extensions.c |3 +++
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 0bae065..a761939 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
+case PIPE_CAP_SEPARATE_COLOR_VARYINGS:
return 1;
/* r300 cannot do swizzling of compressed textures. Supported
otherwise. */
@@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen, unsigned shader, e
* R500 has the ability to turn 3rd and 4th color into
* additional texcoords but there is no two-sided color
* selection then. However the facing bit can be used instead. */
-return 10;
+return 8;
Why are you trying to make r300g behave differently the every other
driver that has existed for that same hardware? This doesn't make any
sense. This is not Apple's driver works for r300 hardware, and it's not
how AMD's Windows driver works (worked, anyway) for r300 hardware.
This feels like an unnecessary hack.
case PIPE_SHADER_CAP_MAX_CONSTS:
return is_r500 ? 256 : 32;
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 30f1d7f..5229c5f 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -467,7 +467,8 @@ enum pipe_cap {
PIPE_CAP_CONDITIONAL_RENDER = 52,
PIPE_CAP_TEXTURE_BARRIER = 53,
PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS = 54, /* temporary */
- PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS = 55 /* temporary */
+ PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS = 55, /* temporary */
+ PIPE_CAP_SEPARATE_COLOR_VARYINGS = 56
};
/**
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index b8a7126..e9298bb 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1805,6 +1805,12 @@ assign_varying_locations(struct gl_context *ctx,
*/
var-mode = ir_var_auto;
} else {
+if (ctx-Const.GLSLSeparateColorVaryings
+(var-location == FRAG_ATTRIB_COL0 ||
+ var-location == FRAG_ATTRIB_COL1)) {
+ continue;
+}
+
/* The packing rules are used for vertex shader inputs are also
* used for fragment shader inputs.
*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1934349..9e9ad83 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2839,6 +2839,15 @@ struct gl_constants
*/
GLboolean GLSLSkipStrictMaxVaryingLimitCheck;
GLboolean GLSLSkipStrictMaxUniformLimitCheck;
+
+ /**
+* Whether the color varyings do not share varying slots with generic
+* varyings. In such a case, the driver must not include the color
+* varyings in the maximum number of varyings limit. In return,
+* the GLSL linker will not count the color varyings to the number of
+* used varying components.
+*/
+ GLboolean GLSLSeparateColorVaryings;
};
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 457d5d6..7a7919f 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -228,6 +228,9 @@ void st_init_limits(struct st_context *st)
c-GLSLSkipStrictMaxVaryingLimitCheck =
screen-get_param(screen, PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS);
+
+ c-GLSLSeparateColorVaryings =
+ screen-get_param(screen, PIPE_CAP_SEPARATE_COLOR_VARYINGS);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa, gallium: add a cap for GPUs without unified color+generic varying slots
On Wed, Dec 14, 2011 at 6:30 PM, Ian Romanick i...@freedesktop.org wrote: On 12/13/2011 04:32 PM, Marek Olšák wrote: --- src/gallium/drivers/r300/r300_screen.c | 3 ++- src/gallium/include/pipe/p_defines.h | 3 ++- src/glsl/linker.cpp | 6 ++ src/mesa/main/mtypes.h | 9 + src/mesa/state_tracker/st_extensions.c | 3 +++ 5 files changed, 22 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index 0bae065..a761939 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_BARRIER: case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS: case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: + case PIPE_CAP_SEPARATE_COLOR_VARYINGS: return 1; /* r300 cannot do swizzling of compressed textures. Supported otherwise. */ @@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen *pscreen, unsigned shader, e * R500 has the ability to turn 3rd and 4th color into * additional texcoords but there is no two-sided color * selection then. However the facing bit can be used instead. */ - return 10; + return 8; Why are you trying to make r300g behave differently the every other driver that has existed for that same hardware? This doesn't make any sense. This is not Apple's driver works for r300 hardware, and it's not how AMD's Windows driver works (worked, anyway) for r300 hardware. This feels like an unnecessary hack. Hi Ian, Simple. I cannot pass the test glsl-max-varyings if I report 40 varying components, because I have only 32 texcoord components + 8 color components. I could re-use the color varyings, but it's not full single-precision. r300 uses a fixed-point type S3.12 for color interpolators, which can represent values in the range [-7., 7.]. That's unusable for used-defined varyings. r500 uses a 20-bit float, which is better, but I am not sure if it's good enough. Also, r500 actually has 10 texcoord interpolators, but we don't use the last two yet (it's non-trivial, there is a special PS3 mode for it). Whether color interpolators can be enabled in that mode is undocumented, though I am almost sure the back colors cannot be. (the DX9 ps_3_0 shader profile doesn't have color inputs at all) Yes, the patch is a hack. However modifying glsl-max-varyings to only test MAX_VARYING_FLOATS - 8 doesn't feel right either. Do you have a better idea? What about the other patch? Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa, gallium: add a cap for GPUs without unified color+generic varying slots
On 12/14/2011 01:47 PM, Marek Olšák wrote: On Wed, Dec 14, 2011 at 6:30 PM, Ian Romanicki...@freedesktop.org wrote: On 12/13/2011 04:32 PM, Marek Olšák wrote: --- src/gallium/drivers/r300/r300_screen.c |3 ++- src/gallium/include/pipe/p_defines.h |3 ++- src/glsl/linker.cpp|6 ++ src/mesa/main/mtypes.h |9 + src/mesa/state_tracker/st_extensions.c |3 +++ 5 files changed, 22 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index 0bae065..a761939 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_BARRIER: case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS: case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: +case PIPE_CAP_SEPARATE_COLOR_VARYINGS: return 1; /* r300 cannot do swizzling of compressed textures. Supported otherwise. */ @@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen *pscreen, unsigned shader, e * R500 has the ability to turn 3rd and 4th color into * additional texcoords but there is no two-sided color * selection then. However the facing bit can be used instead. */ -return 10; +return 8; Why are you trying to make r300g behave differently the every other driver that has existed for that same hardware? This doesn't make any sense. This is not Apple's driver works for r300 hardware, and it's not how AMD's Windows driver works (worked, anyway) for r300 hardware. This feels like an unnecessary hack. Hi Ian, Simple. I cannot pass the test glsl-max-varyings if I report 40 varying components, because I have only 32 texcoord components + 8 color components. I could re-use the color varyings, but it's not full single-precision. r300 uses a fixed-point type S3.12 for color interpolators, which can represent values in the range [-7., 7.]. That's unusable for used-defined varyings. r500 uses a 20-bit float, which is better, but I am not sure if it's good enough. The desktop GL spec isn't very specific about range or precision before either a late 3.x version or one of the 4.x versions (I don't recall which). However, I'm pretty sure ES2 requires 24-bit float. Is 20-bits even a real computer number? :) This also means that r300 and r500 can't handle unclamped colors. Right? I'm thinking of the scenario: - The driver advertises 32 varying components. - The application calls glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE). - The shader uses gl_Color and 32 components worth of other varyings. What happens? Are the colors partially clamped or what? Since color clamping is set independent of compiling or linking, you don't have an opportunity to generate any errors up front. It sounds like the colors have to go through different interpolators anyway if glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE) is used. Is that handled correctly? Now I'm really curious to see glsl-max-varyings run on an Apple system with an r300. Scouting around, that looks like it would have to be a G5 iMac or PowerMac. Hrm... Also, r500 actually has 10 texcoord interpolators, but we don't use the last two yet (it's non-trivial, there is a special PS3 mode for it). Whether color interpolators can be enabled in that mode is undocumented, though I am almost sure the back colors cannot be. (the DX9 ps_3_0 shader profile doesn't have color inputs at all) If colors are counted, you don't need to worry about that. 40 varyings means 40 varyings. Clamped colors would go to the usual slots (leaving 2 texcoords unused), and clamped colors would go in two of the texcoord slots. Yes, the patch is a hack. However modifying glsl-max-varyings to only test MAX_VARYING_FLOATS - 8 doesn't feel right either. Do you have a better idea? What about the other patch? I need to do some research about that. I'm pretty sure i915 needs a slot for WPOS. I want to collect some more data and see if there's a coherent architecture that works for the various platforms. We're starting to get a big pile of band-aids, and that can't hold up in the long run. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa, gallium: add a cap for GPUs without unified color+generic varying slots
---
src/gallium/drivers/r300/r300_screen.c |3 ++-
src/gallium/include/pipe/p_defines.h |3 ++-
src/glsl/linker.cpp|6 ++
src/mesa/main/mtypes.h |9 +
src/mesa/state_tracker/st_extensions.c |3 +++
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 0bae065..a761939 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -102,6 +102,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
+case PIPE_CAP_SEPARATE_COLOR_VARYINGS:
return 1;
/* r300 cannot do swizzling of compressed textures. Supported
otherwise. */
@@ -182,7 +183,7 @@ static int r300_get_shader_param(struct pipe_screen
*pscreen, unsigned shader, e
* R500 has the ability to turn 3rd and 4th color into
* additional texcoords but there is no two-sided color
* selection then. However the facing bit can be used instead. */
-return 10;
+return 8;
case PIPE_SHADER_CAP_MAX_CONSTS:
return is_r500 ? 256 : 32;
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 30f1d7f..5229c5f 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -467,7 +467,8 @@ enum pipe_cap {
PIPE_CAP_CONDITIONAL_RENDER = 52,
PIPE_CAP_TEXTURE_BARRIER = 53,
PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS = 54, /* temporary */
- PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS = 55 /* temporary */
+ PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS = 55, /* temporary */
+ PIPE_CAP_SEPARATE_COLOR_VARYINGS = 56
};
/**
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index b8a7126..e9298bb 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1805,6 +1805,12 @@ assign_varying_locations(struct gl_context *ctx,
*/
var-mode = ir_var_auto;
} else {
+if (ctx-Const.GLSLSeparateColorVaryings
+(var-location == FRAG_ATTRIB_COL0 ||
+ var-location == FRAG_ATTRIB_COL1)) {
+ continue;
+}
+
/* The packing rules are used for vertex shader inputs are also
* used for fragment shader inputs.
*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1934349..9e9ad83 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2839,6 +2839,15 @@ struct gl_constants
*/
GLboolean GLSLSkipStrictMaxVaryingLimitCheck;
GLboolean GLSLSkipStrictMaxUniformLimitCheck;
+
+ /**
+* Whether the color varyings do not share varying slots with generic
+* varyings. In such a case, the driver must not include the color
+* varyings in the maximum number of varyings limit. In return,
+* the GLSL linker will not count the color varyings to the number of
+* used varying components.
+*/
+ GLboolean GLSLSeparateColorVaryings;
};
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 457d5d6..7a7919f 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -228,6 +228,9 @@ void st_init_limits(struct st_context *st)
c-GLSLSkipStrictMaxVaryingLimitCheck =
screen-get_param(screen, PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS);
+
+ c-GLSLSeparateColorVaryings =
+ screen-get_param(screen, PIPE_CAP_SEPARATE_COLOR_VARYINGS);
}
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
