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

[Nicolai Hähnle]

On 22.07.2017 14:00, Daniel Stone wrote:
> On 21 July 2017 at 18:32, Michel Dänzer <michel at daenzer.net> wrote:
>> On 20/07/17 01:08 PM, Daniel Stone wrote:
>>> DRI3 version 1.1 adds support for explicit format modifiers, including
>>> multi-planar buffers.
>>
>> Adding mesa-dev, Nicolai and Marek.
>>
>> We just ran into an issue which might mean that there's still something
>> missing in this v2 proposal:
>>
>> The context is DRI3 PRIME render offloading of glxgears (not useful in
>> practice, but bear with me). The display GPU is Raven Ridge, which requires
>> that the stride even of linear textures is a multiple of 256 bytes. The
>> renderer GPU is Polaris12, which still supports smaller alignment of the
>> stride. With the glxgears window of width 300, the renderer GPU driver
>> chooses a stride of 304 (* 4 / 256 = 4.75), whereas the display GPU would
>> require 320 (* 4 / 256 = 5). This cannot work.
> 
> The obvious answer is just to increase padding on external/winsys
> surfaces? Increasing it for all allocations would probably be a
> non-starter, but winsys surfaces are rare enough that you could
> probably afford to take the hit, I guess.
> 
>> I see two basic approaches to solve this:
>>
>> 1. A protocol request for the client to retrieve the display
>>     GPU constraints on the stride (and possibly other parameters) for a
>>     given format and modifier.
> 
> + corresponding new EGL request and new GBM/KMS API :\
> 
>> 2. A protocol request which allows the creation of a pixmap with
>>     given format and modifier. The renderer GPU driver needs to pass in
>>     the stride it would choose, then the display GPU driver can choose a
>>     stride satisfying the constraints on both sides.
> 
> Heh, that sounds familiar - DRI2!
> 
>> Maybe there are other possible approaches I'm missing? Other comments?
> 
> 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.


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

Cheers,
Nicolai




> 
> Cheers,
> Daniel
> 


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