On Thursday, November 9th, 2023 at 20:09, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > On Thu, Nov 09, 2023 at 03:31:44PM +0000, Simon Ser wrote: > > > > - What would be a good name for the heap? "vc4" is maybe a bit naive and > > > > not precise enough. Something with "cma"? Do we need to plan a naming > > > > scheme to accomodate for multiple vc4 devices? > > > > > > That's a general issue though that happens with pretty much all devices > > > with a separate node for modesetting and rendering, so I don't think > > > addressing it only for vc4 make sense, we should make it generic. > > > > > > So maybe something like "scanout"? > > > > > > One thing we need to consider too is that the Pi5 will have multiple > > > display nodes (4(?) iirc) with different capabilities, vc4 being only > > > one of them. This will impact that solution too. > > > > I'm not sure trying to find a unique generic name for all split render/display > > SoC is a good idea: > > > > - For the purposes of replacing DRM dumb buffers usage from v3d, we don't > > actually need a generic name, it's perfectly fine to hardcode a name here > > since vc4 is pretty much hardcoded there already. > > Right. I'm wondering how that will work with drivers like panfrost or > powervr that will need to interact with different display drivers. We > will have the same issue for those, but we won't be able to hardcode the > driver name. We will be able to hardcode the driver name. In fact, the driver name is already hardcoded in kmsro today (Mesa creates one kmsro .so per supported display driver in /usr/lib/dri). It's just a matter of passing through the actual display device to panfrost in Mesa and adding a very simple mapping of driver name -> heap name. > Similarly, if you have multiple display drivers, what "scanout-capable" > will mean might differ from one device to the other. Some have > constraints on the memory they can access for example, so you cannot > just assume that a scanout-capable buffer allocated by vc4 might not be > scanout-capable for one of the RP1 DSI device. > > > - As you said, "scanout" may be ill-defined depending on the system. What if > > a PCIe or USB device is plugged in? What if vkms is loaded? What if there are > > multiple platform display devices? What does "scanout" mean then? > > - A generic solution to advertise what DMA heaps a DRM display device is > > compatible with is probably better addressed by populating sysfs with new > > files. > > That would be a good idea indeed > > > We've talked with Sima at XDC about adding a symlink pointing to the > > DMA heap and extra metadata files describing priorities and such. > > However we don't actually need that part for the purposes of v3d -- > > I think I'd rather defer that until more DMA heaps are plumbed > > across the DRM drivers. > > Honestly, I don't think we can afford to only consider vc4/v3d here. The > issue you described seem to affect any SoC with a split scanout/GPU, > which is pretty much all of them? And if they are all affected, we > should design something that fixes it once and for all. We don't need any sysfs stuff to fix the primary node and DRM dumb buffer issues in Mesa's kmsro/renderonly. The sysfs stuff is only required for a fully generic buffer placement constraint/compatibility uAPI. Which would be super useful in compositors, but let's do one step at a time.
