Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux