On Fri, Jun 03, 2016 at 12:40:00PM +0100, Arun Siluvery wrote:
> Kernel only need to add a register to HW whitelist, required for a
> preemption related issue.
>
> Reference: HSD#2131039
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/
On Wed, Jun 01, 2016 at 08:10:19AM +0100, chix.d...@intel.com wrote:
> From: Maarten Lankhorst
>
> This patch doesn't change the code to use two-level watermark yet,
Just as a general note, people may look back on this commit in the
future (once it's been accepted and merged upstream) and won't
On Wed, Jun 01, 2016 at 08:10:18AM +0100, chix.d...@intel.com wrote:
> From: Chi Ding
>
> This function will be used not only by SKL but also VLV/CHV.
> Therefore it's renamed.
>
> Signed-off-by: Chi Ding
As with the first patch, you should update the patch headline. Other
than that,
Reviewe
General comment (that applies to the whole series); when you write your
commit message, the first line (which becomes the email subject above)
should be prefixed by "drm/i915:" If your patch is only modifying the
code for a specific platform, you can include that too when appropriate
(e.g., "drm/i
On Fri, Jun 03, 2016 at 09:37:43AM +0200, Boris Brezillon wrote:
> On Thu, 2 Jun 2016 23:57:02 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> > wrote:
> > > Hi Boris,
> > >
> > > Thank you for the patch.
> > >
> > > On Thursday 02 Jun 2016 16:31:28 Boris B
On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote:
> On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > > > On Wed, May 25, 2016 at 12:51
On 2016-06-01 15:06, Daniel Vetter wrote:
> No idea how exactly fsl-du commits hw state changes, but here in flush
> is probably the safest place.
The writes to the DCU_UPDATE_MODE register (DCU_UPDATE_MODE_READREG)
commit state changes. There are several callbacks causing a commit, it
seems to me
> + /* WaDisableDynamicCreditSharing:kbl */
> + if (IS_KBL_REVID(dev_priv, 0, KBL_REVID_B0))
> + WA_SET_BIT(GAMT_CHKN_BIT_REG, (1 << 28));
> +
Let's play name that bit!
Otherwise the patch looks good, although slightly worrying that the
hsd's state the WA is needed up to
On Fri, Jun 03, 2016 at 06:06:19PM +0300, Marius Vlad wrote:
> Introduced by 0e11befe442. openat(2) uses a relative path. Fix by
> passing the correct fd.
>
> Signed-off-by: Marius Vlad
> CC: Chris Wilson
Yup, At one point it was using the drm_fd to search for the right sysfs
every time,
> ---
With a bit of care (and leniency) we can iterate over the object and
wait for previous rendering to complete with judicial use of atomic
reference counting. The ABI requires us to ensure that an active object
is eventually flushed (like the busy-ioctl) which is guaranteed by our
management of reque
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_overlay.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 75bdd335d565..ad57149f4809 100644
--- a/dr
We only need to take the struct_mutex if the object is pinned to the
display engine and so requires checking for clflush. (The race with
userspace pinning the object to a framebuffer is irrelevant.)
v2: Use access once for compiler hints (or not as it is a bitfield)
Signed-off-by: Chris Wilson
C
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under
We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler
The struct_mutex can have some tricky interactions with other mutexes
(mainly due to using nasty constructs like stop_machine() from within
its confines). This makes it "illegal" (lockdep should generate WARNs)
from certain paths like suspend, where the locking order may be
inverted. We can extend
If we try and read or write to an active request, we first must wait
upon the GPU completing that request. Let's do that without holding the
mutex (and so allow someone else to access the GPU whilst we wait). Upn
completion, we will reacquire the mutex and only then start the
operation (i.e. we do
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ab2ba76a2a3b..367b8b2ce5f2 100644
--- a/drivers/gpu/drm/i915
When capturing the error state, we do not need to know about every
address space - just those that are related to the error. We know which
context is active at the time, therefore we know which VM are implicated
in the error. We can then restrict the VM which we report to the
relevant subset.
Sign
The individual bits inside obj->frontbuffer_bits are protected by each
plane->mutex, but the whole bitfield may be accessed by multiple KMS
operations simultaneously and so the RMW need to be under atomics.
However, for updating the single field we do not need to mandate that it
be under the struct
We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler
We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DO
Just move it earlier so that we can use the companion nonblocking
version in a couple of more callsites without having to add a forward
declaration.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 182
1 file changed, 91 insertions(+), 9
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1e91589e7bc..98aa0a7c91f0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3796,7 +
With all callers now not playing tricks with dropping the struct_mutex
between waiting and retiring, we can assert that the request is ready to
be retired.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --g
We allocate a few objects into the GGTT that we never need to access via
the mappable aperture (such as contexts, status pages). We can request
that these are bound high in the VM to increase the amount of mappable
aperture available. However, anything that may be frequently pinned
(such as logical
Treat the VMA as the primary struct responsible for tracking bindings
into the GPU's VM. That is we want to treat the VMA returned after we
pin an object into the VM as the cookie we hold and eventually release
when unpinning. Doing so eliminates the ambiguity in pinning the object
and then searchi
If we enable RCU for the requests (providing a grace period where we can
inspect a "dead" request before it is freed), we can allow callers to
carefully perform lockless lookup of an active request.
However, by enabling deferred freeing of requests, we can potentially
hog a lot of memory when deal
Eviction is VM local, so we can ignore the significance of the
drm_device in the caller, and leave it to i915_gem_evict_something() to
manager itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i9
By applying the same logic as for wait-ioctl, we can query whether a
request has completed without holding struct_mutex. The biggest impact
system-wide is removing the flush_active and the contention that causes.
Testcase: igt/gem_busy
Signed-off-by: Chris Wilson
Cc: Akash Goel
---
drivers/gpu/
Inside the kthread context, we can't be interrupted by signals so
touching the mm.interruptible flag is pointless and wait-request now
consumes EIO itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 6eea4abeb9ce..454be9719daa 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrink
Since we are not concerned with userspace racing itself with set-tiling
(the order is indeterminant even if we take a lock), then we can safely
read back the single obj->tiling_mode and do the static lookup of
swizzle mode without having to take a lock.
get-tiling is reasonably frequent due to the
Tracking the size of the VMA as allocated allows us to dramatically
reduce the complexity of later functions (like inserting the VMA in to
the drm_mm range manager).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 10 +--
drivers/gpu/drm/i915/i915_gem.c | 117 +
Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for
i915_gem_object_ggtt_pin(), spare us the confustion and remove it.
Removing it now simplifies later patches to change the i915_vma_pin()
(and friends) interface.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
It is useful to be able to wait on pending rendering without grabbing
the struct_mutex. We can do this by using the i915_gem_active_get_rcu()
primitive to acquire a reference to the pending request without
requiring struct_mutex, just the RCU read lock, and then call
__i915_wait_request().
Signed-
Following a GPU reset upon hang, we retire all the requests and then
mark them all as complete. If we mark them as complete first, we both
keep the normal retirement order (completed first then retired) and
provide a small optimisation for concurrent lookups.
Signed-off-by: Chris Wilson
---
driv
request->batch_obj is only set by execbuffer for the convenience of
debugging hangs. By moving that operation to the callsite, we can
simplify all other callers and future patches. We also move the
complications of reference handling of the request->batch_obj next to
where the active tracking is se
Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 10 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 131 ++
We are motivated to avoid using a bitfield for obj->active for a couple
of reasons. Firstly, we wish to document our lockless read of obj->active
using READ_ONCE inside i915_gem_busy_ioctl() and that requires an
integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code
when presented
Our GPUs impose certain requirements upon buffers that depend upon how
exactly they are used. Typically this is expressed as that they require
a larger surface than would be naively computed by pitch * height.
Normally such requirements are hidden away in the userspace driver, but
when we accept po
We only need a very lightweight mechanism here as the locking is only
used for co-ordinating a bitfield.
Also double check that the object is still pinned to the display plane
before processing the state change.
v2: Move the cheap unlikely tests into the caller
Signed-off-by: Chris Wilson
---
Split the insertion into the address space's range manager and binding
of that object into the GTT to simplify the code flow when pinning a
VMA.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(
Move the single line to the callsite as the name is now misleading, and
the purpose is solely to add the request to the execution queue.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/
During execbuffer we look up the i915_vma in order to reserver them in
the VM. However, we then do a double lookup of the vma in order to then
pin them, all because we lack the necessary interfaces to operate on
i915_vma.
v2: Tidy parameter lists to remove one level of redirection in the hot
path.
Slight micro-optimise to produce combine loops so that gcc is able to
optimise the inner-loops concisely. Since we are reviewing the loops, we
can update the comments to describe the current state of affairs, in
particular the distinction between evicting from the global GTT (which
may contain untr
We should not rely on obj->active being uptodate unless we manually
flush it. Instead, we can verify that the next available batch object is
idle by looking at its last active request (and checking it for
completion).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 1
This reimplements the denial-of-service protection against igt from
commit 227f782e4667fc622810bce8be8ccdeee45f89c2
Author: Chris Wilson
Date: Thu May 15 10:41:42 2014 +0100
drm/i915: Retire requests before creating a new one
and transfers the stall from before each batch into get_pages()
One issue with the current VMA api is that callers do not take ownership
of the VMA they pin for their use, and corresponding never explicitly
unpin it. Being able to track the VMA they are using, imo, allows for
simpler code that is more easily verified (and is faster and more
accurate - less gues
Ideally, we want to automagically have the GPU respond to the
instantaneous load by reclocking itself. However, reclocking occurs
relatively slowly, and to the client waiting for a result from the GPU,
too late. To compensate and reduce the client latency, we allow the
first wait from a client to b
Space for flushing the GPU cache prior to completing the request is
preallocated and so cannot fail.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +---
drivers/gpu/drm/i915/i915_gem_gtt.c| 18
Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly
the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer -
we need only one vfunc.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +--
drivers/gpu/drm/i915/i915_gem_render_state
Now that the last couple of hacks have been removed from the runtime
powermanagement users, we can fully enable the asserts.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/d
As GEN6+ is now a simple variant on the basic breadcrumbs + tail write,
reuse the common code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 68 +
1 file changed, 27 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
Ringbuffers are now being written to either through LLC or WC paths, so
treating them as simply iomem is no longer adequate. However, for the
older !llc hardware, the hardware is documentated as treating the TAIL
register update as serialising, so we can relax the barriers when filling
the rings (b
In the next patch, request tracking is made more generic and for that we
need a new expanded struct and to separate out the logic changes from
the mechanical churn, we split out the structure renaming into this
patch.
v2: Writer's block. Add some spiel about why we track requests.
v3: Now i915_gem
Now that we have a clear ring/engine split and a struct intel_ring, we
no longer need the stopgap ringbuf names.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 66 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 +--
2 files changed, 36 i
Now that emitting requests is identical between legacy and execlists, we
can use the same function to build up the ring for submitting to either
engine. (With the exception of i915_switch_contexts(), but in time that
will also be handled gracefully.)
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Move request submission from emit_request into its own common vfunc
from i915_add_request().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c| 8 +++---
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +--
drivers/gpu/drm/i915/intel_guc.h | 2 +-
drivers/gp
Since we may have VMA allocated for an object, but we interrupted their
binding, there is a disparity between have elements on the obj->vma_list
and being bound. i915_gem_obj_bound_any() does this check, but this is
not rigorously observed - add an explicit count to make it easier.
Signed-off-by:
The state stored in this struct is not only the information about the
buffer object, but the ring used to communicate with the hardware. Using
buffer here is overly specific and, for me at least, conflates with the
notion of buffer objects themselves.
Signed-off-by: Chris Wilson
---
drivers/gpu/
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects for it (as it is removed from the user's
nam
Just a different colour to better match virtual addresses elsewhere.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
3 files changed, 10 insertions(+), 1
This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
The patch was only a stop-gap measure that fixed half the problem - the
leak of the fbcon when restarting X. A complete solution required
releasing the VMA when the object itself was closed rather than rely on
file/process exit. The pre
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
I
Describe the intent of boosting the GPU frequency to maximum before
waiting on the GPU.
RPS waitboosting was introduced with
commit b29c19b645287f7062e17d70fa4e9781a01a5d88
Author: Chris Wilson
Date: Wed Sep 25 17:34:56 2013 +0100
drm/i915: Boost RPS frequency for CPU stalls
but lacked a
For more consistent oop-naming, we would use intel_ring_verb, so pick
intel_ring_pin() and intel_ring_unpin().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 38 -
drivers/gpu/drm/i915/i
We use "list" to denote the list and "link" to denote an element on that
list. Rename request->list to match this idiom.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_reque
If the object is active and we need to perform a relocation upon it, we
need to take the slow relocation path. Before we do, double check the
active requests to see if they have completed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +++-
1 file ch
Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 4 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm
Both perform the same actions with more or less indirection, so just
unify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 54 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 53 ++---
drivers/gpu/drm/i915/i915_gem_gtt.c| 62 ++---
drivers/gpu
As we can now have multiple VMA inside the global GTT (with partial
mappings, rotations, etc), it is no longer true that there may just be a
single GGTT entry and so we should walk the full vma_list to count up
the actual usage. In addition to unifying the two walkers, switch from
multiplying the o
As we only ever keep the first error state around, we can avoid some
work that can be quite intrusive if we don't record the error the second
time around. This does move the race whereby the user could discard one
error state as the second is being captured, but that race exists in the
current code
The future annotations will track the locking used for access to ensure
that it is always sufficient. We make the preparations now to present
the API ahead and to make sure that GCC can eliminate the unused
parameter.
Before: 6298417 3619610 696320 10614347 a1f64b vmlinux
After: 6298417
Since we track requests, and requests are always added to the GPU fully
formed, we never have to flush the incomplete request and know that the
given request will eventually complete without any further action on our
part.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 58 +++-
In order to prevent a leak of the vma on shared objects, we need to
hook into the object_close callback to destroy the vma on the object for
this file. However, if we destroyed that vma immediately we may cause
unexpected application stalls as we try to unbind a busy vma - hence we
defer the unbind
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 10 +-
drivers/gpu/drm/i915/i915_gem.c| 4 ++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |
When we call i915_vma_unbind(), we will wait upon outstanding rendering.
This will also trigger a retirement phase, which may update the object
lists. If, we extend request tracking to the VMA itself (rather than
keep it at the encompassing object), then there is a potential that the
obj->vma_list
For symmetry with a forthcoming i915_gem_object_get() and
i915_gem_object_pu().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 18 ++-
drivers/gpu/drm/i915/i915_gem.c| 56 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 8 ++-
Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having
to wait for the entire object to be idle). This improves the interaction
when using multiple contexts (with full-ppgtt) and eliminates some
frequent list walk
The drop_pages() function is a dangerous trap in that it can release the
passed in object pointer and so unless the caller is aware, it can
easily trick us into using the stale object afterwards. Move it into its
solitary callsite where we know it is safe.
Signed-off-by: Chris Wilson
---
drivers
Make sure that the RPS bottom-half is flushed before we set the idle
frequency when we decide the GPU is idle. This should prevent any races
with the bottom-half and setting the idle frequency, and ensures that
the bottom-half is bounded by the GPU's rpm reference taken for when it
is active (i.e.
dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the future, to pass those fences
back to userspac
We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the hang, the ring is idle and there is no information
inside the ring pertaining to the hang.
Note carefully that this will reduce the amount of info
Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.
v2: Fix "hang" vs "no progress" message whilst I was there
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 41 ++---
1 file changed, 26 insertions(+),
In the future, we will want to add annotations to the i915_gem_active
struct. The API is thus expanded to hide direct access to the contents
of i915_gem_active and mediated instead through a number of helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 ++--
dr
Initialising the global GTT is tricky as we wish to use the drm_mm range
manager during the modesetting initialisation (to capture stolen
allocations from the BIOS) before we actually enable GEM. To overcome
this, we currently setup the drm_mm first and then carefully rebind
them.
Signed-off-by: C
In order to disambiguate between the pointer to the intel_engine_cs
(called ring) and the intel_ringbuffer (called ringbuf), rename
s/ring/engine/.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 6 ++
dri
If we rewrite the I915_WRITE_TAIL specialisation for the legacy
ringbuffer as submitting the request onto the ringbuffer, we can unify
the vfunc with both execlists and GuC in the next patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 5 +--
drivers/gpu/drm/i915/i
Rather than pass in the num_dwords that the caller wishes to use after
the signal command packet, split the breadcrumb emission into two phases
and have both the signal and breadcrumb individiually acquire space on
the ring. This makes the interface simpler for the reader, and will
simplify for pat
Perform s/ringbuf/ring/ on the context struct for consistency with the
ring/engine split.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 8
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 4 ++--
drivers/gp
Having ringbuf->ring point to an engine is confusing, so rename it once
again to ring->engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/dri
Now that we have (near) universal GPU recovery code, we can inject a
real hang from userspace and not need any fakery. Not only does this
mean that the testing is far more realistic, but we can simplify the
kernel in the process.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.
Rather than recomputing whether semaphores are enabled, we can do that
computation once during early initialisation as the i915.semaphores
module parameter is now read-only.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c |
Tidy up the for loops that handle waiting for read/write vs read-only
access.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 163 +++-
1 file changed, 78 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/
As the list retirement is now clean of implementation details, we can
move it closer to the request management.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 41 -
drivers/gpu/drm/i915/i915_gem_request.c | 33 ++
If is simpler and leads to more readable code through the callstack if
the allocation returns the allocated struct through the return value.
The importance of this is that it no longer looks like we accidentally
allocate requests as side-effect of calling certain functions.
Signed-off-by: Chris W
Now that we use the same vfuncs for emitting the batch buffer in both
execlists and legacy, the golden render state initialisation is
identical between both.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 23 +--
drivers/gpu/drm/i915/i915_gem_rende
Since
commit a6f766f3975185af66a31a2cea2cd38721645999
Author: Chris Wilson
Date: Mon Apr 27 13:41:20 2015 +0100
drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts
and
commit bcafc4e38b6ad03f48989b7ecaff03845b5b7acf
Author: Chris Wilson
Date: Mon Apr 27 13:41:21 2015 +0100
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_gem.c | 26 +-
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
drivers/gpu/drm/
1 - 100 of 237 matches
Mail list logo
