The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is ineffecient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active loca
The single largest factor in the overhead of parsing the commands is the
setup of the virtual mapping to provide a continuous block for the batch
buffer. If we keep those vmappings around (against the better judgement
of mm/vmalloc.c, which we offset by handwaving and looking suggestively
at the sh
Soft-pinning depends upon being able to check for availabilty of an
inverval and evict overlapping object fro a drm_mm range manager very
quickly. Currently it uses a linear list which makes performance dire,
and softpinning not a suitable replacement.
It also helps if the routine reports the corr
Not only does it make for good documentation and debugging aide, but it
is also vital for when we want to unwind requests - such as when
throwing away an incomplete request.
v2: Rebase
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_
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
No functional changes, just less typing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 63
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c2a45
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the numbe
When working with contexts, we most frequently want the GGTT VMA for the
context state, first and foremost. Since the object is available via the
VMA, we need only then store the VMA.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 ++--
drivers/gpu/drm/i915/i915_
The obj->dirty bit is a companion to the obj->active bits that were
moved to the obj->flags bitmask. Since we also update this bit inside
the i915_vma_move_to_active() hotpath, we can aide gcc by also moving
the obj->dirty bit to obj->flags bitmask.
Signed-off-by: Chris Wilson
---
drivers/gpu/dr
Adding to the tail of the client request list as the only other user is
in the throttle ioctl that iterates forwards over the list. It only
needs protection against deletion of a request as it reads it, it simply
won't see a new request added to the end of the list, or it would be too
early and rej
In a nonblocking wait, we gather up all the outstanding requests and
then drop the mutex. However if all those requests have already
completed we do not need to wait upon them and can exit early without
having to drop and reacquire the struct_mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/dr
For simplicity, we want to continue using a contiguous mapping of the
command buffer, but we can reduce the number of vmappings we hold by
switching over to a page-by-page copy from the user batch buffer to the
shadow. The cost for saving one linear mapping is about 5% in trivial
workloads - which
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 19b0d6a7680d..f8ca00ce986e 100644
--- a/drivers/gpu/drm/i91
Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the re
Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.
Signed
This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_evict.c | 23 +++---
drivers/gpu/drm/i915/i915_gem_ex
Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 539 +
1 file changed, 231 insertions(+), 308 deletions(-)
diff --git a/drivers/gpu
The existing code's hashfunction is very suboptimal (most 3D commands
use the same bucket degrading the hash to a long list). The code even
acknowledge that the issue was known and the fix simple:
/*
* If we attempt to generate a perfect hash, we should be able to look at bits
* 31:29 of a comma
Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.
Signed-off-by: Chris Wilson
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_vma_manager.c | 43 ---
include/drm/drm_vma_manager
On the blitter (and in test code), we see long sequences of repeated
commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these,
we can skip the hashtable lookup by remembering the previous command
descriptor and doing a straightforward compare of the command header.
The corollary is t
As we never need to directly access the pages we allocate for scratch and
the pagetables, and always remap them into the GTT through the dma
remapper, we do not need to limit the allocations to lowmem i.e. we can
pass in the __GFP_HIGHMEM flag to the page allocation.
For backwards compatibility, e
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
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7)
dmesg-warn -> PASS (bdw-ultra)
Te
== Summary ==
HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC
integration manifest
Applying: drm: kerneldoc for drm_fops.c
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm: kerneldoc for drm_fops.c
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
dmesg-warn -> PASS (bdw-
Kernel and userspace are able to handle 4GB (1<<32) address space range,
but "A32 Stateless Model" is not. According to documentation, A32 accesses
are based on General State Base Address and bound checking is in place.
Because size field (instruction State Base Address) limitation, it is not
possi
On Mon, Jan 11, 2016 at 11:39:27AM +, Michel Thierry wrote:
> Kernel and userspace are able to handle 4GB (1<<32) address space range,
> but "A32 Stateless Model" is not. According to documentation, A32 accesses
> are based on General State Base Address and bound checking is in place.
> Because
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-ultra)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
On 11/01/16 09:06, Daniel Vetter wrote:
On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrote:
Some stress tests create both the signal helper and a lot of compet
I've fixed some patches with feedback from review.
It's about time that intel_crtc->atomic dies. It was useful
with the transitional helpers, but can be removed safely now.
Maarten Lankhorst (9):
drm/i915: Unify power domain handling.
drm/i915: Kill off intel_crtc->atomic.wait_vblank, v3.
dr
fb_bits is useful to have in the crtc_state for cs flips when
the code is updated to use intel_frontbuffer_flip_prepare/complete.
So calculate it in advance and move it to crtc_state. The other stuff
can be calculated in post_plane_update, and aren't useful elsewhere.
Changes since v1:
- Changing
This can be derived from the atomic state in pre_plane_update,
which makes it more clear when it's supposed to be called.
Reviewed-by: Ander Conselvan de Oliveira
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 26 +++---
drivers/gpu/drm/i915/inte
Commit 791a32be6eb2 ("drm/i915: Drop intel_update_sprite_watermarks")
removes the use of this variable, but forgot to remove it.
Reviewed-by: Matt Roper
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files chan
Currently we perform our own wait in post_plane_update,
but the atomic core performs another one in wait_for_vblanks.
This means that 2 vblanks are done when a fb is changed,
which is a bit overkill.
Merge them by creating a helper function that takes a crtc mask
for the planes to wait on.
The br
intel_post_plane_update did an extra vblank wait that's no longer needed when
enabling ips.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.
Right now there's separate power domain handling for update_pipe and
modesets. Unify this and only grab POWER_DOMAIN_MODESET once.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 64
1 file changed, 21 insertions(+), 43 deletions(-
This is a revert of commit 066cf55b9ce3 "drm/i915: Fix IPS related flicker".
intel_pre_disable_primary already handles this, and now everything
goes through the atomic path there's no need to try to disable ips twice.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
Factor out intel_fbc_supports_rotation and use it in
pre_plane_update as well. This leaves intel_crtc->atomic
empty, so remove it too.
Changes since v1:
- Add a intel_fbc_supports_rotation helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 87 +--
This should not be done this late when nothing changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 13
drivers/gpu/drm/i915/intel_pm.c | 59 +---
3 files changed, 49 inser
On 1/11/2016 2:19 PM, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 01:09:50PM +0530, Goel, Akash wrote:
On 1/10/2016 11:09 PM, Chris Wilson wrote:
On Sat, Jan 09, 2016 at 05:00:21PM +0530, akash.g...@intel.com wrote:
From: Akash Goel
Gen9 has an additional address translation hardware sup
On Sat, Jan 09, 2016 at 05:01:30PM +0530, akash.g...@intel.com wrote:
> +static void* mmap_bo(int fd, uint32_t handle, uint64_t size)
> +{
> + uint32_t *ptr = gem_mmap__cpu(fd, handle, 0, size, PROT_READ);
> + gem_set_domain(fd, handle, I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
read-only
On Mon, Jan 11, 2016 at 12:25:07PM +, Dave Gordon wrote:
> On 11/01/16 09:06, Daniel Vetter wrote:
> >On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
> >>On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
> >>>On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrot
On Mon, Jan 11, 2016 at 12:32:08PM +, Chris Wilson wrote:
> On Sat, Jan 09, 2016 at 05:01:30PM +0530, akash.g...@intel.com wrote:
> > +static void submit_and_sync(int fd, struct drm_i915_gem_execbuffer2
> > *execbuf,
> > + uint32_t batch_buf_handle)
> > +{
> > + gem_exe
Op 11-01-16 om 13:27 schreef Maarten Lankhorst:
> Right now there's separate power domain handling for update_pipe and
> modesets. Unify this and only grab POWER_DOMAIN_MODESET once.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 64
>
On 07/01/16 16:56, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 12:34:39PM +, Dave Gordon wrote:
On 07/01/16 11:58, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote:
There are a number of places where the driver needs a request, but isn't
working on behalf of
On Thu, 07 Jan 2016, Ville Syrjälä wrote:
> On Thu, Jan 07, 2016 at 11:31:25AM +0200, Jani Nikula wrote:
>> On Tue, 05 Jan 2016, Ville Syrjälä wrote:
>> > On Mon, Dec 21, 2015 at 03:11:00PM +0200, Jani Nikula wrote:
>> >> Add parsing of the i2c element, defined in MIPI sequence block v2. Drop
>>
On Thu, 07 Jan 2016, Ville Syrjälä wrote:
> On Mon, Dec 21, 2015 at 03:11:02PM +0200, Jani Nikula wrote:
>> From: vkorjani
>>
>> New sequence element for i2c is been added in the
>> mipi sequence block of the VBT. This patch parses
>> and executes the i2c sequence.
>>
>> v2: Add i2c_put_adapter
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test core_auth:
Subgroup basic-auth:
pass -> SKIP (snb-dellxps)
pass -> SKIP (bdw-ultra)
Test core
Patchwork writes:
> == Summary ==
>
> Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
> 2016y-01m-11d-07h-30m-16s UTC integration manifest
>
> Test gem_storedw_loop:
> Subgroup basic-render:
> pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
>
The changes since the sequence block v2 are:
* The whole MIPI bios data block has a separate 32-bit size field since
v3, stored after the version. This facilitates big sequences.
* The size of the panel specific sequence blocks has grown to 32
bits. This facilitates big sequences.
* The elem
On 11/01/16 12:34, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 12:25:07PM +, Dave Gordon wrote:
On 11/01/16 09:06, Daniel Vetter wrote:
On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 08:4
Don't choke on unknown elements when we do know how to skip them.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 9bd
== Summary ==
HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC
integration manifest
Applying: drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Using index info to reconstruct a base tree...
M Documentation/DocBook/gpu.tmpl
M drivers/gpu/drm
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
v2: Add i2c_put_adapter call(Jani), rebase
v3: corrected the retry loop(Jani), rebase
v4 by Jani:
- don't put the adapter if get fails
- print an error message if
Use our newly created encoder_mask to iterate over the encoders.
Signed-off-by: Maarten Lankhorst
---
This depends on the atomic encoder_mask patches and is required for unifying
power domain handling.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
ind
On Mon, 11 Jan 2016, Jani Nikula wrote:
> On Thu, 07 Jan 2016, Ville Syrjälä wrote:
>> On Mon, Dec 21, 2015 at 03:11:02PM +0200, Jani Nikula wrote:
>>> From: vkorjani
>>>
>>> New sequence element for i2c is been added in the
>>> mipi sequence block of the VBT. This patch parses
>>> and executes
IGT does not build for Android due to a zlib dependency being added
to intel_error_decode.c in a recent patch.
This patch fixes the error by updating the Android makefile to add
the path to the zlib library and using any LDFLAGS specified in
Makefile.sources.
Signed-off-by: Derek Morton
---
tool
I screwed up something, the authorship for this one should have remained
From: vkorjani
Can be fixed while applying, will not resend now.
BR,
Jani.
On Mon, 11 Jan 2016, Jani Nikula wrote:
> New sequence element for i2c is been added in the
> mipi sequence block of the VBT. This patch parses
On Mon, Jan 11, 2016 at 01:29:12PM +, Dave Gordon wrote:
> On 11/01/16 12:34, Chris Wilson wrote:
> >On Mon, Jan 11, 2016 at 12:25:07PM +, Dave Gordon wrote:
> >>On 11/01/16 09:06, Daniel Vetter wrote:
> >>>On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
> On Mon, Jan 11,
== Summary ==
HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC
integration manifest
Applying: drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Using index info to reconstruct a base tree...
M Documentation/DocBook/gpu.tmpl
M drivers/gpu/drm
On 11/01/16 09:16, Chris Wilson wrote:
In order to ensure seqno/irq coherency, we current read a ring register.
We are not sure quite how it works, only that is does. Experiments show
that e.g. doing a clflush(seqno) instead is not sufficient, but we can
remove the forcewake dance from the mmio a
From: Tvrtko Ursulin
Mostly fixing callers who call GEM API wo/ holding the struct_mutex
and a few small code cleanups.
Tvrtko Ursulin (7):
drm/i915/bdw+: Replace list_del+list_add_tail with list_move_tail
drm/i915: Do not call API requiring struct_mutex where it is not
available
drm/
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.
v3:
Some callers of i915_gem_object_create_stolen_for_
From: Tvrtko Ursulin
No need to call ktime_get_raw_ns twice per unlimited wait and can
also elimate a local variable.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem
From: Tvrtko Ursulin
Same effect for slightly less source code and resulting binary.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc
From: Tvrtko Ursulin
We can avoid open-coding the schedule wake-up since
commit 9cff8adeaa34b5d2802f03f89803da57856b3b72
Author: NeilBrown
Date: Fri Feb 13 15:49:17 2015 +1100
sched: Prevent recursion in io_schedule()
exported the io_schedule_timeout function which we can no
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
v2: Renamed gtt_start to gtt_offset. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lrc.c| 3 +--
drivers/gp
From: Tvrtko Ursulin
LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
places where the struct_mutex cannot be grabbed (irq handlers).
To avoid that this patch caches some interesting offsets and
values in the engine and context structures.
Some usages are also removed where they
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i91
On Tue, 2015-12-29 at 18:50 +, R, Durgadoss wrote:
> Hi Ander,
>
> Thanks for looking into this..
>
> > -Original Message-
> > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> > Sent: Tuesday, December 29, 2015 10:52 PM
> > To: R, Durgadoss; intel-gfx@lists.freedeskto
On 22/12/15 17:40, Chris Wilson wrote:
On Tue, Dec 22, 2015 at 11:58:33AM +, Tvrtko Ursulin wrote:
Maybe:
if (!obj->base.filp || cpu_write_needs_clflush(obj))
ret = i915_gem_gtt_pwrite_fast(...);
if (ret == -EFAULT && !obj->base.filp) {
ret
On Mon, Jan 11, 2016 at 02:08:38PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRC lifetime is well defined so we can cache the page pointing
> to the object backing store in the context in order to avoid
> walking over the object SG page list from the interrupt context
> without the
== Summary ==
HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC
integration manifest
Applying: drm/i915: Kill off intel_crtc->atomic.wait_vblank, v3.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i
On Mon, Jan 11, 2016 at 02:08:37PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
> interrupt context without the big lock held.
>
> v2: Renamed gtt_start to gtt_offset. (Daniel Vetter)
No, we want to track the VMA.
-Chris
On Mon, Jan 11, 2016 at 02:08:37PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
> interrupt context without the big lock held.
No. Tracking the pinned VMA has none of these problems.
-Chris
--
Chris Wilson, Intel Open Sou
On Mon, Jan 11, 2016 at 02:08:39PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can avoid open-coding the schedule wake-up since
>
>commit 9cff8adeaa34b5d2802f03f89803da57856b3b72
>Author: NeilBrown
>Date: Fri Feb 13 15:49:17 2015 +1100
>
>sched: Prevent rec
On Mon, Jan 11, 2016 at 02:08:36PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
> places where the struct_mutex cannot be grabbed (irq handlers).
A more general point is that we have to move it out of the interrupt
handle
On Mon, Jan 11, 2016 at 02:08:40PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> No need to call ktime_get_raw_ns twice per unlimited wait and can
> also elimate a local variable.
But we could eliminate both, and the unsightly pointless assignment only
required to shut gcc up.
Still p
On Mon, Jan 11, 2016 at 02:08:41PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> VMA creation and GEM list management need the big lock.
>
> v2:
>
> Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
>
> Not to mention drm_gem_object_unreference was there in existing
On 11/01/16 10:44, Chris Wilson wrote:
We have a false notion of a default_context allocated per engine,
whereas actually it is a singular context reserved for kernel use.
Remove it from the engines, and rename it thus.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
> Retrying with reduced lanes/bw and updating the final
> available lanes/bw to DPCD is needed for upfront link
> train logic. Hence, this patch adds these methods
> and exports them so that these can be called from
> other files like ddi.c/disp
On Mon, Jan 11, 2016 at 02:21:33PM +, Tvrtko Ursulin wrote:
>
> On 22/12/15 17:40, Chris Wilson wrote:
> >On Tue, Dec 22, 2015 at 11:58:33AM +, Tvrtko Ursulin wrote:
> >>Maybe:
> >>
> >>if (!obj->base.filp || cpu_write_needs_clflush(obj))
> >>ret = i915_gem_gtt_pwri
On 11/01/16 14:38, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:08:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unrefere
Hi,
On 10 January 2016 at 23:48, Laurent Pinchart
wrote:
> On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote:
>> @@ -353,18 +354,16 @@ static void drm_events_release(struct drm_file
>> *file_priv) {
>> struct drm_device *dev = file_priv->minor->dev;
>> struct drm_pending_event
On Mon, Jan 11, 2016 at 02:47:17PM +, Tvrtko Ursulin wrote:
>
> On 11/01/16 14:38, Chris Wilson wrote:
> >On Mon, Jan 11, 2016 at 02:08:41PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>VMA creation and GEM list management need the big lock.
> >>
> >>v2:
> >>
> >>Mutex unloc
On 11/01/16 14:36, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:08:40PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
No need to call ktime_get_raw_ns twice per unlimited wait and can
also elimate a local variable.
But we could eliminate both, and the unsightly pointless assignment on
On Mon, Jan 11, 2016 at 03:00:20PM +, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 02:47:17PM +, Tvrtko Ursulin wrote:
> >
> > On 11/01/16 14:38, Chris Wilson wrote:
> > >On Mon, Jan 11, 2016 at 02:08:41PM +, Tvrtko Ursulin wrote:
> > >>From: Tvrtko Ursulin
> > >>
> > >>VMA creation
On 11/01/16 14:31, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:08:37PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
No. Tracking the pinned VMA has none of these problems.
Th
On 11/01/16 14:29, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:08:38PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the
On 11/01/16 14:45, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:21:33PM +, Tvrtko Ursulin wrote:
On 22/12/15 17:40, Chris Wilson wrote:
On Tue, Dec 22, 2015 at 11:58:33AM +, Tvrtko Ursulin wrote:
Maybe:
if (!obj->base.filp || cpu_write_needs_clflush(obj))
r
On Fri, 2015-12-11 at 15:09 +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the bandwi
On 11/01/16 15:04, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 03:00:20PM +, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:47:17PM +, Tvrtko Ursulin wrote:
On 11/01/16 14:38, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 02:08:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On 11/01/16 09:17, Chris Wilson wrote:
Given that the intel_lr_context_pin cannot succeed without the object,
we cannot reach intel_lr_context_unpin() without first allocating that
object - so we can remove the redundant test.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c
On Mon, Jan 11, 2016 at 03:16:16PM +, Tvrtko Ursulin wrote:
>
>
> On 11/01/16 15:04, Chris Wilson wrote:
> > On Mon, Jan 11, 2016 at 03:00:20PM +, Chris Wilson wrote:
> >> On Mon, Jan 11, 2016 at 02:47:17PM +, Tvrtko Ursulin wrote:
> >>>
> >>> On 11/01/16 14:38, Chris Wilson wrote:
>
On 11/01/16 09:16, Chris Wilson wrote:
In order to simplify the next couple of patches, extract the
lazy_coherency optimisation our of the engine->get_seqno() vfunc into
its own callback.
v2: Rename the barrier to engine->irq_seqno_barrier to try and better
reflect that the barrier is only requi
On 11/01/16 09:16, Chris Wilson wrote:
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the required callsites simplifying the common code and
making the required workaround handling much more explicit.
Signe
Ok,
Please ignore this patch.
It is really part of the pre-emption series. Was included as is being used in
Android.
Peter.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, January 8, 2016 3:20 PM
To: Antoine, Peter
Cc: intel-gfx@lists.freedesktop.o
On Mon, Jan 11, 2016 at 03:29:08PM +0200, Jani Nikula wrote:
> Don't choke on unknown elements when we do know how to skip them.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff
On Mon, Jan 11, 2016 at 02:46:52PM +0200, Jani Nikula wrote:
> On Thu, 07 Jan 2016, Ville Syrjälä wrote:
> > On Thu, Jan 07, 2016 at 11:31:25AM +0200, Jani Nikula wrote:
> >> On Tue, 05 Jan 2016, Ville Syrjälä wrote:
> >> > On Mon, Dec 21, 2015 at 03:11:00PM +0200, Jani Nikula wrote:
> >> >> Add
On 11/01/16 08:31, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 11:29:43AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
LRCA can change only when it goes from unpinned to pinned so it
makes sense to check its alignment at that point rather than at
every batch buffer submission.
Furthermo
201 - 300 of 450 matches
Mail list logo
