> 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?)
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
