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
