On Mon, 05 May 2014, Mike Psarras madvine...@hotmail.com wrote:
Hi. I am not sure if I should send this to you but I was asked to send
the below bug to the maintainers list. Could you please have a look
and let me know? In case I should forward the email to someone else,
please let me know.
Greg, ping? Can we go with this?
On Mon, 28 Apr 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Apr 28, 2014 at 01:10:07PM +0300, Jani Nikula wrote:
This reverts the bisected regressing
commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
Author: Jani Nikula jani.nik...@intel.com
Date:
On Tue, May 6, 2014 at 8:03 AM, Jani Nikula jani.nik...@linux.intel.com wrote:
Ubuntu kernel version bisect revealed:
First bad Ubuntu kernel: 3.11.0-0.2
last good Ubuntu kernel: 3.10.0-6.17
A bisect result on upstream kernel pointing at the regression might be
useful... although we've
Hi,
I am developing the HSW's OCL driver in the linux. I encounter a LRI problem on
HSW.
Some gpgpu's applications, which use the shared local memory, must load the
L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3 cache.
So I add L3CTRLREG2 and L3CTRLREG3 to the
Hi all,
New -testing cycle with cool stuff:
- ring init improvements (Chris)
- vebox2 support (Zhao Yakui)
- more prep work for runtime pm on Baytrail (Imre)
- eDram support for BDW (Ben)
- prep work for userptr support (Chris)
- first parts of the encoder-mode_set callback removal (Daniel)
- 64b
Hi Dave -
Some more i915 fixes. There's still some DP issues we are looking into,
but wanted to get these moving.
BR,
Jani.
The following changes since commit 78f2975eec9faff353a6194e854d3d39907bab68:
drm/i915: Move all ring resets before setting the HWS page (2014-04-25
16:01:14 +0300)
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is kept locked'.
(http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html)
This patch aims to reduce the allocation time of
All the somewhat recent VBT specs and the kernel have different format
for the eDP block than what the tool decodes. What the tool does *may*
be correct for really old VBT, but I have no specs or other reference to
suppor this. Just do what the kernel does, that's what we're interested
in anyway.
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers.
On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is kept locked'.
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers
Use defines, do not set anything if VBT has values unknown to us.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_bios.c | 52 ---
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
From: Paulo Zanoni paulo.r.zan...@intel.com
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Most likely the minimums for both should be enough for enabling the
native resolution on the eDP, and we'll end up using the predetermined
optimal link config for the panel.
v2: Add debug prints.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73539
Tested-by: Markus Blank-Burian
On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform
On Tue, May 06, 2014 at 09:57:01AM +0300, Jani Nikula wrote:
Greg, ping? Can we go with this?
I still have over 700 emails pending for the stable releases, I'm
working my way through the patches that were sent to me the simple way
(i.e. through the cc: tag on them), before I get to the rest.
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Signed-off-by: Paulo Zanoni
On Tue, 2014-05-06 at 11:34 +, Chris Wilson wrote:
On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is
On 28.04.2014 15:26, Daniel Vetter wrote:
Hi Dave,
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all
On Tue, May 06, 2014 at 12:59:37PM +, Gupta, Sourab wrote:
On Tue, 2014-05-06 at 11:34 +, Chris Wilson wrote:
On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on
Hi,
V2 series of the render state initialization patches.
I decided not to pursue the copying of the context object as the ctx
is quite big, atleast on bdw. As discussed in irc, the copying
could be done with blitter, on context creation time. But even then we would
need to wait for it to
These are generated with intel-gpu-tools/tools/null_state_gen
v2: Don't use header file for states (Daniel Vetter)
Tested-by: Kristen Carlson Accardi kris...@linux.intel.com (v1)
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/intel_renderstate_gen6.c | 281
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
On Tue, 06 May 2014, Knut Petersen knut_peter...@t-online.de wrote:
On 28.04.2014 15:26, Daniel Vetter wrote:
The patch below is a clear candidate for 3.15 as it fixes a regression
introduced after 3.14
Egbert Eich (1):
drm/i915/SDVO: For sysfs link put directory and target in correct
Ben Widawsky b...@bwidawsk.net writes:
On Tue, Apr 22, 2014 at 08:19:43PM +0300, Mika Kuoppala wrote:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Signed-off-by: Paulo Zanoni
On Tue, May 06, 2014 at 02:34:41PM +0100, Damien Lespiau wrote:
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while
On Tue, May 06, 2014 at 02:56:51PM +0300, Jani Nikula wrote:
Use defines, do not set anything if VBT has values unknown to us.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
___
On Tue, May 06, 2014 at 04:26:05PM +0300, Mika Kuoppala wrote:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
* shrug
What's improper 3d state and what prevents userspace from triggering
badness later?
The only problem I see in the patch is
Why does this work? It is neither the most minimal batch, nor the
maximal. Which state is truly required? It looks like cargo-culted
Chinese.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
On Tue, May 06, 2014 at 02:56:52PM +0300, Jani Nikula wrote:
Most likely the minimums for both should be enough for enabling the
native resolution on the eDP, and we'll end up using the predetermined
optimal link config for the panel.
v2: Add debug prints.
Bugzilla:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
For each new uninitialized context, generate a
valid null render state to be run on context
creation.
This patch introduces a skeleton with empty states.
v2: - No need to vmap (Chris Wilson)
-
Chris Wilson ch...@chris-wilson.co.uk writes:
On Tue, May 06, 2014 at 04:26:05PM +0300, Mika Kuoppala wrote:
HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.
* shrug
What's improper 3d state and what prevents userspace from triggering
On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
Currently user space can access GEM buffers mapped to GTT
Chris Wilson ch...@chris-wilson.co.uk writes:
Why does this work? It is neither the most minimal batch, nor the
maximal. Which state is truly required? It looks like cargo-culted
Chinese.
These are just stripped down version of rendercopy for each gen.
What I would guess would be the key to
On Tue, May 06, 2014 at 02:27:23PM +0300, Jani Nikula wrote:
All the somewhat recent VBT specs and the kernel have different format
for the eDP block than what the tool decodes. What the tool does *may*
be correct for really old VBT, but I have no specs or other reference to
suppor this. Just
On Tue, May 06, 2014 at 07:04:21PM +0300, Jani Nikula wrote:
On Tue, 06 May 2014, Damien Lespiau damien.lesp...@intel.com wrote:
On Tue, May 06, 2014 at 02:27:23PM +0300, Jani Nikula wrote:
All the somewhat recent VBT specs and the kernel have different format
for the eDP block than what
On Tue, 06 May 2014, Damien Lespiau damien.lesp...@intel.com wrote:
On Tue, May 06, 2014 at 02:56:50PM +0300, Jani Nikula wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while
sourab.gu...@intel.com writes:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is kept locked'.
(http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html)
One of
On 05/06/2014 08:26:15 AM, Yang, Rong R wrote:
Hi,
I am developing the HSW’s OCL driver in the linux. I encounter a LRI
problem on HSW.
Some gpgpu's applications, which use the shared local memory, must load
the L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3
cache.
On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
On Tue, 06 May 2014, Knut Petersen knut_peter...@t-online.de wrote:
On 28.04.2014 15:26, Daniel Vetter wrote:
The patch below is a clear candidate for 3.15 as it fixes a regression
introduced after 3.14
Egbert Eich (1):
On Wed, Apr 09, 2014 at 01:28:02PM +0300, ville.syrj...@linux.intel.com wrote:
From: Rafael Barbalho rafael.barba...@intel.com
Page table updates were getting stuck in the CPU cache on chv causing
spurious page faults and strange behaviour.
Signed-off-by: Rafael Barbalho
On Fri, May 02, 2014 at 11:35:51AM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Due to Pipe C DPINVGTT has more bits on CHV.
v2: Fix comment to say VLV/CHV (Rafael)
Reviewed-by: Rafael Barbalho rafael.barba...@intel.com
Signed-off-by:
Adds support for executing the resource streamer on BDW
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
3 files changed, 4
From: Abdiel Janulgue abdiel.janul...@linux.intel.com
This is a re-spin of my resource streamer patchset from October
adapted to enable the feature on Broadwell instead.
The resource streamer is a hw-feature that helps in reducing commands
being submitted by the CPU. Haswell initially has this
Ensures that the batch buffer is executed by the resource streamer
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
include/uapi/drm/i915_drm.h|7 ++-
2 files changed, 14 insertions(+), 1
On Tue, May 06, 2014 at 05:46:01PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:28:50PM +0300, Imre Deak wrote:
On Fri, Apr 25, 2014 at 07:14:42PM +0300, Ville Syrjälä wrote:
On Fri, Apr 25, 2014 at 05:28:00PM +0300, Imre Deak wrote:
In recent dmesg logs reported for unrelated issues I noticed some power
domain WARNs caused by the following.
The workaround
commit
On Mon, Apr 14, 2014 at 08:41:30PM +0300, Imre Deak wrote:
Signed-off-by: Imre Deak imre.d...@intel.com
Ok, pulled it all in. Thanks for patchesreview.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[ I managed to leave out this last
This patchseries tests a resource streamer feature called hw-generated binding
tables,
which can be enabled from userspace. It is essentially a newer format that uses
the hw to
generate and submit binding tables to the GPU. It uses the basic rendercopy
test to toggle
the feature on and off and
Add option in basic test for the render_copy to test and toggle
hw-generated binding tables feature.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
tests/gem_render_copy.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/gem_render_copy.c
Use on-chip hw-binding table generator to generate binding
tables when the test emits SURFACE_STATES packets. The hw generates
these binding table packets internally so we don't have to
allocate space on the batchbuffer.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
On Tue, 2014-05-06 at 21:27 +0200, Daniel Vetter wrote:
On Tue, May 06, 2014 at 05:46:01PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:59 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 02:42:26PM +0300, Imre Deak wrote:
On Tue, 2014-05-06 at 12:40 +0100, Chris Wilson wrote:
On Tue, May 06, 2014 at 10:04:17PM +0200, Knut Petersen wrote:
On 06.05.2014 20:59, Daniel Vetter wrote:
On Tue, May 06, 2014 at 04:30:45PM +0300, Jani Nikula wrote:
On Tue, 06 May 2014, Knut Petersen knut_peter...@t-online.de wrote:
On 28.04.2014 15:26, Daniel Vetter wrote:
The patch below
On Tue, May 06, 2014 at 10:48:01PM +0300, Abdiel Janulgue wrote:
This patchseries tests a resource streamer feature called hw-generated
binding tables,
which can be enabled from userspace. It is essentially a newer format that
uses the hw to
generate and submit binding tables to the GPU. It
On Tue, May 06, 2014 at 10:25:06PM +0300, Abdiel Janulgue wrote:
Ensures that the batch buffer is executed by the resource streamer
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
include/uapi/drm/i915_drm.h
On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
Use on-chip hw-binding table generator to generate binding
tables when the test emits SURFACE_STATES packets. The hw generates
these binding table packets internally so we don't have to
allocate space on the batchbuffer.
Add test that makes sure RS bit only gets executed on BDW and
on the render ring.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
tests/gem_exec_params.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/gem_exec_params.c b/tests/gem_exec_params.c
index
On Wednesday, May 07, 2014 12:38:04 AM Ville Syrjälä wrote:
On Tue, May 06, 2014 at 10:48:02PM +0300, Abdiel Janulgue wrote:
Use on-chip hw-binding table generator to generate binding
tables when the test emits SURFACE_STATES packets. The hw generates
these binding table packets internally
On Wed, May 07, 2014 at 12:40:53AM +0300, Abdiel Janulgue wrote:
Add test that makes sure RS bit only gets executed on BDW and
on the render ring.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
tests/gem_exec_params.c | 11 +++
1 file changed, 11
On Wed, May 07, 2014 at 12:40:13AM +0200, Daniel Vetter wrote:
On Wed, May 07, 2014 at 12:40:53AM +0300, Abdiel Janulgue wrote:
Add test that makes sure RS bit only gets executed on BDW and
on the render ring.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
From: Ben Widawsky benjamin.widaw...@linux.intel.com
Daniel requested in the bug that I use a 3GB fallback size. Since this
is not in the spec as a valid size, I decided against it. We could
potentially add a patch to bump it to 3GB on top of this one.
This probably should be CC: stable - but
This will be useful for some upcoming patches which do more platform
specific work. Having it in one central place just makes things a bit
cleaner and easier.
There is a small functional change here. There are more calls to the
tracepoints.
NOTE: I didn't actually end up using this patch for the
It was always the intention to do the topdown allocation for context
objects (Chris' idea originally). Unfortunately, I never managed to land
the patch, but someone else did, so now we can use it.
As a reminder, hardware contexts never need to be in the precious GTT
aperture space - which is what
We only actually want to retry if the failure mode was not enough space,
and so we'll evict. This will help us realize quickly in case we missed
a change in the common drm code.
NOTE: A similar check is already in place for the GEN7 PPGTT code.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
There is a good debate to be had about how best to fit the aliasing
PPGTT into the code. However, as it stands right now, getting aliasing
PPGTT bindings is a hack, and done through implicit arguments. To make
this absolutely clear, WARN and return an error if a driver writer tries
to do something
The two users were already really similar. By adding the flags (I hope
you like a lot of arguments in your functions), we can satisfy both
callers quite well.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 16
The driver currently lets callers pin global, and then tries to do
things correctly inside the function. Doing so has two downsides:
1. It's not possible to exclusively pin to a global, or an aliasing
address space.
2. It's difficult to read, and understand.
The eventual goal when realized should
This patch finishes off actually separating the aliasing and global
finds. Prior to this, all global binds would be aliased. Now if aliasing
binds are required, they must be explicitly asked for. So far, we have
no users of this outside of execbuf - but Mika has already submitted a
patch
The DRM node allocation code was already a bit of an ugly bit of code
within a complex function. Removing it serves the purpose of cleaning
the function up. More importantly, it provides a way to have a
preallocated (address space) VMA to easily skip this code. Something
we're very likely to need.
AFAICT, it's impossible to actually infinitely retry the allocation in
our current code. However, a small oversight on my part, slight bug, or
future bug, could easily change that.
To avoid a potential breakage, a simple retry variable of 16 bits will
help us prevent infinitely running.
Retry is
On Mon, 2014-05-05 at 16:07 +0200, Daniel Vetter wrote:
On Mon, May 05, 2014 at 05:13:18PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
There is a use case, when user space (display compositor) tries
to directly flip a fb (without any prior rendering) on
73 matches
Mail list logo
