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

[Alex Deucher]

On Wed, Jul 26, 2017 at 8:15 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> 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.

We should be able to do some 1D tiling modes.  That doesn't have any
per sku alignment dependencies.

Alex

>
>
>>>> 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.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev