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

Paul Berry stereotype441 at gmail.com
Tue Dec 6 12:39:44 PST 2011


On 6 December 2011 11:53, Eric Anholt <eric at anholt.net> wrote:

> On Tue, 6 Dec 2011 08:17:57 -0800, Paul Berry <stereotype441 at gmail.com>
> wrote:
> > 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.
>
> We'll have to figure it out anyway because the X Server sure isn't
> setting up GS URB space to match ours, and it's not doing that
> workaround.  So, unless pipeline flushes are sufficient (but they
> probably are), we'll need to work it out.  And if pipeline flushes are
> sufficient, that seems like a suitable workaround.
>
> "Dummy draw" is a term I only know from the simulator for handling
> pipelining.  There's no existing code on our side I know of.
>

Ok, in v2 of the patch series, I'll modify this patch so that (a) if the GS
is not in use, it gives all of the URB space to the VS, and (b) if the GS
has been used since the last pipeline flush, do another flush before
issuing any more draws.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111206/49deea03/attachment-0001.htm>


More information about the mesa-dev mailing list