On 18/07/17 09:55 PM, zhoucm1 wrote:
On 2017年07月18日 21:57, Christian König wrote:
Am 18.07.2017 um 04:29 schrieb zhoucm1:
On 2017年07月18日 01:35, Christian König wrote:
Am 17.07.2017 um 19:22 schrieb Marek Olšák:
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie <airlied@xxxxxxxxx>
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&id=e7f85d0ca617fa41e72624780c9035df132e23c4
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?
Yeah, exactly that was my thinking as well.
Just one thought, Could we remove and not use bo list at all?
Instead, we expose api like amdgpu_bo_make_resident with proper
privilege to user mode? That way, we will obviously short CS ioctl.
Not really, but I'm working on per process resources now. E.g. you
specify a flag that a resource is always bound to the process and
always used instead of specifying it every time.
The tricky part is that you then can't export that resource to other
processes, so it only works for buffers/textures which aren't
exchanged with anybody.
Yeah, Making bo resident obviously doesn't work for imported/foreign
BOs, but imported BOs are always pinned when exported to others, aren't
they?
Only while being shared between different GPUs, not between different
processes on the same GPU (e.g. DRI3). We'll still need to use some kind
of BO list for that case.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
