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

Daniel Stone daniel at fooishbar.org
Fri Jan 29 04:36:32 PST 2016


On 29 January 2016 at 03:44, Michel Dänzer <michel at daenzer.net> wrote:
> It still sounds like significant work (particularly for somebody like me
> who isn't very familiar with Wayland details yet). It should be done by
> somebody who cares about the difference you're describing. I think it's
> unreasonable to expect myself or Axel to do it, especially since you
> said on IRC:
>
>  08:35 #dri-devel: < daniels> mannerov: it makes the flag totally
>                    meaningless - s/SCANOUT/NOT_A_FBO/ and i'll ack it
>
> Which makes little sense to me — even if the SCANOUT flags aren't used
> optimally yet, their meaning is quite clear.

It's nothing to do with Wayland really.

The core problem is that:
a) buffer allocation is incompletely described over the wire (AFAICT,
tiling is enabled for that buffer, but the combination of RGB format +
0 modifier implies a purely linear format),
which prevents an exacerbating problem from being properly fixed:
b) the Gallium gbm implementation does not reject tiled buffers when
importing to a display which cannot show tiled buffers
and you are proposing a hack:
c) pessimise all winsys allocations to the lowest common denominator:
avoiding tiling by mandating they be scanout-compatible

It works I guess, but until a and b are fixed, performance is going to
be suboptimal - again, if there was no performance impact to these
allocations, then they would always just happen by default.

Merging the hack makes it impossible for non-Gallium drivers to have a
and b correct (I'm not sure off the top of my head whether they are
correct or whether we just get lucky on allocations), because as soon
as those are fixed, we can't remove the scanout flag without breaking
Gallium until it also fixes those two. And it seems like that's
exceedingly unlikely to happen, so all of Mesa gets reduced
performance.

Cheers,
Daniel


More information about the mesa-dev mailing list