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

Rob Clark [off-list ref] writes:

quoted

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.

well, even not knowing the size up front shouldn't really be a
show-stopper, unless you had to mmap it to userspace, perhaps..
normally backing pages aren't allocated until drm_gem_get_pages() so
allocating the gem bo as placeholder to track dependencies of the
batch/submit shouldn't be an issue.  But I noticed you don't use
drm_gem_get_pages().. maybe w/ cma helpers it is harder to decouple
allocation of the drm_gem_object from the backing store.

BR,
-R