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

[Paul Berry]

On 9 September 2013 23:39, Kenneth Graunke <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
    * 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130910/d50c65f2/attachment.html>