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

[Rob Clark]

On Tue, Nov 15, 2016 at 1:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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.

afaiu weston already supports planar formats, and I know android does.
So really only a matter of fixing x11 ;-)

> 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.

I'm needing something like this for sharing tiled yuv buffers w/ video
decoder, so even outside of window-system it has some utility.

BR,
-R