[PATCH 00/49] ttm mem manager refactoring.

Christian König christian.koenig at amd.com
Mon Aug 3 11:13:22 UTC 2020


Am 03.08.20 um 09:12 schrieb Dave Airlie:
> On Fri, 31 Jul 2020 at 19:17, Christian König <christian.koenig at amd.com> wrote:
>> Am 31.07.20 um 06:04 schrieb Dave Airlie:
>>> I started pulling on a thread, and it led me down a hole.
>> We might want to make that hole even bigger :)
>>
>> How about we rename the ttm_mem_reg into ttm_resource and
>> ttm_mem_type_manager into ttm_resource_manager.
>>
> https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~airlied%2Flinux%2Flog%2F%3Fh%3Dttm-refactor-mem-manager-rename&data=02%7C01%7Cchristian.koenig%40amd.com%7Cc1498ce352be4c56b30908d8377cae61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637320355926010223&sdata=qXhKP8gmv6QsJiS%2BPprtM%2BVn8uE1XAFbZC0DI00zol8%3D&reserved=0
>
> has the series with some stuff moved around but 3 added rename patches
> at the end.
>
> ttm_bo_manager -> ttm_range_manager
> ttm_mem_type_manager -> ttm_resource_manager
> ttm_mem_reg -> ttm_resource.
>
> The one slightly messy one is we have a lot of ttm_mem_reg *mem
> (*old_mem or *new_mem).
>   I didn't try and rename those, but I could probably do it if we
> decided it was really necessary.

I really want to reduce the usage of those in the long term from the 
driver anyway.

> I've got to go back and fold in some review comments from people yet
> and add r-bs I'll try and get to that tomorrow.

Feel free to add my Acked-by to the ones where I haven't given an 
explicit rb so for.

Going to prepare more cleanups on top of this series.

Christian.

>
> Dave.
>
>> Neither amdgpu's OA/GWS resources nor the IDs in VMGFX are really memory.
>>
>> In the long term I also want to move the whole address handling into
>> each backend.
>>
>> Going to send comments on the individual patches as well.
>>
>>> This series refactors the ttm ttm_mem_type_manager object into
>>> a driver owned, allocated, subclassaed object.
>>>
>>> It starts with two minor fixes for some bad assumptions in two drivers.
>>>
>>> Enables a new init path, ports all the drivers to the new init
>>> path, and cleans up the old init path.
>>> Enables a new takedown path, ports all the drivers to the new takedown
>>> path, and cleans up the old takedown path
>>> Wraps all access to the memory managers in the bo_device in a wrapper
>>> across all drivers.
>>> Make debug callback optional
>>> Enables driver to provide their own mem manager objects
>>> Subclasses the objects in all drivers and makes them into driver owned object
>>> Drops the bo_device arrays of pointers, and some unneeded links and
>>> struct members
>>> Cleans up one api.
>>>
>>> I think I'd probably want to merge all this via drm-misc, so if I can collect
>>> acks/r-b from driver maintainers that would be good.
>>>
>>> This is also based on Chrisitan's work to remove init_mem_type, so it won't
>>> apply until he's finished getting all of that into drm-misc.
>> Preparing to push that to drm-misc-next just now.
>>
>> Regards,
>> Christian.
>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~airlied%2Flinux%2Flog%2F%3Fh%3Dttm-refactor-mem-manager&data=02%7C01%7Cchristian.koenig%40amd.com%7Cc1498ce352be4c56b30908d8377cae61%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637320355926010223&sdata=zrVYgyObEI8auSZ4AS7dDO%2BJ6WHYMITmuDQ%2F0lCxt1I%3D&reserved=0
>>> is the tree I've built this on top off, so it's probably going to get rebased
>>> but the code should stay mostly the same.
>>>
>>> I've done some boot testing on nouveau, and I hope to test it on vmwgfx and
>>> amdgpu soon.
>>>
>>> Dave.
>>>
>>>



More information about the dri-devel mailing list