On Fri, May 13, 2022 at 9:13 AM Tejun Heo tj@kernel.org wrote:
Hello,
On Thu, May 12, 2022 at 08:43:52PM -0700, T.J. Mercier wrote:
I'm actually happy I've asked this question, wasn't silly after all. I think the problem here is a naming issue. What you really are monitor is "video memory", which consist of a memory segment allocated to store data used to render images (its not always images of course, GPU an VPU have specialized buffers for their purpose).
Whether this should be split between what is used specifically by the GPU drivers, the display drivers, the VPU (CODEC and pre/post-processor) or camera drivers is something that should be discussed. But in the current approach, you really meant Video memory as a superset of the above. Personally, I think generically (to de-Andronized your work), en-globing all video memory is sufficient. What I fail to understand is how you will manage to distinguished DMABuf Heap allocation (which are used outside of Android btw), from Video allocation or other type of usage. I'm sure non-video usage will exist in the future (think of machine learning, compute, other high bandwidth streaming thingy ...)
Ok thank you for pointing out the naming issue. The naming is a consequence of the initial use case, but I guess it's too specific. What I want out of this change is that android can track dmabufs that come out of heaps, and drm can track gpu memory. But other drivers could track different resources under different names. Imagine this were called a buffer cgroup controller instead of a GPU cgroup controller. Then the use component ("video memory") isn't tied up with the name of the controller, but it's up to the name of the bucket the resource is tracked under. I think this meets the needs of the two use cases I'm aware of now, while leaving the door open to other future needs. Really the controller is just enabling abstract named buckets for tracking and eventually limiting a type of resource.
So, there hasn't been whole lot of discussion w/ other GPU folks and what comes up still seems to indicate that we're still long way away from having a meaningful gpu controller.
Yes, and I would still be happy to collaborate.
For your use case, would it make sense to just add dmabuf as a key to the misc controller?
Thanks for your suggestion. This almost works. "dmabuf" as a key could work, but I'd actually like to account for each heap. Since heaps can be dynamically added, I can't accommodate every potential heap name by hardcoding registrations in the misc controller.
I'm not sure it makes sense to push "gpu controller" forward if there's no conceptual consensus around what resources are.
Thanks.
-- tejun