Re: Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
> Sorry, I was being sloppy again![1] I meant CPU mmapped. No worries, just wanted to check :) > Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer - > since SAME_VA means permanently mapped on the CPU this translated to > mmapping a HEAP object. Why it does this I've no idea. I'm not sure I follow. Conceptually, if you're permanently mapped, there's nothing to grow, right? Is there a reason not to just disable HEAP in this cases, i.e.: if (flags & SAME_VA) flags &= ~GROW_ON_GPF; It may not be fully optimal, but that way the legacy code keeps working and upstream userspace isn't held back :) > The main use in the blob for > this is being able to dump buffers when debugging (i.e. dump buffers > before/after every GPU job). Could we disable HEAP support in userspace (not setting the flags) for debug builds that need to dump buffers? In production the extra memory usage matters, hence this patch, but in dev, there's plenty of memory to spare. > Ideally you also need a way of querying which pages have been backed > by faults (much easier with kbase where that's always just the number > of pages). Is there a use case for this with one of the userland APIs? (Maybe Vulkan?) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 17:13, Alyssa Rosenzweig wrote: >> Either we should prevent mapping of HEAP objects > > I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped > anyway in normal use; if you need them mapped (for debugging etc), it's > no big deal to just.. not set the HEAP flag in debug builds. > > Or do you mean GPU mapping? Sorry, I was being sloppy again![1] I meant CPU mmapped. I agree there isn't a strong use case for it. I've been investigating/testing Panfrost kernel with the Arm Mali blob. Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer - since SAME_VA means permanently mapped on the CPU this translated to mmapping a HEAP object. Why it does this I've no idea. So I've got an interest in trying to maintain compatibility. kbase places no restriction on mmapping buffers. The main use in the blob for this is being able to dump buffers when debugging (i.e. dump buffers before/after every GPU job). Ideally you also need a way of querying which pages have been backed by faults (much easier with kbase where that's always just the number of pages). Steve [1] kbase+the blob have different terminology here to Panfrost, I do sometimes struggle with the idea of "not mapped on the GPU" - it's not really a concept in kbase. All buffers are "mapped" - they just might be "growable" and not yet full size... :) Hence "mapped" refers to the CPU. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
