@@ -18,114 +18,5 @@ real, with all the uAPI bits is:
1818 * Route shmem backend over to TTM SYSTEM for discrete
1919 * TTM purgeable object support
2020 * Move i915 buddy allocator over to TTM
21- * MMAP ioctl mode(see `I915 MMAP `_)
22- * SET/GET ioctl caching(see `I915 SET/GET CACHING `_)
2321* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
2422* Add pciid for DG1 and turn on uAPI for real
25-
26- New object placement and region query uAPI
27- ==========================================
28- Starting from DG1 we need to give userspace the ability to allocate buffers from
29- device local-memory. Currently the driver supports gem_create, which can place
30- buffers in system memory via shmem, and the usual assortment of other
31- interfaces, like dumb buffers and userptr.
32-
33- To support this new capability, while also providing a uAPI which will work
34- beyond just DG1, we propose to offer three new bits of uAPI:
35-
36- DRM_I915_QUERY_MEMORY_REGIONS
37- -----------------------------
38- New query ID which allows userspace to discover the list of supported memory
39- regions(like system-memory and local-memory) for a given device. We identify
40- each region with a class and instance pair, which should be unique. The class
41- here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
42- like DG1.
43-
44- Side note: The class/instance design is borrowed from our existing engine uAPI,
45- where we describe every physical engine in terms of its class, and the
46- particular instance, since we can have more than one per class.
47-
48- In the future we also want to expose more information which can further
49- describe the capabilities of a region.
50-
51- .. kernel-doc :: include/uapi/drm/i915_drm.h
52- :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions
53-
54- GEM_CREATE_EXT
55- --------------
56- New ioctl which is basically just gem_create but now allows userspace to provide
57- a chain of possible extensions. Note that if we don't provide any extensions and
58- set flags=0 then we get the exact same behaviour as gem_create.
59-
60- Side note: We also need to support PXP[1] in the near future, which is also
61- applicable to integrated platforms, and adds its own gem_create_ext extension,
62- which basically lets userspace mark a buffer as "protected".
63-
64- .. kernel-doc :: include/uapi/drm/i915_drm.h
65- :functions: drm_i915_gem_create_ext
66-
67- I915_GEM_CREATE_EXT_MEMORY_REGIONS
68- ----------------------------------
69- Implemented as an extension for gem_create_ext, we would now allow userspace to
70- optionally provide an immutable list of preferred placements at creation time,
71- in priority order, for a given buffer object. For the placements we expect
72- them each to use the class/instance encoding, as per the output of the regions
73- query. Having the list in priority order will be useful in the future when
74- placing an object, say during eviction.
75-
76- .. kernel-doc :: include/uapi/drm/i915_drm.h
77- :functions: drm_i915_gem_create_ext_memory_regions
78-
79- One fair criticism here is that this seems a little over-engineered[2]. If we
80- just consider DG1 then yes, a simple gem_create.flags or something is totally
81- all that's needed to tell the kernel to allocate the buffer in local-memory or
82- whatever. However looking to the future we need uAPI which can also support
83- upcoming Xe HP multi-tile architecture in a sane way, where there can be
84- multiple local-memory instances for a given device, and so using both class and
85- instance in our uAPI to describe regions is desirable, although specifically
86- for DG1 it's uninteresting, since we only have a single local-memory instance.
87-
88- Existing uAPI issues
89- ====================
90- Some potential issues we still need to resolve.
91-
92- I915 MMAP
93- ---------
94- In i915 there are multiple ways to MMAP GEM object, including mapping the same
95- object using different mapping types(WC vs WB), i.e multiple active mmaps per
96- object. TTM expects one MMAP at most for the lifetime of the object. If it
97- turns out that we have to backpedal here, there might be some potential
98- userspace fallout.
99-
100- I915 SET/GET CACHING
101- --------------------
102- In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but
103- DG1 doesn't support non-snooped pcie transactions, so we can just always
104- allocate as WB for smem-only buffers. If/when our hw gains support for
105- non-snooped pcie transactions then we must fix this mode at allocation time as
106- a new GEM extension.
107-
108- This is related to the mmap problem, because in general (meaning, when we're
109- not running on intel cpus) the cpu mmap must not, ever, be inconsistent with
110- allocation mode.
111-
112- Possible idea is to let the kernel picks the mmap mode for userspace from the
113- following table:
114-
115- smem-only: WB. Userspace does not need to call clflush.
116-
117- smem+lmem: We only ever allow a single mode, so simply allocate this as uncached
118- memory, and always give userspace a WC mapping. GPU still does snooped access
119- here(assuming we can't turn it off like on DG1), which is a bit inefficient.
120-
121- lmem only: always WC
122-
123- This means on discrete you only get a single mmap mode, all others must be
124- rejected. That's probably going to be a new default mode or something like
125- that.
126-
127- Links
128- =====
129- [1] https://patchwork.freedesktop.org/series/86798/
130-
131- [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791
0 commit comments