Rob Clark <robdclark@xxxxxxxxx> writes: > On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: >> 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
