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