Am 06.08.20 um 05:46 schrieb Dave Airlie:
That was not what I was talking about. Take a look at what those fields are used for :)
As far as I see the only usage of the size is in ttm_resource_manager_debug(). But this size is actually totally opaque to TTM, it could be pages, bytes, fried chicken wings or whatever. In other words it would be much better to print it in the debug callback of each resource manager.
Size is a bit trickier as the drivers use in a couple of funky places, radeon pokes inside the range manager and adjust its size post init, and amdgpu uses size to validate a bunch of bo sizing. These shouldn't be too messy to workaround.
Yeah, I already wanted o clean that up in radeon for years now :)
Amdgpu should be easy to fix, most likely we just don't store the gtt size anywhere else.
But yes, those are TTM internals which drivers should not touch.
The available_caching is completely superfluous as well. The original idea what that a driver could specify multiple placements as flags in one entry, but no driver ever used that as far as I know and it became completely deprecated in 2014 when I moved the lpfn and fpfn into each place.
The default_caching is used in ttm_bo_select_caching(), but this is complete utterly nonsense. It just results in multiple possible cache behaviors being selected, which are then fortunately ignored by ttm_tt_set_placement_caching :)
To be honest I think just removing those parameters and the associated caching flags all together is the next logical step.
Definitely something to burn down alright.
IIRC we have a bit of dead AGP code in radeon which still tries to use this.
Nouveau might have something as well, going to take a look now.
But in general I think that drivers should just say I want caching X for this BO instead of TTM making an educated guess based on some flags set in different places.
Christian.
Dave.