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

[Rob Clark]

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

BR,
-R

> Marek