[Mesa-dev] [PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Nicolai Hähnle]

On 26.07.2017 08:29, Michel Dänzer wrote:
> On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
>> On 22.07.2017 14:00, Daniel Stone wrote:
>>>
>>> I don't have any great solution off the top of my head, but I'd be
>>> inclined to bundle stride in with placement. TTBOMK (from having
>>> looked at radv), buffers shared cross-GPU also need to be allocated
>>> from a separate externally-visible memory heap. And at the moment,
>>> lacking placement information at allocation time (at least for EGL
>>> allocations, via DRIImage), that happens via transparent migration at
>>> import time I think. Placement restrictions would probably also
>>> involve communicating base address alignment requirements.
>>
>> Stride isn't really in the same category as placement and base address
>> alignment, though.
>>
>> Placement and base address alignment requirements can apply to all
>> possible texture layouts, while the concept of stride is specific to
>> linear layouts.
> 
> Also, the starting address of shareable buffers is generally aligned to
> at least the CPU page size anyway. Do we know of any cases requiring
> higher alignment than that, and if so, which address space does the
> requirement apply to?

Only tiling modes, as Marek mentioned. We don't do tiling shares across 
different GPUs right now.

Maybe we can do it in the future with gfx9 GPUs. But then the alignment 
requirements should be known on both sides based on the tiling mode 
anyway -- if they even apply for non-VRAM textures.


>>> Given that, I'm fairly inclined to punt those until we have the grand
>>> glorious allocator, rather than trying to add it to EGL/GBM
>>> separately. The modifiers stuff was a fairly obvious augmentation -
>>> EGL already had no-modifier format import but no query as to which
>>> formats it would accept, and modifiers are a logical extension of
>>> format - but adding the other restrictions is a bigger step forward.
>>
>> Perhaps a third option would be to encode the required pitch_in_bytes
>> alignment as part of the modifier?
>>
>> So DRI3GetSupportedModifiers would return DRM_FORMAT_MOD_LINEAR_256B
>> when the display GPU is a Raven Ridge.
>>
>> More generally, we could say that fourcc_mod_code(NONE, k) means that
>> the pitch_in_bytes has to be a multiple of 2**k for e.g. k <= 31. Or if
>> you prefer, we could have a stride requirement in elements or pixels
>> instead of bytes.
> 
> Interesting idea. FWIW, I suspect we'd need to support specifying the
> requirement in both bytes or pixels, since one or the other alone may
> not be sufficient to describe the constraints of all hardware.

 From what I've seen, modifiers are always specified together with one 
specific format, so the bytes-per-pixel are always known, so I don't 
think we need both. Specifying it in bytes is a bit more natural for our 
hardware, that's all.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.