<div dir="ltr">On 3 August 2013 19:59, Chris Forbes <span dir="ltr"><<a href="mailto:chrisf@ijw.co.nz" target="_blank">chrisf@ijw.co.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also adjust the SF URB read offset to account for there being two<br>
additional slots of stuff it doesn't care about.<br>
<br>
Signed-off-by: Chris Forbes <<a href="mailto:chrisf@ijw.co.nz">chrisf@ijw.co.nz</a>><br>
---<br>
src/mesa/drivers/dri/i965/brw_sf.h | 2 +-<br>
src/mesa/drivers/dri/i965/brw_vs.c | 2 ++<br>
2 files changed, 3 insertions(+), 1 deletion(-)<br>
<br>
diff --git a/src/mesa/drivers/dri/i965/brw_sf.h b/src/mesa/drivers/dri/i965/brw_sf.h<br>
index 09880fe..eb40551 100644<br>
--- a/src/mesa/drivers/dri/i965/brw_sf.h<br>
+++ b/src/mesa/drivers/dri/i965/brw_sf.h<br>
@@ -105,6 +105,6 @@ void brw_emit_point_setup( struct brw_sf_compile *c, bool allocate );<br>
void brw_emit_point_sprite_setup( struct brw_sf_compile *c, bool allocate );<br>
void brw_emit_anyprim_setup( struct brw_sf_compile *c );<br>
<br>
-#define BRW_SF_URB_ENTRY_READ_OFFSET 1<br>
+#define BRW_SF_URB_ENTRY_READ_OFFSET 2<br></blockquote><div><br></div><div>I don't think this is going to work, since SF needs to be able to read the clip distances out of the URB in case they are needed by the FS (GLSL 1.30 allows fragment shaders to read from the gl_ClipDistance array). I wonder if this is why you ran into trouble with patch 3?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
#endif<br>
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c<br>
index 5b8173d..e6d8c5d 100644<br>
--- a/src/mesa/drivers/dri/i965/brw_vs.c<br>
+++ b/src/mesa/drivers/dri/i965/brw_vs.c<br>
@@ -94,6 +94,8 @@ brw_compute_vue_map(struct brw_context *brw, struct brw_vue_map *vue_map,<br>
*/<br>
assign_vue_slot(vue_map, VARYING_SLOT_PSIZ);<br>
assign_vue_slot(vue_map, BRW_VARYING_SLOT_NDC);<br>
+ assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST0);<br>
+ assign_vue_slot(vue_map, VARYING_SLOT_CLIP_DIST1);<br></blockquote><div><br></div><div>Technically I don't think this is actually necessary. All that is needed is for the clip distance varying slots to be next to each other in the VUE, since patch 07/10 assumes that all clip distances are contiguous in the VUE. And that will happen anyhow, since VARYING_SLOT_CLIP_DIST1 == VARYING_SLOT_CLIP_DIST0 + 1.<br>
<br></div><div>Having said that, I don't think there's anything wrong with moving the clip distances to the start of the VUE. It has the advantage of making Gen4-5 more consistent with Gen6-7, and that's a nice thing. So if you want to leave this code in, that's fine with me.<br>
<br>I would recommend, however, placing these two calls to assign_vue_slot() inside an "if (userclip_active)" conditional (like we do for Gen6-7) so that we don't have to waste VUE slots in programs that don't use user-defined clipping.<br>
</div><br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
assign_vue_slot(vue_map, VARYING_SLOT_POS);<br>
break;<br>
case 6:<br>
<span class=""><font color="#888888">--<br>
1.8.3.4<br>
<br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</font></span></blockquote></div><br></div></div>