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.
