[Mesa-dev] [PATCH 07/10] i965: Initial stab at GS URB space allocation.

[Paul Berry]

On 5 December 2011 14:57, Eric Anholt <eric at anholt.net> wrote:

> On Mon,  5 Dec 2011 09:40:50 -0800, Paul Berry <stereotype441 at gmail.com>
> wrote:
> > From: Kenneth Graunke <kenneth at whitecape.org>
> >
> > The 50/50 split is just an attempt to get things working.  We likely
> > want to tune this, and probably want to avoid allocating the GS any
> > space if we're not using it.
> >
> > For now, this is good enough.
> >
> > Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>
> This should be changed to not take up URB space for non-GS mode.
>

In the long term, I agree.  How critical do you think it is to make this
change in this patch series?  The reason I ask is that there is this
enigmatic comment in the Sandy Bridge PRM (vol 2 part 1, 1.4.7 3DSTATE_URB,
p27, or equivalently in the BSpec vol2a 3D Pipeline - Overview [SNB+] > 3D
Pipeline > 3D Pipeline State Overview > 3DSTATE_URB DevSNB):

"Because of a urb corruption caused by allocating a previous gsunit’s urb
entry to vsunit software is
required to send a “GS NULL Fence”(Send URB fence with VS URB size == 1 and
GS URB size == 0)
plus a dummy DRAW call before any case where VS will be taking over GS URB
space."

If we change this patch to only allocate URB space to the GS when the GS is
in use, then I think we have to follow this part of the documentation
(because when switching out of transform feedback mode we'll be reassigning
URB entries from the GS to the VS).  But I don't know how to interpret
this, since AFAICT, "URB fence" is a command that doesn't exist on Sandy
Bridge.  It's possible that what they meant to say in that parenthetical
comment was "Send 3DSTATE_URB with VS URB Entry Allocation Size == 1 and GS
URB Entry Allocation Size == 0", but I'm not sure how comfortable I am with
that level of reinterpretation.

Also, there is a need to send a dummy DRAW call.  Is there existing i965
code to do this?  I found the documentation for how to do a dummy draw in
the bspec and it looks pretty simple but I would rather not duplicate
existing code.

If you can help me work out these details, I'd be glad to modify this patch
series to only allocate URB space to the GS when the GS is in use.
Otherwise, my preference would be to postpone this until we have transform
feedback working, so it will be easier to test for data corruption and
verify that we've done the GS NULL Fence correctly.

What would you recommend?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111206/7f9ad2b2/attachment.html>