On Mon, Aug 17, 2020 at 02:23:47AM -0400, Marek Olšák wrote: > On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > > On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote: > > > There are a few cases when the flags can change, for example DCC can be > > > disabled due to a hw limitation in the 3d engine. Modifiers give the > > > misleading impression that they help with that, but they don't. They > > don't > > > really help with anything. > > > > But if that happens, how do you tell the other side that it needs to > > sample new flags? Does that just happen all the time? > > > > Also do the DDC state changes happen for shared buffers too? > > > > I thought we were only talking about shared buffers. > > If the other side is only a consumer and the producer must disable DCC, the > producer decompresses DCC and then disables it and updates the BO flags. > The consumer doesn't need the new flags, because even if DCC stays enabled > in the consumer, it's in a decompressed state (it has no effect). Only the > producer knows it's disabled, and any new consumer will also know it when > it queries the latest BO flags. > > It doesn't work if both sides use writes, because it's not communicated > that DCC is disabled (BO flags are queried only once). This hasn't been a > problem so far. > > Is there a way to disable DCC correctly and safely across processes? Yes. > So why don't we do it? Because it would add more GPU overhead. Yeah but in this case you can get away with just sampling the bo flags once (which is what you're doing), so doing that at addfb time should be perfectly fine. Ofc you might waste a bit of $something also scanning out the compression metadata (which tells the hw that it's all uncompressed), but that doesn't seem to be a problem for you. So treating the legacy bo flags as invariant for shared buffers should be perfectly fine. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
