PRT support for amdgpu
bas at basnieuwenhuizen.nl
Thu Feb 2 09:29:03 UTC 2017
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 :/
More information about the amd-gfx