PRT support for amdgpu

[Bas Nieuwenhuizen]

On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote:
> [ ceterum censeo, + John for addrlib :P ]
> 
> On 02.02.2017 02:49, Dave Airlie wrote:
> >>> answered better by Dave.
> >>
> >>
> >> Yeah, though so as well. Dave can you comment?
> >
> > 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.

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?

> 
> 
> > And uggh on addrlib, just stick the whole thing on github already.
> 
> I wish :/
> 
> Nicolai