From: Oscar Mateo oscar.ma...@intel.com
Again, it's low-level enough to simply take a ringbuf and nothing
else.
Trivial change.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu
From: Oscar Mateo oscar.ma...@intel.com
It's simple enough that it doesn't need to know anything about the
engine.
Trivial change.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 13
From: Oscar Mateo oscar.ma...@intel.com
More prep work: with Execlists, we are going to start creating a lot
of extra ringbuffers soon, so these functions are handy.
No functional changes.
v2: rename allocate/destroy_ring_buffer to alloc/destroy_ringbuffer_obj
because the name is more
From: Oscar Mateo oscar.ma...@intel.com
This is preparatory work for Execlists: we plan to use it later to
allocate our own context objects (since Logical Ring Contexts do
not have the same kind of backing objects).
No functional changes.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
From: Oscar Mateo oscar.ma...@intel.com
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field
From: Oscar Mateo oscar.ma...@intel.com
A bit of background on the context elements.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu
From: Oscar Mateo oscar.ma...@intel.com
So that we isolate the legacy ringbuffer submission mechanism, which becomes
a good candidate to be abstracted away. This is prep-work for Execlists (which
will its own workload submission mechanism).
No functional changes.
Reviewed-by: Jesse Barnes jbar
From: Oscar Mateo oscar.ma...@intel.com
For the moment this is just a placeholder, but it shows one of the
main differences between the good ol' HW contexts and the shiny
new Logical Ring Contexts: LR contexts allocate and free their
own backing objects. Another difference is that the allocation
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
For a description of this patchset, please check the previous cover letters:
[1], [2] and [3].
The main changes introduced in this v4 are:
- Do not abstract __i915_add_request away.
- Squash together the two emit request functions.
- Always pass
From: Oscar Mateo oscar.ma...@intel.com
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.
v2: Rename advanced contexts
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
On a previous iteration of this patch, I created an Execlists
version of __i915_add_request and asbtracted it away as a
vfunc. Daniel Vetter wondered then why that was needed:
with the clean split in command submission I expect every
function to know
make
sure that it was properly aligned. Spotted by Alistair Mcaulay
alistair.mcau...@intel.com.
v5:
- Improved source code comments as suggested by Chris Wilson.
- No need to abstract submit_ctx away, as pointed by Brad Volkin.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
Up until recently, semaphores weren't enabled in BDW so we didn't care
about them. But then Rodrigo came and enabled them:
commit 521e62e49a42661a4ee0102644517dbe2f100a23
Author: Rodrigo Vivi rodrigo.v...@intel.com
drm/i915: Enable semaphores
.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch was accidentally dropped in the first Execlists version, and
it has been very useful indeed. Put it back again, but as a standalone
debugfs file.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
From: Oscar Mateo oscar.ma...@intel.com
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). These are
things all engines/rings have in common.
Stopping the ring before cleanup
From: Oscar Mateo oscar.ma...@intel.com
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 oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
These two functions make no sense in an Logical Ring Context Execlists
world.
v2: We got rid of lrc_enabled and centralized everything in the sanitized
i915.enbale_execlists instead.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
As suggested by Daniel Vetter. The idea, in subsequent patches, is to
provide an alternative to these vfuncs for the Execlists submission
mechanism.
v2: Splitted into two and reordered to illustrate our intentions, instead
of showing it off. Also, remove
From: Oscar Mateo oscar.ma...@intel.com
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 oscar.ma...@intel.com
---
drivers
.
v5: Squash with drm/i915/bdw: Do not call intel_runtime_pm_get() in an
interrupt, as suggested by Daniel.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 35 ++---
drivers/gpu/drm/i915/intel_lrc.c| 129
From: Oscar Mateo oscar.ma...@intel.com
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.
v2: Squash with: drm/i915: Extract pipe control
From: Oscar Mateo oscar.ma...@intel.com
The normal flip function places things in the ring in the legacy
way, so we either fix that or force MMIO flips always as we do in
this patch.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
Dispatch_execbuffer's evil twin.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 28
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
2 files changed, 30 insertions(+)
diff --git
From: Oscar Mateo oscar.ma...@intel.com
For the most part, logical ring context objects are similar to hardware
contexts in that the backing object is meant to be opaque. There are
some exceptions where we need to poke certain offsets of the object for
initialization, updating the tail pointer
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
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.
v4: Integrate it in the DocBook template.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
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.
v3: Daniel suggests to drop
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
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 oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19
From: Oscar Mateo oscar.ma...@intel.com
This is what i915_gem_do_execbuffer calls when it wants to execute some
worload in an Execlists world.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 6 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
The backing objects and ringbuffers for contexts created via open
fd are actually empty until the user starts sending execbuffers to
them. At that point, we allocate populate them. We do this because,
at create time, we really don't know which engine
From: Oscar Mateo oscar.ma...@intel.com
Up until now, we have pinned every logical ring context backing object
during creation, and left it pinned until destruction. This made my life
easier, but it's a harmful thing to do, because we cause fragmentation
of the GGTT (and, eventually, we would run
From: Oscar Mateo oscar.ma...@intel.com
Very similar to the legacy add_request, only modified to account for
logical ringbuffer.
v2: Use MI_GLOBAL_GTT, as suggested by Brad Volkin.
v3: Unify render and non-render in the same function, as noticed by
Brad Volkin.
Signed-off-by: Oscar Mateo
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
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
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
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 nee
From: Oscar Mateo oscar.ma...@intel.com
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).
Unfortunately, this case is also more complex than the previous one
because we need to map and access the ringbuffer in several places
initialization.
- Damien's kmalloc review comments: check return, use sizeof(*req),
do not cast.
v5:
- Do not reuse drm_i915_gem_request. Instead, create our own.
- New namespace.
Signed-off-by: Michel Thierry michel.thie...@intel.com (v1)
Signed-off-by: Oscar Mateo oscar.ma...@intel.com (v2-v5
From: Oscar Mateo oscar.ma...@intel.com
Same as the legacy-style ring-flush.
v2: The BSD invalidate bit still exists in GEN8! Add it for the VCS
rings (but still consolidate the blt and bsd ring flushes into one).
This was noticed by Brad Volkin.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
v3: Grab the Execlists spinlock (noticed by Daniel Vetter).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 +
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
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 instead of reusing code, one might wonder
From: Oscar Mateo oscar.ma...@intel.com
Guarantees that error capture works at a very basic level.
v2: Also check that the ring object contains a reloc with MI_BB_START
for the presumed batch object's address.
v3: Chris review comments:
- Move variables to local scope.
- Do not assume
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
tests/.gitignore | 1 +
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/gem_execlist.c | 266 +
4 files changed, 269
From: Ben Widawsky benjamin.widaw...@intel.com
for_each_ring() iterates over all rings supported by the hardware, not
just those which have been initialized as in for_each_active_ring()
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Acked-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
v2: The Full PPGTT series have moved things around a little bit.
Also, don't forget the VEBOX.
v3: Checking ring-dev is not a good way to test if a ring is
initialized...
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
...@bwidawsk.net
v2: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 16
drivers/gpu/drm/i915/i915_gem_context.c
From: Oscar Mateo oscar.ma...@intel.com
The __ name is too confusing, specially given the refactoring patch
that comes soon with more new ringbuffer management functions.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 ++-
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
v3: Add a module parameter to enable execlists. Execlist are relatively
new, and so it'd be wise to be able to switch back to ring submission
to debug subtle problems that will inevitably arise.
Signed-off-by: Damien Lespiau damien.lesp
From: Oscar Mateo oscar.ma...@intel.com
We are going to use it later to allocate our own objects.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Continue with the refactoring: do not init or clean a ringbuffer when
you actually mean a ring, because they are not the same thing anymore.
Again, no functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
This patch should have no functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
In Execlists we don't really write to the tail register to submit
a workload to the GPU, so the name is going to stop being accurate
soon.
Change and name suggested by Brad.
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Oscar Mateo oscar.ma
From: Oscar Mateo oscar.ma...@intel.com
Allocating only the RCS backing object won't be enough for LRCs, so
give callers the opportunity to skip it.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
The default context holds pointers to every engine's default ringbuffer,
and makes its own allocation of the corresponding backing objects. During
ringbuffer creation we might try to allocate them again, but this will
fail silently (same thing
From: Oscar Mateo oscar.ma...@intel.com
The context are going to become very important pretty soon, and
we need to be able to access them in a number of places inside
the command submission path. The idea is that, when we need to
place commands inside a ringbuffer or update the tail register,
we
From: Oscar Mateo oscar.ma...@intel.com
We need functions that are aware of the fact that the ringbuffer might be living
somewhere else than in the engine. After this commit and some of the previous,
these
new ringbuffer functions finally are:
intel_ringbuffer_get
intel_ringbuffer_begin
From: Oscar Mateo oscar.ma...@intel.com
The backing objects for user-created contexts (either via open fd or
create context ioctl) 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
.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
v3: Factor out a enable_execlists() function so it's clear what the
condition is. Use module parameter to enable.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c
From: Ben Widawsky benjamin.widaw...@intel.com
Logical ring contexts do not need most of the ring init: we just need
the pipe control object for the render ring and a few workarounds (some
more stuff to be added later).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
As we said earlier, logical ring contexts created by the user have their
own ringbuffer: not only the backing pages, but the whole management struct.
Since this is now ready, we use the context ringbuffer or the engine's
default ringbuffer depending
From: Oscar Mateo oscar.ma...@intel.com
For a description of this patchset, please check the previous cover letter [1].
Together with this patchset, I'm also submitting an IGT test: gem_execlist [2].
v2:
- Use the same context struct for all the different engines (suggested by Brad
Volkin
From: Oscar Mateo oscar.ma...@intel.com
Thanks to the previous functions and intel_ringbuffer_get(), every function
that needs to be context-aware can get the ringbuffer from the appropriate
place.
Others (either pre-GEN8 or that clearly manipulate the rings's default
ringbuffer)
get
From: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
v2: Set Replay Mode to 0 per BSpec
Michel Thierry michel.thie...@intel.com
v3: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 10
From: Oscar Mateo oscar.ma...@intel.com
We are going to reuse it during logical ring context creation.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
2 files changed, 3 insertions(+), 1
From: Oscar Mateo oscar.ma...@intel.com
We need it (at least) to properly update the last retired head.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
that we don't waste memory in rings that might not get initialized).
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Some legacy HW context and ringbuffer 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
Widawsky b...@bwidawsk.net
v2: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
This commit changes the ABI, so it is provided separately so that it can be
dropped by the maintainer is so he wishes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
1 file changed, 6 deletions(-)
diff
From: Oscar Mateo oscar.ma...@intel.com
Following the logic behind the previous patch, the ringbuffers and the rings
belong in different structs. For the time being, we will keep the relationship
between the two via the default_ringbuf living inside each ring.
This commit should not introduce
, as the BSpec suggest we do.
- Prevent warning when compiling a 32-bits kernel without HIGHMEM64.
- Add a clarifying comment to the context population code.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 159
From: Oscar Mateo oscar.ma...@intel.com
When we start using Execlists, a context backing object only makes
sense for a given engine (because it will hold state data specific to
it) so multiplex the context struct to contain no-of-engines objects.
In legacy ringbuffer sumission mode, the only
From: Oscar Mateo oscar.ma...@intel.com
Even though we have one Hardware Status Page per context, we are still
managing the seqnos per engine. Therefore, the sequence number must be
written to a consistent place for all contexts: one of the global
default contexts.
Signed-off-by: Thomas Daniel
From: Oscar Mateo oscar.ma...@intel.com
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).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4
1 file
From: Oscar Mateo oscar.ma...@intel.com
Each logical ring context has the tail pointer in the context object,
so update it before submission.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff
of the software use-only bits of the Context ID in the Context Descriptor
Format) without the hassle of the previous submission Id construction.
Also, re-add the ELSP porting read (it was dropped somewhere during the
rebases).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 27 ++---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
4 files changed
From: Oscar Mateo oscar.ma...@intel.com
Finally, start queueing request on ring-submit. Also, remove
remaining legacy context switches.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c| 9 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 10
-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_irq.c | 38 +++-
drivers/gpu/drm/i915/intel_lrc.c| 102 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
The write tail function is a very special place for execlists: since
all access to the ring is mediated through requests (thanks to
Chris Wilson's Write RING_TAIL once per-request for that) and all
requests end up with a write tail, this is the place we
From: Thomas Daniel thomas.dan...@intel.com
BSPEC says: SW must set Force Wakeup bit to prevent GT from
entering C6 while ELSP writes are in progress.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
Acked-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 74 +
drivers/gpu/drm/i915/i915_reg.h | 7
drivers/gpu/drm/i915
the queue/lock init to the late ring initialization.
- Damien's kmalloc review comments: check return, use sizeof(*req),
do not cast.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/intel_lrc.c| 57
From: Oscar Mateo oscar.ma...@intel.com
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
.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch was accidentally dropped in the first Execlists version, and
it has been very useful indeed. Put it back again, but as a standalone
debugfs file.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
From: Oscar Mateo oscar.ma...@intel.com
Explain intel_lrc.c with some execlists notes
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
v2: Add notes on logical ring context creation.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 67
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
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
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests and that we re-program the ring for
execution. Also, reset the hangcheck counters.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
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
From: Oscar Mateo oscar.ma...@intel.com
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
From: Oscar Mateo oscar.ma...@intel.com
This is missing in:
commit 78325f2d270897c9ee0887125b7abb963eb8efea
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Tue Apr 29 14:52:29 2014 -0700
drm/i915: Virtualize the ringbuffer signal func
Looks to me like a rebase side-effect
1 - 100 of 865 matches
Mail list logo
