On 5 December 2011 14:57, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Mon, 5 Dec 2011 09:40:50 -0800, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote: > From: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> > > 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 <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> </div>This should be changed to not take up URB space for non-GS mode. </blockquote></div> 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?