intel_crtc is being allocated as part of intel_modeset_init_nogem
and not freed as part of driver remove. This will lead to memory
leak. Hence free up the allocated crtc on driver remove as part of
intel_modeset_driver_remove_nogem.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/i
On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
> > On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> > > VM_BIND and related uapi definitions
> > >
> > > v2: Reduce the scope to simple Mesa
On Wed, Jun 29, 2022 at 11:15:31PM -0700, Niranjana Vishwanathapura wrote:
On Thu, Jun 30, 2022 at 12:11:15AM -0500, Jason Ekstrand wrote:
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura
wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case
On Mon, Jun 27, 2022 at 10:55:16AM +0200, Daniel Vetter wrote:
On Sat, Jun 25, 2022 at 12:02:19PM -0700, Niranjana Vishwanathapura wrote:
On Fri, Jun 24, 2022 at 10:07:26PM +0200, Daniel Vetter wrote:
> On Fri, Jun 24, 2022 at 10:49:36AM -0700, Niranjana Vishwanathapura wrote:
> > VM_BIND and re
On Thu, Jun 30, 2022 at 12:11:15AM -0500, Jason Ekstrand wrote:
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura
wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIN
On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VA
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev2)
URL : https://patchwork.freedesktop.org/series/105167/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_105167v2_full
Summary
On Wed, Jun 29, 2022 at 05:38:59PM -0700, Zanoni, Paulo R wrote:
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
v3: Expand documentation on dma-resv usage, TLB flus
== Series Details ==
Series: drm/i915/reset: Handle reset timeouts under unrelated kernel hangs
(rev2)
URL : https://patchwork.freedesktop.org/series/105748/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11828 -> Patchwork_105748v2
On Sat, Jun 25, 2022 at 8:49 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM
== Series Details ==
Series: drm/fb-helper: Remove helpers to change frame buffer config
URL : https://patchwork.freedesktop.org/series/105773/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_105773v1_full
=
From: Chris Wilson
When resuming after hibernate sometimes we see hangs in unrelated kernel
subsystems. These hangs often result in the following i915 trace:
i915 :00:02.0: [drm] *ERROR* \
intel_gt_reset_global timed out, cancelling all in-flight rendering
implying our reset task ha
Ping?
On 2022/06/10 23:57, Tetsuo Handa wrote:
> Then, does this flush_scheduled_work() mean to wait all
> schedule_work()/schedule_delayed_work()
> calls inside drivers/gpu/drm/i915/ directory?
== Series Details ==
Series: drm/edid: expand on struct drm_edid usage (rev8)
URL : https://patchwork.freedesktop.org/series/104309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825_full -> Patchwork_104309v8_full
Summar
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand documentation on dma-resv usage, TLB flushing and
> execbuf3.
> v4: Remove vm_bind tlb flush requ
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remo
On Wed, Jun 29, 2022 at 09:20:46PM +, Patchwork wrote:
== Series Details ==
Series: series starting with [CI,1/2] iosys-map: Add per-word read (rev2)
URL : https://patchwork.freedesktop.org/series/105746/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11823_full -> Patchw
On Wed, Jun 29, 2022 at 03:16:09PM -0700, Matt Roper wrote:
On Mon, Jun 27, 2022 at 03:59:28PM +0300, Lionel Landwerlin wrote:
The recommended number of stackIDs for Ray Tracing subsystem is 512
rather than 2048 (default HW programming).
v2: Move the programming to dg2_ctx_gt_tuning_init() (Luc
On Mon, Jun 27, 2022 at 03:59:28PM +0300, Lionel Landwerlin wrote:
> The recommended number of stackIDs for Ray Tracing subsystem is 512
> rather than 2048 (default HW programming).
>
> v2: Move the programming to dg2_ctx_gt_tuning_init() (Lucas)
I'm not sure this is actually the correct move. A
On Wed, Jun 29, 2022 at 06:47:21AM -0700, José Roberto de Souza wrote:
> Display is turned off by i915_drm_suspend() during the suspend
> procedure, removing the last reference of some gem objects that were
> used by display.
>
> The issue is that those objects are only actually freed when
> mm.fr
== Series Details ==
Series: series starting with [CI,1/2] iosys-map: Add per-word read (rev2)
URL : https://patchwork.freedesktop.org/series/105746/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11823_full -> Patchwork_105746v2_full
===
Sorry for the late review. I finally got some time to look at this.
On Mon, 16 May 2022 16:56:39 -0600
Jim Cromie wrote:
> diff --git a/include/trace/events/drm.h b/include/trace/events/drm.h
> new file mode 100644
> index ..6de80dd68620
> --- /dev/null
> +++ b/include/trace/event
== Series Details ==
Series: drm/i915: Fix NPD in PMU during driver teardown
URL : https://patchwork.freedesktop.org/series/105790/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105790v1
Summary
---
== Series Details ==
Series: drm/i915: Remove __dma_fence_is_chain()
URL : https://patchwork.freedesktop.org/series/105760/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105760v1_full
Summary
---
kms_frontbuffer_tracking@basic falls over if the fb needs to be migrated
from non-mappable device memory, to the mappable part, due to being
temporarily pinned for scanout, when hitting the CPU fault handler,
which just gives us SIGBUS. If the device has a small BAR let's attempt
to use the mappabl
We should mark the objects that need to be captured with
NEEDS_CPU_ACCESS to ensure we can capture them if they are allocated in
lmem. We also need to consider that capture only properly works on
non-recoverable context, for discrete platforms. We can now also expect
CPU invisible objects to be ski
Will be useful later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
lib/i915/intel_memory_region.c | 2 ++
lib/i915/intel_memory_region.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/i915/intel_memory_region.c b/lib/i915/intel_memory_region.c
index 3
Sanity both the unallocated_size & unallocated_cpu_visible_size tracking.
v2(Petri): always use from_user_pointer()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
tests/i915/i915_query.c | 274 +++-
1 file changed, 273 insertio
Add some basic sanity checks for this, like checking if this falls
within the probed_size. On older kernels the value reported here should
be zero.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
tests/i915/i915_query.c | 19 ---
1 file changed, 16
Most users shouldn't care about such an interface, but where required,
this should be useful to aid in setting NEEDS_CPU_ACCESS for a given BO.
Underneath we try to smooth over needing to provide an explicit SMEM
region, or if this is SMEM-only, we don't want the kernel to throw an
error.
Signed-o
Add some basic tests for this new flag.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
tests/i915/gem_create.c | 309 +++-
1 file changed, 308 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_c
For now dump into i915_drm_local.h. Once the uapi on the kernel side is
merged, and is part of drm-next, we can sync the kernel headers and
remove this.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
lib/i915/i915_drm_local.h | 21 +
1 file cha
For now limit to direct callers.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
lib/i915/gem_create.c | 9 ++---
lib/i915/gem_create.h | 5 +++--
lib/i915/intel_memory_region.c | 2 +-
tests/i915/gem_create.c| 24 --
In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
se
== Series Details ==
Series: series starting with [CI,v4,01/13] drm/doc: add rfc section for small
BAR uapi
URL : https://patchwork.freedesktop.org/series/105787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105787v1
===
== Series Details ==
Series: drm/i915: use DISPLAY_VER() instead of accessing match_info directly
(rev2)
URL : https://patchwork.freedesktop.org/series/105734/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105734v2_full
== Series Details ==
Series: series starting with [CI,v4,01/13] drm/doc: add rfc section for small
BAR uapi
URL : https://patchwork.freedesktop.org/series/105787/
State : warning
== Summary ==
Error: dim checkpatch failed
1e231f799d31 drm/doc: add rfc section for small BAR uapi
-:46: WARNING:
Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which smells like an info
leak.
Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs
objects"
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage. Also
extend to newer integrated platforms.
v2(Thomas):
- Also extend to newer integrated
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR. Also tweak
the locking so we nice consistent values for both the mm->avail and the
visible track
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landw
We should always be explicit and allocate a fence slot before adding a
new fence.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
v2: (Nirmoy & Thomas):
- s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so plumb that thr
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Da
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access.
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +--
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
== Series Details ==
Series: drm/i915: Drain freed object after suspend display (rev3)
URL : https://patchwork.freedesktop.org/series/105779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v3
Summary
== Series Details ==
Series: drm/i915/guc: ADL-N should use the same GuC FW as ADL-S (rev3)
URL : https://patchwork.freedesktop.org/series/105444/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11822_full -> Patchwork_105444v3_full
==
On 6/29/22 18:28, Matthew Auld wrote:
On 29/06/2022 17:11, Thomas Hellström wrote:
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or mems
On 29/06/2022 17:22, Thomas Hellström wrote:
On 6/29/22 14:14, Matthew Auld wrote:
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
obje
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev2)
URL : https://patchwork.freedesktop.org/series/105167/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105167v2
Summary
---
On 29/06/2022 17:11, Thomas Hellström wrote:
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this f
On 6/29/22 14:14, Matthew Auld wrote:
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.
Signed-off-by: Matthew Au
On 6/29/22 14:14, Matthew Auld wrote:
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
v2: (Nirmoy & Thomas):
- s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.
Signed-off-by: Matthew Auld
C
Hi, Matthew,
On 6/29/22 14:14, Matthew Auld wrote:
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now w
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev2)
URL : https://patchwork.freedesktop.org/series/105167/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev2)
URL : https://patchwork.freedesktop.org/series/105167/
State : warning
== Summary ==
Error: dim checkpatch failed
b88ec824a39f drm/i915/gt: Ignore TLB invalidations on idle engines
-:132: CHECK:MACRO_ARG_REUSE: Macro
On 29/06/2022 16:30, Mauro Carvalho Chehab wrote:
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
.. which for me means a different patch 1, followed by patch 6 (moved
to be patch 2) would be ideal stable material.
Then we have the current patch 2 which is open/unknown (to me at le
== Series Details ==
Series: drm/i915: Drain freed object after suspend display (rev2)
URL : https://patchwork.freedesktop.org/series/105779/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v2
Summary
On Wed, Jun 29, 2022 at 02:28:59PM +0300, Alexander Usyskin wrote:
> Add GSC support for XeHP SDV and DG2 platforms.
>
> The series includes changes for the mei driver:
> - add ability to use polling instead of interrupts
> - add ability to use extended timeouts
> - setup extended operational memo
On Wed, Jun 29, 2022 at 02:29:12PM +0300, Alexander Usyskin wrote:
> From: Tomas Winkler
>
> Add pxp mode devstate to debugfs to monitor
> pxp state machine progress. During debug
> it is important to understand in what state
> the pxp handshake is.
>
> CC: Vitaly Lubart
> Signed-off-by: Tomas
On Wed, Jun 29, 2022 at 02:29:12PM +0300, Alexander Usyskin wrote:
> From: Tomas Winkler
>
> Add pxp mode devstate to debugfs to monitor
> pxp state machine progress. During debug
> it is important to understand in what state
> the pxp handshake is.
You have 72 columns for changelog text, as you
Issue is related to https://gitlab.freedesktop.org/drm/intel/-/issues/6310
All tests - general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b7c6b
Since we have clean BAT results from Rev 2, I haven’t re-reported.
Lakshmi.
From: Lucas De Marchi
Sent: Tuesday, June 28, 2022
On Tue, 28 Jun 2022 16:49:23 +0100
Tvrtko Ursulin wrote:
>.. which for me means a different patch 1, followed by patch 6 (moved
> to be patch 2) would be ideal stable material.
>
> Then we have the current patch 2 which is open/unknown (to me at least).
>
> And the rest seem like optimisations
From: Chris Wilson
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmi
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no
From: Chris Wilson
As an extension of the current skip TLB invalidations,
check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed.
This becomes more significant with GuC, as it can o
i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
When such test runs, the only output is:
[ 68.811639] i915: Performing live selftes
== Series Details ==
Series: small BAR uapi bits (rev5)
URL : https://patchwork.freedesktop.org/series/104369/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_104369v5
Summary
---
**FAILURE**
Seri
== Series Details ==
Series: small BAR uapi bits (rev5)
URL : https://patchwork.freedesktop.org/series/104369/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: small BAR uapi bits (rev5)
URL : https://patchwork.freedesktop.org/series/104369/
State : warning
== Summary ==
Error: dim checkpatch failed
fca09013097d drm/doc: add rfc section for small BAR uapi
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), d
== Series Details ==
Series: drm/i915: Drain freed object after suspend display
URL : https://patchwork.freedesktop.org/series/105779/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105779v1
Summary
--
== Series Details ==
Series: drm/i915/guc/slpc: Add a new SLPC selftest (rev5)
URL : https://patchwork.freedesktop.org/series/105005/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11820_full -> Patchwork_105005v5_full
Summa
Display is turned off by i915_drm_suspend() during the suspend
procedure, removing the last reference of some gem objects that were
used by display.
The issue is that those objects are only actually freed when
mm.free_work executed and that can happen very late in the suspend
process causing issue
On Tue, 07 Jun 2022, Lyude Paul wrote:
> As Daniel Vetter pointed out, if we only use the atomic modesetting locks
> with MST it's technically possible for a driver with non-blocking modesets
> to race when it comes to MST displays - as we make the mistake of not doing
> our own CRTC commit tracki
== Series Details ==
Series: drm/edid: expand on struct drm_edid usage (rev7)
URL : https://patchwork.freedesktop.org/series/104309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11820_full -> Patchwork_104309v7_full
Summar
== Series Details ==
Series: small BAR uapi bits (rev4)
URL : https://patchwork.freedesktop.org/series/104369/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_104369v4
Summary
---
**FAILURE**
Seri
== Series Details ==
Series: small BAR uapi bits (rev4)
URL : https://patchwork.freedesktop.org/series/104369/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: small BAR uapi bits (rev4)
URL : https://patchwork.freedesktop.org/series/104369/
State : warning
== Summary ==
Error: dim checkpatch failed
0815fb1423e5 drm/doc: add rfc section for small BAR uapi
-:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), d
== Series Details ==
Series: GSC support for XeHP SDV and DG2 platforms (rev4)
URL : https://patchwork.freedesktop.org/series/102339/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_102339v4
Summary
---
On 28/06/2022 17:22, Robert Beckett wrote:
On 28/06/2022 09:46, Tvrtko Ursulin wrote:
On 27/06/2022 18:08, Robert Beckett wrote:
On 22/06/2022 10:05, Tvrtko Ursulin wrote:
On 21/06/2022 20:11, Robert Beckett wrote:
On 21/06/2022 18:37, Patchwork wrote:
*Patch Details*
*Series:*
On 2022-06-29 at 13:14:26 +0100, Matthew Auld wrote:
> Falling back to memcpy/memset shouldn't be allowed if we know we have
> CCS state to manage using the blitter. Otherwise we are potentially
> leaving the aux CCS state in an unknown state, which smells like an info
> leak.
>
> Fixes: 48760ffe9
== Series Details ==
Series: drm/fb-helper: Remove helpers to change frame buffer config
URL : https://patchwork.freedesktop.org/series/105773/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11825 -> Patchwork_105773v1
Summa
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
v2: (Nirmoy & Thomas):
- s/full BAR/Resizable BAR/ which is hopefully more easily
understood by users.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Falling back to memcpy/memset shouldn't be allowed if we know we have
CCS state to manage using the blitter. Otherwise we are potentially
leaving the aux CCS state in an unknown state, which smells like an info
leak.
Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs
objects"
If the move or clear operation somehow fails, and the memory underneath
is not cleared, like when moving to lmem, then we currently fallback to
memcpy or memset. However with small-BAR systems this fallback might no
longer be possible. For now we use the set_wedged sledgehammer if we
ever encounter
We should always be explicit and allocate a fence slot before adding a
new fence.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas
It's not supported, and just skips later anyway. With small-BAR things
get more complicated since all of stolen is likely not even CPU
accessible, hence not passing I915_BO_ALLOC_GPU_ONLY just results in the
object create failing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landw
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Da
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access.
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +--
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage. Also
extend to newer integrated platforms.
v2(Thomas):
- Also extend to newer integrated
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so plumb that thr
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR. Also tweak
the locking so we nice consistent values for both the mm->avail and the
visible track
IGT: https://patchwork.freedesktop.org/series/104368/#rev2
Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16739
--
2.36.1
1 - 100 of 137 matches
Mail list logo
