On Mon, Jan 30, 2017, at 13:57, Christian König wrote: > Hi Dave and Bas, > > Hi Dave and Bas, > > the following set of patches is a proposal for adding support for partial > resident textures (PRT) to the amdgpu kernel module. > > The basic idea behind PRT support is that you turn of VM fault reporting > and only map parts of a texture into your virtual address space. If we add some backing to a range, do we need to unmap the PRT range, split and map two PRt ranges? Or will this be handled like mmap and a new map just overrides the earlier maps for that range? > > When a shader now tries to sample from a not present page it gets a > notification instead of a VM fault and can react gracefully by switch to > a different LOD for example. So to confirm this is just using texture instruction with the TFE bit enabled, no trap handlers or such? > > On our current available hardware generation you can unfortunately only > turn of VM faults globally, but on future generation you can do this on a > per page basis. So my proposal is to have a consistent interface over all > generations with a per mapping PRT flag, but enable/disable it globally > on current hardware when the first/last mapping is made/destroyed. > > An open problem with the proposal is that we don't know when or if we > want to add the userspace implementation into radeonsi. > > So price question could you guys use this for radv as well? Or is it > sufficient to just write an unit test for it? So this API seems usable, and I think this is something we can use for radv. However, I'm not sure how much time it takes for us to implement, as the TFE variants are not in LLVM yet and I haven't figured out what values the NACKs get. Furthermore, if addrlib is missing stuff like Nicolai suggests then that could result in complications. I can try if I can get something working over the weekend, but no promises. As far as an unit test being sufficient, I assume you mean as open source user for inclusion into the kernel? I think that'd be a question answered better by Dave. > > Best regards, > Christian. > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
