On Fri, May 29, 2020 at 9:58 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi Alex, > > On Fri, 29 May 2020 at 14:29, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > On Fri, May 29, 2020 at 4:59 AM Simon Ser <contact@xxxxxxxxxxx> wrote: > > > OK. In this case I think it's fine to make the DMA-BUF import fail, as > > > we've suggested on IRC. The more-or-less planned fix for these buffer > > > sharing issues is to revive the buffer constraints proposal from the > > > allocator project. It's a lot of work though. > > > > I get that, but why explicitly limit modifiers then? Shouldn't we try > > and do the best we can with what we have now? If not the situation is > > not much better than what we have now. Why go through the effort or > > adding modifer support in the first place if they are mostly useless? > > Well sure, we could add pitch alignment in there. And height > alignment. And starting byte offset. And acceptable byte distance > between planes. And physical contiguity / number of backing pages. And > placement (system vs. GTT vs. local), which also implies adding a > device-unique identifier whilst we're at it. And acceptable > width/height bounds. All of those are perfectly valid constraints > which could cause imports to fail, and not even an exhaustive list. > > How does Navi ensure that every single linear dmabuf source it can > ever receive is aligned to 256 bytes today? How does adding support > for modifiers - something which does solve other problems, like 'every > three months I wearily review a patch forcing all winsys buffers to be > allocated for scanout usage for a new random reason, regressing > performance for a lot of other vendors' - make Navi's situation worse? > > > I don't quite get what we are trying to do with them. What does this > > mean "Modifiers must uniquely encode buffer layout"? We have a number > > of buffer layouts that are the same from a functional standpoint, but > > they have different alignment requirements depending on the chip and > > the number of memory channels, etc. Would those be considered the > > same modifer? If not, then we are sort of implicitly encoding > > alignment requirements into the modifier. > > Yes, of course some requirements are implicit. Given that tiles are > indivisible, it makes no sense to have a 64x64 tiled buffer with a > 32-pixel stride. But that isn't the same thing as encoding an > arbitrary constraint, it's just a requirement of the encoding. > > The reason why modifiers have been successful and adopted by every > other vendor apart from IMG, is exactly because they _don't_ attempt > to boil the ocean, but are the most practical realisation of improving > performance within a complex ecosystem. The allocator is the complete > and exhaustive solution to all our problems, but it's not exactly > going to be done tomorrow. Maybe I'm over thinking this. I just don't want to get into a situation where we go through a lot of effort to add modifier support and then performance ends up being worse than it is today in a lot of cases. Alex > > Playing a single video today could easily involve a V4L2 codec source > into a V4L2 postprocessor into Chromium's Wayland host compositor > through Chromium itself into the host Wayland compositor and finally > into EGL and/or Vulkan and/or KMS. If you want to figure out what the > V4L2/DRM/KMS, GStreamer/VA-API/Kodi, EGL/Vulkan, and Wayland/X11 APIs > look for negotiating a totally optimal layout across at least three > different hardware classes from at least three different vendors, then > I'm all for it. I'll be cheering you on from the sidelines and doing > what I can to help. But the only reason we've got to this point today > is because Allwinner, AmLogic, Arm, Broadcom, Intel, NVIDIA, NXP, > Qualcomm, Rockchip, Samsung, and VeriSilicon, have all spent the last > few years trying to avoid perfection being the enemy of good. (And > those are just the hardware vendors - obviously Collabora and others > like us have also put not-inconsiderable effort into getting at least > this far.) > > Cheers, > Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
