On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: > 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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
