On 9 September 2013 23:39, Kenneth Graunke <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
* 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
