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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
