This should enable accurate frontbuffer tracking and keep PSR disabled
whilst (and only while) the scanout is being directly accessed either by
the CPU or by the GPU. The important difference here is that the
tracking is more accurate and we check in the re-enable worker whether
the fb is still bei
On Sat, Jun 14, 2014 at 01:39:45AM +0200, Daniel Vetter wrote:
> On Fri, Jun 13, 2014 at 10:32 PM, Chris Wilson
> wrote:
> > Let userspace know the status of Panel Self-Refresh by virtue of a
> > property on the appropriate connector.
> >
> > v2: Only attach the property if the driver is capable
On Fri, Jun 13, 2014 at 10:32 PM, Chris Wilson wrote:
> Let userspace know the status of Panel Self-Refresh by virtue of a
> property on the appropriate connector.
>
> v2: Only attach the property if the driver is capable of PSR.
>
> Signed-off-by: Chris Wilson
Shouldn't we attach this to the cr
From: Paulo Zanoni
Any comment containing "current Intel hardware supports" quickly
becomes obsolete, so remove it and let people discover the information
by looking at the function implementation.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
1 file changed, 1 in
From: Paulo Zanoni
Two BSpec updates changed the recommended values for BDW eDP and DP
DDI buffer translations. Now the signal levels also match the HSW signal
levels, which simplify things a little bit.
It seems some DP sinks don't work properly without voltage level 0 and
pre-emphasis level 3,
Let userspace know the status of Panel Self-Refresh by virtue of a
property on the appropriate connector.
v2: Only attach the property if the driver is capable of PSR.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_dp.c| 13
Let userspace know the status of Panel Self-Refresh by virtue of a
property on the appropriate connector.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_dp.c| 13 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i
On Fri, Jun 13, 2014 at 09:51:22PM +0200, Christoph Jaeger wrote:
> intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
> 'intel_connector' point to. Simply bail out before allocating memory.
>
> Picked up by Coverity - CID 1222750.
>
> Signed-off-by: Christoph Jaeger
Queued f
intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
'intel_connector' point to. Simply bail out before allocating memory.
Picked up by Coverity - CID 1222750.
Signed-off-by: Christoph Jaeger
---
drivers/gpu/drm/i915/intel_dsi.c | 14 +++---
1 file changed, 7 insertions
On Fri, Jun 13, 2014 at 05:10:03AM -0700, Rodrigo Vivi wrote:
> The perfect solution for psr_exit is the hardware tracking the changes and
> doing the psr exit by itself. This scenario works for HSW and BDW with some
> environments like Gnome and Wayland.
>
> However there are many other scenarios
On Fri, Jun 13, 2014 at 05:10:03AM -0700, Rodrigo Vivi wrote:
> The perfect solution for psr_exit is the hardware tracking the changes and
> doing the psr exit by itself. This scenario works for HSW and BDW with some
> environments like Gnome and Wayland.
>
> However there are many other scenarios
The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.
However there are many other scenarios that this isn't true. Mainly one right
now is KDE users on HSW and BDW
On Fri, Jun 13, 2014 at 04:37:20PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> The reason for doing this will be better explained in the following
> patch. For now, suffice it to say that this backing object is only
> used with the render ring, so we're making this fact more expli
On Fri, Jun 13, 2014 at 04:37:23PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> ... and namespace appropriately.
>
> It looks to me like it belongs logically there.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h| 3 +++
> drivers/gpu/drm/i91
On Fri, Jun 13, 2014 at 04:37:20PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> The reason for doing this will be better explained in the following
> patch. For now, suffice it to say that this backing object is only
> used with the render ring, so we're making this fact more expli
On Fri, Jun 13, 2014 at 04:37:55PM +0100, oscar.ma...@intel.com wrote:
> +static void execlists_elsp_write(struct intel_engine_cs *ring,
> + struct drm_i915_gem_object *ctx_obj0,
> + struct drm_i915_gem_object *ctx_obj1)
> +{
> + struct
As a small summary, I don't think we should be exposing the
plane_commit() function and always go through igt_display_commit() to
make hooking the atomic ioctl() easier. Loosing the plane ordering is a
bit meh but should be able to live with it. The rest looks good.
--
Damien
On Fri, Jun 13, 2014 at 04:38:01PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Since the ringbuffer does not belong per engine anymore, we have to
> make sure that we are always recording the correct ringbuffer.
>
> TODO: This is only a small fix to keep basic error capture worki
On Fri, Jun 13, 2014 at 07:45:50PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 13, 2014 at 09:28:33AM -0700, Jesse Barnes wrote:
> > Early revs didn't have PPGTT support, so disable there.
> >
> > v2: add debug msg when disabling on early stepping
> > v3: enable on other B3 packages as well (unteste
On Fri, Jun 13, 2014 at 04:38:09PM +0100, oscar.ma...@intel.com wrote:
> +/**
> + * intel_execlists_ctx_id() - get the Execlists Context ID
> + * @ctx_obj: Logical Ring Context backing object.
> + *
> + * Do not confuse with ctx->id! Unfortunately we have a name overload
> + * here: the old context
On Fri, Jun 13, 2014 at 09:28:33AM -0700, Jesse Barnes wrote:
> Early revs didn't have PPGTT support, so disable there.
>
> v2: add debug msg when disabling on early stepping
> v3: enable on other B3 packages as well (untested) (Ville)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=
On Fri, Jun 13, 2014 at 05:26:17PM +0100, Chris Wilson wrote:
> When using remap_pfn_range() from a fault handler, we are exposed to
> races between concurrent faults. Rather than hitting a BUG, report the
> error back to the caller, like vm_insert_pfn().
>
> Signed-off-by: Chris Wilson
> Cc: And
Hans de Goede writes:
>>> If I set video.use_native_backlight=0 in kernel command line the problem
>>> goes away. Or if I revert your commit 0e9f81d3b7c the problem also goes
>>> away. Any ideas?
>>
>> Not really...
>> I've added i915 people maybe they have an idea.
>
> This is a known issue in
On Fri, 13 Jun 2014 17:02:10 +0100
Chris Wilson wrote:
> On Fri, Jun 13, 2014 at 06:54:02PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote:
> > > Early revs didn't have PPGTT support, so disable there.
> > >
> > > References: https://bugs.freedesktop
And also pimp the spatch file itself with usage hints.
Signed-off-by: Daniel Vetter
---
NEWS | 3 +++
lib/igt.cocci | 8
2 files changed, 11 insertions(+)
diff --git a/NEWS b/NEWS
index ee920744f4c4..33354f9d5360 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,9 @@
Release 1.8 (-
Re-run with correct igt_fail rules. Again manually fixup missing
includes for igt_core.h.
Signed-off-by: Daniel Vetter
---
tests/ddi_compute_wrpll.c | 12 +
tests/drv_hangman.c | 14 ++
tests/gem_bad_reloc.c | 4 +-
tests/gem_fence_upload.c| 18 ++
I've yet again totally screwed things up (this time automated with
cocci even, but not yet pushed luckily). So finally add a new version
for easier conversion and adjust the cocci script.
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 9 -
lib/igt_core.h | 28
These should go to stdout instead. The next patch will clean this up
with cocci, so no change from fprintf(stdout, to printf( here.
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 1 +
tests/gem_stress.c | 2 +-
tests/testdisplay.c | 34 +-
3 files chang
abort should only be used for internal library checks - using
abort() we get a "crash" result, using igt_fail we get "fail"
in piglit.
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/igt.cocci b/lib/igt.cocci
index 97aa43f9f057..dcb7b
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 8
1 file changed, 8 insertions(+)
diff --git a/lib/igt.cocci b/lib/igt.cocci
index dcb7bbc94dd0..e944c7d12f4f 100644
--- a/lib/igt.cocci
+++ b/lib/igt.cocci
@@ -22,6 +22,14 @@ expression list[n] Ep;
- igt_skip(Ep);
- }
+ igt_skip_on_f
Also update old hunks to match on igt logging instead of fprintf.
v2: Don't forget about perror.
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/lib/igt.cocci b/lib/igt.cocci
index a5f7c2dbfbce..97
igt_fixture and igt_subtests use longjmp/setjmp internally, which
means local variables at the same stack frame are at risk. Best
practice is to move them out right in front of the igt_main block.
It would be awesome if someone could come up with a cocci patch to
auto-fix this, but unfortunately m
Early revs didn't have PPGTT support, so disable there.
v2: add debug msg when disabling on early stepping
v3: enable on other B3 packages as well (untested) (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
References: https://bugs.freedesktop.org/show_bug.cgi?id=79670
Signe
On Thu, May 29, 2014 at 08:09:15AM -0700, Matt Roper wrote:
> Recent changes in igt_kms to support universal planes have removed the
> plane list order guarantees that kms_plane depended upon. Ensure that
> we loop over the entire plane list properly and then selectively skip
> non-overlay planes.
When using remap_pfn_range() from a fault handler, we are exposed to
races between concurrent faults. Rather than hitting a BUG, report the
error back to the caller, like vm_insert_pfn().
Signed-off-by: Chris Wilson
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Peter Zijlstra
Cc: Rik van Riel
On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces: 8134MiB/s -> 8154MiB/s
Upload rate for 2 tiled surfaces: 8625MiB/s -> 8632MiB/s
Upload rate for 4 linear surfaces: 8127MiB/s -> 8134MiB/s
Upload rate for 4 tiled surfaces: 8602MiB/s -> 8629MiB/s
Up
On Thu, May 29, 2014 at 08:09:14AM -0700, Matt Roper wrote:
> For some of our tests, we want to make sure that bogus plane programming
> attempts fail with the expected error code. Add
> igt_drm_plane_try_commit() that will just return the error code on
> failure rather than failing the current su
On Thu, May 29, 2014 at 08:09:13AM -0700, Matt Roper wrote:
> Add support for universal planes. This involves revamping the existing
> plane handling a bit to allow primary & cursor planes to come from the
> DRM plane list, rather than always being manually added. Also,
> eliminate the hard-coded
Early revs didn't have PPGTT support, so disable there.
v2: add debug msg when disabling on early stepping
References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
References: https://bugs.freedesktop.org/show_bug.cgi?id=79670
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem_
At Fri, 13 Jun 2014 18:07:06 +0200,
Daniel Vetter wrote:
>
> On Fri, Jun 13, 2014 at 05:56:02PM +0200, Takashi Iwai wrote:
> > When a machine is booted with nomodeset option, i915 driver skips the
> > whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
> > by request_symbol() wi
On Fri, 13 Jun 2014 18:54:02 +0300
Ville Syrjälä wrote:
> On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote:
> > Early revs didn't have PPGTT support, so disable there.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
> > References: https://bugs.freedesktop.org/
Put hw limitations first, disabling ppgtt if necessary right away.
After that, check user passed args or auto-detect and do the right
thing, falling back to aliasing PPGTT if the user tries to enable full
PPGTT but it isn't available.
v2: simplify auto-detect case since we already caught the no PP
This reverts commit 6903ab04e5f9048e3932eb3225e94b6a228681ba.
The igt_assert conversion rule is broken and doesn't invert the check
as it should.
Signed-off-by: Daniel Vetter
---
tests/drv_hangman.c | 14 ++
tests/kms_psr_sink_crc.c | 4 ++--
2 files changed, 12 insertions(+),
On Fri, Jun 13, 2014 at 05:56:02PM +0200, Takashi Iwai wrote:
> When a machine is booted with nomodeset option, i915 driver skips the
> whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
> by request_symbol() without knowing that the initialization was
> skipped, and eventually
Put hw limitations first, disabling ppgtt if necessary right away.
After that, check user passed args or auto-detect and do the right
thing, falling back to aliasing PPGTT if the user tries to enable full
PPGTT but it isn't available.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem
sanitize_enable_ppgtt is the function that checks all the conditions,
honoring a forced ppgtt status or doing auto-detect as necessary. Just
make sure it returns the right value in all cases and use that in the
macros instead of the confusing intel_enable_ppgtt() function.
Signed-off-by: Jesse Ba
On Fri, Jun 13, 2014 at 06:54:02PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote:
> > Early revs didn't have PPGTT support, so disable there.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
> > References: https://bugs.freedesktop
>---
>
>All, I intend to push this to drm-intel-fixes, any objections?
>
>Jani.
>---
[TOR:] I have no objections. Looks good to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
When a machine is booted with nomodeset option, i915 driver skips the
whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_
On Fri, Jun 13, 2014 at 08:32:38AM -0700, Jesse Barnes wrote:
> Early revs didn't have PPGTT support, so disable there.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
> References: https://bugs.freedesktop.org/show_bug.cgi?id=79670
> Signed-off-by: Jesse Barnes
> ---
> driver
From: Oscar Mateo
Execlists need a new submission mechanism, so split the preparation
from the submission.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/dr
From: Oscar Mateo
Reusing stuff, a penny at a time.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/dr
From: Oscar Mateo
As suggested by Daniel.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h| 26
drivers/gpu/drm/i915/i915_gem.c| 48 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 +++-
3 files c
From: Oscar Mateo
So that we isolate the legacy ringbuffer submission mechanism, which becomes
a good candidate to be abstracted away.
No functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 298 -
1 file changed, 162 inse
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3ccdf0d..e5db287 100644
--- a/dri
From: Oscar Mateo
Each logical ring context has the tail pointer in the context object,
so update it before submission.
v2: New namespace.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i
From: Oscar Mateo
Also known as __i915_add_request's evil twin.
On seqno preallocation, we set the request context information
correctly so that we can retrieve it both when we want to emit
or retire the request.
This is a candidate to be abstracted away (so that it replaces
__i915_add_request
From: Thomas Daniel
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to schedule new contexts on interrupt when a previously
From: Oscar Mateo
v2: Warn and return if LRCs are not enabled.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 72 +
drivers/gpu/drm/i915/intel_lrc.c| 6
drivers/gpu/drm/i915/intel_lrc.h| 7
3 files changed, 79 insert
From: Oscar Mateo
Or with a spinlock grabbed, because it might sleep, which is not
a nice thing to do. Instead, do the runtime_pm get/put together
with the create/destroy request, and handle the forcewake get/put
directly.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 26 ++
From: Oscar Mateo
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful (e.g. dump the
context
From: Oscar Mateo
I want to reuse it from the new logical ring code (as it seems
innocent enough).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 13 +
2 files changed, 19 insertions(
From: Oscar Mateo
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full preemption occurs:
1)
From: Ben Widawsky
A context switch occurs by submitting a context descriptor to the
ExecList Submission Port. Given that we can now initialize a context,
it's possible to begin implementing the context switch by creating the
descriptor and submitting it to ELSP (actually two, since the ELSP
has
From: Oscar Mateo
For the moment, just mark the place (we still need to do a lot of
preparation before execlists are ready to start submitting things).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c| 11 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
From: Oscar Mateo
Trivial change.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h| 6 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i91
From: Oscar Mateo
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue function. At most, the
From: Oscar Mateo
Very similar to the legacy add_request, only modified to account for
logical ringbuffer.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 61 +
drivers/gpu/drm/i915/intel_r
From: Oscar Mateo
Logical rings do not need most of the initialization their
legacy ringbuffer counterparts do: we just need the pipe
control object for the render ring, enable Execlists on the
hardware and a few workarounds.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 54
From: Oscar Mateo
Things are starting to get messy, and this helps a little.
And some point in time, it would be a good idea to split
intel_lrc.c/.h even further, but for the moment just shove
everything together.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
From: Michel Thierry
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a queue and those
request are later consumed when the right context switch interrupt is
received
From: Oscar Mateo
It is generic enough to be reused.
Trivial change.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer
From: Oscar Mateo
Notice that the BSD invalidate bit is no longer present in GEN8, so
we can consolidate the blt and bsd ring flushes into one.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c| 80 +
drivers/gpu/drm/i915/intel_ringbuffer.c
From: Oscar Mateo
Add theory of operation notes to intel_lrc.c and comments to externally
visible functions.
v2: Add notes on logical ring context creation.
v3: Use kerneldoc.
Signed-off-by: Thomas Daniel (v1)
Signed-off-by: Oscar Mateo (v2, v3)
---
drivers/gpu/drm/i915/intel_lrc.c | 235 +++
From: Oscar Mateo
This is what i915_gem_do_execbuffer calls when it wants to execute some
worload in an Execlists world. It's a candidate for abstracting the
submission mechanism away.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +-
drivers/gpu/drm/i915/inte
From: Oscar Mateo
Dispatch_execbuffer's evil twin.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c| 29 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/dri
From: Oscar Mateo
Well, new-ish: if all this code looks familiar, that's because it's
a clone of the existing submission mechanism (with some modifications
here and there to adapt it to LRCs and Execlists).
And why did we do this? Execlists offer several advantages, like
control over when the GP
From: Oscar Mateo
We need to attend context switch interrupts from all rings. Also, fixed writing
IMR/IER and added HWSTAM at ring init time.
Notice that, if added to irq_enable_mask, the context switch interrupts would
be incorrectly masked out when the user interrupts are due to no users waiti
From: Oscar Mateo
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915
From: Oscar Mateo
Execlists are indeed a brave new world with respect to workload
submission to the GPU.
In previous version of these series, I have tried to impact the
legacy ringbuffer submission path as little as possible (mostly,
passing the context around and using the correct ringbuffer wh
From: Sourab Gupta
If we want flips to work, either we create an Execlists-aware version
of intel_gen7_queue_flip, or we don't place commands directly in the
ringbuffer.
When upstreamed, this patch should implement the second option:
drm/i915: Replaced Blitter ring based flips with MMIO fli
From: Oscar Mateo
No mistery here: the seqno is still retrieved from the engine's
HW status page (the one in the default context. For the moment,
I see no reason to worry about other context's HWS page).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 20
From: Oscar Mateo
I plan to reuse these for the new logical ring path.
No functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 31 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
2 files changed, 21 insertions(+), 13 de
From: Ben Widawsky
This has turned out to be really handy in debug so far.
Update:
Since writing this patch, I've gotten similar code upstream for error
state. I've used it quite a bit in debugfs however, and I'd like to keep
it here at least until preemption is working.
Signed-off-by: Ben Wida
From: Oscar Mateo
The batchbuffer that sets the render context state is submitted
in a different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists fun
From: Oscar Mateo
This is a hard one, since there is no direct hardware ring to
control when in Execlists.
We reuse intel_ring_idle here, but it should be fine as long
as i915_add_request does the ring thing.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 27 +++
From: Oscar Mateo
Allocate and populate the default LRC for every ring, call
gen-specific init/cleanup, init/fini the command parser and
set the status page (now inside the LRC object).
Stopping the ring before cleanup and initializing the seqnos
is left as a TODO task (we need more infrastructu
From: Oscar Mateo
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89b6d5c..b62b
From: Oscar Mateo
The backing objects for contexts created via open fd are actually
empty until the user starts sending execbuffers to them. We do this
because, at create time, we really don't know which engine is going
to be used with the context later on.
v2: As context created via ioctl can o
From: Oscar Mateo
As we have said a couple of times by now, logical ring contexts have
their own ringbuffers: not only the backing pages, but the whole
management struct.
In a previous version of the series, this was achieved with two separate
patches:
drm/i915/bdw: Allocate ringbuffer backing o
From: Oscar Mateo
Without this, i915_gem_context_free looks obfuscated. But, also, it
gives me the possibility to know which kind of context I am dealing
with at freeing time (at this point we only have fake and legacy hw
contexts, but soon we will have logical ring contexts as well).
Signed-off
From: Oscar Mateo
This is mostly for correctness so that we know we are running the LR
context correctly (this is, the PDPs are contained inside the context
object).
v2: Move the check to inside the enable PPGTT function. The switch
happens in two places: the legacy context switch (that we won't
From: Oscar Mateo
... and namespace appropriately.
It looks to me like it belongs logically there.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem_context.c| 23 +++
drivers/gpu/drm/i915/i915_gem_execbuf
From: Oscar Mateo
We are going to start creating a lot of extra ringbuffers soon, so
these functions are handy.
No functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 --
drivers/gpu/drm/i915/intel_ringbuffer.h | 4
2 f
From: Oscar Mateo
GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
These expanded contexts enable a number of new abilities, especially
"Execlists".
The macro is defined to off until we have things in place to hope to
work. In dev_priv, lrc_enabled will reflect the state of
From: Oscar Mateo
Some legacy HW context code assumptions don't make sense for this new
submission method, so we will place this stuff in a separate file.
Note for reviewers: I've carefully considered the best name for this file
and this was my best option (other possibilities were intel_lr_cont
From: Oscar Mateo
The reason for doing this will be better explained in the following
patch. For now, suffice it to say that this backing object is only
used with the render ring, so we're making this fact more explicit.
Done with the following Coccinelle patch (plus manual renaming of the
struc
From: Oscar Mateo
A context backing object only makes sense for a given engine (because
it holds state data specific to that engine).
In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really
perform is for the render engine, so one backing object is all we needed.
With Execlists,
From: Oscar Mateo
We are going to use it later to allocate our own context objects.
No functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 54 +
2 files changed, 37 insert
From: Oscar Mateo
There are a few big differences between context init and fini with the
previous implementation of hardware contexts. One of them is
demonstrated in this patch: we must allocate a ctx backing object for
each engine.
Regarding the context size, reading the register to calculate t
1 - 100 of 177 matches
Mail list logo
