On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
I'm confused what exactly this tests, since it seems to never fail ...
automated tests should have some checks for expected results.
Also I'm not sure whether we want such ddx/X
On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote:
On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
I'm confused what exactly this tests,
On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote:
On Tue, Aug 20, 2013 at 03:43:05PM -0300, Rodrigo Vivi wrote:
Signed-off-by:
On Wed, Aug 21, 2013 at 1:55 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Aug 21, 2013 at 11:00:53AM +0200, Daniel Vetter wrote:
On
On Wed, Aug 21, 2013 at 9:03 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 1:55 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Wed, Aug 21, 2013 at 6:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 11:16 AM, Chris Wilson ch...@chris-wilson.co.uk
On Tue, Aug 20, 2013 at 10:17 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register - i.e. the state on the old context is saved
when SAVE_EX_STATE_EN is currently set in the old context address before
the update, and
the modules and aio-direct
trees.
Hi,
I still have this issue with next-20130821 and Linux v3.11-rc6 plus
drm-intel-nightly on top
Any new development on this?
Patches?
Tbh I'm at a loss what we could try
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
Similarly for busy loops to wait for a bit to flip we use the _NOTRACE
variant to avoid filling up the tracebuffers with gunk. Spotted while
reading some
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do
Release 2.21.15 (2013-08-21)
Some build fixes for the BSDs and alternate compiler, and conflicting
configure options and a critcial fix for some PRIME setups.
* Don't fail to configure if DRI1 is not available and the user asks
for both DRI and KMS-only
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 17 -
1 file changed, 17 deletions(-)
diff --git
Hi Ben,
How will Gfx driver support runtime PM on Haswell? Will the Gfx driver trigger
Adapter Power State notification to BIOS when GPU switch state between D0 and
D3?
We need to support RTD3 for HD-A legacy audio on Haswell Ultrabook. And this
depends on Gfx driver to implement two BIOS
On Wed, Aug 21, 2013 at 04:43:33PM +0300, Ville Syrjälä wrote:
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register - i.e. the state on the old context is saved
when SAVE_EX_STATE_EN
ok, if we don't care about this hotplug bits state I liked the simplification.
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This was causing WARNs in one machine, so instead
I haven't reviewed the patches that add pc8 itself, but I can assume
it is correct since it was already rv-b Chris.
So:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Make it
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This should be working, so enable it by default. Also easy to revert.
v2: Rebase, s/allow/enable/.
Signed-off-by: Paulo
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 19, 2013 at 1:18 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We currently only enter PC8+ after all its required conditions are
met, there's no rendering, and we stay like that for at least
From: Rafael Barbalho rafael.barba...@intel.com
As the relocate entry function was getting a bit too big I've moved
the code that used to use either the cpu or the gtt to for the
relocation into two separate functions.
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we
On Mon, Aug 19, 2013 at 09:31:42PM +0200, Thierry Reding wrote:
On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote:
On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
[...]
+#define
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we
-direct tree.
The akpm-current tree gained conflicts against the modules and aio-direct
trees.
Hi,
I still have this issue with next-20130821 and Linux v3.11-rc6 plus
drm-intel-nightly on top
Any new
v2: Don't add to kernel tests.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/Makefile.am | 9 +-
tests/ddx_intel_after_fbdev | 73 +
2 files changed, 81 insertions(+), 1 deletion(-)
create mode 100755
to add my...
Tested-by: Sedat Dilek sedat.di...@gmail.com (against next-20130821)
- Sedat -
[1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/032182.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Wed, Aug 21, 2013 at 03:13:13PM -0300, Rodrigo Vivi wrote:
v2: Don't add to kernel tests.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
lgtm, applied.
-Daniel
---
tests/Makefile.am | 9 +-
tests/ddx_intel_after_fbdev | 73
this issue with next-20130821 and Linux v3.11-rc6 plus
drm-intel-nightly on top
Any new development on this?
Patches?
Tbh I'm at a loss what we could try abovebeyond what Chris has already
tried out.
Currently, I have two workarounds:
[1] Revert this commit:
commit
On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote:
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Regressing commit citation missing and also cc: stable I
On Wed, Aug 21, 2013 at 06:31:07PM +0300, Ville Syrjälä wrote:
On Wed, Aug 21, 2013 at 04:43:33PM +0300, Ville Syrjälä wrote:
On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
The extended state bits are stored in the LCA register and affect all
updates to the LCA register -
On Wed, Aug 21, 2013 at 10:59:47AM -0300, Paulo Zanoni wrote:
2013/8/21 Daniel Vetter daniel.vet...@ffwll.ch:
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
Similarly for busy loops to wait for a
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
While at it add the missing posting read in the lcpll enable function
that Paulo spotted.
v2: Drop the _NOTRACE changes, tracing such wait_for loops in the
On Wed, 21 Aug 2013 23:23:04 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote:
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk hangs or other bad behavior.
Signed-off-by: Jesse Barnes
2013/8/21 Daniel Vetter daniel.vet...@ffwll.ch:
If we don't use the return value of a mmio read our coding style is to
use the POSTING_READ macro. This avoids cluttering the mmio traces.
While at it add the missing posting read in the lcpll enable function
that Paulo spotted.
v2: Drop the
On Wed, Aug 21, 2013 at 02:39:34PM -0700, Jesse Barnes wrote:
On Wed, 21 Aug 2013 23:23:04 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 21, 2013 at 08:08:55AM -0700, Jesse Barnes wrote:
Turns out the BIOS will do this for us as needed, and if we try to do it
again we risk
This interface can enhanced over time to get more per plane information.
I've just flip counts for now. What I'd like to do with flip counts is
integrate them with existing flip tests. It serves a similar, but more
course purpose to some of the CRC work being done.
Unfortunately, I've been unable
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 53d0e70..d1079db 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++
This interface can enhanced over time to get more per plane information.
I've just flip counts for now. What I'd like to do with flip counts is
integrate them with existing flip tests. It serves a similar, but more
coarse purpose to some of the CRC work being done. It can be used to
determine if
On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote:
Sent the unfinished commit by accident
On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote:
This interface can enhanced over time to get more per plane information.
I've just flip counts for now. What I'd like to do with
On Thu, Aug 22, 2013 at 03:21:09AM +0100, Chris Wilson wrote:
On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote:
Sent the unfinished commit by accident
On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote:
This interface can enhanced over time to get more per plane
On Wed, Aug 21, 2013 at 07:27:11PM -0700, Ben Widawsky wrote:
On Thu, Aug 22, 2013 at 03:21:09AM +0100, Chris Wilson wrote:
On Wed, Aug 21, 2013 at 07:16:53PM -0700, Ben Widawsky wrote:
Sent the unfinished commit by accident
On Wed, Aug 21, 2013 at 08:15:53PM -0700, Ben Widawsky wrote:
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms before
This is the missing component for the last past that provides the
wait-boost. After boosting the RPS frequency of the GPU, it would not
decay, leaving the GPU at high clocks whenever it woke from idle. If we
apply the Valleyview logic of resetting our request to the optimal
frequency when we
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do
43 matches
Mail list logo
