MRT rendering speed up from the pro driver

[Dave Airlie]

On 7 July 2017 at 14:25, Dave Airlie <airlied at gmail.com> wrote:
> Hi,
>
> Hopefully someone in here can help with this, and maybe ask the
> internal Vulkan team how this works.
>
> I've been looking into a large perf cliff in radv vs pro when MRT
> rendering is enabled (I didn't know that
> was what I was looking for until today - about 2-3 weeks ago I was
> just digging around).
>
> I looked at some traces from pro and finally spotted that it realigns
> the non-zero MRT color bases and
> dcc bases on 0x3800 (14336) multiples on my rx480 gpu, if I hack radv
> to do the same I get the same
> MRT speedups.
>
> I think radeonsi should look into doing the same sort of alignments,
> it might be easier there.
>
> Now with vulkan changing the base address of the image after
> allocation and image view creation
> seems to be fraught with dangerous corner cases. Vulkan is pretty
> explicit, and I've no idea
> what would happen if you rendered to a target as MRT2 then later
> decided to render to same target
> as MRT1. I've no idea how we can propogate the MRT offset we find out
> about at vkCreateFramebuffer
> time into texture descriptors that we store in image views, (short of
> keeping a long list of every image
> view that was ever created for the image and propogating the change
> across all of them), and how would
> that work if two threads did vkCreateFramebufer on the same image one
> for MRT1 and one for MRT2,

Glenn pointed out on irc a method to do this bit, so I'm playing with a patch
now.

Dave.