Rob Clark [off-list ref] writes:

On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt [off-list ref] wrote:

quoted

Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed.  When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.

We were looking at "what's currently running in the binner", but since
the bin/render submission split, we may end up with the binner
completing and having no new job while the renderer is still
processing.  So, if we don't find a bin job at all, look at the
highest-seqno (last) render job to attach our overflow to.

so, drive-by comment.. but can you allocate gem bo's without backing
them immediately with pages?  If so, just always allocate the bo
up-front and attach it as a dependency of the batch, and only pin it
to actual pages when you have to overflow?

The amount of overflow for a given CL is arbitrary, depending on the
geometry submitted, and the overflow pool just gets streamed into by the
hardware as you submit bin jobs.  You'll end up allocating [0,n] new
overflows per bin job.  I don't see where "allocate gem BOs without
backing them immediately with pages" idea would fit into this.