<div dir="ltr">On 21 January 2013 14:48, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/21/2013 01:38 PM, Eric Anholt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>> writes:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---<br>
  src/mesa/drivers/dri/i965/brw_<u></u>state.h             | 3 ++-<br>
  src/mesa/drivers/dri/i965/brw_<u></u>wm.c                | 2 +-<br>
  src/mesa/drivers/dri/i965/brw_<u></u>wm_surface_state.c  | 8 ++++++--<br>
  src/mesa/drivers/dri/i965/<u></u>gen7_wm_surface_state.c | 4 ++--<br>
  4 files changed, 11 insertions(+), 6 deletions(-)<br>
<br>
I believe the BRW_NEW_VERTEX_PROGRAM/BRW_<u></u>NEW_FRAGMENT_PROGRAM dirty bits<br>
on the brw_texture_surfaces atom should cover my new usage of shProg.<br>
Eric, can you confirm?  I always get confused by _NEW_PROGRAM vs.<br>
CACHE_NEW_WM/VS_PROG vs. BRW_NEW_VERTEX/FRAGMENT_<u></u>PROGRAM.  Thanks!<br>
</blockquote>
<br>
CACHE_NEW_*_PROG covers prog_data, BRW_NEW_*_PROGRAM covers the<br>
brw_*_program and gl_shader_program structs, so that sounds good.  But I<br>
see an issue anyway...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
diff --git a/src/mesa/drivers/dri/i965/<u></u>brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/<u></u>brw_wm_surface_state.c<br>
index 5e99592..b609b09 100644<br>
--- a/src/mesa/drivers/dri/i965/<u></u>brw_wm_surface_state.c<br>
+++ b/src/mesa/drivers/dri/i965/<u></u>brw_wm_surface_state.c<br>
@@ -685,8 +685,10 @@ brw_get_surface_num_<u></u>multisamples(unsigned num_samples)<br>
   * swizzling.<br>
   */<br>
  int<br>
-brw_get_texture_swizzle(const struct gl_texture_object *t)<br>
+brw_get_texture_swizzle(<u></u>struct gl_context *ctx,<br>
+                        const struct gl_texture_object *t)<br>
  {<br>
+   const struct gl_shader_program *shProg = ctx->Shader._<u></u>CurrentFragmentProgram;<br>
</blockquote>
<br>
You're looking at the FS even if we're trying to set up textures for the<br>
VS.  I think the caller should pass in the particular program, and then<br>
it'll be more obvious to the caller which state flag is right.<br>
</blockquote>
<br></div></div>
Eric mentioned this on IRC:<br>
<br>
<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.<br>
<br>
which is true - otherwise the VS/FS link would have failed.<br></blockquote><div><br></div><div style>Is this still going to be true when we implement ARB_separate_shader_objects?</div><div><br></div></div></div></div>