MRT rendering speed up from the pro driver

[Dave Airlie]

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,

Anyways just thought I'd share the results of the investigating and
hope someone can fill me in on
how to calculate 0x3800 and how we might do this cleanly in radv.

Dave.