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.
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%7Caa32512acf9f4bf455ef08d83506f9d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637317651361302583&sdata=2sQt4A48ODl0Nq4P21YG3vRNdhkDZcZp0XHkQ930SAI%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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
