<div dir="ltr">On 9 September 2013 23:39, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 09/09/2013 08:20 AM, Paul Berry wrote:<br>
> +void<br>
> +vec4_generator::generate_gs_set_channel_masks(struct brw_reg dst,<br>
> + struct brw_reg src)<br>
> +{<br>
> + /* From p21 of volume 4 part 2 of the Ivy Bridge PRM (2.4.3.1 Message<br>
> + * Header: M0.5):<br>
> + *<br>
> + * 15 Vertex 1 DATA [3] / Vertex 0 DATA[7] Channel Mask<br>
> + *<br>
> + * When Swizzle Control = URB_INTERLEAVED this bit controls Vertex 1<br>
> + * DATA[3], when Swizzle Control = URB_NOSWIZZLE this bit controls<br>
> + * Vertex 0 DATA[7]. This bit is ANDed with the corresponding<br>
> + * channel enable to determine the final channel enable. For the<br>
> + * URB_READ_OWORD & URB_READ_HWORD messages, when final channel<br>
> + * enable is 1 it indicates that Vertex 1 DATA [3] will be included<br>
> + * in the writeback message. For the URB_WRITE_OWORD &<br>
> + * URB_WRITE_HWORD messages, when final channel enable is 1 it<br>
> + * indicates that Vertex 1 DATA [3] will be written to the surface.<br>
> + *<br>
> + * 0: Vertex 1 DATA [3] / Vertex 0 DATA[7] channel not included<br>
> + * 1: Vertex DATA [3] / Vertex 0 DATA[7] channel included<br>
> + *<br>
> + * 14 Vertex 1 DATA [2] Channel Mask<br>
> + * 13 Vertex 1 DATA [1] Channel Mask<br>
> + * 12 Vertex 1 DATA [0] Channel Mask<br>
> + * 11 Vertex 0 DATA [3] Channel Mask<br>
> + * 10 Vertex 0 DATA [2] Channel Mask<br>
> + * 9 Vertex 0 DATA [1] Channel Mask<br>
> + * 8 Vertex 0 DATA [0] Channel Mask<br>
> + *<br>
> + * (This is from a section of the PRM that is agnostic to the particular<br>
> + * type of shader being executed, so "Vertex 0" and "Vertex 1" refer to<br>
> + * geometry shader invocations 0 and 1, respectively). Since we have the<br>
> + * enable flags for geometry shader invocation 0 in bits 0-3 of DWORD 0,<br>
> + * and the enable flags for geometry shader invocation 1 in bits 4-7 of<br>
> + * DWORD 4, we just need to OR them together and store the result in bits<br>
> + * 15-8 of DWORD 5.<br>
<br>
</div></div>One thing isn't entirely clear to me here: are bits 7:4 of DWord 0 and<br>
bits 3:0 of DWord 4 both zero? Otherwise, OR'ing them together will<br>
result in a mishmash of the bits you want and...whatever other rubbish<br>
is there.<br>
<br>
I assume it works out, but maybe expand the comment to explain this?<br></blockquote><div><br></div><div>Good point. I've added a comment that says:<br><br> * Note: this relies on the source register having zeros in (a) bits 7:4 of<br>
* DWORD 0 and (b) bits 3:0 of DWORD 4. We can rely (b) because the source<br> * register was prepared by GS_OPCODE_PREPARE_CHANNEL_MASKS (which shifts<br> * DWORD 4 left by 4 bits), and we can rely on (a) because prior to the<br>
* execution of GS_OPCODE_PREPARE_CHANNEL_MASKS, DWORDs 0 and 4 need to<br> * contain valid channel mask values (which are in the range 0x0-0xf).<br><br></div><div>I've also added text above the definition of GS_OPCODE_PREPARE_CHANNEL_MASKS that says:<br>
<br> * Note: since GS_OPCODE_SET_CHANNEL_MASKS ORs DWORDs 0 and 4 together to<br> * form the final channel mask, DWORDs 0 and 4 of the dst register must not<br> * have any extraneous bits set prior to execution of this opcode (that is,<br>
* they should be in the range 0x0 to 0xf).<br><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>
One other nitpick: you list bits as 0-3, 4-7, and 15-8. Might be nice<br>
to pick a consistent order. Usually the hardware docs use "High:Low".<br></blockquote><div><br></div><div>Fixed.<br></div></div></div></div>