On 29/05/2020 15:56, Daniel Stone 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. > > 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.) I have an hard time understanding how this affects the Amlogic Framebuffer Compression patchset I sent at [1]. [1] http://lore.kernel.org/r/20200529151935.13418-2-narmstrong@xxxxxxxxxxxx Neil > > Cheers, > Daniel > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
