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

Michel Dänzer michel at daenzer.net
Sun Jan 31 19:48:52 PST 2016


On 29.01.2016 21:36, Daniel Stone wrote:
> 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),

What does "the wire" refer to here, if not the Wayland protocol?


> 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

scanout-compatible doesn't imply no tiling, but other than that, sounds
about right.


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

So, which driver(s) in Mesa right now would be affected by this, and how?


> 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),

As I said before, looking at intel_validate_usage, I suspect the latter.


> 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, [...]

Why is that? I wouldn't mind looking into fixing the Gallium specific parts.


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


More information about the mesa-dev mailing list