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 at 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&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? Combining your per process resources, we can have a try, I think. Regards, David Zhou > > Regards, > Christian. > >> >> David Zhou >>> >>> Christian. >>> >>>> Marek >>> >>> >>> _______________________________________________ >>> amd-gfx mailing list >>> amd-gfx at lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >
