Re: [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

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

 



Hi Nanley,

thanks for the review.

+Ville, Chris.

On Tue, Dec 01, 2020 at 02:18:26AM +0200, Chery, Nanley G wrote:
> Hi Imre,
>  
> I have a question and a couple comments:
> 
> Is the map of the clear color address creating a new synchronization
> point between the GPU and CPU? If so, I wonder how this will impact
> performance.

The kmap to read the clear value is not adding any sync overhead if
that's what you mean. But the clear value must be in place before we
read it out and that should be guaranteed by the flush we do anyway to wait
for the render result (even considering the explicit L3/RT flush, depth
stall the spec requires for fast clears).

However now that you mention: atm the kmap/readout happens after the
explicit but before the implicit fence-wait. I think it should happen
after the implicit fence-wait.

Ville, Chris, could you confirm the above and also that the above flush
is enough to ensure the CPU read is coherent?

> There was some talk of asynchronously updating the clear color
> register a while back. 

Couldn't find anything with a quick search, do you have a pointer? Just
before the flip we must wait for the render results anyway, as we do
now, so not sure how it could be optimized.

> We probably don't have to update the header, but we noticed in our
> testing that the clear color prefers an alignment greater than 64B.
> Unfortunately, I can't find any bspec note about this. As long as the
> buffer creators are aware though, I think we should be fine. I don't
> know if this is the best forum to bring it up, but I thought I'd
> share.

Yes, would be good to clarify this and get it also to the spec. Then the
driver should also check the alignment of the 3rd FB plane.

> Seems like the upper converted clear color is untested due to the lack
> of RGBX16 support. I suppose that if there are any issues there, they
> can be fixed later...

Yes, a 64bpp RC-CC subtest in IGT is missing, should be easy to add
that.

--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

  Powered by Linux