* [PATCH 1/4] drm/doc/rfc: Remove i915_gem_lmem.rst
2026-04-20 8:33 [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Maarten Lankhorst
@ 2026-04-20 8:33 ` Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 2/4] drm/doc/rfc: Remove i915_vm_bind Maarten Lankhorst
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Maarten Lankhorst @ 2026-04-20 8:33 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Maarten Lankhorst
The doc talks about DG1, but we do already support DG2 in i915, and
a new driver was created specifically to handle all lmem cases
even better.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 22 ----------------------
Documentation/gpu/rfc/index.rst | 6 +-----
2 files changed, 1 insertion(+), 27 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst
deleted file mode 100644
index b421a3c1806ec..0000000000000
--- a/Documentation/gpu/rfc/i915_gem_lmem.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-=========================
-I915 DG1/LMEM RFC Section
-=========================
-
-Upstream plan
-=============
-For upstream the overall plan for landing all the DG1 stuff and turning it for
-real, with all the uAPI bits is:
-
-* Merge basic HW enabling of DG1(still without pciid)
-* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag
- * At this point we can still make changes, but importantly this lets us
- start running IGTs which can utilize local-memory in CI
-* Convert over to TTM, make sure it all keeps working. Some of the work items:
- * TTM shrinker for discrete
- * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock
- * Use TTM CPU pagefault handler
- * Route shmem backend over to TTM SYSTEM for discrete
- * TTM purgeable object support
- * Move i915 buddy allocator over to TTM
-* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
-* Add pciid for DG1 and turn on uAPI for real
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index ef19b0ba2a3ea..8313194af0683 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,10 +20,6 @@ host such documentation:
gpusvm.rst
-.. toctree::
-
- i915_gem_lmem.rst
-
.. toctree::
i915_scheduler.rst
@@ -37,4 +33,4 @@ host such documentation:
i915_vm_bind.rst
.. toctree::
- color_pipeline.rst
\ No newline at end of file
+ color_pipeline.rst
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 2/4] drm/doc/rfc: Remove i915_vm_bind.
2026-04-20 8:33 [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 1/4] drm/doc/rfc: Remove i915_gem_lmem.rst Maarten Lankhorst
@ 2026-04-20 8:33 ` Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 3/4] drm/doc/rfc: Remove i915_small_bar rfc Maarten Lankhorst
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Maarten Lankhorst @ 2026-04-20 8:33 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Maarten Lankhorst
i915 supports soft pinning, and the xe driver
has been created to properly support VM_BIND instead.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
Documentation/gpu/rfc/i915_vm_bind.h | 290 -------------------------
Documentation/gpu/rfc/i915_vm_bind.rst | 245 ---------------------
Documentation/gpu/rfc/index.rst | 4 -
3 files changed, 539 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h
deleted file mode 100644
index bc26dc1261041..0000000000000
--- a/Documentation/gpu/rfc/i915_vm_bind.h
+++ /dev/null
@@ -1,290 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2022 Intel Corporation
- */
-
-/**
- * DOC: I915_PARAM_VM_BIND_VERSION
- *
- * VM_BIND feature version supported.
- * See typedef drm_i915_getparam_t param.
- *
- * Specifies the VM_BIND feature version supported.
- * The following versions of VM_BIND have been defined:
- *
- * 0: No VM_BIND support.
- *
- * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
- * previously with VM_BIND, the ioctl will not support unbinding multiple
- * mappings or splitting them. Similarly, VM_BIND calls will not replace
- * any existing mappings.
- *
- * 2: The restrictions on unbinding partial or multiple mappings is
- * lifted, Similarly, binding will replace any mappings in the given range.
- *
- * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
- */
-#define I915_PARAM_VM_BIND_VERSION 57
-
-/**
- * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
- *
- * Flag to opt-in for VM_BIND mode of binding during VM creation.
- * See struct drm_i915_gem_vm_control flags.
- *
- * The older execbuf2 ioctl will not support VM_BIND mode of operation.
- * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
- * execlist (See struct drm_i915_gem_execbuffer3 for more details).
- */
-#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
-
-/* VM_BIND related ioctls */
-#define DRM_I915_GEM_VM_BIND 0x3d
-#define DRM_I915_GEM_VM_UNBIND 0x3e
-#define DRM_I915_GEM_EXECBUFFER3 0x3f
-
-#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
-#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
-#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
-
-/**
- * struct drm_i915_gem_timeline_fence - An input or output timeline fence.
- *
- * The operation will wait for input fence to signal.
- *
- * The returned output fence will be signaled after the completion of the
- * operation.
- */
-struct drm_i915_gem_timeline_fence {
- /** @handle: User's handle for a drm_syncobj to wait on or signal. */
- __u32 handle;
-
- /**
- * @flags: Supported flags are:
- *
- * I915_TIMELINE_FENCE_WAIT:
- * Wait for the input fence before the operation.
- *
- * I915_TIMELINE_FENCE_SIGNAL:
- * Return operation completion fence as output.
- */
- __u32 flags;
-#define I915_TIMELINE_FENCE_WAIT (1 << 0)
-#define I915_TIMELINE_FENCE_SIGNAL (1 << 1)
-#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 1))
-
- /**
- * @value: A point in the timeline.
- * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
- * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
- * binary one.
- */
- __u64 value;
-};
-
-/**
- * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
- *
- * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
- * virtual address (VA) range to the section of an object that should be bound
- * in the device page table of the specified address space (VM).
- * The VA range specified must be unique (ie., not currently bound) and can
- * be mapped to whole object or a section of the object (partial binding).
- * Multiple VA mappings can be created to the same section of the object
- * (aliasing).
- *
- * The @start, @offset and @length must be 4K page aligned. However the DG2 has
- * 64K page size for device local memory and has compact page table. On that
- * platform, for binding device local-memory objects, the @start, @offset and
- * @length must be 64K aligned. Also, UMDs should not mix the local memory 64K
- * page and the system memory 4K page bindings in the same 2M range.
- *
- * Error code -EINVAL will be returned if @start, @offset and @length are not
- * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code
- * -ENOSPC will be returned if the VA range specified can't be reserved.
- *
- * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered. Furthermore, parts of the VM_BIND operation can be done
- * asynchronously, if valid @fence is specified.
- */
-struct drm_i915_gem_vm_bind {
- /** @vm_id: VM (address space) id to bind */
- __u32 vm_id;
-
- /** @handle: Object handle */
- __u32 handle;
-
- /** @start: Virtual Address start to bind */
- __u64 start;
-
- /** @offset: Offset in object to bind */
- __u64 offset;
-
- /** @length: Length of mapping to bind */
- __u64 length;
-
- /**
- * @flags: Supported flags are:
- *
- * I915_GEM_VM_BIND_CAPTURE:
- * Capture this mapping in the dump upon GPU error.
- *
- * Note that @fence carries its own flags.
- */
- __u64 flags;
-#define I915_GEM_VM_BIND_CAPTURE (1 << 0)
-
- /**
- * @fence: Timeline fence for bind completion signaling.
- *
- * Timeline fence is of format struct drm_i915_gem_timeline_fence.
- *
- * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag
- * is invalid, and an error will be returned.
- *
- * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence
- * is not requested and binding is completed synchronously.
- */
- struct drm_i915_gem_timeline_fence fence;
-
- /**
- * @extensions: Zero-terminated chain of extensions.
- *
- * For future extensions. See struct i915_user_extension.
- */
- __u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.
- *
- * This structure is passed to VM_UNBIND ioctl and specifies the GPU virtual
- * address (VA) range that should be unbound from the device page table of the
- * specified address space (VM). VM_UNBIND will force unbind the specified
- * range from device page table without waiting for any GPU job to complete.
- * It is UMDs responsibility to ensure the mapping is no longer in use before
- * calling VM_UNBIND.
- *
- * If the specified mapping is not found, the ioctl will simply return without
- * any error.
- *
- * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done
- * asynchronously, if valid @fence is specified.
- */
-struct drm_i915_gem_vm_unbind {
- /** @vm_id: VM (address space) id to bind */
- __u32 vm_id;
-
- /** @rsvd: Reserved, MBZ */
- __u32 rsvd;
-
- /** @start: Virtual Address start to unbind */
- __u64 start;
-
- /** @length: Length of mapping to unbind */
- __u64 length;
-
- /**
- * @flags: Currently reserved, MBZ.
- *
- * Note that @fence carries its own flags.
- */
- __u64 flags;
-
- /**
- * @fence: Timeline fence for unbind completion signaling.
- *
- * Timeline fence is of format struct drm_i915_gem_timeline_fence.
- *
- * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag
- * is invalid, and an error will be returned.
- *
- * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence
- * is not requested and unbinding is completed synchronously.
- */
- struct drm_i915_gem_timeline_fence fence;
-
- /**
- * @extensions: Zero-terminated chain of extensions.
- *
- * For future extensions. See struct i915_user_extension.
- */
- __u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_execbuffer3 - Structure for DRM_I915_GEM_EXECBUFFER3
- * ioctl.
- *
- * DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and VM_BIND mode
- * only works with this ioctl for submission.
- * See I915_VM_CREATE_FLAGS_USE_VM_BIND.
- */
-struct drm_i915_gem_execbuffer3 {
- /**
- * @ctx_id: Context id
- *
- * Only contexts with user engine map are allowed.
- */
- __u32 ctx_id;
-
- /**
- * @engine_idx: Engine index
- *
- * An index in the user engine map of the context specified by @ctx_id.
- */
- __u32 engine_idx;
-
- /**
- * @batch_address: Batch gpu virtual address/es.
- *
- * For normal submission, it is the gpu virtual address of the batch
- * buffer. For parallel submission, it is a pointer to an array of
- * batch buffer gpu virtual addresses with array size equal to the
- * number of (parallel) engines involved in that submission (See
- * struct i915_context_engines_parallel_submit).
- */
- __u64 batch_address;
-
- /** @flags: Currently reserved, MBZ */
- __u64 flags;
-
- /** @rsvd1: Reserved, MBZ */
- __u32 rsvd1;
-
- /** @fence_count: Number of fences in @timeline_fences array. */
- __u32 fence_count;
-
- /**
- * @timeline_fences: Pointer to an array of timeline fences.
- *
- * Timeline fences are of format struct drm_i915_gem_timeline_fence.
- */
- __u64 timeline_fences;
-
- /** @rsvd2: Reserved, MBZ */
- __u64 rsvd2;
-
- /**
- * @extensions: Zero-terminated chain of extensions.
- *
- * For future extensions. See struct i915_user_extension.
- */
- __u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_create_ext_vm_private - Extension to make the object
- * private to the specified VM.
- *
- * See struct drm_i915_gem_create_ext.
- */
-struct drm_i915_gem_create_ext_vm_private {
-#define I915_GEM_CREATE_EXT_VM_PRIVATE 2
- /** @base: Extension link. See struct i915_user_extension. */
- struct i915_user_extension base;
-
- /** @vm_id: Id of the VM to which the object is private */
- __u32 vm_id;
-};
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst
deleted file mode 100644
index 0b3b525ac6200..0000000000000
--- a/Documentation/gpu/rfc/i915_vm_bind.rst
+++ /dev/null
@@ -1,245 +0,0 @@
-==========================================
-I915 VM_BIND feature design and use cases
-==========================================
-
-VM_BIND feature
-================
-DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
-objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
-specified address space (VM). These mappings (also referred to as persistent
-mappings) will be persistent across multiple GPU submissions (execbuf calls)
-issued by the UMD, without user having to provide a list of all required
-mappings during each submission (as required by older execbuf mode).
-
-The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
-signaling the completion of bind/unbind operation.
-
-VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION.
-User has to opt-in for VM_BIND mode of binding for an address space (VM)
-during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
-
-VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are
-not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done
-asynchronously, when valid out fence is specified.
-
-VM_BIND features include:
-
-* Multiple Virtual Address (VA) mappings can map to the same physical pages
- of an object (aliasing).
-* VA mapping can map to a partial section of the BO (partial binding).
-* Support capture of persistent mappings in the dump upon GPU error.
-* Support for userptr gem objects (no special uapi is required for this).
-
-TLB flush consideration
-------------------------
-The i915 driver flushes the TLB for each submission and when an object's
-pages are released. The VM_BIND/UNBIND operation will not do any additional
-TLB flush. Any VM_BIND mapping added will be in the working set for subsequent
-submissions on that VM and will not be in the working set for currently running
-batches (which would require additional TLB flushes, which is not supported).
-
-Execbuf ioctl in VM_BIND mode
--------------------------------
-A VM in VM_BIND mode will not support older execbuf mode of binding.
-The execbuf ioctl handling in VM_BIND mode differs significantly from the
-older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
-Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
-struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
-execlist. Hence, no support for implicit sync. It is expected that the below
-work will be able to support requirements of object dependency setting in all
-use cases:
-
-"dma-buf: Add an API for exporting sync files"
-(https://lwn.net/Articles/859290/)
-
-The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
-works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
-VM_BIND call) at the time of execbuf3 call are deemed required for that
-submission.
-
-The execbuf3 ioctl directly specifies the batch addresses instead of as
-object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
-support many of the older features like in/out/submit fences, fence array,
-default gem context and many more (See struct drm_i915_gem_execbuffer3).
-
-In VM_BIND mode, VA allocation is completely managed by the user instead of
-the i915 driver. Hence all VA assignment, eviction are not applicable in
-VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
-be using the i915_vma active reference tracking. It will instead use dma-resv
-object for that (See `VM_BIND dma_resv usage`_).
-
-So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
-evictions, vma lookup table, implicit sync, vma active reference tracking etc.,
-are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling
-should be in a separate file and only functionalities common to these ioctls
-can be the shared code where possible.
-
-VM_PRIVATE objects
--------------------
-By default, BOs can be mapped on multiple VMs and can also be dma-buf
-exported. Hence these BOs are referred to as Shared BOs.
-During each execbuf submission, the request fence must be added to the
-dma-resv fence list of all shared BOs mapped on the VM.
-
-VM_BIND feature introduces an optimization where user can create BO which
-is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during
-BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on
-the VM they are private to and can't be dma-buf exported.
-All private BOs of a VM share the dma-resv object. Hence during each execbuf
-submission, they need only one dma-resv fence list updated. Thus, the fast
-path (where required mappings are already bound) submission latency is O(1)
-w.r.t the number of VM private BOs.
-
-VM_BIND locking hierarchy
--------------------------
-The locking design here supports the older (execlist based) execbuf mode, the
-newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
-system allocator support (See `Shared Virtual Memory (SVM) support`_).
-The older execbuf mode and the newer VM_BIND mode without page faults manages
-residency of backing storage using dma_fence. The VM_BIND mode with page faults
-and the system allocator support do not use any dma_fence at all.
-
-VM_BIND locking order is as below.
-
-1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in
- vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the
- mapping.
-
- In future, when GPU page faults are supported, we can potentially use a
- rwsem instead, so that multiple page fault handlers can take the read side
- lock to lookup the mapping and hence can run in parallel.
- The older execbuf mode of binding do not need this lock.
-
-2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to
- be held while binding/unbinding a vma in the async worker and while updating
- dma-resv fence list of an object. Note that private BOs of a VM will all
- share a dma-resv object.
-
- The future system allocator support will use the HMM prescribed locking
- instead.
-
-3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of
- invalidated vmas (due to eviction and userptr invalidation) etc.
-
-When GPU page faults are supported, the execbuf path do not take any of these
-locks. There we will simply smash the new batch buffer address into the ring and
-then tell the scheduler run that. The lock taking only happens from the page
-fault handler, where we take lock-A in read mode, whichever lock-B we need to
-find the backing storage (dma_resv lock for gem objects, and hmm/core mm for
-system allocator) and some additional locks (lock-D) for taking care of page
-table races. Page fault mode should not need to ever manipulate the vm lists,
-so won't ever need lock-C.
-
-VM_BIND LRU handling
----------------------
-We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid
-performance degradation. We will also need support for bulk LRU movement of
-VM_BIND objects to avoid additional latencies in execbuf path.
-
-The page table pages are similar to VM_BIND mapped objects (See
-`Evictable page table allocations`_) and are maintained per VM and needs to
-be pinned in memory when VM is made active (ie., upon an execbuf call with
-that VM). So, bulk LRU movement of page table pages is also needed.
-
-VM_BIND dma_resv usage
------------------------
-Fences needs to be added to all VM_BIND mapped objects. During each execbuf
-submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent
-over sync (See enum dma_resv_usage). One can override it with either
-DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object
-dependency setting.
-
-Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for
-DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch
-check. Instead, the execbuf3 out fence should be used for end of batch check
-(See struct drm_i915_gem_execbuffer3).
-
-Also, in VM_BIND mode, use dma-resv apis for determining object activeness
-(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the
-older i915_vma active reference tracking which is deprecated. This should be
-easier to get it working with the current TTM backend.
-
-Mesa use case
---------------
-VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris),
-hence improving performance of CPU-bound applications. It also allows us to
-implement Vulkan's Sparse Resources. With increasing GPU hardware performance,
-reducing CPU overhead becomes more impactful.
-
-
-Other VM_BIND use cases
-========================
-
-Long running Compute contexts
-------------------------------
-Usage of dma-fence expects that they complete in reasonable amount of time.
-Compute on the other hand can be long running. Hence it is appropriate for
-compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage
-must be limited to in-kernel consumption only.
-
-Where GPU page faults are not available, kernel driver upon buffer invalidation
-will initiate a suspend (preemption) of long running context, finish the
-invalidation, revalidate the BO and then resume the compute context. This is
-done by having a per-context preempt fence which is enabled when someone tries
-to wait on it and triggers the context preemption.
-
-User/Memory Fence
-~~~~~~~~~~~~~~~~~~
-User/Memory fence is a <address, value> pair. To signal the user fence, the
-specified value will be written at the specified virtual address and wakeup the
-waiting process. User fence can be signaled either by the GPU or kernel async
-worker (like upon bind completion). User can wait on a user fence with a new
-user fence wait ioctl.
-
-Here is some prior work on this:
-https://patchwork.freedesktop.org/patch/349417/
-
-Low Latency Submission
-~~~~~~~~~~~~~~~~~~~~~~~
-Allows compute UMD to directly submit GPU jobs instead of through execbuf
-ioctl. This is made possible by VM_BIND is not being synchronized against
-execbuf. VM_BIND allows bind/unbind of mappings required for the directly
-submitted jobs.
-
-Debugger
----------
-With debug event interface user space process (debugger) is able to keep track
-of and act upon resources created by another process (debugged) and attached
-to GPU via vm_bind interface.
-
-GPU page faults
-----------------
-GPU page faults when supported (in future), will only be supported in the
-VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of
-binding will require using dma-fence to ensure residency, the GPU page faults
-mode when supported, will not use any dma-fence as residency is purely managed
-by installing and removing/invalidating page table entries.
-
-Page level hints settings
---------------------------
-VM_BIND allows any hints setting per mapping instead of per BO. Possible hints
-include placement and atomicity. Sub-BO level placement hint will be even more
-relevant with upcoming GPU on-demand page fault support.
-
-Page level Cache/CLOS settings
--------------------------------
-VM_BIND allows cache/CLOS settings per mapping instead of per BO.
-
-Evictable page table allocations
----------------------------------
-Make pagetable allocations evictable and manage them similar to VM_BIND
-mapped objects. Page table pages are similar to persistent mappings of a
-VM (difference here are that the page table pages will not have an i915_vma
-structure and after swapping pages back in, parent page link needs to be
-updated).
-
-Shared Virtual Memory (SVM) support
-------------------------------------
-VM_BIND interface can be used to map system memory directly (without gem BO
-abstraction) using the HMM interface. SVM is only supported with GPU page
-faults enabled.
-
-VM_BIND UAPI
-=============
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 8313194af0683..1256dde0fb3b1 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -28,9 +28,5 @@ host such documentation:
i915_small_bar.rst
-.. toctree::
-
- i915_vm_bind.rst
-
.. toctree::
color_pipeline.rst
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 3/4] drm/doc/rfc: Remove i915_small_bar rfc.
2026-04-20 8:33 [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 1/4] drm/doc/rfc: Remove i915_gem_lmem.rst Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 2/4] drm/doc/rfc: Remove i915_vm_bind Maarten Lankhorst
@ 2026-04-20 8:33 ` Maarten Lankhorst
2026-04-20 8:33 ` [PATCH 4/4] drm/doc/rfc: Remove i915_scheduler item Maarten Lankhorst
2026-04-20 18:52 ` [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Rodrigo Vivi
4 siblings, 0 replies; 6+ messages in thread
From: Maarten Lankhorst @ 2026-04-20 8:33 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Maarten Lankhorst
Probably done, with commit 525e93f6317a ("drm/i915/uapi: add NEEDS_CPU_ACCESS hint")
and 3f4309cbdc84 ("drm/i915/uapi: add probed_cpu_visible_size")
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
Documentation/gpu/rfc/i915_small_bar.h | 189 -----------------------
Documentation/gpu/rfc/i915_small_bar.rst | 47 ------
Documentation/gpu/rfc/index.rst | 4 -
3 files changed, 240 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_small_bar.h
delete mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h b/Documentation/gpu/rfc/i915_small_bar.h
deleted file mode 100644
index 6003c81d5aa40..0000000000000
--- a/Documentation/gpu/rfc/i915_small_bar.h
+++ /dev/null
@@ -1,189 +0,0 @@
-/**
- * struct __drm_i915_memory_region_info - Describes one region as known to the
- * driver.
- *
- * Note this is using both struct drm_i915_query_item and struct drm_i915_query.
- * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS
- * at &drm_i915_query_item.query_id.
- */
-struct __drm_i915_memory_region_info {
- /** @region: The class:instance pair encoding */
- struct drm_i915_gem_memory_class_instance region;
-
- /** @rsvd0: MBZ */
- __u32 rsvd0;
-
- /**
- * @probed_size: Memory probed by the driver
- *
- * Note that it should not be possible to ever encounter a zero value
- * here, also note that no current region type will ever return -1 here.
- * Although for future region types, this might be a possibility. The
- * same applies to the other size fields.
- */
- __u64 probed_size;
-
- /**
- * @unallocated_size: Estimate of memory remaining
- *
- * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
- * Without this (or if this is an older kernel) the value here will
- * always equal the @probed_size. Note this is only currently tracked
- * for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
- * will always equal the @probed_size).
- */
- __u64 unallocated_size;
-
- union {
- /** @rsvd1: MBZ */
- __u64 rsvd1[8];
- struct {
- /**
- * @probed_cpu_visible_size: Memory probed by the driver
- * that is CPU accessible.
- *
- * This will be always be <= @probed_size, and the
- * remainder (if there is any) will not be CPU
- * accessible.
- *
- * On systems without small BAR, the @probed_size will
- * always equal the @probed_cpu_visible_size, since all
- * of it will be CPU accessible.
- *
- * Note this is only tracked for
- * I915_MEMORY_CLASS_DEVICE regions (for other types the
- * value here will always equal the @probed_size).
- *
- * Note that if the value returned here is zero, then
- * this must be an old kernel which lacks the relevant
- * small-bar uAPI support (including
- * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
- * such systems we should never actually end up with a
- * small BAR configuration, assuming we are able to load
- * the kernel module. Hence it should be safe to treat
- * this the same as when @probed_cpu_visible_size ==
- * @probed_size.
- */
- __u64 probed_cpu_visible_size;
-
- /**
- * @unallocated_cpu_visible_size: Estimate of CPU
- * visible memory remaining
- *
- * Note this is only tracked for
- * I915_MEMORY_CLASS_DEVICE regions (for other types the
- * value here will always equal the
- * @probed_cpu_visible_size).
- *
- * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable
- * accounting. Without this the value here will always
- * equal the @probed_cpu_visible_size. Note this is only
- * currently tracked for I915_MEMORY_CLASS_DEVICE
- * regions (for other types the value here will also
- * always equal the @probed_cpu_visible_size).
- *
- * If this is an older kernel the value here will be
- * zero, see also @probed_cpu_visible_size.
- */
- __u64 unallocated_cpu_visible_size;
- };
- };
-};
-
-/**
- * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
- * extension support using struct i915_user_extension.
- *
- * Note that new buffer flags should be added here, at least for the stuff that
- * is immutable. Previously we would have two ioctls, one to create the object
- * with gem_create, and another to apply various parameters, however this
- * creates some ambiguity for the params which are considered immutable. Also in
- * general we're phasing out the various SET/GET ioctls.
- */
-struct __drm_i915_gem_create_ext {
- /**
- * @size: Requested size for the object.
- *
- * The (page-aligned) allocated size for the object will be returned.
- *
- * Note that for some devices we have might have further minimum
- * page-size restrictions (larger than 4K), like for device local-memory.
- * However in general the final size here should always reflect any
- * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
- * extension to place the object in device local-memory. The kernel will
- * always select the largest minimum page-size for the set of possible
- * placements as the value to use when rounding up the @size.
- */
- __u64 size;
-
- /**
- * @handle: Returned handle for the object.
- *
- * Object handles are nonzero.
- */
- __u32 handle;
-
- /**
- * @flags: Optional flags.
- *
- * Supported values:
- *
- * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
- * the object will need to be accessed via the CPU.
- *
- * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only
- * strictly required on configurations where some subset of the device
- * memory is directly visible/mappable through the CPU (which we also
- * call small BAR), like on some DG2+ systems. Note that this is quite
- * undesirable, but due to various factors like the client CPU, BIOS etc
- * it's something we can expect to see in the wild. See
- * &__drm_i915_memory_region_info.probed_cpu_visible_size for how to
- * determine if this system applies.
- *
- * Note that one of the placements MUST be I915_MEMORY_CLASS_SYSTEM, to
- * ensure the kernel can always spill the allocation to system memory,
- * if the object can't be allocated in the mappable part of
- * I915_MEMORY_CLASS_DEVICE.
- *
- * Also note that since the kernel only supports flat-CCS on objects
- * that can *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore
- * don't support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with
- * flat-CCS.
- *
- * Without this hint, the kernel will assume that non-mappable
- * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
- * kernel can still migrate the object to the mappable part, as a last
- * resort, if userspace ever CPU faults this object, but this might be
- * expensive, and so ideally should be avoided.
- *
- * On older kernels which lack the relevant small-bar uAPI support (see
- * also &__drm_i915_memory_region_info.probed_cpu_visible_size),
- * usage of the flag will result in an error, but it should NEVER be
- * possible to end up with a small BAR configuration, assuming we can
- * also successfully load the i915 kernel module. In such cases the
- * entire I915_MEMORY_CLASS_DEVICE region will be CPU accessible, and as
- * such there are zero restrictions on where the object can be placed.
- */
-#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)
- __u32 flags;
-
- /**
- * @extensions: The chain of extensions to apply to this object.
- *
- * This will be useful in the future when we need to support several
- * different extensions, and we need to apply more than one when
- * creating the object. See struct i915_user_extension.
- *
- * If we don't supply any extensions then we get the same old gem_create
- * behaviour.
- *
- * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see
- * struct drm_i915_gem_create_ext_memory_regions.
- *
- * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see
- * struct drm_i915_gem_create_ext_protected_content.
- */
-#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0
-#define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1
- __u64 extensions;
-};
diff --git a/Documentation/gpu/rfc/i915_small_bar.rst b/Documentation/gpu/rfc/i915_small_bar.rst
deleted file mode 100644
index d6c03ce3b862b..0000000000000
--- a/Documentation/gpu/rfc/i915_small_bar.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-==========================
-I915 Small BAR RFC Section
-==========================
-Starting from DG2 we will have resizable BAR support for device local-memory(i.e
-I915_MEMORY_CLASS_DEVICE), but in some cases the final BAR size might still be
-smaller than the total probed_size. In such cases, only some subset of
-I915_MEMORY_CLASS_DEVICE will be CPU accessible(for example the first 256M),
-while the remainder is only accessible via the GPU.
-
-I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag
-----------------------------------------------
-New gem_create_ext flag to tell the kernel that a BO will require CPU access.
-This becomes important when placing an object in I915_MEMORY_CLASS_DEVICE, where
-underneath the device has a small BAR, meaning only some portion of it is CPU
-accessible. Without this flag the kernel will assume that CPU access is not
-required, and prioritize using the non-CPU visible portion of
-I915_MEMORY_CLASS_DEVICE.
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h
- :functions: __drm_i915_gem_create_ext
-
-probed_cpu_visible_size attribute
----------------------------------
-New struct__drm_i915_memory_region attribute which returns the total size of the
-CPU accessible portion, for the particular region. This should only be
-applicable for I915_MEMORY_CLASS_DEVICE. We also report the
-unallocated_cpu_visible_size, alongside the unallocated_size.
-
-Vulkan will need this as part of creating a separate VkMemoryHeap with the
-VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set, to represent the CPU visible portion,
-where the total size of the heap needs to be known. It also wants to be able to
-give a rough estimate of how memory can potentially be allocated.
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h
- :functions: __drm_i915_memory_region_info
-
-Error Capture restrictions
---------------------------
-With error capture we have two new restrictions:
-
- 1) Error capture is best effort on small BAR systems; if the pages are not
- CPU accessible, at the time of capture, then the kernel is free to skip
- trying to capture them.
-
- 2) On discrete and newer integrated platforms we now reject error capture
- on recoverable contexts. In the future the kernel may want to blit during
- error capture, when for example something is not currently CPU accessible.
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 1256dde0fb3b1..3ab666616c3c5 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -24,9 +24,5 @@ host such documentation:
i915_scheduler.rst
-.. toctree::
-
- i915_small_bar.rst
-
.. toctree::
color_pipeline.rst
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 4/4] drm/doc/rfc: Remove i915_scheduler item.
2026-04-20 8:33 [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Maarten Lankhorst
` (2 preceding siblings ...)
2026-04-20 8:33 ` [PATCH 3/4] drm/doc/rfc: Remove i915_small_bar rfc Maarten Lankhorst
@ 2026-04-20 8:33 ` Maarten Lankhorst
2026-04-20 18:52 ` [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Rodrigo Vivi
4 siblings, 0 replies; 6+ messages in thread
From: Maarten Lankhorst @ 2026-04-20 8:33 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Maarten Lankhorst
I've seen no updates since e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
Documentation/gpu/rfc/i915_scheduler.rst | 152 -----------------------
Documentation/gpu/rfc/index.rst | 4 -
2 files changed, 156 deletions(-)
delete mode 100644 Documentation/gpu/rfc/i915_scheduler.rst
diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
deleted file mode 100644
index 2974525f0ac54..0000000000000
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ /dev/null
@@ -1,152 +0,0 @@
-=========================================
-I915 GuC Submission/DRM Scheduler Section
-=========================================
-
-Upstream plan
-=============
-For upstream the overall plan for landing GuC submission and integrating the
-i915 with the DRM scheduler is:
-
-* Merge basic GuC submission
- * Basic submission support for all gen11+ platforms
- * Not enabled by default on any current platforms but can be enabled via
- modparam enable_guc
- * Lots of rework will need to be done to integrate with DRM scheduler so
- no need to nit pick everything in the code, it just should be
- functional, no major coding style / layering errors, and not regress
- execlists
- * Update IGTs / selftests as needed to work with GuC submission
- * Enable CI on supported platforms for a baseline
- * Rework / get CI heathly for GuC submission in place as needed
-* Merge new parallel submission uAPI
- * Bonding uAPI completely incompatible with GuC submission, plus it has
- severe design issues in general, which is why we want to retire it no
- matter what
- * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step
- which configures a slot with N contexts
- * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
- a slot in a single execbuf IOCTL and the batches run on the GPU in
- parallel
- * Initially only for GuC submission but execlists can be supported if
- needed
-* Convert the i915 to use the DRM scheduler
- * GuC submission backend fully integrated with DRM scheduler
- * All request queues removed from backend (e.g. all backpressure
- handled in DRM scheduler)
- * Resets / cancels hook in DRM scheduler
- * Watchdog hooks into DRM scheduler
- * Lots of complexity of the GuC backend can be pulled out once
- integrated with DRM scheduler (e.g. state machine gets
- simpler, locking gets simpler, etc...)
- * Execlists backend will minimum required to hook in the DRM scheduler
- * Legacy interface
- * Features like timeslicing / preemption / virtual engines would
- be difficult to integrate with the DRM scheduler and these
- features are not required for GuC submission as the GuC does
- these things for us
- * ROI low on fully integrating into DRM scheduler
- * Fully integrating would add lots of complexity to DRM
- scheduler
- * Port i915 priority inheritance / boosting feature in DRM scheduler
- * Used for i915 page flip, may be useful to other DRM drivers as
- well
- * Will be an optional feature in the DRM scheduler
- * Remove in-order completion assumptions from DRM scheduler
- * Even when using the DRM scheduler the backends will handle
- preemption, timeslicing, etc... so it is possible for jobs to
- finish out of order
- * Pull out i915 priority levels and use DRM priority levels
- * Optimize DRM scheduler as needed
-
-TODOs for GuC submission upstream
-=================================
-
-* Need an update to GuC firmware / i915 to enable error state capture
-* Open source tool to decode GuC logs
-* Public GuC spec
-
-New uAPI for basic GuC submission
-=================================
-No major changes are required to the uAPI for basic GuC submission. The only
-change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
-This attribute indicates the 2k i915 user priority levels are statically mapped
-into 3 levels as follows:
-
-* -1k to -1 Low priority
-* 0 Medium priority
-* 1 to 1k High priority
-
-This is needed because the GuC only has 4 priority bands. The highest priority
-band is reserved with the kernel. This aligns with the DRM scheduler priority
-levels too.
-
-Spec references:
-----------------
-* https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt
-* https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap5.html#devsandqueues-priority
-* https://spec.oneapi.com/level-zero/latest/core/api.html#ze-command-queue-priority-t
-
-New parallel submission uAPI
-============================
-The existing bonding uAPI is completely broken with GuC submission because
-whether a submission is a single context submit or parallel submit isn't known
-until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple
-contexts in parallel with the GuC the context must be explicitly registered with
-N contexts and all N contexts must be submitted in a single command to the GuC.
-The GuC interfaces do not support dynamically changing between N contexts as the
-bonding uAPI does. Hence the need for a new parallel submission interface. Also
-the legacy bonding uAPI is quite confusing and not intuitive at all. Furthermore
-I915_SUBMIT_FENCE is by design a future fence, so not really something we should
-continue to support.
-
-The new parallel submission uAPI consists of 3 parts:
-
-* Export engines logical mapping
-* A 'set_parallel' extension to configure contexts for parallel
- submission
-* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
-
-Export engines logical mapping
-------------------------------
-Certain use cases require BBs to be placed on engine instances in logical order
-(e.g. split-frame on gen11+). The logical mapping of engine instances can change
-based on fusing. Rather than making UMDs be aware of fusing, simply expose the
-logical mapping with the existing query engine info IOCTL. Also the GuC
-submission interface currently only supports submitting multiple contexts to
-engines in logical order which is a new requirement compared to execlists.
-Lastly, all current platforms have at most 2 engine instances and the logical
-order is the same as uAPI order. This will change on platforms with more than 2
-engine instances.
-
-A single bit will be added to drm_i915_engine_info.flags indicating that the
-logical instance has been returned and a new field,
-drm_i915_engine_info.logical_instance, returns the logical instance.
-
-A 'set_parallel' extension to configure contexts for parallel submission
-------------------------------------------------------------------------
-The 'set_parallel' extension configures a slot for parallel submission of N BBs.
-It is a setup step that must be called before using any of the contexts. See
-I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for
-similar existing examples. Once a slot is configured for parallel submission the
-execbuf2 IOCTL can be called submitting N BBs in a single IOCTL. Initially only
-supports GuC submission. Execlists supports can be added later if needed.
-
-Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
-drm_i915_context_engines_parallel_submit to the uAPI to implement this
-extension.
-
-.. c:namespace-push:: rfc
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
- :functions: i915_context_engines_parallel_submit
-
-.. c:namespace-pop::
-
-Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
--------------------------------------------------------------------
-Contexts that have been configured with the 'set_parallel' extension can only
-submit N BBs in a single execbuf2 IOCTL. The BBs are either the last N objects
-in the drm_i915_gem_exec_object2 list or the first N if I915_EXEC_BATCH_FIRST is
-set. The number of BBs is implicit based on the slot submitted and how it has
-been configured by 'set_parallel' or other extensions. No uAPI changes are
-required to the execbuf2 IOCTL.
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 3ab666616c3c5..975b7094e259a 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,9 +20,5 @@ host such documentation:
gpusvm.rst
-.. toctree::
-
- i915_scheduler.rst
-
.. toctree::
color_pipeline.rst
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915.
2026-04-20 8:33 [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915 Maarten Lankhorst
` (3 preceding siblings ...)
2026-04-20 8:33 ` [PATCH 4/4] drm/doc/rfc: Remove i915_scheduler item Maarten Lankhorst
@ 2026-04-20 18:52 ` Rodrigo Vivi
4 siblings, 0 replies; 6+ messages in thread
From: Rodrigo Vivi @ 2026-04-20 18:52 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: dri-devel, intel-gfx
On Mon, Apr 20, 2026 at 10:33:18AM +0200, Maarten Lankhorst wrote:
> I believe small_bar has been implemented, as is gem_lmem.
>
> xe has implemented GuC submission and VM_BIND, but realistically
> this will never happen for i915.
>
> Either way, those RFC's are completed, and can be removed.
>
> Maarten Lankhorst (4):
> drm/doc/rfc: Remove i915_gem_lmem.rst
> drm/doc/rfc: Remove i915_vm_bind.
> drm/doc/rfc: Remove i915_small_bar rfc.
> drm/doc/rfc: Remove i915_scheduler item.
Thanks for the clean-up.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> Documentation/gpu/rfc/i915_gem_lmem.rst | 22 --
> Documentation/gpu/rfc/i915_scheduler.rst | 152 ------------
> Documentation/gpu/rfc/i915_small_bar.h | 189 ---------------
> Documentation/gpu/rfc/i915_small_bar.rst | 47 ----
> Documentation/gpu/rfc/i915_vm_bind.h | 290 -----------------------
> Documentation/gpu/rfc/i915_vm_bind.rst | 245 -------------------
> Documentation/gpu/rfc/index.rst | 18 +-
> 7 files changed, 1 insertion(+), 962 deletions(-)
> delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
> delete mode 100644 Documentation/gpu/rfc/i915_scheduler.rst
> delete mode 100644 Documentation/gpu/rfc/i915_small_bar.h
> delete mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
> delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
>
> --
> 2.53.0
>
^ permalink raw reply [flat|nested] 6+ messages in thread