PRT support for amdgpu

[Christian König]

Am 02.02.2017 um 10:33 schrieb 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.

Thanks, that would be great. I'm going to send out my latest bug fixes 
for the kernel side in a few minutes.

>
>
>> 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?

Alex did that internally just last week, but nobody volunteered to take 
care of pushing it.

Basically everybody is just to busy to look into it.

Regards,
Christian.

>
> Nicolai