PRT support for amdgpu

[Nicolai Hähnle]

On 02.02.2017 10:29, Bas Nieuwenhuizen wrote:
> On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote:
>> On 02.02.2017 02:49, Dave Airlie wrote:
>>> I think we would require a fully open source user for this sort of thing,
>>> there are way to many corner cases for us to fall down here, prematurely
>>> pushing the API without a proven test suite running on it would be bad.
>>>
>>> We'd want to get radeonsi or radv up and running and have a complete
>>> run of the conformance suite to make sure the kernel API was sane,
>>> design is good, proving the design is the hard bit.
>>
>> I think we can start with just GL_ARB_sparse_buffer. That extension
>> isn't as useful in comparison, but it exercises all the memory
>> management bits without having to worry about texture layout
>> considerations, and doing that one first seems like a reasonable
>> development strategy anyway.
>
> Yeah, I noticed that vulkan had a similar extension that can be done
> pretty easily, trying to get that done before the weekend.

That would be cool. I thought of doing this for radeonsi, but I 
seriously doubt that I'll get to it any time soon.


> What would be a plan for upstreaming all this? In an earlier case (the
> wait on multiple fences ioctl), AFAIU the problem for upstreaming was
> that there was no open-source user.  However I then wrote a branch
> (which is probably outdated by now ...), but would like to wait with
> upstreaming it till I know which libdrm and kernel driver version to use
> for the feature tests. As a result all three the parts (kernel, libdrm,
> radv) haven't been upstreamed yet. How can we avoid having the same
> problem with this feature?

Once all the parts are there, the sequence should be upstream kernel, 
upstream libdrm, upstream radv.

Maybe you can ping the corresponding threads or re-send the patches for 
review?

Nicolai