<div dir="ltr">On 23 January 2013 07:38, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.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 05:16 PM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch paves the way for allowing varying structs by generalizing<br>
varying_matches::compute_<u></u>packing_order to handle any type of varying.<br>
Previously, we packed in the order (vec4, vec2, float, vec3), with<br>
matrices being packed according to the size of their columns. Now, we<br>
pack everything according to its number of components mod 4, in the<br>
order (0, 2, 1, 3).<br>
<br>
There is no behavioural change for vectors. Matrices are now packed<br>
slightly more sensibly (e.g. a mat2 is now packed with vec4's, which<br>
guarantees that it will occupy a single varying slot, whereas it<br>
previously was packed with vec2's, which meant that it might get split<br>
across two adjacent slots).<br>
---<br>
src/glsl/link_varyings.cpp | 5 ++---<br>
1 file changed, 2 insertions(+), 3 deletions(-)<br>
<br>
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp<br>
index 5a3240b..d8f501c 100644<br>
--- a/src/glsl/link_varyings.cpp<br>
+++ b/src/glsl/link_varyings.cpp<br>
@@ -804,16 +804,15 @@ varying_matches::compute_<u></u>packing_order(ir_variable *var)<br>
{<br>
const glsl_type *element_type = var->type;<br>
<br>
- /* FINISHME: Support for "varying" records in GLSL 1.50. */<br>
while (element_type->base_type == GLSL_TYPE_ARRAY) {<br>
element_type = element_type->fields.array;<br>
}<br>
<br>
- switch (element_type->vector_<u></u>elements) {<br>
+ switch (element_type->component_<u></u>slots() % 4) {<br>
</blockquote>
<br></div></div>
Will this produce the same result for all matrix types as well? I think a mat2x3 would be 3 in the old scheme, but 2 in the new scheme. Right?</blockquote><div><br></div><div>Yes, a number of matrix types will get new packing orders. Here's the complete list:<br>
<br></div><div>- mat2x2 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC2. As I argue above, this is slightly better, because it guarantees that the matrix occupies a single varying slot.<br><br></div><div>- mat2x3 gets assigned PACKING_ORDER_VEC2 instead of PACKING_ORDER_VEC3. This is kind of a wash. Previously, mat2x3 had a 25% chance of having neither of its columns double parked, a 50% chance of having exactly one of its columns double parked, and a 25% chance of having both of its columns double parked. Now it always has exactly one of its columns double parked.<br>
<br></div><div>- mat3x3 gets assigned PACKING_ORDER_SCALAR instead of PACKING_ORDER_VEC3. This doesn't affect much, since in both cases there is no guarantee of how the matrix will be aligned.<br><br></div><div>- mat4x2 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC2. I think this is slightly better for the same reason as in mat2x2.<br>
<br></div><div>- mat4x3 gets assigned PACKING_ORDER_VEC4 instead of PACKING_ORDER_VEC3. I think this is slightly better for the same reason as in mat2x2.<br><br></div><div>Do you think I should include these details in the commit message?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
case 1: return PACKING_ORDER_SCALAR;<br>
case 2: return PACKING_ORDER_VEC2;<br>
case 3: return PACKING_ORDER_VEC3;<br>
- case 4: return PACKING_ORDER_VEC4;<br>
+ case 0: return PACKING_ORDER_VEC4;<br>
default:<br>
assert(!"Unexpected value of vector_elements");<br>
return PACKING_ORDER_VEC4;<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>