On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie airlied@gmail.com wrote:
I can take a look at it, I just won't have time until next week most likely.
I've taken a look, and it's seemingly more complicated than I'm expecting I'd want to land in Mesa before 17.2 ships, I'd really prefer to just push the new libdrm_amdgpu api from this patch. If I have to port all the current radv code to the new API, I'll most definitely get something wrong.
Adding the new API so far looks like https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw
https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw... being the API, and whether it should take a uint32_t context id or context handle left as an open question in the last patch in the series.
However to hook this into radv or radeonsi will take a bit of rewriting of a lot of code that is probably a bit more fragile than I'd like for this sort of surgery at this point.
I'd actually suspect if we do want to proceed with this type of interface, we might be better doing it all in common mesa code, and maybe bypassing libdrm_amdgpu altogether, which I suppose the API I've written here is mostly already doing.
Well, we plan to stop using the BO list ioctl. The interface has bo_list_handle in it. Will we just set it to 0 when add the chunk for the inlined buffer list i.e. what radeon has?
Marek