From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
Signed-off-by: Chia-I Wu o...@lunarg.com
Cc: Ian Romanick ian.d.roman...@intel.com
Cc: Chad Versace
[Additional comments, and copy Ian and Chad for real]
On Mon, Jan 27, 2014 at 4:18 PM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark
We seem to get confused when trying to reconstruct this from the pipe
get_config when reading out pfit state. In our code these two are
connected, but in the hardware they're not.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Cc: Alan Stern st...@rowland.harvard.edu
Cc:
Apparently we really only need this when the pfit is enabled, at least
I couldn't dicern any difference here. Furthermore the hacks we have
to reconstruct this bit is a bit glaring, and probably only works
because we can't move the lvds port to any other pipe than pipe B on
gen2/3.
So let's just
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
Don't bother. I'll redo it using the drm-intel-nightly branch, but I
won't have time for a few days.
My apologies for the delay in getting around to this. Can you please
test the patch i've just posted?
On Mon, Jan 27, 2014 at 9:33 AM, Chia-I Wu olva...@gmail.com wrote:
[Additional comments, and copy Ian and Chad for real]
On Mon, Jan 27, 2014 at 4:18 PM, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled
On Sun, Jan 26, 2014 at 03:33:32PM +0100, Daniel Vetter wrote:
On Sat, Jan 25, 2014 at 08:59:49PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 07:47:59PM +, Chris Wilson wrote:
On Thu, Jan 23, 2014 at 04:49:07PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville
On Sun, Jan 26, 2014 at 03:35:42PM +0100, Daniel Vetter wrote:
On Sun, Jan 26, 2014 at 03:33:32PM +0100, Daniel Vetter wrote:
On Sat, Jan 25, 2014 at 08:59:49PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 07:47:59PM +, Chris Wilson wrote:
On Thu, Jan 23, 2014 at 04:49:07PM
On Sat, Jan 25, 2014 at 08:57:34PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 04:49:12PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Hm, running the fbc tests with a
On Mon, Jan 27, 2014 at 10:00:31AM +0100, Daniel Vetter wrote:
We seem to get confused when trying to reconstruct this from the pipe
get_config when reading out pfit state. In our code these two are
connected, but in the hardware they're not.
Huh? I think the change is to only read out the
On Mon, Jan 27, 2014 at 09:57:11AM +, Chris Wilson wrote:
On Mon, Jan 27, 2014 at 10:00:31AM +0100, Daniel Vetter wrote:
We seem to get confused when trying to reconstruct this from the pipe
get_config when reading out pfit state. In our code these two are
connected, but in the hardware
On Sun, Jan 26, 2014 at 06:29:06PM +0100, Daniel Vetter wrote:
On Tue, Jan 21, 2014 at 04:12:38PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two
On 01/24/14 14:52, Ville Syrjälä wrote:
On Fri, Jan 24, 2014 at 02:13:14PM +0200, Antti Koskipaa wrote:
+#define PIPE_A_OFFSET 0x7
+#define PIPE_B_OFFSET 0x71000
+#define PIPE_C_OFFSET 0x72000
I'd like a comment here to explain what PIPE_EDP_OFFSET
actually means.
Sorry, sent the wrong file. Ignore this one.
--
- Antti
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP
On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
PATCHv1: Fixed offsets for VLV
Upcoming
And subject is misleading, I don't call this a clean up.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
PATCHv1: Fixed offsets for VLV
Upcoming hardware will not have the various display pipe register
ranges evenly spaced
On 01/27/14 13:21, Chris Wilson wrote:
On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
PATCHv1:
On Mon, Jan 27, 2014 at 02:51:53PM +0200, Antti Koskipää wrote:
On 01/27/14 13:21, Chris Wilson wrote:
On Mon, Jan 27, 2014 at 01:17:25PM +0200, Antti Koskipaa wrote:
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP
On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
Actually BSpec even goes as far as saying that
Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_params.c | 12 ++--
1 file changed, 6
On Mon, Jan 27, 2014 at 03:09:34PM +0200, Antti Koskipaa wrote:
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 11:47:40AM +, Chris Wilson wrote:
On Fri, Jan 24, 2014 at 06:17:45PM
Currently we report through our error state only the rings that have
been initialised (as detected by ring-obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print
On Mon, Jan 27, 2014 at 01:52:34PM +, Chris Wilson wrote:
Currently we report through our error state only the rings that have
been initialised (as detected by ring-obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the
On Mon, Jan 27, 2014 at 10:30:11AM -0500, Alan Stern wrote:
On Mon, 27 Jan 2014, Daniel Vetter wrote:
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu
wrote:
Don't bother. I'll redo it using the drm-intel-nightly branch, but I
won't have time for a few days.
On Mon, Jan 27, 2014 at 01:06:33PM +0200, Ville Syrjälä wrote:
On Sun, Jan 26, 2014 at 06:29:06PM +0100, Daniel Vetter wrote:
On Tue, Jan 21, 2014 at 04:12:38PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a mechanism by which we
From: Deepak S deepa...@intel.com
Below patches addes WA to set Gfx freq while clock are down and enable/disable
the pm interrupts based on cur delay.
Deepak S (2):
drm/i915: Disable/Enable PM Intrrupts based on the current freq.
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin
From: Deepak S deepa...@intel.com
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock
On Mon, 27 Jan 2014, Daniel Vetter wrote:
By the way, I tried getting an up-to-date version of your
drm-intel-nightly branch, and ended up with the following:
$ git clone --depth 1 -b drm-intel-nightly
http://cgit.freedesktop.org/~danvet/drm-intel/
Cloning into 'drm-intel'...
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2:
On Mon, Jan 27, 2014 at 04:05:24PM +0200, Ville Syrjälä wrote:
On Mon, Jan 27, 2014 at 01:52:34PM +, Chris Wilson wrote:
Currently we report through our error state only the rings that have
been initialised (as detected by ring-obj). This check is done after
the GPU reset and ring
On Mon, 27 Jan 2014, Daniel Vetter wrote:
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
Don't bother. I'll redo it using the drm-intel-nightly branch, but I
won't have time for a few days.
My apologies for the delay in getting around to this. Can you please
On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
The current frequency should reach the minimum frequency within a
reasonable time during idle.
v2: Not using
On Mon, Jan 27, 2014 at 03:07:45PM +0200, Ville Syrjälä wrote:
On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as
On Mon, Jan 27, 2014 at 03:26:38PM +0200, Jani Nikula wrote:
Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Queued for -next,
On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote:
On Mon, 27 Jan 2014, Daniel Vetter wrote:
By the way, I tried getting an up-to-date version of your
drm-intel-nightly branch, and ended up with the following:
$ git clone --depth 1 -b drm-intel-nightly
On Mon, Jan 27, 2014 at 09:35:06PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle,
On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
The current frequency should reach the minimum
On Mon, Jan 27, 2014 at 09:35:06PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle,
On Mon, 27 Jan 2014, Daniel Vetter wrote:
On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote:
On Mon, 27 Jan 2014, Daniel Vetter wrote:
By the way, I tried getting an up-to-date version of your
drm-intel-nightly branch, and ended up with the following:
$ git clone
Hi Chris,
A few questions/comments throughout. I may be off the mark on some. Please
bear with me as I try to get more familiar with the gem code.
Thanks,
Brad
[ snip ]
On Fri, Jan 24, 2014 at 01:00:19AM -0800, Chris Wilson wrote:
+static void
+__i915_mmu_notifier_destroy_worker(struct
On Mon, Jan 27, 2014 at 09:56:12AM -0800, Volkin, Bradley D wrote:
+static void
+i915_mmu_notifier_del(struct i915_mmu_notifier *mmu,
+ struct i915_mmu_object *mn)
+{
+ bool destroy;
+
+ spin_lock(mmu-lock);
+ interval_tree_remove(mn-it, mmu-objects);
+
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Apparently I've lost a game of chicken. For review I'd like to sign up Jani for
the overall series and Ben to upgrade his ack on the actual bugfix to a full
r-b.
Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Tighter code since legacy gem has only mappable anyway.
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file
From: Chris Wilson ch...@chris-wilson.co.uk
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
On Mon, Jan 27, 2014 at 01:45:22PM +, Chris Wilson wrote:
On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 11:47:40AM
There's no need not to, really.
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
drivers/gpu/drm/i915/i915_gem.c | 20
2 files
This is prep work for reworking the object_pin logic. Atm
it still does a (now redundant) lookup of the vma. The next
patch will fix this.
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter
We access it through the cpu window. No functional difference expected
atm since we default to a bottom-up allocation scheme. But that might
eventually change so that we prefer the unmappable range for buffers
that don't need cpu gtt access.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Only the hardware really access them, so no need to have cpu
gtt access available.
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c
On Mon, Jan 27, 2014 at 01:45:22PM +, Chris Wilson wrote:
On Sun, Jan 26, 2014 at 01:47:29PM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 07:55:59PM +, Chris Wilson wrote:
On Sun, Jan 26, 2014 at 11:05:40AM -0800, Ben Widawsky wrote:
On Sun, Jan 26, 2014 at 11:47:40AM
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 12
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite
On Mon, Jan 27, 2014 at 09:49:47PM +0100, Daniel Vetter wrote:
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here
On Mon, Jan 27, 2014 at 12:31:08PM -0800, Ben Widawsky wrote:
The other issue is the existing method doesn't rely as much on proper
request handling, ie. this could be more resilient to driver bugs. I
kind of want to keep both...
Actually I think it is. Part of the process of reading an error
On Mon, Jan 27, 2014 at 10:26 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Jan 27, 2014 at 09:49:47PM +0100, Daniel Vetter wrote:
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence
On Mon, Jan 27, 2014 at 07:10:51PM +0100, Daniel Vetter wrote:
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
This patch introduces PIN_GLOBAL which is required for ggtt_pin to
remain correct with the flag changes in the later patches, but
On Mon, Jan 27, 2014 at 09:31:04PM +, Chris Wilson wrote:
On Mon, Jan 27, 2014 at 12:31:08PM -0800, Ben Widawsky wrote:
The other issue is the existing method doesn't rely as much on proper
request handling, ie. this could be more resilient to driver bugs. I
kind of want to keep both...
On Mon, Jan 27, 2014 at 09:47:12PM +, Chris Wilson wrote:
On Mon, Jan 27, 2014 at 07:10:51PM +0100, Daniel Vetter wrote:
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
This patch introduces PIN_GLOBAL which is required for
On Mon, Jan 27, 2014 at 05:50:04PM +0100, Daniel Vetter wrote:
On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 03:54:50PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee
According to the latest documentation, any PIPE_CONTROL with the
Command Streamer Stall bit set must also have another bit set,
with five different options. I chose Stall at Pixel Scoreboard
since we've used it effectively in the past, but the choice is
fairly arbitrary.
Signed-off-by: Kenneth
This should apply even for production hardware.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 37 -
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
On Broadwell, any PIPE_CONTROL with the State Cache Invalidate bit set
must be preceded by a PIPE_CONTROL with the CS Stall bit set.
Documented on the BSpec 3D workarounds page.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +
1
These should only be necessary on pre-production hardware.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
v2: Undo the behaviour change in object_pin that Chris spotted.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky
From: Chris Wilson ch...@chris-wilson.co.uk
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a
On Mon, Jan 27, 2014 at 04:23:26PM -0600, Jeff McGee wrote:
On Mon, Jan 27, 2014 at 05:50:04PM +0100, Daniel Vetter wrote:
On Mon, Jan 27, 2014 at 10:24:53AM -0600, Jeff McGee wrote:
On Sat, Jan 25, 2014 at 08:46:45PM +0100, Daniel Vetter wrote:
On Thu, Jan 23, 2014 at 03:54:50PM -0600,
As the VM do not track activity of objects and instead use a large
hammer to forcibly idle and evict all of their associated objects when
one is released, it is possible for that to cause a recursion when we
need to wait for free space on a ring and call retire requests.
(intel_ring_begin -
On Sun, 26 Jan 2014 12:24:33 + Chris Wilson ch...@chris-wilson.co.uk
wrote:
Note for maintainers, this is being proposed for use by i915.ko, so it
may make the most sense to merge it via the drm/i915 tree in the next
cycle.
Yes, please proceed that way.
On Mon, 13 Jan 2014 16:24:45 +0530
akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
The 'offset' field of the 'scatterlist' structure was wrongly
programmed with the offset value from the base of stolen area,
whereas this field indicates the offset from where the interested
On Mon, Jan 27, 2014 at 02:20:14PM -0800, Kenneth Graunke wrote:
According to the latest documentation, any PIPE_CONTROL with the
Command Streamer Stall bit set must also have another bit set,
with five different options. I chose Stall at Pixel Scoreboard
since we've used it effectively in
On Mon, Jan 27, 2014 at 02:20:18PM -0800, Kenneth Graunke wrote:
These should only be necessary on pre-production hardware.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed,
On Mon, Jan 27, 2014 at 02:20:16PM -0800, Kenneth Graunke wrote:
On Broadwell, any PIPE_CONTROL with the State Cache Invalidate bit set
must be preceded by a PIPE_CONTROL with the CS Stall bit set.
Documented on the BSpec 3D workarounds page.
FWIW, I am not clear this is actually needed. If
From: Zhao Yakui yakui.z...@intel.com
The Sampler/Constant cache is read-only. And it can't be used as
the target cache agent of WRITE message.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
assembler/gram.y | 4
1 file changed, 4 deletions(-)
diff --git a/assembler/gram.y
On Mon, Jan 27, 2014 at 9:07 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Jan 27, 2014 at 04:18:36PM +0800, Chia-I Wu wrote:
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain
From: Chia-I Wu o...@lunarg.com
The optimization helps IVB too. No piglit regression.
Signed-off-by: Chia-I Wu o...@lunarg.com
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
From: Chia-I Wu o...@lunarg.com
The optimization is available on Ivy Bridge and later, and is disabled by
default. Enabling it helps certain workloads such as GLBenchmark TRex test.
No piglit regression.
v2
- no need to save the register before suspend as init_clock_gating can
correctly
There are cases where we want to know if there is a full, or aliased
PPGTT. Currently, in fact the only distinction we ever need to make is
when we're using full PPGTT.
This patch is simply to promote readability and clarify for the
confusing existing usage where aliasing meant aliasing and full.
The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.
A subsequent patch will clean this function up.
Signed-off-by: Ben Widawsky
Create logical sections in an attempt to clean up, and continue to keep
future additions clean.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gpu_error.c | 60 +--
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git
Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */
Requested-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 4
v2: Rebased upon cleaned up error state
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 9
drivers/gpu/drm/i915/i915_gpu_error.c | 39 +++
2 files changed, 48
This helps make an upcoming patch a bit more reviewable
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 43 -
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 62 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 137 +-
2 files changed, 99 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
On Thu, 19 Dec 2013, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because we already do the wait in software: see
ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.
For the backlight on delay, even BSpec says we need to program 0x1
to
92 matches
Mail list logo
