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

[Michel Dänzer]

On 26/07/17 09:15 PM, Nicolai Hähnle 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:
>>>>
>>>> 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.

The proposal adds two DRI3 extension requests for querying the list of
supported formats and modifiers, respectively. This suggests that the
supported formats and modifiers can be freely combined.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer