On 31.01.2017 17:28, Christian König wrote:
Am 31.01.2017 um 14:06 schrieb Bas Nieuwenhuizen:
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.
Actually this is also useful without the special NACK handling. E.g.
when you sample from a texture part which isn't present you always get
zero and writes are ignored.
The TFE bit and the extra signaling to for special handling in shader
code are only optional if I'm not completely mistaken.
I think it's needed for ARB_sparse_texture2 / whatever the Vulkan
equivalent of that is. But yeah, I don't think ARB_sparse_texture needs
TFE support in LLVM.
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.
Not sure what concern Nicolai has about addrlib here. In general we
should know where the different parts of a texture start (LODs, layers
etc...) and as far as I can see that's all you need to know.
Well, you're right that it's probably possible to work with the open
addrlib already.
In particular, you need address info not just for layers and levels, but
also for blocks within each 2D image, to be able to compute
VIRTUAL_PAGE_SIZE_X/Y, and to map them to the corresponding addresses.
There are AddrComputeSurfaceAddrFromCoord and
AddrComputeSurfaceCoordFromAddr functions that can be tricked into
providing the necessary info.
It may be more natural with some additional functions that aren't open yet.
Also, you might possibly want different tilings for sparse textures, but
I don't think that's really needed for an initial implementation.
Cheers,
Nicolai
As far as an unit test being sufficient, I assume you mean as open
source user for inclusion into the kernel?
Yes.
I think that'd be a question
answered better by Dave.
Yeah, though so as well. Dave can you comment?
Thanks for the comments,
Christian.
Best regards,
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
