On 01/21/2013 08:52 PM, Paul Berry wrote:
On 21 January 2013 14:48, Kenneth Graunke <[email protected] <mailto:[email protected]>> wrote:On 01/21/2013 01:38 PM, Eric Anholt wrote: Kenneth Graunke <[email protected] <mailto:[email protected]>> writes: --- src/mesa/drivers/dri/i965/brw___state.h | 3 ++- src/mesa/drivers/dri/i965/brw___wm.c | 2 +- src/mesa/drivers/dri/i965/brw___wm_surface_state.c | 8 ++++++-- src/mesa/drivers/dri/i965/__gen7_wm_surface_state.c | 4 ++-- 4 files changed, 11 insertions(+), 6 deletions(-) I believe the BRW_NEW_VERTEX_PROGRAM/BRW___NEW_FRAGMENT_PROGRAM dirty bits on the brw_texture_surfaces atom should cover my new usage of shProg. Eric, can you confirm? I always get confused by _NEW_PROGRAM vs. CACHE_NEW_WM/VS_PROG vs. BRW_NEW_VERTEX/FRAGMENT___PROGRAM. Thanks! CACHE_NEW_*_PROG covers prog_data, BRW_NEW_*_PROGRAM covers the brw_*_program and gl_shader_program structs, so that sounds good. But I see an issue anyway... diff --git a/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c index 5e99592..b609b09 100644 --- a/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/__brw_wm_surface_state.c @@ -685,8 +685,10 @@ brw_get_surface_num___multisamples(unsigned num_samples) * swizzling. */ int -brw_get_texture_swizzle(const struct gl_texture_object *t) +brw_get_texture_swizzle(__struct gl_context *ctx, + const struct gl_texture_object *t) { + const struct gl_shader_program *shProg = ctx->Shader.___CurrentFragmentProgram; You're looking at the FS even if we're trying to set up textures for the VS. I think the caller should pass in the particular program, and then it'll be more obvious to the caller which state flag is right. Eric mentioned this on IRC: <anholt> Kayden: oh, I suppose my comment about looking at the wrong program in your depth change doesn't really matter since Version will be the same in both. which is true - otherwise the VS/FS link would have failed. Is this still going to be true when we implement ARB_separate_shader_objects?
No, but a lot of this code is going to have to get reworked when we do that. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
