In the past, we tracked bo->tiling_mode and bo->stride, and used
GEM_{GET,SET}_TILING on all buffers we allocated. This made more sense
in the old days (long before iris even existed) when we used GTT maps to
detile resources. However, that support is now gone, and we never used
it in iris anyway. We don't need to do this in most cases anymore.
We are trying to deprecate these kernel APIs. They have many issues.
One is having a global tiling mode for a buffer when userspace may
want to suballocate multiple resources with different tiling modes
from the same object. Another is...what if processes want to interpret
the data differently, and hot-swap the tiling mode out from under
another process? Another is the fundamental race conditions. There
are many reasons not to use these APIs.
Unfortunately, there is still one case where it's used: when importing
and exporting DMABUFs, we have to communicate the tiling somehow. The
right way to do that is using modifiers, but those didn't always exist,
and aren't always enabled (maybe aren't even commonly enabled). So we
use GET/SET_TILING as a poor-man's IPC mechanism of sorts.
This patch stops calling those APIs in general but continues doing so
for imported/exported objects when we don't have modifiers.
We eliminate iris_bo_alloc_tiled entirely. There is now only one!
One small behavioral change snuck in: iris_memobj_create_from_handle
now aligns the virtual address to 64K rather than 1B when modifiers
aren't present. This should be harmless, and lets us delete a whole
bunch of code.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11169>
ab49063f44