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
