15:41 <Putti> Hi, would it make sense to implement CMA / continuous memory allocation for lima? Now it does non-contiguous allocations and uses iommu. I would like to use lima render node to allocate SCANOUT compatible buffers so I can display the renderings directly with the display controller that seems to only support CMA memory.

15:42 <Putti> In mesa3d I see some other drivers using kmsro in combination with the render node allocation but not quite sure how that works, so if lima would benefit from CMA allocator I would gladly implement it.

16:06 <daniels> damn, they left :(

16:06 <daniels> Putti: oh no, you didn't leave, tab complete just didn't work ...

16:06 <daniels> anyway, renderonly is the exact solution for what you're looking for

16:07 <daniels> it doesn't make sense to force lima to use CMA when lima doesn't need to use CMA

16:07 <daniels> for example, you don't need to allocate contiguous buffers for e.g. every FBO

16:07 <Putti> daniels, sorry, my connection dropped

16:07 <daniels> no problem! it's IRC's fault, not yours :)

16:07 <daniels> anyway, the way renderonly/kmsro works, is that your display controller implements dumb buffer allocation via CMA

16:08 <daniels> when a buffer actually needs to be displayed on the display controller (e.g. via GBM), it allocates a buffer via the KMS driver, exports it into a dmabuf, then imports it into lima

16:08 <Putti> daniels, right, so on android platform I guess we need to implement DRM magic for card node since it is used by the hardware composer process already

16:08 <daniels> ah ...

16:09 <Putti> I think one of the reasons for render nodes was so that drm magic would not be needed

16:09 <Putti> and now it would be needed again because of kmsro

16:09 <daniels> yeah, it's sort of unresolved atm

16:09 <daniels> https://gitlab.collabora.com/spurv/gbm_gralloc/-/commits/master might help you out though

16:10 <daniels> that was for etnaviv on imx6 which has the exact same constraint as you

16:14 <dllud> daniels, sorry to jump into the conversation, I've also been helping Putti on this.

16:14 <dllud> Current master branch of gbm_gralloc from robherring (what we're using), seems to have most (all?) of those commits.

16:14 <dllud> Did etnaviv render node had the same restriction of being unable to alloc contiguous mem as lima does?

16:14 <dllud> Do you know in particular what was their solution?

16:15 <Putti> daniels, as far as I can tell we have here 3 competing ways of doing memory allocations: 1) card+render node meanings using the kmsro driver and gpu driver 2) using ION gralloc for everything really flexible as far as I can tell 3) making the render node able to do contiguous and non-contiguous allocations

16:16 <Putti> daniels, and the issue I think we have is that we have not agreed as a community which design route to go forward

16:17 <Putti> daniels, maybe some folks already have a view on this but this information has not propagated down to the wider community

16:17 <Putti> should we continue discussion on #dri-devel?

16:17 <daniels> dllud: don't be sorry! thanks for the input :)

16:18 <daniels> dllud: etnaviv rendernode on that platform is indeed using an IOMMU/SG, whereas the display requires contiguous

16:19 <daniels> Putti: #dri-devel sounds good - it's definitely a long-standing problem ever since gralloc got made into a service with Treble

16:20 <daniels> the SPURV tree isn't intended as a real upstream solution; it's a proof-of-concept that we (Collabora) periodically refresh in our own time away from client projects, with the goal of understanding the gap between Android and mainline, and having an accurate to-do list of problems to solve ... actually solving those problems is a slightly harder task and we're taken up with other work (like Panfrost) atm :)

16:21 <daniels> also, to be honest, non-IOMMU IP blocks are not a very high priority for us atm

16:22 <dllud> daniels, thanks, so exact same situation. I guess it's worth to ask Tomeu Vizoso what solution he went for.

16:22 <dllud> Is he on the room? Do you know his nick?

16:24 <daniels> he's on #dri-devel as tomeu, but I can tell you that whatever solution he went with is in the gbm_gralloc / drm_hwc / frameworks trees in those repos :P

16:24 <daniels> (we work together)

16:25 <dllud> Thanks, I'll dig in there then!

16:31 <daniels> good luck! and yeah, you can ping him on #dri-devel and he'll answer, though he has just finished his day so you may have to wait until tomorrow

16:32 <Putti> daniels, I started the discussion on #dri-devel now, thanks a lot for the confirmation for our ideas, now we know at least that we are on the right track.

16:32 <daniels> no problem! good luck with it, it's cool to see more people using the upstream stack :)