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.
