Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
On Mon, Jun 27, 2011 at 8:38 AM, Roland Scheidegger srol...@vmware.com wrote: Am 25.06.2011 00:22, schrieb Vadim Girlin: On 06/24/2011 11:38 PM, Jerome Glisse wrote: On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440 Signed-off-by: Vadim Girlinvadimgir...@gmail.com As discussed previously, there is better to handle this. I think best solution is to always add the instruction and to conditionally execute them thanks to the boolean constant. If this reveal to have a too big impact on shader, other solution i see is adding a cf block with those instructions and to enable or disable that block (cf_nop) and reupload shader that would avoid a rebuild. I know its not optimal to do a full rebuild, but rebuild is needed only when the application will use the same shader in different clamping states. It won't be a problem if the application doesn't change clamping state or if it changes the state but uses each shader in one state only. So assuming that typical app will not use one shader in both states, it shouldn't be a problem. Is this assumption wrong? I'm not really sure because I have no much experience in this. But if it's wrong then it's probably better for performance to build and cache both versions. I tend to think you're right apps probably don't want to use the same shader both with and without clamping. Well if boolean block (see COND field set to SQ_CF_COND_BOOL in SQ_CF_WORD1) are free from perf point of view then i think it's best to have one shader with the clamp instruction inside the boolean enabled block. Only benchmark can tell. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
On Mon, Jun 27, 2011 at 2:38 PM, Roland Scheidegger srol...@vmware.com wrote: Am 25.06.2011 00:22, schrieb Vadim Girlin: On 06/24/2011 11:38 PM, Jerome Glisse wrote: On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440 Signed-off-by: Vadim Girlinvadimgir...@gmail.com As discussed previously, there is better to handle this. I think best solution is to always add the instruction and to conditionally execute them thanks to the boolean constant. If this reveal to have a too big impact on shader, other solution i see is adding a cf block with those instructions and to enable or disable that block (cf_nop) and reupload shader that would avoid a rebuild. I know its not optimal to do a full rebuild, but rebuild is needed only when the application will use the same shader in different clamping states. It won't be a problem if the application doesn't change clamping state or if it changes the state but uses each shader in one state only. So assuming that typical app will not use one shader in both states, it shouldn't be a problem. Is this assumption wrong? I'm not really sure because I have no much experience in this. But if it's wrong then it's probably better for performance to build and cache both versions. I tend to think you're right apps probably don't want to use the same shader both with and without clamping. It still can be changed by st/mesa or by u_blitter and u_blit for various reasons. IIRC, the OpenGL default is TRUE if the current framebuffer is fixed-point including texture_snorm and FALSE otherwise, so changing the framebuffer may change the clamp color state. Besides that, the u_blitter and u_blit operations always disable the clamping, so if a framebuffer is fixed-point and thus clamp color state is TRUE (if not changed by an app), the driver may receive state changes that turn the clamping on, off, on, off,... with the blit operations turning it off and everything else turning it on. The state might be changing pretty much all the time and doing full shader rebuilds repeatedly may turn some apps into a slideshow. Therefore we must ensure that a fragment shader is set/built as late as possible, i.e. in draw_vbo. Each shader variant should be compiled once at most and stored for later use. create_fs_state and bind_fs_state should not do anything except copying the parameters. Marek Also it seems last write to color output components is often done with op2 instructions, so there is another optimization possible - to find last op2 writes and set clamp bit instead of using additional instructions. Probably it's not very hard to implement with this patch. AFAICS it will be impossible with other suggested solutions. Such optimization should probably be part of a more generic optimization pass. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
On Mon, 2011-06-27 at 15:32 +0200, Marek Olšák wrote: On Mon, Jun 27, 2011 at 2:38 PM, Roland Scheidegger srol...@vmware.com wrote: Am 25.06.2011 00:22, schrieb Vadim Girlin: On 06/24/2011 11:38 PM, Jerome Glisse wrote: On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440 Signed-off-by: Vadim Girlinvadimgir...@gmail.com As discussed previously, there is better to handle this. I think best solution is to always add the instruction and to conditionally execute them thanks to the boolean constant. If this reveal to have a too big impact on shader, other solution i see is adding a cf block with those instructions and to enable or disable that block (cf_nop) and reupload shader that would avoid a rebuild. I know its not optimal to do a full rebuild, but rebuild is needed only when the application will use the same shader in different clamping states. It won't be a problem if the application doesn't change clamping state or if it changes the state but uses each shader in one state only. So assuming that typical app will not use one shader in both states, it shouldn't be a problem. Is this assumption wrong? I'm not really sure because I have no much experience in this. But if it's wrong then it's probably better for performance to build and cache both versions. I tend to think you're right apps probably don't want to use the same shader both with and without clamping. It still can be changed by st/mesa or by u_blitter and u_blit for various reasons. IIRC, the OpenGL default is TRUE if the current framebuffer is fixed-point including texture_snorm and FALSE otherwise, so changing the framebuffer may change the clamp color state. Besides that, the u_blitter and u_blit operations always disable the clamping, so if a framebuffer is fixed-point and thus clamp color state is TRUE (if not changed by an app), the driver may receive state changes that turn the clamping on, off, on, off,... with the blit operations turning it off and everything else turning it on. The state might be changing pretty much all the time and doing full shader rebuilds repeatedly may turn some apps into a slideshow. I haven't looked at the code, maybe this is irrelevant for some reason, but the alternative to doing rebuilds when this type of state changes is to permit 1 compiled version of the shader to exist, parameterized in different ways. That way the ping-pong scenario you describe results in swapping between shaders (which should be cheap), rather than rebuilding. Therefore we must ensure that a fragment shader is set/built as late as possible, i.e. in draw_vbo. Each shader variant should be compiled once at most and stored for later use. create_fs_state and bind_fs_state should not do anything except copying the parameters. Actually it sounds like you're describing the same idea here... Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
Am 27.06.2011 16:04, schrieb Keith Whitwell: On Mon, 2011-06-27 at 15:32 +0200, Marek Olšák wrote: On Mon, Jun 27, 2011 at 2:38 PM, Roland Scheidegger srol...@vmware.com wrote: Am 25.06.2011 00:22, schrieb Vadim Girlin: On 06/24/2011 11:38 PM, Jerome Glisse wrote: On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440 Signed-off-by: Vadim Girlinvadimgir...@gmail.com As discussed previously, there is better to handle this. I think best solution is to always add the instruction and to conditionally execute them thanks to the boolean constant. If this reveal to have a too big impact on shader, other solution i see is adding a cf block with those instructions and to enable or disable that block (cf_nop) and reupload shader that would avoid a rebuild. I know its not optimal to do a full rebuild, but rebuild is needed only when the application will use the same shader in different clamping states. It won't be a problem if the application doesn't change clamping state or if it changes the state but uses each shader in one state only. So assuming that typical app will not use one shader in both states, it shouldn't be a problem. Is this assumption wrong? I'm not really sure because I have no much experience in this. But if it's wrong then it's probably better for performance to build and cache both versions. I tend to think you're right apps probably don't want to use the same shader both with and without clamping. It still can be changed by st/mesa or by u_blitter and u_blit for various reasons. IIRC, the OpenGL default is TRUE if the current framebuffer is fixed-point including texture_snorm and FALSE otherwise, so changing the framebuffer may change the clamp color state. Besides that, the u_blitter and u_blit operations always disable the clamping, so if a framebuffer is fixed-point and thus clamp color state is TRUE (if not changed by an app), the driver may receive state changes that turn the clamping on, off, on, off,... with the blit operations turning it off and everything else turning it on. The state might be changing pretty much all the time and doing full shader rebuilds repeatedly may turn some apps into a slideshow. I haven't looked at the code, maybe this is irrelevant for some reason, but the alternative to doing rebuilds when this type of state changes is to permit 1 compiled version of the shader to exist, parameterized in different ways. That way the ping-pong scenario you describe results in swapping between shaders (which should be cheap), rather than rebuilding. Therefore we must ensure that a fragment shader is set/built as late as possible, i.e. in draw_vbo. Each shader variant should be compiled once at most and stored for later use. create_fs_state and bind_fs_state should not do anything except copying the parameters. Actually it sounds like you're describing the same idea here... Keith I wasn't aware that the boolean block might be free in terms of performance. If so that might indeed be a good solution without needing to recompile. But there might be other cases which could benefit from cached shaders, so it looks both options have merit. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/evergreen_state.c |2 +
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/drivers/r600/r600_pipe.h |7 +++-
src/gallium/drivers/r600/r600_shader.c | 52 +++---
src/gallium/drivers/r600/r600_shader.h |1 +
src/gallium/drivers/r600/r600_state.c|2 +
src/gallium/drivers/r600/r600_state_common.c | 30 ++-
7 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index f86e4d4..dfe7896 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -256,6 +256,8 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
}
rstate = rs-rstate;
+ rs-clamp_vertex_color = state-clamp_vertex_color;
+ rs-clamp_fragment_color = state-clamp_fragment_color;
rs-flatshade = state-flatshade;
rs-sprite_coord_enable = state-sprite_coord_enable;
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 38801d6..12599bf 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -377,6 +377,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
case PIPE_CAP_SM3:
case PIPE_CAP_SEAMLESS_CUBE_MAP:
+ case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
return 1;
/* Supported except the original R600. */
@@ -392,7 +393,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
/* Unsupported features. */
case PIPE_CAP_STREAM_OUTPUT:
case PIPE_CAP_PRIMITIVE_RESTART:
- case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
case PIPE_CAP_TGSI_INSTANCEID:
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 63ddd39..dc9aad0 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -88,6 +88,8 @@ struct r600_pipe_sampler_view {
struct r600_pipe_rasterizer {
struct r600_pipe_state rstate;
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean flatshade;
unsignedsprite_coord_enable;
float offset_units;
@@ -125,6 +127,7 @@ struct r600_pipe_shader {
struct r600_bo *bo;
struct r600_bo *bo_fetch;
struct r600_vertex_element vertex_elements;
+ struct tgsi_token *tokens;
};
struct r600_pipe_sampler_state {
@@ -202,6 +205,8 @@ struct r600_pipe_context {
struct pipe_query *saved_render_cond;
unsignedsaved_render_cond_mode;
/* shader information */
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean spi_dirty;
unsignedsprite_coord_enable;
boolean flatshade;
@@ -265,7 +270,7 @@ void r600_init_query_functions(struct r600_pipe_context
*rctx);
void r600_init_context_resource_functions(struct r600_pipe_context *r600);
/* r600_shader.c */
-int r600_pipe_shader_create(struct pipe_context *ctx, struct r600_pipe_shader
*shader, const struct tgsi_token *tokens);
+int r600_pipe_shader_create(struct pipe_context *ctx, struct r600_pipe_shader
*shader);
void r600_pipe_shader_destroy(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
int r600_find_vs_semantic_index(struct r600_shader *vs,
struct r600_shader *ps, int id);
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 904cc69..2e5d4a6 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -118,9 +118,9 @@ static int r600_pipe_shader(struct pipe_context *ctx,
struct r600_pipe_shader *s
return 0;
}
-static int r600_shader_from_tgsi(const struct tgsi_token *tokens, struct
r600_shader *shader);
+static int r600_shader_from_tgsi(struct r600_pipe_context * rctx, struct
r600_pipe_shader *pipeshader);
-int r600_pipe_shader_create(struct pipe_context *ctx, struct r600_pipe_shader
*shader, const struct tgsi_token *tokens)
+int r600_pipe_shader_create(struct pipe_context *ctx, struct r600_pipe_shader
*shader)
{
static int dump_shaders = -1;
struct r600_pipe_context *rctx =
Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlin vadimgir...@gmail.com wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
As discussed previously, there is better to handle this. I think best
solution is to always add the instruction and to conditionally execute
them thanks to the boolean constant. If this reveal to have a too big
impact on shader, other solution i see is adding a cf block with those
instructions and to enable or disable that block (cf_nop) and reupload
shader that would avoid a rebuild.
But as a mean time solution i think this patch is ok
Cheers,
Jerome
---
src/gallium/drivers/r600/evergreen_state.c | 2 +
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 7 +++-
src/gallium/drivers/r600/r600_shader.c | 52
+++---
src/gallium/drivers/r600/r600_shader.h | 1 +
src/gallium/drivers/r600/r600_state.c | 2 +
src/gallium/drivers/r600/r600_state_common.c | 30 ++-
7 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index f86e4d4..dfe7896 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -256,6 +256,8 @@ static void *evergreen_create_rs_state(struct
pipe_context *ctx,
}
rstate = rs-rstate;
+ rs-clamp_vertex_color = state-clamp_vertex_color;
+ rs-clamp_fragment_color = state-clamp_fragment_color;
rs-flatshade = state-flatshade;
rs-sprite_coord_enable = state-sprite_coord_enable;
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 38801d6..12599bf 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -377,6 +377,7 @@ static int r600_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
case PIPE_CAP_SM3:
case PIPE_CAP_SEAMLESS_CUBE_MAP:
+ case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
return 1;
/* Supported except the original R600. */
@@ -392,7 +393,6 @@ static int r600_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
/* Unsupported features. */
case PIPE_CAP_STREAM_OUTPUT:
case PIPE_CAP_PRIMITIVE_RESTART:
- case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
case PIPE_CAP_TGSI_INSTANCEID:
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 63ddd39..dc9aad0 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -88,6 +88,8 @@ struct r600_pipe_sampler_view {
struct r600_pipe_rasterizer {
struct r600_pipe_state rstate;
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean flatshade;
unsigned sprite_coord_enable;
float offset_units;
@@ -125,6 +127,7 @@ struct r600_pipe_shader {
struct r600_bo *bo;
struct r600_bo *bo_fetch;
struct r600_vertex_element vertex_elements;
+ struct tgsi_token *tokens;
};
struct r600_pipe_sampler_state {
@@ -202,6 +205,8 @@ struct r600_pipe_context {
struct pipe_query *saved_render_cond;
unsigned saved_render_cond_mode;
/* shader information */
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean spi_dirty;
unsigned sprite_coord_enable;
boolean flatshade;
@@ -265,7 +270,7 @@ void r600_init_query_functions(struct r600_pipe_context
*rctx);
void r600_init_context_resource_functions(struct r600_pipe_context *r600);
/* r600_shader.c */
-int r600_pipe_shader_create(struct pipe_context *ctx, struct
r600_pipe_shader *shader, const struct tgsi_token *tokens);
+int r600_pipe_shader_create(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
void r600_pipe_shader_destroy(struct pipe_context *ctx, struct
r600_pipe_shader *shader);
int r600_find_vs_semantic_index(struct r600_shader *vs,
struct r600_shader *ps, int id);
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 904cc69..2e5d4a6 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -118,9 +118,9 @@ static
Re: [Mesa-dev] [PATCH 3/3] r600g: implement fragment and vertex color clamp
On 06/24/2011 11:38 PM, Jerome Glisse wrote:
On Fri, Jun 24, 2011 at 12:29 PM, Vadim Girlinvadimgir...@gmail.com wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38440
Signed-off-by: Vadim Girlinvadimgir...@gmail.com
As discussed previously, there is better to handle this. I think best
solution is to always add the instruction and to conditionally execute
them thanks to the boolean constant. If this reveal to have a too big
impact on shader, other solution i see is adding a cf block with those
instructions and to enable or disable that block (cf_nop) and reupload
shader that would avoid a rebuild.
I know its not optimal to do a full rebuild, but rebuild is needed only
when the application will use the same shader in different clamping
states. It won't be a problem if the application doesn't change clamping
state or if it changes the state but uses each shader in one state only.
So assuming that typical app will not use one shader in both states, it
shouldn't be a problem. Is this assumption wrong? I'm not really sure
because I have no much experience in this. But if it's wrong then it's
probably better for performance to build and cache both versions.
Also it seems last write to color output components is often done with
op2 instructions, so there is another optimization possible - to find
last op2 writes and set clamp bit instead of using additional
instructions. Probably it's not very hard to implement with this patch.
AFAICS it will be impossible with other suggested solutions.
Thanks for pushing it.
Regards,
Vadim
But as a mean time solution i think this patch is ok
Cheers,
Jerome
---
src/gallium/drivers/r600/evergreen_state.c |2 +
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/drivers/r600/r600_pipe.h |7 +++-
src/gallium/drivers/r600/r600_shader.c | 52 +++---
src/gallium/drivers/r600/r600_shader.h |1 +
src/gallium/drivers/r600/r600_state.c|2 +
src/gallium/drivers/r600/r600_state_common.c | 30 ++-
7 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index f86e4d4..dfe7896 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -256,6 +256,8 @@ static void *evergreen_create_rs_state(struct pipe_context
*ctx,
}
rstate =rs-rstate;
+ rs-clamp_vertex_color = state-clamp_vertex_color;
+ rs-clamp_fragment_color = state-clamp_fragment_color;
rs-flatshade = state-flatshade;
rs-sprite_coord_enable = state-sprite_coord_enable;
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 38801d6..12599bf 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -377,6 +377,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
case PIPE_CAP_SM3:
case PIPE_CAP_SEAMLESS_CUBE_MAP:
+ case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
return 1;
/* Supported except the original R600. */
@@ -392,7 +393,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
/* Unsupported features. */
case PIPE_CAP_STREAM_OUTPUT:
case PIPE_CAP_PRIMITIVE_RESTART:
- case PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL:
case PIPE_CAP_TGSI_INSTANCEID:
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 63ddd39..dc9aad0 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -88,6 +88,8 @@ struct r600_pipe_sampler_view {
struct r600_pipe_rasterizer {
struct r600_pipe_state rstate;
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean flatshade;
unsignedsprite_coord_enable;
float offset_units;
@@ -125,6 +127,7 @@ struct r600_pipe_shader {
struct r600_bo *bo;
struct r600_bo *bo_fetch;
struct r600_vertex_element vertex_elements;
+ struct tgsi_token *tokens;
};
struct r600_pipe_sampler_state {
@@ -202,6 +205,8 @@ struct r600_pipe_context {
struct pipe_query *saved_render_cond;
unsignedsaved_render_cond_mode;
/* shader information */
+ boolean clamp_vertex_color;
+ boolean clamp_fragment_color;
boolean spi_dirty;
unsigned
