On 10/01, Rob Clark wrote:
On Thu, Oct 1, 2015 at 3:25 PM, Rob Clark robdclark@gmail.com wrote:
On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd sboyd@codeaurora.org wrote:
The simplest thing to do is to split the memory between GPU and vidc statically. The other use cases with preemption and eviction and DMA add a lot of complexity that we can explore at a later time if need be.
true, as long as one of the clients is the static gpu client, I guess we could reasonably easily support up to two clients reasonably easily...
btw, random thought.. drm_mm is a utility in drm that serves a similar function to genalloc for graphics drivers to manage their address space(s) (used for everything from mmap virtual address space of buffers allocated against device to managing vram and gart allocations, etc... when vram carveout is used w/ drm/msm (due to no iommu) I use it to manage allocations from the carveout). It has some potentially convenient twists, like supporting allocation from top of the "address space" instead of bottom. I'm thinking in particular of allocating "narrow mode" allocations from top and "wide mode" from bottom since wide vs narrow can only be set per region and not per macro within the region. (It can also search by first-fit or best-fit.. although not sure if that is useful to us, since OCMEM size is relatively constrained.)
Not that I really want to keep ocmem allocator in drm.. I'd really rather it be someone else's headache once it gets to implementing the crazy stuff for all the random use-cases of other OCMEM users, since gpu's use of OCMEM is rather simple/static..
The way downstream driver does this is with a bunch of extra bookkeeping on top of genalloc so it can do a dummy allocation to force "from the top" allocation (and then immediately freeing the dummy allocation).. Maybe it just makes sense to teach genalloc how to do from-top vs from-bottom allocations? Not really sure..
It looks like video and GPU both use wide mode, if I'm reading the code correctly. So it seems that we don't need to do anything special for allocations, just hand the GPU and vidc a chunk of the memory in wide mode and then let the GPU and vidc drivers manage buffers within their chunk however they see fit.
One pitfall is going to be power management. ocmem is closely tied to the GPU power domains, so when video is using its chunk of memory we're going to need to keep ocmem powered up even if the GPU is off. I suppose for now we can just leave it always powered on once the driver probes, but if we ever want to turn it off we're going to need some tracking mechanism to make sure we don't turn it off when buffers are in use.