[Mesa-dev] [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI
kenneth at whitecape.org
Wed Apr 28 15:16:05 UTC 2021
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> +Existing uAPI issues
> +Some potential issues we still need to resolve.
> +I915 MMAP
> +In i915 there are multiple ways to MMAP GEM object, including mapping the same
> +object using different mapping types(WC vs WB), i.e multiple active mmaps per
> +object. TTM expects one MMAP at most for the lifetime of the object. If it
> +turns out that we have to backpedal here, there might be some potential
> +userspace fallout.
> +I915 SET/GET CACHING
> +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but
> +DG1 doesn't support non-snooped pcie transactions, so we can just always
> +allocate as WB for smem-only buffers. If/when our hw gains support for
> +non-snooped pcie transactions then we must fix this mode at allocation time as
> +a new GEM extension.
> +This is related to the mmap problem, because in general (meaning, when we're
> +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with
> +allocation mode.
> +Possible idea is to let the kernel picks the mmap mode for userspace from the
> +following table:
> +smem-only: WB. Userspace does not need to call clflush.
> +smem+lmem: We allocate uncached memory, and give userspace a WC mapping
> +for when the buffer is in smem, and WC when it's in lmem. GPU does snooped
> +access, which is a bit inefficient.
I think you meant to write something different here. What I read was:
- If it's in SMEM, give them WC
- If it's in LMEM, give them WC
Presumably one of those should have been something else, since otherwise
you would have written "always WC" :)
> +lmem only: always WC
> +This means on discrete you only get a single mmap mode, all others must be
> +rejected. That's probably going to be a new default mode or something like
> + https://patchwork.freedesktop.org/series/86798/
> + https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the mesa-dev