[Mesa-dev] [PATCH 7/9] i965/gs: Add opcodes needed for EndPrimitive().

[Kenneth Graunke]

On 09/10/2013 09:07 PM, Paul Berry wrote:
> On 9 September 2013 23:39, Kenneth Graunke <kenneth at whitecape.org
> <mailto:kenneth at 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.