Documentation/gpu/rfc/i915_gem_lmem.rst

   1 =========================
   2 I915 DG1/LMEM RFC Section
   3 =========================
   4
   5 Upstream plan
   6 =============
   7 For upstream the overall plan for landing all the DG1 stuff and turning it for
   8 real, with all the uAPI bits is:
   9
  10 * Merge basic HW enabling of DG1(still without pciid)
  11 * Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag
  12         * At this point we can still make changes, but importantly this lets us
  13           start running IGTs which can utilize local-memory in CI
  14 * Convert over to TTM, make sure it all keeps working. Some of the work items:
  15         * TTM shrinker for discrete
  16         * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock
  17         * Use TTM CPU pagefault handler
  18         * Route shmem backend over to TTM SYSTEM for discrete
  19         * TTM purgeable object support
  20         * Move i915 buddy allocator over to TTM
  21         * MMAP ioctl mode(see `I915 MMAP`_)
  22         * SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
  23 * Send RFC(with mesa-dev on cc) for final sign off on the uAPI
  24 * 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