== Series Details ==
Series: Introduce drm scaling filter property (rev7)
URL : https://patchwork.freedesktop.org/series/73883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8832 -> Patchwork_18296
Summary
---
== Series Details ==
Series: Introduce drm scaling filter property (rev7)
URL : https://patchwork.freedesktop.org/series/73883/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Introduce drm scaling filter property (rev7)
URL : https://patchwork.freedesktop.org/series/73883/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e4e6d491d898 drm: Introduce plane and CRTC scaling filter properties
aef69ee0f157 drm/drm-kms.rst: Add
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest
Add documentation for newly introduced KMS plane and CRTC scaling
filter properties.
changes since v3:
* None
changes since v1:
* None
changes since RFC:
* Add separate documentation for plane and CRTC.
Signed-off-by: Pankaj Bharadiya
---
Documentation/gpu/drm-kms.rst | 12
1 file
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
Earlier, I kept this series on hold since we wanted to have a
reference userspace implementation in place.
Now, Sameer has implemented Integer scaling in Kodi Retro gaming
framework which demonstrate how Integer scaling gives distinctive
look to pixel art games when played on higher resolution
== Series Details ==
Series: series starting with [01/42] drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80179/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8832_full -> Patchwork_18295_full
Hi,
On 7/29/20 10:12 AM, Andy Shevchenko wrote:
On Tue, Jul 28, 2020 at 09:55:22PM +0200, Hans de Goede wrote:
On 7/28/20 8:57 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
...
Maybe I'm too picky, but I would go even further and split apply to
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote:
> Wait, I'm not convinced yet. I know that if a PCI read fails, you
> normally get ~0 data because the host bridge fabricates it to complete
> the CPU load.
>
> But what guarantees that a PCI config register cannot contain ~0?
Well,
Hi,
On 8/2/20 1:25 PM, Andy Shevchenko wrote:
On Sat, Aug 01, 2020 at 04:38:16PM +0200, Hans de Goede wrote:
On 7/29/20 12:54 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
...
One comment to consider, though. There are three channels in that PWM
== Series Details ==
Series: Add generic i915_ggtt ballooning support
URL : https://patchwork.freedesktop.org/series/80177/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8832_full -> Patchwork_18294_full
Summary
---
Quoting Dave Airlie (2020-08-02 18:56:44)
> On Mon, 3 Aug 2020 at 02:44, Chris Wilson wrote:
> >
> > Lots of small incremental improvements to reduce execution latency
> > which basically offsets the small regressions incurred when compared to
> > 5.7. And then there are some major fixes found
On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote:
> On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> > Because the value ~0 has a meaning to some drivers and only
>
> No, ~0 means that the PCI read failed. For *every* PCI device I know.
Wait, I'm not convinced
On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> Because the value ~0 has a meaning to some drivers and only
No, ~0 means that the PCI read failed. For *every* PCI device I know.
Here's me reading from 0xf0 offset of my hostbridge:
# setpci -s 00:00.0 0xf0.l
0100
That
On Mon, 3 Aug 2020 at 02:44, Chris Wilson wrote:
>
> Lots of small incremental improvements to reduce execution latency
> which basically offsets the small regressions incurred when compared to
> 5.7. And then there are some major fixes found while staring agape at
> lockstat.
What introduced
== Series Details ==
Series: series starting with [01/42] drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80179/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8832 -> Patchwork_18295
Summary
== Series Details ==
Series: series starting with [01/42] drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80179/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [01/42] drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80179/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
641fe3760e7f drm/i915/gem: Don't drop the timeline lock during execbuf
1eace725c392
Currently, we construct and teardown the i915_dependency chains using a
global spinlock. As the lists are entirely local, it should be possible
to use an double-lock with an explicit nesting [signaler -> waiter,
always] and so avoid the costly convenience of a global spinlock.
Signed-off-by:
As a topological sort, we expect it to run in linear graph time,
O(V+E). In removing the recursion, it is no longer a DFS but rather a
BFS, and performs as O(VE). Let's demonstrate how bad this is with a few
examples, and build a few test cases to verify a potential fix.
Signed-off-by: Chris
When cloning the engines from the source context, we need to ensure that
the engines are not freed as we copy them, and that the flags we clone
from the source correspond with the engines we copy across. To do this
we need only take a reference to the src->engines, rather than hold the
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 53 ++-
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent
Lots of small incremental improvements to reduce execution latency
which basically offsets the small regressions incurred when compared to
5.7. And then there are some major fixes found while staring agape at
lockstat.
-Chris
___
Intel-gfx mailing list
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data
Watching lock_stat, we noticed that the kmem_cache_free() would cause
the occasional multi-millisecond spike (directly affecting max-holdtime
and so the max-waittime). Delaying our submission of the next ELSP by a
millisecond will leave the GPU idle, so defer the kmem_cache_free()
until
Take a snapshot of the ctx->engines, so we can avoid taking the
ctx->engines_mutex for a mere read in get_engines().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 +
1 file changed, 8 insertions(+), 31 deletions(-)
diff --git
Lift the busy-stats context-in/out implementation out of intel_lrc, so
that we can reuse it for other scheduler implementations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49
drivers/gpu/drm/i915/gt/intel_lrc.c | 34
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be
tasklet_kill() ensures that we _yield_ the processor until a remote
tasklet is completed. However, this leads to a starvation condition as
being at the bottom of the scheduler's runqueue means that anything else
is able to run, including all hogs keeping the tasklet occupied.
Signed-off-by: Chris
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 44 +
1 file changed, 19
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue
Lift the list iteration defines for traversing the signaler/waiter lists
into i915_scheduler.h for reuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 --
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 ++
2 files changed, 10 insertions(+),
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single
As we know when we expect the heartbeat to be checked for completion,
pass this information along as its deadline. We still do not complain if
the deadline is missed, at least until we have tried a few times, but it
will allow for quicker hang detection on systems where deadlines are
adhered to.
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow
A side-effect of our priority inheritance scheme is that we promote
requests from one priority to the next, moving them from one list to the
next. This can often leave the old priority list empty, but still
resident in the rbtree, which we then have to traverse during HW
submission. rb_next() is
Avoid the full blown memory barrier of test_and_set_bit() by noting the
completed request and removing it from the lists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git
Looking to the future, we want to set the scheduling attributes
explicitly and so replace the generic engine->schedule() with the more
direct i915_request_set_priority()
What it loses in removing the 'schedule' name from the function, it
gains in having an explicit entry point with a stated goal.
As context-in/out is now always serialised, we do not have to worry
about concurrent enabling/disable of the busy-stats and can reduce the
atomic_t active to a plain unsigned int, and the seqlock to a seqcount.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client
In anticipation of wanting to be able to call pi from underneath an
engine's active.lock, rework the priority inheritance to primarily work
along an engine's priority queue, delegating any other engine that the
chain may traverse to a worker. This reduces the global spinlock from
governing the
For a modeset/pageflip, there is a very precise deadline by which the
frame must be completed in order to hit the vblank and be shown. While
we don't pass along that exact information, we can at least inform the
scheduler that this request-chain needs to be completed asap.
Signed-off-by: Chris
As we do not have any internal priority levels, the priority can be set
directed from the user values.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +--
.../i915/gem/selftests/i915_gem_object_blt.c |
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Since schedule-in/out is now entirely serialised by the tasklet bitlock,
we do not need to worry about concurrent in/out operations and so reduce
the atomic operations to plain instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
The first "scheduler" was a topographical sorting of requests into
priority order. The execution order was deterministic, the earliest
submitted, highest priority request would be executed first. Priority
inherited ensured that inversions were kept at bay, and allowed us to
dynamically boost
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any.
From: Tianjia Zhang
In function i915_active_acquire_preallocate_barrier(), not all
paths have the return value set correctly, and in case of memory
allocation failure, a negative error code should be returned.
Cc: Chris Wilson
Signed-off-by: Tianjia Zhang
Reviewed-by: Chris Wilson
Since we are not using any internal priority levels, and in the next few
patches will introduce a new index for which the optimisation is not so
lear cut, discard the small table within the priolist.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
Treat the dependency between bonded requests as weak and leave the
remainder of the pair on the GPU if one hangs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
Our timeline lock is our defence against a concurrent execbuf
interrupting our request construction. we need hold it throughout or,
for example, a second thread may interject a relocation request in
between our own relocation request and execution in the ring.
A second, major benefit, is that it
The core of the scheduling algorithm is that we compute the topological
order of the fence DAG. Knowing that we have a DAG, we should be able to
use a DFS to compute the topological sort in linear time. However,
during the conversion of the recursive algorithm into an iterative one,
the
Originally, we used the signal->lock as a means of following the
previous link in its timeline and peeking at the previous fence.
However, we have replaced the explicit serialisation with a series of
very careful probes that anticipate the links being deleted and the
fences recycled before we are
Since we use a flag within i915_request.flags to indicate when we have
boosted the request (so that we only apply the boost) once, this can be
used as the serialisation with i915_request_retire() to avoid having to
explicitly take the i915_request.lock which is more heavily contended.
When we introduced the saturated workload detection to tell us to back
off from semaphore usage [semaphores have a noticeable impact on
contended bus cycles with the CPU for some heavy workloads], we first
introduced it as a per-context tracker. This allows individual contexts
to try and optimise
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff
In the next patch, we remove the strict priority system and continuously
re-evaluate the relative priority of tasks. As such we need to enable
the timeslice whenever there is more than one context in the pipeline.
This simplifies the decision and removes some of the tweaks to suppress
timeslicing,
Pull the individual strands of creating a custom heartbeat requests into
a pair of common functions. This will reduce the number of changes we
will need to make in future.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 56 +--
1 file changed, 38
== Series Details ==
Series: Add generic i915_ggtt ballooning support
URL : https://patchwork.freedesktop.org/series/80177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8832 -> Patchwork_18294
Summary
---
== Series Details ==
Series: Add generic i915_ggtt ballooning support
URL : https://patchwork.freedesktop.org/series/80177/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
Quoting Michal Wajdeczko (2020-08-02 16:34:09)
> Reserving part of the GGTT for the GuC requires same steps
> as in VGT GGTT ballooning. Add generic GGTT ballooning
> helpers to intel_ggtt.c to avoid code duplication.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Xiong Zhang
> Cc: Chris Wilson
>
Since VGT ballooning nodes are GGTT specific, we can move them
to i915_ggtt struct close to some other similar nodes. This way
we drop another place in driver that uses static data.
Signed-off-by: Michal Wajdeczko
Cc: Xiong Zhang
Cc: Chris Wilson
Cc: Jani Nikula
---
Rebase forgotten series [1]
[1] https://patchwork.freedesktop.org/series/71920/
Michal Wajdeczko (2):
drm/i915/ggtt: Add generic i915_ggtt ballooning support
drm/i915/vgt: Move VGT GGTT ballooning nodes to i915_ggtt
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69 +++--
Reserving part of the GGTT for the GuC requires same steps
as in VGT GGTT ballooning. Add generic GGTT ballooning
helpers to intel_ggtt.c to avoid code duplication.
Signed-off-by: Michal Wajdeczko
Cc: Xiong Zhang
Cc: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69
Hi Anitha.
On Thu, Jul 30, 2020 at 01:44:44PM -0700, Anitha Chrisanthus wrote:
> This is a basic KMS atomic modesetting display driver for KeemBay family of
> SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> driver at the connector level.
>
> Single CRTC with LCD
== Series Details ==
Series: drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80175/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8830_full -> Patchwork_18293_full
Summary
---
On 8/1/20 5:56 AM, Borislav Petkov wrote:
> On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
>> The return value of pci_read_config_*() may not indicate a device error.
>> However, the value read by these functions is more likely to indicate
>> this kind of error. This
> > > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > > b/drivers/gpu/drm/i915/i915_active.c
> > > index d960d0be5bd2..cc017e3cc9c5 100644
> > > --- a/drivers/gpu/drm/i915/i915_active.c
> > > +++ b/drivers/gpu/drm/i915/i915_active.c
> > > @@ -758,7 +758,7 @@ int
== Series Details ==
Series: drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8830 -> Patchwork_18293
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: Fix wrong return value
URL : https://patchwork.freedesktop.org/series/80175/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
From: Tianjia Zhang
In function i915_active_acquire_preallocate_barrier(), not all
paths have the return value set correctly, and in case of memory
allocation failure, a negative error code should be returned.
Cc: Chris Wilson
Signed-off-by: Tianjia Zhang
Reviewed-by: Chris Wilson
Quoting Andi Shyti (2020-08-02 12:40:44)
> Hi Tianjia,
>
> > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > b/drivers/gpu/drm/i915/i915_active.c
> > index d960d0be5bd2..cc017e3cc9c5 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@
Hi Tianjia,
> diff --git a/drivers/gpu/drm/i915/i915_active.c
> b/drivers/gpu/drm/i915/i915_active.c
> index d960d0be5bd2..cc017e3cc9c5 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -758,7 +758,7 @@ int
On Sat, Aug 01, 2020 at 04:38:16PM +0200, Hans de Goede wrote:
> On 7/29/20 12:54 PM, Andy Shevchenko wrote:
> > On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
...
> > One comment to consider, though. There are three channels in that PWM AFAIU.
> > One of them is backlight
80 matches
Mail list logo
