[Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers

[Marek Olšák]

On Tue, Nov 15, 2016 at 6:26 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Nov 15, 2016 at 12:17 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Tue, Nov 15, 2016 at 5:58 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Tue, Nov 15, 2016 at 11:44 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Is the modifier just a driver-specific description of the tiling
>>>> layout and compression?
>>>>
>>>> What makes you think that 8 bytes is enough to describe that? What if
>>>> I need 9 bytes just to program the display hardware?
>>>>
>>>> Drivers importing DMABUFs still have to invoke the texture tiling
>>>> calculator to get all necessary parameters for rendering (not just
>>>> display), which may even be 128 bytes per plane.
>>>
>>> fwiw, this maps 1:1 to addfb2 ioctl, and just brings egl to parity with kms.
>>>
>>> Maybe the addfb2 approach wasn't the best idea compared to some of the
>>> ideas proposed for hypothetical "liballoc" for being ultra-generic.
>>> OTOH perhaps you can just treat it like an enum?  I mean maybe the set
>>> of tiled formats that you would actually exchange with another device
>>> is less than 2^^72.  It seems reasonable to restrict the possible
>>> tiled formats supported by this extension to only things that can be
>>> exchanged with i965..
>>
>> For tile modes alone, 64 bits seem enough.
>>
>> For compression, you may need a separate buffer to hold compression
>> data, so now you have to encode the tile mode and other parameters of
>> the plane, parameters of the compression buffer, and possibly also the
>> pitch and offset of the compression buffer.
>>
>> I'm not saying it can't be done, but it wouldn't be nice.
>
> Perhaps pass the compression buffer as a separate plane?  Then it gets
> it's own dmabuf fd, and stride (and offset incase it really is a
> single buffer) plus 64b modifier..

And then I'd have to update all the window system protocols to get the
second plane for basic RGBA formats. Thank you very much, I'm not
interested.

Immutable metadata (modifiers) stored in the kernel is the only
scalable (and thus usable) solution here. There was an argument
against _mutable_ metadata attached to BOs and the synchronization
hell it can cause, but I've not seen any argument against _immutable_
metadata. Trying to push the metadata (modifiers) through window
system protocols seems like a horrible idea to me, not just because of
that fact that window system protocols shouldn't care about
driver-specific stuff, but also because of the immense burden once you
realize that you have to fix all window system protocols and KMS apps
because 64 bits of metadata is not enough to support your hardware.
It's clearly not economically sustainable.

That said, I'm OK with the patch series (I didn't read all of it - you
still need an ack from someone else), but widespread adoption of this
feature is unlikely to happen.

Marek