On Mon, Feb 01, 2016 at 12:48:52PM +0900, Michel Dänzer wrote: > On 29.01.2016 21:36, Daniel Stone wrote: > > On 29 January 2016 at 03:44, Michel Dänzer <mic...@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?
It's all in-flight and massive amounts of work across the entire stack, but i965 is gaining support for render compression and fancy new tiling formats. And we really don't want to fall back to the lowest common denominator scanout format which is guaranteed to always work. Of course there's more work for that, but slightly annoying when we first have to undo/paper around a quick hack. > > 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. Just jumping in here, but it's correct atm. Well if we ignore a recent bug to enable Y-tiling where mesa shouldn't. Currently Intel solves the above problem by being careful in the selection of what's possible for winsys buffers, to make sure that the other side is guaranteed to be able to use it. Having read the thread I think fixing up the validation part on the compositor side would be the correct fix short term for this. That will keep all options open for the future to optimize this however we want, without the need for flag days across all mesa drivers. And yes, adding required additional metadata to the wayland drm proto will be a bit of work, since to make it all work we'd also need to add import support for that to gbm. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
