On Jul 8, 2017 1:59 PM, "Christian König" <deathsim...@vodafone.de> wrote:
Am 08.07.2017 um 00:27 schrieb Marek Olšák: > On Fri, Jul 7, 2017 at 9:37 PM, Dave Airlie <airl...@gmail.com> wrote: > >> On 8 July 2017 at 04:07, Christian König <deathsim...@vodafone.de> wrote: >> >>> Am 07.07.2017 um 18:51 schrieb Marek Olšák: >>> >>>> On Fri, Jul 7, 2017 at 11:18 AM, Christian König >>>> <deathsim...@vodafone.de> wrote: >>>> >>>>> What tilling format have the destination textures? >>>>> >>>>> Sounds like the offset is just added so that we distribute memory >>>>> accesses >>>>> more equally over memory channels. >>>>> >>>> You can't set an offset that is not aligned. The hardware ignores the >>>> low unaligned bits, so they have a different meaning. They specify >>>> pipe and bank rotation for macro tiling. It's like a state. It >>>> basically rotates the tile pattern. >>>> >>> >>> Yeah, I know. That's what I meant with distributing memory accesses more >>> equally over all channels. The lower bits select a memory bank swizzle >>> IIRC. >>> >>> I've tried years ago with R600 if shuffling them randomly could improve >>> performance, but MRT wasn't widely used and/or supported at that time. >>> >> I'd known this and forgotten, the public CIK docs say bits 0..7 must be >> zero, >> but I have older docs which had more info. It would be nice if we could >> get >> proper docs released for the bottom bits considering AMD are using them >> in their >> drivers. >> > I'm pretty sure AMD released that stuff years ago because I knew of it before starting to work for AMD. I think it was first released as addrlib source code. Some people might have had access to docs under NDA, but it wasn't known publicly. I didn't know it when I started at AMD. Marek The low 8 bits of the address are unused and can't be set, because > CB_COLOR0_BASE is shifted by 8 bits. We are really talking about bits > starting from 8 going higher. E.g. 8K alignment gives you 5 bits that > can be used to express the rotation. > > It would be good to know what registers have the bits that matter (i.e. >> BASE, >> FMASK, CMASK, DCC, and resource descriptors.) >> > The feature to select the memory pipe/bank to start with is implemented in the MC. So AFAIK all blocks are programmed the same way regarding this. E.g. you can use it for UVD/VCE as well. >> Then I suppose we'd need to know the algorithm for programming them, and >> if we need to make any allocations bigger in order to do so. >> > As far as I understand it you don't need to make anything bigger. Addrlib makes sure anyway that all pipe/banks are covered by a texture allocation as soon as you select some tilling mode (linear is obviously an exception). Regards, Christian. I expect this only starts to matter when we hit memory bandwidth limits, >> the deferred demo does 3 MRT, one depth at 2kx2k then samples from those >> down to 1280x720 displayed. This combined with a 3 instanced 57k vertex >> draw seemed to be enough to see the pain. (Maybe a GL example doing >> something >> similiar might show the problem for radeonsi). >> > Addrlib contains the encoding code for the base address pipe/bank bits. > > The other open question I have, is does this just matter for MRT or does >> texture >> sampling also get some boost from it, my hack patch does it for only >> surfaces which >> will end up attached to the CB. >> > Yes, it should be done for read-only textures too. > > I'll update the patch to not call it an offset but name them the tile >> rotation bits. >> > The proper name is "tile swizzle" or "pipe/bank swizzle". On gfx9, > it's called "pipe/bank xor". > > Marek >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
