Am 04.08.20 um 03:42 schrieb Dave Airlie:
On Fri, 31 Jul 2020 at 23:32, Christian König <christian.koenig@xxxxxxx> wrote:
Am 31.07.20 um 06:05 schrieb Dave Airlie:
From: Dave Airlie <airlied@xxxxxxxxxx>
This makes it easier to move these to a driver allocated system
No, sorry that looks like going into the wrong direction to me.
I already wanted to suggest to get rid of the size argument instead.
I'm not sure how it should look then, I don't want the driver poking
around inside the range manager code, the range manager should be a
generic object that driver inits and leaves alone,
I definitely don't want the driver to be poking caching and size
values into the man objects for it, since it isn't a driver object.
Do you have some other view on how the generic range manager should work?
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.
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.
Regards,
Christian.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
