Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Marek
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux