[PATCH 00/49] ttm mem manager refactoring.

[Christian König]

Am 31.07.20 um 11:29 schrieb daniel at ffwll.ch:
> On Fri, Jul 31, 2020 at 11:17:26AM +0200, Christian König 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.
> +1 on names I can understand, I alwas get confused about what exactly ttm
> means with mem_reg and mem_type_manager.

Well mem_type_manager was obvious, but to be honest I never figured out 
what _reg meant either :)

Christian.

> -Daniel
>
>> 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%7C7966b55d1dfd4ffd393908d835343faf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637317846121673630&sdata=mqjdwhu9o3LfYSa%2FgW3GDDv2AABddmIPMZiAXoaNv6M%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.
>>>
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C7966b55d1dfd4ffd393908d835343faf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637317846121673630&sdata=%2BiZVquH6tc7FwEubwDmqkU6PcwdsdCCzDm1leuwOIa4%3D&reserved=0