After checking the Intel_gpu_tools test results, we found two new failure:
gem_mmap_gtt and gem_exec_bad_domains.
But with the latest commit on -testing branch(Updated 2 days ago), these two
cases could pass. Just the case gem_exec_bad_domains still dump ERROR
information in the dmesg. We updat
On Wed, Feb 8, 2012 at 20:14, Kai Krakow wrote:
> Eugeni Dodonov schrieb:
>
> > if you are among the ones affected by any kind of RC6 issues on Sandy
> > Bridge platform, please, try the following patch and report if it changes
> > the behavior somehow on your machine.
>
> Can it be pulled from
On Wed, 8 Feb 2012 23:53:10 +0100, Daniel Vetter wrote:
> On Fri, Feb 03, 2012 at 05:48:21PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > My laptop has two 1440x900 modes: one is the fixed_mode and the other
> > has different timings. If I use xrandr to switch from the fixed mode to
On Wed, Feb 08, 2012 at 02:53:32PM -0800, Jesse Barnes wrote:
> On Fri, 3 Feb 2012 17:47:15 -0200
> Paulo Zanoni wrote:
>
> > From: Paulo Zanoni
> >
> > I'm not sure why they are needed (I didn't notice any difference in my
> > tests), but these bits are in our documentation and they are also
On Fri, 3 Feb 2012 17:47:15 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I'm not sure why they are needed (I didn't notice any difference in my
> tests), but these bits are in our documentation and they are also set by
> the Windows driver.
>
> Signed-off-by: Paulo Zanoni
> ---
This m
On Fri, 3 Feb 2012 17:47:15 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I'm not sure why they are needed (I didn't notice any difference in my
> tests), but these bits are in our documentation and they are also set by
> the Windows driver.
>
> Signed-off-by: Paulo Zanoni
> ---
Do we
On Fri, Feb 03, 2012 at 05:48:21PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> My laptop has two 1440x900 modes: one is the fixed_mode and the other
> has different timings. If I use xrandr to switch from the fixed mode to
> the "other" 1440x900 mode, xrandr will tell me the change was
>
On Wed, Feb 08, 2012 at 08:09:28PM +, Chris Wilson wrote:
> So that we can tally the request against the command sequence in the
> ringbuffer, or merely jump to the interesting locations.
>
> Signed-off-by: Chris Wilson
I like the level of paranoia this is approaching ;-)
Reviewed-by: Daniel
On Wed, Feb 08, 2012 at 08:09:27PM +, Chris Wilson wrote:
> Being able to tally the list of outstanding requests with the sequence
> of commands in the ringbuffer is often useful evidence with respect to
> driver corruption.
>
> Signed-off-by: Chris Wilson
I like this and I think we can nice
Eugeni Dodonov schrieb:
> if you are among the ones affected by any kind of RC6 issues on Sandy
> Bridge platform, please, try the following patch and report if it changes
> the behavior somehow on your machine.
Can it be pulled from git somewhere? I do not use any tools for getting
patches fro
On Wed, Feb 01, 2012 at 01:39:03PM -0800, Ben Widawsky wrote:
> On Tue, Jan 31, 2012 at 04:47:56PM +0100, Daniel Vetter wrote:
> > Signed-Off-by: Daniel Vetter
> Reviewed-by: Ben Widawsky
Queued for -next, thanks for the review.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 36
On Wed, Feb 08, 2012 at 11:17:08PM +0100, Ben Widawsky wrote:
> On 01/31/2012 04:47 PM, Daniel Vetter wrote:
> > On gen5 we also need to correctly set up swizzling in the display
> > scanout engine, but only there. Consolidate this into the same
> > function.
> >
> > This has a small effect on ums
On Tue, Feb 07, 2012 at 11:56:36AM -0800, Eric Anholt wrote:
> On Mon, 6 Feb 2012 16:45:00 +0100, Daniel Vetter wrote:
> > On Sat, Feb 04, 2012 at 09:59:57PM +0100, Eric Anholt wrote:
> > > On Thu, 2 Feb 2012 09:58:12 +0100, Daniel Vetter
> > > wrote:
> > > It looks to me like you're making the
On 01/31/2012 04:47 PM, Daniel Vetter wrote:
> On gen5 we also need to correctly set up swizzling in the display
> scanout engine, but only there. Consolidate this into the same
> function.
>
> This has a small effect on ums setups - the kernel now also sets this
> bit in addition to userspace set
Hi Oliver
On Wed, Feb 8, 2012 at 9:12 PM, Oliver Seitz wrote:
> Am 08.02.2012 10:55, schrieb Graeme Russ:
>
>> Hi Oliver,
>>
>> On 02/08/2012 08:28 PM, Oliver Seitz wrote:
$ xrandr --output HDMI1 --mode 1680x1050
Will set the display mode properly, but the gnome menu bar (norm
<#part sign=pgpmime>
On Wed, 8 Feb 2012 13:46:46 -0800, Jesse Barnes
wrote:
> There's nothing there yet, but there will be (namely the interlaced
> paranoia from Daniel and hopefully an RC6 fix that brings joy to the
> world).
I've got the interlaced paranoia on top of my tree now; let's hope y
On Wed, 08 Feb 2012 11:38:02 -0800
"Keith Packard" wrote:
>
> I'm leaving tomorrow for three weeks of biking in New Zealand with my
> father. Jesse has kindly offered to manage drm-intel-fixes while I'm
> away to make sure that critical bug fixes get merged for testing even if
> I'm not on the n
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable
Hi,
if you are among the ones affected by any kind of RC6 issues on Sandy Bridge
platform, please, try the following patch and report if it changes the
behavior somehow on your machine.
This patch allows to enable different and separate RC6 stages independently
from each other. So chances are, wi
The BSpec Workarounds page states that bits 10 and 26 must be set to
avoid 3D ring hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610
Tested-by: Eugeni Dodonov
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i
From: Eugeni Dodonov
This adds the workaround for WaCatErrorRejectionIssue which could result
in a system hang.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610
Tested-by: Eugeni Dodonov
Reviewed-by: Kenneth Graunke
Signe
From: Eugeni Dodonov
This adds two cache-related workarounds for Ivy Bridge which can lead to
3D ring hangs and corruptions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610
Tested-by: Eugeni Dodonov
Signed-off-by: Eugeni
From: Eugeni Dodonov
This is yet another workaround related to clock gating which we need on
Ivy Bridge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610
Tested-by: Eugeni Dodonov
Signed-off-by: Eugeni Dodonov
Signed-off-
These fix many GPU hangs for Eugeni, though not on my machine for some
reason.
Oddly, the register writes to UCGCTL2 and SQ_CHICKEN_MBCUNIT_CONFIG stick,
but the writes to L3_CHICKEN_MODE, L3CNTLREG1, and COMMON_SLICE_CHICKEN1
don't seem to take effect. Currently no theories why.
Manually writin
On Wed, Feb 08, 2012 at 12:05:05PM -0800, Kenneth Graunke wrote:
> There may be some updates required, but assuming Ivybridge is similar to
> Sandybridge is a decent start; previously it fell through to the Gen2/3
> case and nothing worked.
>
> Signed-off-by: Kenneth Graunke
intel_reg_read/write
On 02/08/2012 09:05 PM, Kenneth Graunke wrote:
> There may be some updates required, but assuming Ivybridge is similar to
> Sandybridge is a decent start; previously it fell through to the Gen2/3
> case and nothing worked.
I didn't think anyone actually used this register map... so I never
bothere
So that we can tally the request against the command sequence in the
ringbuffer, or merely jump to the interesting locations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |5 +++--
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |1
Being able to tally the list of outstanding requests with the sequence
of commands in the ringbuffer is often useful evidence with respect to
driver corruption.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 24 +
drivers/gpu/drm/i915/i915_drv.h | 17 ++
There may be some updates required, but assuming Ivybridge is similar to
Sandybridge is a decent start; previously it fell through to the Gen2/3
case and nothing worked.
Signed-off-by: Kenneth Graunke
---
lib/intel_reg_map.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --
I'm leaving tomorrow for three weeks of biking in New Zealand with my
father. Jesse has kindly offered to manage drm-intel-fixes while I'm
away to make sure that critical bug fixes get merged for testing even if
I'm not on the net for a couple of days.
--
keith.pack...@intel.com
pgpXjYX0hvn8H.
On Wed, 8 Feb 2012 16:56:30 -0200, Eugeni Dodonov wrote:
> On Wed, Feb 8, 2012 at 16:06, Chris Wilson wrote:
> > + /* Record the position of the start of the request so that
> > +* should we detect the updated seqno part-way through the
> > +* GPU processing the request, we
<#part sign=pgpmime>
On Wed, 8 Feb 2012 19:02:47 +0100, Daniel Vetter wrote:
> The issue is that the first one introduces a pretty decent perf
> regression, iirc Chris mentions something much large than 10x slowdown
> on certain cairo traces on sna. So we can only merge the first one
> together w
On Wed, Feb 8, 2012 at 16:06, Chris Wilson wrote:
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1784,12 +1784,20 @@ i915_add_request(struct intel_ring_buffer *ring,
> {
>drm_i915_private_t *dev_priv = ring->dev->dev_private;
>uint32_t seqno
On Wed, Feb 08, 2012 at 06:06:30PM +, Chris Wilson wrote:
> By recording the location of every request in the ringbuffer, we know
> that in order to retire the request the GPU must have finished reading
> it and so the GPU head is now beyond the tail of the request. We can
> therefore provide a
On Wed, Feb 08, 2012 at 06:17:00PM +, Chris Wilson wrote:
> On Wed, 8 Feb 2012 19:02:47 +0100, Daniel Vetter wrote:
> > The issue is that the first one introduces a pretty decent perf
> > regression, iirc Chris mentions something much large than 10x slowdown
> > on certain cairo traces on sna.
On Wed, 8 Feb 2012 19:02:47 +0100, Daniel Vetter wrote:
> The issue is that the first one introduces a pretty decent perf
> regression, iirc Chris mentions something much large than 10x slowdown
> on certain cairo traces on sna. So we can only merge the first one
> together with the second one.
A
On Wed, 8 Feb 2012 16:50:13 +0100
Daniel Vetter wrote:
> On Wed, Feb 08, 2012 at 02:16:09AM +, Reese, Armin C wrote:
> > I worked with Jesse Barnes to develop a sprite demo/test program for
> > SNB/IVB. It uses the new IOCTLs: GETPLANERESOURCES, GETPLANE, and
> > SETPLANE. I also intend on
By recording the location of every request in the ringbuffer, we know
that in order to retire the request the GPU must have finished reading
it and so the GPU head is now beyond the tail of the request. We can
therefore provide a conservative estimate of where the GPU is reading
from in order to av
On Wed, Feb 8, 2012 at 18:36, Keith Packard wrote:
> <#part sign=pgpmime>
> On Wed, 8 Feb 2012 15:54:25 +0100, Daniel Vetter wrote:
>
>> I'm on the fence whether we should include this in -fixes. On one hand it
>> fixes a severe issue on snb, but introduces a perf regression without the
>> second
<#part sign=pgpmime>
On Wed, 8 Feb 2012 15:54:25 +0100, Daniel Vetter wrote:
> I'm on the fence whether we should include this in -fixes. On one hand it
> fixes a severe issue on snb, but introduces a perf regression without the
> second patch. Otoh we've never shipped snb without it broken like
<#part sign=pgpmime>
On Wed, 8 Feb 2012 16:42:52 +0100, Daniel Vetter
wrote:
> According to a bug report, it doesn't have one.
I've merged this to -fixes
--
keith.pack...@intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://l
On Wed, Feb 08, 2012 at 02:16:09AM +, Reese, Armin C wrote:
> I worked with Jesse Barnes to develop a sprite demo/test program for
> SNB/IVB. It uses the new IOCTLs: GETPLANERESOURCES, GETPLANE, and
> SETPLANE. I also intend on using the program as an example of how to
> set up a mode, displa
According to a bug report, it doesn't have one.
Cc: sta...@kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
Acked-by: Chris Wilson
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --
On Wed, Feb 08, 2012 at 01:34:13PM +, Chris Wilson wrote:
> This is a revert of 6aa56062eaba67adfb247cded244fd877329588d.
>
> This was originally introduced to workaround reads of the ringbuffer
> registers returning 0 on SandyBridge causing hangs due to ringbuffer
> overflow. The root cause h
On Wed, Feb 08, 2012 at 01:34:14PM +, Chris Wilson wrote:
> By recording the location of every request in the ringbuffer, we know
> that in order to retire the request the GPU must have finished reading
> it and so the GPU head is now beyond the tail of the request. We can
> therefore provide a
By recording the location of every request in the ringbuffer, we know
that in order to retire the request the GPU must have finished reading
it and so the GPU head is now beyond the tail of the request. We can
therefore provide a conservative estimate of where the GPU is reading
from in order to av
This is a revert of 6aa56062eaba67adfb247cded244fd877329588d.
This was originally introduced to workaround reads of the ringbuffer
registers returning 0 on SandyBridge causing hangs due to ringbuffer
overflow. The root cause here was reads through the GT powerwell require
the forcewake dance, some
On Tue, 17 Jan 2012 11:14:04 +, Chris Wilson
wrote:
> On Tue, 17 Jan 2012 11:59:27 +0100, Daniel Vetter wrote:
> > I guess this is just the usual "snb doesn't like being pushed to hard bug"
> > resulting in random crashes with confusing error_states. So I think I'll
> > drop this. Correct?
>
On 02/08/2012 11:28 AM, Chris Wilson wrote:
> On Wed, 8 Feb 2012 11:15:58 +0100, Daniel Vetter wrote:
>> Bit a bikeshed comment, but I prefer explicit control flow instead of
>> playing tricks with the short-circuiting behaviour of &&. Mind if you can
>> change that, too?
>
> Whilst we're on the
On Wed, 8 Feb 2012 11:15:58 +0100, Daniel Vetter wrote:
> Bit a bikeshed comment, but I prefer explicit control flow instead of
> playing tricks with the short-circuiting behaviour of &&. Mind if you can
> change that, too?
Whilst we're on the subject of bikesheds, having an explicit tracepoint
f
On Tue, Feb 07, 2012 at 04:21:50PM +0100, Ben Widawsky wrote:
> If we don't have a sufficient number of free entries in the FIFO, we
> proceed to do a write anyway. With this check we should have a clue if
> that write actually failed or not.
>
> After some discussion with Daniel Vetter regarding
On Tue, Feb 07, 2012 at 04:21:49PM +0100, Ben Widawsky wrote:
> This is similar to a patch I wrote several months ago. It's been updated
> for the new FORCEWAKE_MT, and it also no longer clears the debug
> register as it may be helpful to get that for the error state. Also
> recommended by Chris W
Am 08.02.2012 10:55, schrieb Graeme Russ:
Hi Oliver,
On 02/08/2012 08:28 PM, Oliver Seitz wrote:
$ xrandr --output HDMI1 --mode 1680x1050
Will set the display mode properly, but the gnome menu bar (normally on the
bottom) appears in the middle of the screen and logging of reverts back
This i
On Wed, 25 Jan 2012 14:04:00 +0100, Daniel Vetter
wrote:
> We still have reports of missed irqs even on Sandybridge with the
> HWSTAM workaround in place. Testing by the bug reporter gets rid of
> them with the forcewake voodoo and no HWSTAM writes.
>
> Because I've slightly botched the rebasing
Hi Oliver,
On 02/08/2012 08:28 PM, Oliver Seitz wrote:
>> $ xrandr --output HDMI1 --mode 1680x1050
>>
>> Will set the display mode properly, but the gnome menu bar (normally on the
>> bottom) appears in the middle of the screen and logging of reverts back
>
> This is a gnome thing, then. Try swit
$ xrandr --output HDMI1 --mode 1680x1050
Will set the display mode properly, but the gnome menu bar (normally on the
bottom) appears in the middle of the screen and logging of reverts back
This is a gnome thing, then. Try switching off VGA completly, gnome
might then adopt to the higher resolu
On 02/08/2012 08:16 PM, Graeme Russ wrote:
> Hi Guys,
>
>
> Any idea how to tell it to pick HDMI?
$ xrandr --output HDMI1 --mode 1680x1050
Will set the display mode properly, but the gnome menu bar (normally on the
bottom) appears in the middle of the screen and logging of reverts back
Regard
Hi Guys,
Well after all my troubles with the ASRock MB, I'm now running a Gigabyte
Z68P-DS3 which only has a HDMI output. So I managed to get hold of a HDMI
to DVI cable, but I can only get 1024x768 :(
$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 connected
On Wed, 1 Feb 2012 19:47:28 +0800, zhigang.g...@linux.intel.com wrote:
> From: Zhigang Gong
>
> The previous version calls glamor_egl_close_screen and
> glamor_egl_free_screen manually which is not align with
> standard process. Now glamor change the way to follow
> standard method:
>
> glamor
59 matches
Mail list logo
