On Fri, Nov 10, 2023 at 11:21:15AM +0000, Simon Ser wrote: > On Thursday, November 9th, 2023 at 20:17, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > > > Can we add another function pointer to the struct drm_driver (or > > > similar) to do the allocation, and move the actual dmabuf handling > > > code into the core? > > > > Yeah, I agree here, it just seems easier to provide a global hook and a > > somewhat sane default to cover all drivers in one go (potentially with > > additional restrictions, like only for modeset-only drivers or > > something). > > First off not all drivers are using the GEM DMA helpers (e.g. vc4 with > !vc5 does not). Right. vc4 pre-RPi4 is the exception though, so it's kind of what I meant by providing sane defaults: the vast majority of drivers are using GEM DMA helpers, and we should totally let drivers override that if relevant. Basically, we already have 2.5 citizen classes, I'd really like to avoid having 3 officially, even more so if it's not super difficult to do. > The heap code in this patch only works with drivers leveraging GEM DMA > helpers. We could add a new hook to drm_driver to allocate heaps, link to a default implementation in DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(), and then use that new hook in your new heap. It would already cover 40 drivers at the moment, instead of just one, with all of them (but atmel-hlcdc maybe?) being in the same situation than RPi4-vc4 is. > Then maybe it's somewhat simple to cover typical display devices found > on split render/display SoCs, however for the rest it's going to be much > more complicated. For x86 typically there are multiple buffer placements > supported by the GPU and we need to have one heap per possible placement. > And then figuring out all of the rules, priority and compatibility stuff > is a whole other task in and of itself. But x86 typically doesn't have a split render/display setup, right? Maxime
Attachment:
signature.asc
Description: PGP signature
