On 29 January 2016 at 03:44, Michel Dänzer <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
