On Wed, 2015-03-18 at 23:57 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Wednesday, March 18, 2015 12:57 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH v4] drm
On Thu, 2015-03-19 at 00:44 +, Konduru, Chandra wrote:
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 08/19] drm/i91
On Thu, 2015-03-19 at 00:12 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 04/19] drm/
On Thu, 2015-03-19 at 00:38 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 07/19] drm/
Hi Dave -
Backporting a couple of plane related fixes from drm-next to v4.0.
BR,
Jani.
The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel ta
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5989
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 268/268
Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly impacting
Michel Thierry writes:
> From: Ben Widawsky
>
> This patch was formerly known as, "Force pd restore when PDEs change,
> gen6-7." I had to change the name because it is needed for GEN8 too.
>
> The real issue this is trying to solve is when a new object is mapped
> into the current address space.
On Tue, Mar 17, 2015 at 05:22:08PM +0200, Jani Nikula wrote:
> On Fri, 13 Mar 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
> > supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5995
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
On 03/18/2015 05:33 PM, Tvrtko Ursulin wrote:
On 03/18/2015 05:27 PM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 04:51:58PM +, Tvrtko Ursulin wrote:
On 03/09/2015 09:55 AM, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_
From: Ville Syrjälä
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it before the nack. So include that i
From: Ville Syrjälä
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/atombios_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/g
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
> Oh right, I got it, but not sure I like it that much. I don't think
> batch pool implementation is well enough decoupled from the users.
"batch pool" Splitting it this way actually improves decoupling.
> Well in a way at least wher
On Thu, Mar 19, 2015 at 03:22:42AM +, Song, Ruiling wrote:
>
> > Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would
> > work for OCL 2.0 pointer sharing, it's a little different than we were
> > planning.
> > To summarize, we have three possible approaches, each with its
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> AUX addresses are 20 bits long. Send out the entire address instead of
> just the low 16 bits.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 5 +++--
> 1 f
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When doing a native or i2c aux write the sink will indicate the number
> of bytes written even if it the nacks the transfer. When we receive a
> nack we just return an error upwards, but it might still be interesti
From: Deepak S
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_irq.c | 6 +-
1 file changed,
On Thursday 19 March 2015 03:38 AM, Chris Wilson wrote:
The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable re
On Thu, 19 Mar 2015, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Signed-off-by: Deepak S
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.
Do we want to throw out the actual code as well then?
>
> Bugzilla
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5996
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 272/272
On 3/19/2015 9:01 AM, Mika Kuoppala wrote:
Michel Thierry writes:
From: Ben Widawsky
This patch was formerly known as, "Force pd restore when PDEs change,
gen6-7." I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapp
On Thu, Mar 19, 2015 at 04:23:32PM +0530, Deepak S wrote:
> Hi Chris,
>
> if we map the object into unmappable region. I think we should skip fence
> create ?
We should just ignore the failure. Whether or not we want the fence
pinned is a matter for the FBC code, which is a different level.
But
The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and h
On 03/19/2015 10:06 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Oh right, I got it, but not sure I like it that much. I don't think
batch pool implementation is well enough decoupled from the users.
"batch pool" Splitting it this way actually improve
From: Ville Syrjälä
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it before the nack. So include that i
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5999
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 272/272
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.
Is there any way to identify either what systems it's OK to use on,
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When doing a native or i2c aux write the sink will indicate the number
> of bytes written even if it the nacks the transfer. When we receive a
> nack we just return an error upwards, but it might still be interesti
On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote:
> On 03/19/2015 10:06 AM, Chris Wilson wrote:
> >On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
> >>Well in a way at least where when we talk about LRU ordering, it
> >>depends on retiring working properly and that is
On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote:
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Do we want to
On 03/19/2015 11:46 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote:
On 03/19/2015 10:06 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Well in a way at least where when we talk about LRU ordering, it
depends on r
On Thu, Mar 19, 2015 at 11:58:17AM +, Tvrtko Ursulin wrote:
> How about retire all rings and then the inactive batch search with a
> global pool becomes only O(num_rings) at worst? Might be worth
> saving memory resource (multiple pools) vs. trivial traversal like
> that?
There isn't a memory
From: John Harrison
The request allocation code is largely duplicated between legacy mode and
execlist mode. The actual difference between the two versions of the code is
pretty minimal.
This patch moves the common code out into a separate function. This is then
called by the execution specific
From: John Harrison
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch updates the legacy code path to match the execlist version. Th
From: John Harrison
Start of explicit request management in the execbuffer code path. This patch
adds a call to allocate a request structure before all the actual hardware work
is done. Thus guaranteeing that all that work is tagged by a known request. At
present, nothing further is done with the
From: John Harrison
The driver tracks GPU work using request structures. Unfortunately, this
tracking is not currently explicit but is done by means of a catch-all request
that floats around in the background hoovering up work until it gets submitted.
This background request (ring->outstanding_la
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplifies the prototype by passing a
From: John Harrison
The only usage of intel_logical_ring_begin() is within intel_lrc.c so it can be
made static. To avoid a forward declaration at the top of the file, it and bunch
of other functions have been shuffled upwards.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i91
From: John Harrison
The legacy and LRC code paths have an almost identical procedure for waiting for
space in the ring buffer. They both search for a request in the free list that
will advance the tail to a point where sufficient space is available. They then
wait for that request, retire it and
From: John Harrison
The submission portion of the execbuffer code path was abstracted into a
function pointer indirection as part of the legacy vs execlist work. The two
implementation functions are called 'i915_gem_ringbuffer_submission' and
'intel_execlists_submission' but the pointer was calle
From: John Harrison
Shrunk the parameter list of i915_gem_execbuffer_retire_commands() to a single
structure as everything it requires is available in the execbuff_params object.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_drv.h|
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c
From: John Harrison
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the error
case. This means that the execbuff code is no longe
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_drv.
From: John Harrison
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and
From: John Harrison
Updated a couple of trace points to use the now cached request pointer rather
than extracting it from the ring.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c
From: John Harrison
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring->outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it knowing
exactly which request it actually owns.
v2: Up
From: John Harrison
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
updates and such), moves the request structure onto the right list and other
such house keeping tasks. However, the work
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the
From: John Harrison
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/
From: John Harrison
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_context.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --
From: John Harrison
Now that everything above has been converted to use requests, it is possible to
update init_context() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_context.c |
From: John Harrison
Updated the ring->sync_to() implementations to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/i915_trace.h |
From: John Harrison
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard batch buffer submission proce
From: John Harrison
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data to the ring
which floats around in that ring's OLR until
From: John Harrison
The render state initialisation code does an explicit i915_add_request() call to
commit the init commands. It was passing in the initialisation batch buffer to
add_request() as the batch object parameter. However, the batch object entry in
the request structure (which is all t
From: John Harrison
Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_drv.h
From: John Harrison
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for keeping hold
of reference counts on contexts and such like.
Previously, the fall back path of polling for space in the ring would st
From: John Harrison
Updated *_ring_invalidate_all_caches(), i915_reset_gen7_sol_offsets() and
i915_emit_box() to take request structures instead of ring or ringbuf/context
pairs.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |
From: John Harrison
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_render_state.c
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single request between the sync and the
page flip. The _sync() functi
From: John Harrison
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_lrc.c| 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c |
From: John Harrison
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does call i915_gem_retire_requests_ring(). Hence it is
pretty much redundant as the two callers could just call retire directly. This
patch makes that change.
For: VIZ-511
From: John Harrison
Now that everything above has been converted to use requests,
intel_logical_ring_begin() can be updated to take a request instead of a
ringbuf/context pair. This also means that it no longer needs to lazily allocate
a request if no-one happens to have done it earlier.
Note th
From: John Harrison
Updated the switch_mm() code paths to take a request instead of a ring. This
includes the myriad *_mm_switch functions themselves and a bunch of PDP related
helper functions.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i91
From: John Harrison
Much of the driver has now been converted to passing requests around instead of
rings/ringbufs/contexts. Thus the function for retreiving the request from a
ring (i.e. the OLR) is no longer used and can be removed.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Toma
From: John Harrison
Updated the *_ring_flush_all_caches() functions to take requests instead of
rings or ringbuf/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/intel_lrc.c|
From: John Harrison
Updated do_switch() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
v2: Removed some overzealous req-> dereferencing.
---
drivers/gpu/drm/i915/i915_gem_context.c |7 ---
1 file changed, 4 insertions(+), 3 deletio
From: John Harrison
Updated the various ring->dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
drivers/gpu/drm/i915/i915_gem_render_state.c
From: John Harrison
The overlay update code path to do explicit request creation and submission
rather than relying on the OLR to do the right thing.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_overlay.c | 56 +-
1 file changed, 4
From: John Harrison
Udpated the various ring->flush() functions to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |
From: John Harrison
Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/d
From: John Harrison
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_display.c|2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
drivers/gpu/drm/i915/intel
From: John Harrison
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a request explicitly passed in from on
high. Everything that was relying upon it behind the scenes is now explicitly
creating/passing/submitting it's own private re
From: John Harrison
Now that the *_ring_begin() functions no longer call the request allocation
code, it is finally safe for the request allocation code to call *_ring_begin().
This is important to guarantee that the space reserved for the subsequent
i915_add_request() call does actually get rese
From: John Harrison
Updated the various ring->emit_flush() implementations to take a request instead
of a ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_lrc.c| 17 -
drivers/gpu/drm/i915/intel_ri
From: John Harrison
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 28
2 files changed, 29 deletio
From: John Harrison
The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.
This patch moves the ring looping out of that function in to the top level
caller i915_gem_init
From: John Harrison
In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is not
necessarily the same as when the request was submitted
From: John Harrison
When the ring buffer is full, the driver finds an outstanding request that will
free up sufficient space for the current operation and waits for it to complete.
If no such request can be found, there is a fall back path of just polling until
sufficient space is available.
Thi
From: John Harrison
The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
allocated request structure in to each step rather than passing a ring
structure. This patch updates both i915_ppgtt_init_ring() and
i915_gem_context_enable() to take request pointers.
For: VIZ-51
From: John Harrison
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |5 +++--
drivers/gpu/drm/i915/
From: John Harrison
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has many more contexts than legacy
mode and many are never actually used. Previously, the initialisation commands
were written to the ring and tagged with s
From: John Harrison
Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.
The sequence is now to create a request, queue the work to the ring, assign the
know
From: John Harrison
Updated the various ring->signal() implementations to take a request instead of
a ring. This removes their reliance on the OLR to obtain the seqno value that
should be used for the signal.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/dr
From: John Harrison
Updated the ring->emit_request() implementation to take a request instead of a
ringbuf/request pair. Also removed it's use of the OLR for obtaining the
request's seqno.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c
From: John Harrison
Now that everything above has been converted to use requests, intel_ring_begin()
can be updated to take a request instead of a ring. This also means that it no
longer needs to lazily allocate a request if no-one happens to have done it
earlier.
For: VIZ-5115
Signed-off-by: Jo
From: John Harrison
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa() and
gen8_emit_pipe_control() to take requests instead of rings.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +++
From: John Harrison
A bunch of the low level LRC functions were passing around ringbuf and ctx
pairs. In a few cases, they took the r/c pair and a request as well. This is all
quite messy and unnecesary. The context_queue() call is especially bad since the
fake request code got removed - it takes
From: John Harrison
Updated the ring->emit_bb_start() implementation to take a request instead of a
ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_lrc.c| 12 +---
drivers/gpu/drm/i915/intel_ringbuffer.h
From: John Harrison
Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.
Also removed the warning that the request's context must match
From: John Harrison
Updated the various ring->add_request() implementations to take a request
instead of a ring. This removes their reliance on the OLR to obtain the seqno
value that the request should be tagged with.
For: VIZ-5115
Signed-off-by: John Harrison
Reviewed-by: Tomas Elf
---
drive
This patch adds fast link training support if BDB version
is equal or higher than 182 and the feature is supported
in VBT.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 4
drivers/gpu/drm/i915/intel_bios.h | 1 +
drivers/gpu/d
On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Is there any
From: Ben Widawsky
This patch was formerly known as, "Force pd restore when PDEs change,
gen6-7." I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU does not snoop the new mappi
On ti, 2015-03-17 at 15:45 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 90/270 rotated scanout needs a rotated GTT view of the framebuffer.
>
> This is put in a separate VMA with a dedicated ggtt view and wired such that
> it is created when a framebuffer is pinned to a 90/270 rotated
On Thursday 19 March 2015 04:59 PM, Chris Wilson wrote:
The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable re
1 - 100 of 224 matches
Mail list logo
