[Mesa-dev] [PATCH] egl/wayland: Set __DRI_IMAGE_USE_SCANOUT for shared buffers

[Daniel Stone]

On 28 January 2016 at 03:21, Michel Dänzer <michel at daenzer.net> wrote:
> On 27.01.2016 23:54, Daniel Stone wrote:
>> On 27 January 2016 at 14:16, Axel Davy <axel.davy at ens.fr> wrote:
>>> On 27/01/2016 13:43, Daniel Stone wrote:
>>>> If the compositor wants to scan out directly, it will import via
>>>> GBM, which is in a position to reject the import if the buffer is
>>>> not suitable for scanout. So there's something missing here,
>>>> either in the GBM implementation to set magic flags when
>>>> importing, or failure to communicate tiling mode correctly, or
>>>> whatever.
>>>>
>>>> So for now, I would NAK this
>
> And you can NAK this because... ? :)

Well, why not just skip review and bang whatever you feel like into
egl/wayland then. Seems like that's the prevailing feeling anyway, or
at least the impression I get trying to solve problems correctly in
Mesa rather than bodging around everything.

>>> As long as the app has no way to know what the compositor wants
>>> (there was talks I remember on irc on ways to do that), I think
>>> enforcing scanout as default is sane.
>>
>> Again, negotiating scanout is something we can handle internally
>> through wl_drm without having to have a flag-day API change. If you
>> assume that scanout negates tiling, then every browser you launch is
>> going to be rendered to a non-tiled format. This has a non-trivial
>> impact on a lot of architectures, and is only really mostly kind of
>> fine on desktop architectures where you have the power to waste
>> anyway.
>
> You're saying there are architectures where tiling is essential for
> energy consumption, but the rendering and display hardware don't have
> any common tiling formats? The mind boggles.
>
> FWIW, on our hardware there's no such issue, scanout just requires
> special tiling modes.

No, 'special tiling modes' is what I meant. It is not at all uncommon
to have hardware which requires special tiling modes (for variants of
'special tiling modes' which include 'no tiling') which force a less
efficient render pass, or even a separate resolve pass, for scanout.
It follows that pessimising _all_ client rendering to account for this
special case is a bad idea. If there was no impact, then every buffer
would just be allocated as scanout, no? Else why is it a separate
flag?

By power, I mean performance (where memory bandwidth is approximately
infinite, and one resolve pass has zero impact on your overall
performance) as much as energy consumption.

>>> The other thing you mention, ie failing to import non-scanout
>>> buffers when scanout is requested is, I believe, unrelated to this
>>> patch, and would require a bit more work. In particular this is
>>> handled by a function validateUsage, which doesn't seem to be fully
>>> implemented on gallium. I suggest to file a bug on bugzillla.
>>
>> Well, I could, but if this fix goes in, I assume nothing will ever
>> happen for Gallium drivers, so not sure there's much point, aside
>> from having a URL to point to the next time this comes up.
>
> intel_validate_usage doesn't handle scanout either, but AFAIR at least
> older generations of Intel GPUs don't support all tiling modes for
> scanout either. So I don't see how that could work in the scheme you
> describe other than by luck.
>
> Assuming there was any validateUsage hook which would properly catch
> buffers which can't be scanned out, can you point us to other code which
> would allow the Wayland compositor to make sure clients allocate buffers
> which can be scanned out?

The code doesn't exist now, but essentially gbm_bo_import would be
able to track a wl_buffer back to the source, and send a wl_drm event
back to Mesa (remember that this is private protocol, so can be
changed at will) informing it that it should allocate with more
optimal flags. Not a great deal of work.

Anyway, it all comes down to what you want to optimise for; with
pretty much every web browser using GL-accelerated composition, that's
a _lot_ of performance/energy you're wasting by allocating every
client surface as scanout. The tradeoff is of course that you can
potentially use hardware overlays to display the content, but without
something like HWComposer you're probably negative on power using them
anyway.

Cheers,
Daniel