| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We have at least 2 future features(OA and future media engines
capabilities) that will require Xe to provide more information about
engines to UMDs.
But this information should not just be added to
drm_xe_engine_class_instance for a couple of reasons:
- drm_xe_engine_class_instance is used as input to other structs/uAPIs
and those uAPIs don't care about any of these future new engine fields
- those new fields are useless information after initialization for
some UMDs, so it should not need to carry that around
So here my proposal is to make DRM_XE_DEVICE_QUERY_ENGINES return an
array of drm_xe_query_engine_info that contain
drm_xe_engine_class_instance and 3 u64s to be used for future features.
Reference OA:
https://patchwork.freedesktop.org/patch/558362/?series=121084&rev=6
v2: Reduce reserved[] to 3 u64 (Matthew Brost)
Cc: Francois Dugast <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
[Rodrigo Rebased]
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
Although the flags are about the creation, the memory placement
of the BO deserves a proper dedicated field in the uapi.
Besides getting more clear, it also allows to remove the
'magic' shifts from the flags that was a concern during the
uapi reviews.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
The bind api is extensible but for a single bind op, there
is not a mechanism to extend. Add extensions field to
struct drm_xe_vm_bind_op.
Cc: Rodrigo Vivi <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Dominik Grzegorzek <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Allow userspace to directly control the pat_index for a given vm
binding. This should allow directly controlling the coherency, caching
behaviour, compression and potentially other stuff in the future for the
ppGTT binding.
The exact meaning behind the pat_index is very platform specific (see
BSpec or PRMs) but effectively maps to some predefined memory
attributes. From the KMD pov we only care about the coherency that is
provided by the pat_index, which falls into either NONE, 1WAY or 2WAY.
The vm_bind coherency mode for the given pat_index needs to be at least
1way coherent when using cpu_caching with DRM_XE_GEM_CPU_CACHING_WB. For
platforms that lack the explicit coherency mode attribute, we treat
UC/WT/WC as NONE and WB as AT_LEAST_1WAY.
For userptr mappings we lack a corresponding gem object, so the expected
coherency mode is instead implicit and must fall into either 1WAY or
2WAY. Trying to use NONE will be rejected by the kernel. For imported
dma-buf (from a different device) the coherency mode is also implicit
and must also be either 1WAY or 2WAY.
v2:
- Undefined coh_mode(pat_index) can now be treated as programmer
error. (Matt Roper)
- We now allow gem_create.coh_mode <= coh_mode(pat_index), rather than
having to match exactly. This ensures imported dma-buf can always
just use 1way (or even 2way), now that we also bundle 1way/2way into
at_least_1way. We still require 1way/2way for external dma-buf, but
the policy can now be the same for self-import, if desired.
- Use u16 for pat_index in uapi. u32 is massive overkill. (José)
- Move as much of the pat_index validation as we can into
vm_bind_ioctl_check_args. (José)
v3 (Matt Roper):
- Split the pte_encode() refactoring into separate patch.
v4:
- Rebase
v5:
- Check for and reject !coh_mode which would indicate hw reserved
pat_index on xe2.
v6:
- Rebase on removal of coh_mode from uapi. We just need to reject
cpu_caching=wb + pat_index with coh_none.
Testcase: igt@xe_pat
Bspec: 45101, 44235 #xe
Bspec: 70552, 71582, 59400 #xe2
Signed-off-by: Matthew Auld <[email protected]>
Cc: Pallavi Mishra <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Cc: Zhengguo Xu <[email protected]>
Cc: Francois Dugast <[email protected]>
Tested-by: José Roberto de Souza <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Acked-by: Zhengguo Xu <[email protected]>
Acked-by: Bartosz Dunajski <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Allow userspace to specify the CPU caching mode at object creation.
Modify gem create handler and introduce xe_bo_create_user to replace
xe_bo_create. In a later patch we will support setting the pat_index as
part of vm_bind, where expectation is that the coherency mode extracted
from the pat_index must be least 1way coherent if using cpu_caching=wb.
v2
- s/smem_caching/smem_cpu_caching/ and
s/XE_GEM_CACHING/XE_GEM_CPU_CACHING/. (Matt Roper)
- Drop COH_2WAY and just use COH_NONE + COH_AT_LEAST_1WAY; KMD mostly
just cares that zeroing/swap-in can't be bypassed with the given
smem_caching mode. (Matt Roper)
- Fix broken range check for coh_mode and smem_cpu_caching and also
don't use constant value, but the already defined macros. (José)
- Prefer switch statement for smem_cpu_caching -> ttm_caching. (José)
- Add note in kernel-doc for dgpu and coherency modes for system
memory. (José)
v3 (José):
- Make sure to reject coh_mode == 0 for VRAM-only.
- Also make sure to actually pass along the (start, end) for
__xe_bo_create_locked.
v4
- Drop UC caching mode. Can be added back if we need it. (Matt Roper)
- s/smem_cpu_caching/cpu_caching. Idea is that VRAM is always WC, but
that is currently implicit and KMD controlled. Make it explicit in
the uapi with the limitation that it currently must be WC. For VRAM
+ SYS objects userspace must now select WC. (José)
- Make sure to initialize bo_flags. (José)
v5
- Make to align with the other uapi and prefix uapi constants with
DRM_ (José)
v6:
- Make it clear that zero cpu_caching is only allowed for kernel
objects. (José)
v7: (Oak)
- With all the changes from the original design, it looks we can
further simplify here and drop the explicit coh_mode. We can just
infer the coh_mode from the cpu_caching. i.e reject cpu_caching=wb +
coh_none. It's one less thing for userspace to maintain so seems
worth it.
v8:
- Make sure to also update the kselftests.
Testcase: igt@xe_mmap@cpu-caching
Signed-off-by: Pallavi Mishra <[email protected]>
Co-developed-by: Matthew Auld <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Cc: Zhengguo Xu <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Oak Zeng <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Acked-by: Zhengguo Xu <[email protected]>
Acked-by: Bartosz Dunajski <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Let's bring a bit of clarity on this 'region' field that is
part of vm_bind operation struct. Rename and document to make
it more than obvious that it is a region instance and not a
mask and also that it should only be used with the prefetch
operation itself.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
|
|
On one hand the WAIT_OP represents the operation use for waiting such
as ==, !=, > and so on. On the other hand, the mask is applied to the
value used for comparision. Split those two to bring clarity to the uapi.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
|
|
Only cosmetic things. No functional change on this patch.
Define every flag with (1 << n) and use singular FLAG name.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
'Usage' gives an impression of telemetry information where someone
would query to see how the memory is currently used and available
size, etc. However this API is more than this. It is about a global
view of all the memory regions available in the system and user
space needs to have this information so they can then use the
mem_region masks that are returned for the engine access.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
- 'native' doesn't make much sense on integrated devices.
- 'slow' is not necessarily true and doesn't go well with opposition
to 'native'.
Instead, let's use 'near' vs 'far'. It makes sense with all the current
Intel GPUs and it is future proof. Right now, there's absolutely no need
to define among the 'far' memory, which ones are slower, either in terms
of latency, nunmber of hops or bandwidth.
In case of this might become a requirement in the future, a new query
could be added to indicate the certain 'distance' between a given engine
and a memory_region. But for now, this fulfill all of the current
requirements in the most straightforward way for the userspace drivers.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
Change rsvd to pad in struct drm_xe_class_instance to prevent the field
from being used in future.
v2: Change from fixup to regular commit because this touches the
uAPI (Francois Dugast)
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Most constants defined in xe_drm.h which can be used for flags are
named DRM_XE_*_FLAG_*, which is helpful to identify them. Make this
systematic and add _FLAG where it was missing.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Most constants defined in xe_drm.h use DRM_XE_ as prefix which is
helpful to identify the name space. Make this systematic and add
this prefix where it was missing.
v2:
- fix vertical alignment of define values
- remove double DRM_ in some variables (José Roberto de Souza)
v3: Rebase
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Drop interrupt event from PMU as that is not useful and not being used
by any UMD.
Cc: Rodrigo Vivi <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Francois Dugast <[email protected]>
Signed-off-by: Aravind Iddamsetty <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
As part of uAPI cleanup, remove this constant which is not used. Number
of GTs are provided as num_gt in drm_xe_query_gt_list.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
As part of uAPI cleanup, remove this constant which is not used. Memory
regions can be queried with DRM_XE_DEVICE_QUERY_MEM_USAGE.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This is not used and also the negative of the other 2 regions:
native_mem_regions and slow_mem_regions.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Remove unused IOCTL.
Without any userspace using it we need to remove before we
can be accepted upstream.
At this point we are breaking the compatibility for good,
so we don't need to break when we are in-tree. So, let's
also use this breakage to sort out the IOCTL entries and
fix all the small indentation and line issues.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
With the split between tile and gt, this is currently unused.
Also it is bringing confusion because main vs remote would be
more a concept of the tile itself and not about GT.
So, the MAIN one is the traditional GT used for every operation
in older platforms, and for render/graphics and compute on platforms
that contains the stand-alone Media GT.
Cc: Matt Roper <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
num_params can be used to retrieve the size of the info array
for the specific version of the kernel being used.
v2: Also remove XE_QUERY_CONFIG_NUM_PARAM (José Roberto de Souza)
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add conditional check for access counter granularity.
This check will return -EINVAL if granularity is beyond 64M
which is a hardware limitation.
v2: Defined
XE_ACC_GRANULARITY_128K 0
XE_ACC_GRANULARITY_2M 1
XE_ACC_GRANULARITY_16M 2
XE_ACC_GRANULARITY_64M 3
as part of uAPI.
So, that user can also use it.(Oak)
v3: Move uAPI to proper location and give proper
documentation.(Brian, Oak)
Cc: Oak Zeng <[email protected]>
Cc: Janga Rahul Kumar <[email protected]>
Cc: Brian Welty <[email protected]>
Signed-off-by: Priyanka Dandamudi <[email protected]>
Reviewed-by: Oak Zeng <[email protected]>
Reviewed-by: Oak Zeng <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This is used for the priority of an exec queue (not an engine) and
should be named accordingly.
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
During the uapi review it was identified a possible confusion
with the plural of acronym with a new acronym. So the
recommendation is to go with gt_list instead.
Suggested-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
We already have many bits reserved at the end already.
Let's kill the unused ones.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
Let's have a single GT ID per GT within the PCI Device Card.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
Split drm_xe_query_gt out of the gt list one in order to better
document it.
No functional change at this point. Any actual change to the
uapi should come in follow-up additions.
v2: s/maks/mask
Cc: Matt Roper <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
Async worker is gone. All jobs and memory allocations done in IOCTL to
align with dma fencing rules.
Async vs. sync now means when do bind operations complete relative to
the IOCTL. Async completes when out-syncs signal while sync completes
when the IOCTL returns. In-syncs and out-syncs are only allowed in async
mode.
If memory allocations fail in the job creation step the VM is killed.
This is temporary, eventually a proper unwind will be done and VM will
be usable.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This is not used nor does it align VM async document, kill this.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This extension is currently not used and it is not aligned with
the error handling on async VM_BIND. Let's remove it and along with
that, since it was the only extension for the vm_create, remove VM
extension entirely.
v2: rebase on top of the removal of drm_xe_ext_exec_queue_set_property
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
There really is no difference between 'struct drm_xe_ext_vm_set_property'
and 'struct drm_xe_ext_exec_queue_set_property', they are extensions which
specify a <property, value> pair. Replace the two extensions with a single
common 'struct drm_xe_ext_set_property' extension. The rationale is that
rather than have each XE module (including future modules) invent their own
property/value extensions, all XE modules use a common set_property
extension when possible.
Signed-off-by: Ashutosh Dixit <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
Functionality of XE_EXEC_QUEUE_SET_PROPERTY_COMPUTE_MODE deprecated in a
previous patch, drop from uAPI. The property is just simply inherented
from the VM.
v2:
- Update commit message (Niranjana)
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This was previously used in UMD for timestamp correlation, which can now
be done with DRM_XE_QUERY_CS_CYCLES.
Link: https://lore.kernel.org/all/[email protected]/
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/636
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Use different members in the drm_xe_vm_bind_op for op and for flags as
it is done in other structures.
Type is left to u32 to leave enough room for future operations and flags.
v2: Remove the XE_VM_BIND_* flags shift (Rodrigo Vivi)
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/303
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|
|
Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these timestamps separately and the calculated delta between these
timestamps lack enough accuracy.
To improve the accuracy of these time measurements to within a few us,
add a query that returns the engine and cpu timestamps captured as
close to each other as possible.
Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24591
v2:
- Fix kernel-doc warnings (CI)
- Document input params and group them together (Jose)
- s/cs/engine/ (Jose)
- Remove padding in the query (Ashutosh)
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
[Rodrigo finished the s/cs/engine renaming]
|
|
There are a set of engine group busyness counters provided by HW which are
perfect fit to be exposed via PMU perf events.
BSPEC: 46559, 46560, 46722, 46729, 52071, 71028
events can be listed using:
perf list
xe_0000_03_00.0/any-engine-group-busy-gt0/ [Kernel PMU event]
xe_0000_03_00.0/copy-group-busy-gt0/ [Kernel PMU event]
xe_0000_03_00.0/interrupts/ [Kernel PMU event]
xe_0000_03_00.0/media-group-busy-gt0/ [Kernel PMU event]
xe_0000_03_00.0/render-group-busy-gt0/ [Kernel PMU event]
and can be read using:
perf stat -e "xe_0000_8c_00.0/render-group-busy-gt0/" -I 1000
time counts unit events
1.001139062 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
2.003294678 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
3.005199582 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
4.007076497 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
5.008553068 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
6.010531563 43520 ns xe_0000_8c_00.0/render-group-busy-gt0/
7.012468029 44800 ns xe_0000_8c_00.0/render-group-busy-gt0/
8.013463515 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
9.015300183 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
10.017233010 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
10.971934120 0 ns xe_0000_8c_00.0/render-group-busy-gt0/
The pmu base implementation is taken from i915.
v2:
Store last known value when device is awake return that while the GT is
suspended and then update the driver copy when read during awake.
v3:
1. drop init_samples, as storing counters before going to suspend should
be sufficient.
2. ported the "drm/i915/pmu: Make PMU sample array two-dimensional" and
dropped helpers to store and read samples.
3. use xe_device_mem_access_get_if_ongoing to check if device is active
before reading the OA registers.
4. dropped format attr as no longer needed
5. introduce xe_pmu_suspend to call engine_group_busyness_store
6. few other nits.
v4: minor nits.
v5: take forcewake when accessing the OAG registers
v6:
1. drop engine_busyness_sample_type
2. update UAPI documentation
v7:
1. update UAPI documentation
2. drop MEDIA_GT specific change for media busyness counter.
Co-developed-by: Tvrtko Ursulin <[email protected]>
Co-developed-by: Bommu Krishnaiah <[email protected]>
Signed-off-by: Aravind Iddamsetty <[email protected]>
Reviewed-by: Ashutosh Dixit <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The min_page_size is useful information to ensure alignment and it is
an API actually in use. However max_page_size doesn't bring any useful
information to the userspace hence being not used at all.
So, let's remove and only bring it back if that ever gets used.
Suggested-by: Thomas Hellström <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
|
|
Fix typos, lingo and other small things identified during uapi
review.
v2: Also fix ALIGNMENT typo at xe_query.c
v3: Do not touch property to get/set. (Francois)
Link: https://lore.kernel.org/all/[email protected]/
Suggested-by: Thomas Hellström <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
|
|
Engine was inappropriately used to refer to execution queues and it
also created some confusion with hardware engines. Where it applies
the exec_queue variable name is changed to q and comments are also
updated.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/162
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Send uevent in case of gt reset failure. This intimation can be used by
userspace monitoring tool to do the device level reset/reboot
when GT reset fails. udevadm can be used to monitor the uevents.
v2:
- Support only gt failure notification (Rodrigo)
v3
- Rectify the comments in header file.
v4
- Use pci kobj instead of drm kobj for notification.(Rodrigo)
- Cleanup (Badal)
v5
- Add tile id and gt id as additional info provided by uevent.
- Provide code documentation for the uevent. (Rodrigo)
Cc: Aravind Iddamsetty <[email protected]>
Cc: Tejas Upadhyay <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Badal Nilawar <[email protected]>
Signed-off-by: Himal Prasad Ghimiray <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This config is the only real one. If execlist remains in the
code it will forever be experimental and we shouldn't maintain
an uapi like that for that experimental piece of code that
should never be used by real users.
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
Mostly the same as i915. We add a new hint for userspace to force an
object into the mappable part of vram.
We also need to tell userspace how large the mappable part is. In Vulkan
for example, there will be two vram heaps for small-bar systems. And
here the size of each heap needs to be known. Likewise the used/avail
tracking needs to account for the mappable part.
We also limit the available tracking going forward, such that we limit
to privileged users only, since these values are system wide and are
technically considered an info leak.
v2 (Maarten):
- s/NEEDS_CPU_ACCESS/NEEDS_VISIBLE_VRAM/ in the uapi. We also no
longer require smem as an extra placement. This is more flexible,
and lets us use this for clear-color surfaces, since we need CPU access
there but we don't want to attach smem, since that effectively disables
CCS from kernel pov.
- Reject clear-color CCS buffers where NEEDS_VISIBLE_VRAM is not set,
instead of migrating it behind the scenes.
v3 (José):
- Split the changes that limit the accounting for perfmon_capable()
into a separate patch.
- Use XE_BO_CREATE_VRAM_MASK.
v4 (Gwan-gyeong Mun):
- Add some kernel-doc for the query bits.
v5:
- One small kernel-doc correction. The cpu_visible_size and
corresponding used tracking are always zero for non
XE_MEM_REGION_CLASS_VRAM.
v6:
- Without perfmon_capable() it likely makes more sense to report as
zero, instead of reporting as used == total size. This should give
similar behaviour as i915 which rather tracks free instead of used.
- Only enforce NEEDS_VISIBLE_VRAM on rc_ccs_cc_plane surfaces when the
device is actually small-bar.
Testcase: igt/tests/xe_query
Testcase: igt/tests/xe_mmap@small-bar
Signed-off-by: Matthew Auld <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Using jiffies as a timeout from userspace is weird even if
theoretically exists possiblity of acquiring jiffies via getconf.
Unfortunately this method is unreliable and the returned
value may vary from the one configured in the kernel config.
Now timeout is expressed in nanoseconds and its interpretation depends
on setting DRM_XE_UFENCE_WAIT_ABSTIME flag. Relative timeout (flag
is not set) means fence expire at now() + timeout. Absolute timeout
(flag is set) means that the fence expires at exact point of time.
Passing negative timeout means we will wait "forever" by setting
wait time to MAX_SCHEDULE_TIMEOUT.
Cc: Andi Shyti <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Zbigniew Kempczyński <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
./include/uapi/drm/xe_drm.h:263: warning: Function parameter or member
'gts' not described in 'drm_xe_query_gts'
./include/uapi/drm/xe_drm.h:854: WARNING: Inline emphasis start-string
without end-string.
With the idea to also include the uapi file in the pre-merge CI hooks
when building the kernel-doc, so first make sure it's clean:
https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/16
v2: (Francois)
- It makes more sense to just fix the kernel-doc for 'gts'
Signed-off-by: Matthew Auld <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Since we need to extend this, we should also take the time to add some
basic kernel-doc here for the existing bits. Note that this is all still
subject to change when upstreaming.
Also convert XE_MEM_REGION_CLASS_* into an enum, so we can more easily
create links to it from other parts of the uapi.
Suggested-by: Gwan-gyeong Mun <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Provide information on the types of topology masks that can be
queried and add some examples.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Align on same rule in the whole file: defines then doc then relevant
field, with an empty line to separate fields.
v2:
- Rebase on drm-xe-next
- Fix ordering of defines and fields in uAPI (Lucas De Marchi)
v3: Remove useless empty lines (Lucas De Marchi)
v4: Move changelog to commit
v5: Rebase
Reported-by: Oded Gabbay <[email protected]>
Link: https://lists.freedesktop.org/archives/intel-xe/2023-May/004704.html
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This adds documentation to the various structures used to query
memory, GTs, topology, engines, and so on. It includes a functional
code snippet to query engines.
v2:
- Rebase on drm-xe-next
- Also document structures related to drm_xe_device_query, changed
pseudo code to snippet (Lucas De Marchi)
v3:
- Move changelog to commit
- Fix warnings showed only using dim checkpath
Reported-by: Oded Gabbay <[email protected]>
Link: https://lists.freedesktop.org/archives/intel-xe/2023-May/004704.html
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add uAPI and implementation for NULL bindings. A NULL binding is defined
as writes dropped and read zero. A single bit in the uAPI has been added
which results in a single bit in the PTEs being set.
NULL bindings are intendedd to be used to implement VK sparse bindings,
in particular residencyNonResidentStrict property.
v2: Fix BUG_ON shown in VK testing, fix check patch warning, fix
xe_pt_scan_64K, update __gen8_pte_encode to understand NULL bindings,
remove else if vma_addr
Reviewed-by: Thomas Hellström <[email protected]>
Suggested-by: Paulo Zanoni <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Fix spacing, alignment, and repeated words in the documentation.
Reported-by: Oded Gabbay <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Move the definition of drm_xe_engine_class_instance to group it with
other engine related structs and to follow the ioctls order.
Reported-by: Oded Gabbay <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|