On Mon, 29 Aug 2016, Andrea Arcangeli wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> CC'ed Martin w
On ma, 2016-08-29 at 16:45 +0100, Chris Wilson wrote:
> On Mon, Aug 29, 2016 at 04:43:04PM +0300, Joonas Lahtinen wrote:
> >
> > On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > > + * (and so added to the list to be woken).
> > > + */
> > > +
> > > + smp_mb__before_spinlock();
> > > + s
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> +static int __i915_sw_fence_call submit_notify(struct i915_sw_fence *fence)
> +{
> + struct drm_i915_gem_request *request =
> + container_of(fence, typeof(*request), submit);
> +
> + if (i915_sw_fence_done(fence))
notify_e
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> We are about to specialize object synchronisation to enable nonblocking
> execbuf submission. First we make a copy of the current object
> synchronisation for execbuffer. The general i915_gem_object_sync() will
> be removed following the remov
On Tue, 30 Aug 2016, Martin van Es wrote:
> Hi Andrea,
>
> I'd be happy to test, but what am I testing when applying these boot
> parameters? In other words: what should I report?
The point is, for an ivybridge setting those parameters should not make
*any* difference.
BR,
Jani.
>
> And just
Rather than blindly assuming we need to advance the tail for
resubmitting the request via the ELSP, record the position.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.h | 15 +--
drivers/gpu/drm/i915/intel_lrc.c| 4 ++--
2
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The s
The GuC required a couple of fixes to allow deferred request submission
and for reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Similar to the issue with reading from the context status buffer,
see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the
execlists lock"), we frequently write to the ELSP register (4 writes per
interrupt) and know we hold the required spinlock and forcewake throughout.
We can further re
Access to intel_init_emon() is strictly ordered by gt_powersave, using
struct_mutex around it is overkill (and will conflict with the caller
holding struct_mutex themselves).
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed, 2 del
Just rearrange the code to reduce churn in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.
A side-effect
We need finer control over wakeup behaviour during i915_wait_request(),
so expand the current bool interruptible to a bitmask.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_request.c | 7 ---
driver
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will bec
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.
The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This
If a waiter is holding the struct_mutex, then the reset worker cannot
reset the GPU until the waiter returns. We do not want to return -EAGAIN
form i915_wait_request as that breaks delicate operations like
i915_vma_unbind() which often cannot be restarted easily, and returning
-EIO is just as usele
Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reserve some space in the
GuC command queue fo
In preparation for introducing a per-engine reset, we can first separate
the mixing of the reset state from the global reset counter.
The loss of atomicity in updating the reset state poses a small problem
for handling the waiters. For requests, this is solved by advancing the
seqno so that a wait
Leave the more complicated request dequeueing to the tasklet and instead
just kick start the tasklet if we detect we are adding the first
request.
v2: Play around with list operators until we agree upon something
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
dri
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.
Signed-off-by: Chris Wilso
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
Signed-off-by: C
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> @@ -442,6 +442,18 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> */
> req->head = req->ring->tail;
>
> + prev = i915_gem_active_peek(&engine->last_request,
> + &req->i915->drm.str
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> Now that we can wait upon fences before emitting the request, it becomes
> trivial to wait upon any implicit fence provided by the dma-buf
> reservation object.
>
> Testcase: igt/prime_vgem/fence-wait
> Signed-off-by: Chris Wilson
> Reviewed
On Tue, Aug 30, 2016 at 11:35:14AM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > @@ -442,6 +442,18 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> > */
> > req->head = req->ring->tail;
> >
> > + prev = i915_gem_active_peek(&engine
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> Userspace is faced with a dilemma. The kernel requires implicit fencing
> to manage resource usage (we always must wait for the GPU to finish
> before releasing its PTE) and for third parties. However, userspace may
> wish to avoid this serial
On ti, 2016-08-30 at 09:43 +0100, Chris Wilson wrote:
> On Tue, Aug 30, 2016 at 11:35:14AM +0300, Joonas Lahtinen wrote:
> >
> > On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > >
> > > @@ -442,6 +442,18 @@ i915_gem_request_alloc(struct intel_engine_cs
> > > *engine,
> > > */
> > >
== Series Details ==
Series: series starting with [01/18] drm/i915: Add a sw fence for collecting up
dma fences
URL : https://patchwork.freedesktop.org/series/11768/
State : success
== Summary ==
Series 11768v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11768/
On Tue, Aug 30, 2016 at 11:45:10AM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > Userspace is faced with a dilemma. The kernel requires implicit fencing
> > to manage resource usage (we always must wait for the GPU to finish
> > before releasing its PTE)
On Tue, Aug 30, 2016 at 08:57:12AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [01/18] drm/i915: Add a sw fence for collecting
> up dma fences
> URL : https://patchwork.freedesktop.org/series/11768/
> State : success
>
> == Summary ==
>
> Series 11768v1 Ser
On Tue, Aug 30, 2016 at 11:10:29AM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> > We are about to specialize object synchronisation to enable nonblocking
> > execbuf submission. First we make a copy of the current object
> > synchronisation for execbuffer.
On dinsdag 30 augustus 2016 11:13:40 CEST Jani Nikula wrote:
> On Tue, 30 Aug 2016, Martin van Es wrote:
> > Hi Andrea,
> >
> > I'd be happy to test, but what am I testing when applying these boot
> > parameters? In other words: what should I report?
>
> The point is, for an ivybridge setting th
Hi Andrea,
I'd be happy to test, but what am I testing when applying these boot
parameters? In other words: what should I report?
And just to be sure, I THINK I own an IVB but intel is not very vocal about it
when searching for familyname. I have a
vendor_id : GenuineIntel
cpu family
Hi Jani,
These patches made my brightness and screen off hot keys back to work.
Tested-by: Marcos Paulo de Souza
On Sat, Aug 27, 2016 at 10:51:51PM +0200, Peter Wu wrote:
> Hi Jani,
>
> The method is somehow not reliable. At boot I was still able to capture
> brightness hotkeys (via acpi_liste
On su, 2016-08-28 at 21:46 +0100, Chris Wilson wrote:
> @@ -1915,6 +1979,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> ret = execbuf_submit(params, args, &eb->vmas);
> err_request:
> __i915_add_request(params->request, ret == 0);
> + if (out_fence) {
> +
On Fri, Aug 26, 2016 at 06:50:56PM +0100, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
> provides several other useful intermediate levels such as NOTICE and
> WARNING. So this patch fills out the set by providing simple macros for
> the additional le
The intention behind EXEC_OBJECT_ASYNC is to instruct the kernel to
ignore implicit fences on the object but still maintain them for the GEM
API. The user is expected to provide explicit fencing to maintain
correct ordering of rendering.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources |
When execbuf2 supports explicit fencing with sync_file in/out fences
(via a fence-fd), we can control execution via the fence.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/gem_exec_fence.c | 366 +
2 files changed, 367 inse
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
v2: Do the fence
On ma, 2016-08-29 at 16:25 +0100, Chris Wilson wrote:
> On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > Hmm, this always confuses me. Is the freeze callback called to
> > > the
> > > loader kernel?
> >
> > It's called both
On ma, 2016-08-29 at 18:46 +0200, Lukas Wunner wrote:
> On Mon, Aug 29, 2016 at 04:25:25PM +0100, Chris Wilson wrote:
> > On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > > Hmm, this always confuses me. Is the freeze callb
== Series Details ==
Series: series starting with [01/17] drm/i915: Add a sw fence for collecting up
dma fences (rev2)
URL : https://patchwork.freedesktop.org/series/11684/
State : success
== Summary ==
Series 11684v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
Hi Jani
Following the thread :
http://www.spinics.net/lists/intel-gfx/msg92832.html
I tried to build a kernel with the patch
https://patchwork.freedesktop.org/series/4783/ but did not succeed.
What i did is: git clone git https://cgit.freedesktop.org/~jani/drm/
then i looked into the intel_op
In preparation for introducing a per-engine reset, we can first separate
the mixing of the reset state from the global reset counter.
The loss of atomicity in updating the reset state poses a small problem
for handling the waiters. For requests, this is solved by advancing the
seqno so that a wait
Chris Wilson writes:
> In preparation for introducing a per-engine reset, we can first separate
> the mixing of the reset state from the global reset counter.
>
> The loss of atomicity in updating the reset state poses a small problem
> for handling the waiters. For requests, this is solved by ad
== Series Details ==
Series: series starting with [01/17] drm/i915: Add a sw fence for collecting up
dma fences (rev3)
URL : https://patchwork.freedesktop.org/series/11684/
State : success
== Summary ==
Series 11684v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> Set the intel_crtc->active flag after pipe/crtc is actually active in
> haswell_crtc_enable function.
Why?
Can you please elaborate more on why this change is needed, what are
the benefits it brings, what are the problems it solves and
Hi
Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> This patch enables Transition WM for SKL+ platforms.
>
> Transition WM are used if IPC is enabled, to decide, number of blocks
> to be fetched before reducing the priority of display to fetch from
> memory.
>
> Signed-off-by: Kumar,
Hello,
nope, also after suspend nothing changed.
I also tried using evtest before and after the patch and I got the same
result: nothing shows up when I press FN+F8/F9 (brightness)
--
Paolo Stivanin
paolostiva...@fastmail.fm
Public Key ID: E71B7545
On Mon, Aug 29, 2016, at 08:42 AM, Maarte
On Tue, 2016-08-30 at 08:59 +0800, Randy Li wrote:
> Hi all:
> When I just doing the driver for us chip, we would request the
> Nalu
> header present in the data to be process. But I found the data be
> Rendered to with type VASliceDataBufferType is removed the Nalu start
> code. Is there any
On 08/31/2016 09:52 AM, Xiang, Haihao wrote:
On Tue, 2016-08-30 at 08:59 +0800, Randy Li wrote:
Hi all:
When I just doing the driver for us chip, we would request the
Nalu
header present in the data to be process. But I found the data be
Rendered to with type VASliceDataBufferType is remove
53 matches
Mail list logo
