Re: PRT support for amdgpu

["Nicolai Hähnle" <nhaehnle-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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