On Tue, 2012-01-31 at 17:32 +0100, Christoph Evers wrote:
> Hi folks,
>
> i am not sure whether this issue belongs to the libva mailinglist or
> this one. I'll give it a try :-)
You can send all VAAPI related mail to li...@lists.freedesktop.org
> For testing purpose I switched to vaapi-ext bra
Hi,
I know what is the problem. For some reason, the native pixel format
for MPEG-2 decoding on Clarkdale is I420, however the input pixel format
of deinterlacing is NV12 in the driver, so the driver doesn't support
deinterlacing for MPEG-2 on Clardale. We will try to fix this issue but
don't
On Tue, 31 Jan 2012 21:08:14 +0100, Daniel Vetter
wrote:
> These are all user-trigerable, so tune down their loudness a notch.
> For some of these we have i-g-t tests (because they prevent
> newly-discovered bugs), without this patches running the test suite
> leaves behind a dirty dmesg.
>
> Si
These are all user-trigerable, so tune down their loudness a notch.
For some of these we have i-g-t tests (because they prevent
newly-discovered bugs), without this patches running the test suite
leaves behind a dirty dmesg.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_execbuff
On Wed, Dec 14, 2011 at 04:46:48PM -0200, Eugeni Dodonov wrote:
> On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote:
>
> > From: Chris Wilson
> >
> > As the buffer is not necessarily accessible through the GTT at the time
> > of a GPU hang, and capturing some of its contents is far more valuabl
On Mon, Jan 30, 2012 at 04:55:49PM +0100, Daniel Vetter wrote:
> Chris Wilson reported that with a bunch of patches to no longer force
> batchbuffer (in most cases at least) into the mappable part of gtt
> that his Pineview died while prefetching the last page of the gtt.
>
> Turns out that since
Hi folks,
i am not sure whether this issue belongs to the libva mailinglist or
this one. I'll give it a try :-)
For testing purpose I switched to vaapi-ext branch of intel-driver and
libva (master is working fine).
I am using xine-lib-vaapi for playback with xine which uses a vaapi
acceler
From: Daniel Vetter
The problem this patch solves is that the forcewake accounting
necessary for register reads is protected by dev->struct_mutex. But the
hangcheck and error_capture code need to access registers without
grabbing this mutex because we hold it while waiting for the gpu.
So a new l
From: Daniel Vetter
This was forgotten in the original multi-threaded forcewake
conversion:
commit 8d715f0024f64ad1b1be85d8c081cf577944c847
Author: Keith Packard
Date: Fri Nov 18 20:39:01 2011 -0800
drm/i915: add multi-threaded forcewake support
Upstream patch:
commit 8109021313c7a3d894
We don't need to check 3rd pipe specifically, as it shares PLL with some
other one.
(v2 - for stable kernel: clarify bug description to explain that this
fixes suspend when 3rd pipe is active - fd.o bug #41977).
Upstream commit:
commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee
Author: Eugeni Dodon
From: Rodrigo Vivi
TV Out refresh rate was half of the specification for almost all modes.
Due to this reason pixel clock was so low for some modes causing flickering
screen.
Upstream patch:
commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d
Author: Rodrigo Vivi
Date: Wed Dec 14 21:10:06 2011 -
From: Daniel Vetter
Otherwise hangcheck spuriously fires when running blitter/bsd-only
workloads.
Contrary to a similar patch by Ben Widawsky this does not check
INSTDONE of the other rings. Chris Wilson implied that in a failure to
detect a hang, most likely because INSTDONE was fluctuating. Th
From: Wu Fengguang
On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
so that the audio driver will receive hot plug events and take action
to refresh its device state and ELD contents.
Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
only when the link traini
From: Wu Fengguang
On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
the audio driver will receive hot plug events and take action to refresh
its device state and ELD contents.
The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
HDMI audio after DPMS o
Hi Greg,
those are some patches related to i915 module for inclusion in the 3.2
series.
The force_wake-related ones are particularly interesting as the 'drm/i915:
paper over missed irq issues with force wake voodoo' patch was queued for this
kernel. They prevent WARNs and possible hangs on Sandy
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 681cbe4..4ebca6d 100644
--- a/drivers/gpu/drm/i915/i915_debug
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 setting it. Given that this code only
runs when userspace ei
We have to do this manually. Somebody had a Great Idea.
I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but
Atechsystem freenet.de> writes:
>
>
> Hello,
>
> I’ve written an email to Haihao Xiang regarding the “no deinterlacing” bug on
Clarkdale a week ago and he answered today. He will check this issue. I’ll hope
he can fix it. Will the extended vaapi-ext deinterlacers (temporal or spatial I
guess
On Tue, Jan 31, 2012 at 02:24:36PM +0100, Daniel Vetter wrote:
> Ok, I've botched up the testing on my snb, shame on me.
>
> Without this patch my snb also dies with gem_cs_prefetch, but like Chris'
> pnv, survives without a hitch. So it looks like I've lucked out.
This is getting funny: I've mea
On Mon, Jan 30, 2012 at 08:22:29PM +0100, Daniel Vetter wrote:
> On Mon, Jan 30, 2012 at 08:14:21PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 30, 2012 at 11:09:01AM -0800, Eric Anholt wrote:
> > > On Mon, 30 Jan 2012 16:55:49 +0100, Daniel Vetter
> > > wrote:
> > > > Chris Wilson reported that
> -Original Message-
> From: intel-gfx-bounces+gordon.jin=intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+gordon.jin=intel@lists.freedesktop.org] On
> Behalf Of Alan W. Irwin
> Sent: Sunday, January 22, 2012 3:45 AM
> To: Daniel Vetter
> Cc: Intel Graphics Development
> Subj
On Tue, Jan 31, 2012 at 09:46:14AM +0100, Daniel Vetter wrote:
> On Mon, Jan 30, 2012 at 03:07:40PM -0800, AW wrote:
> > Is it possible that this
> > https://bugzilla.kernel.org/show_bug.cgi?id=42691
> >
> > is caused by the intel graphix driver?
> >
> > This does not crash:
> > 1. reboot
> > 2.
On Mon, Jan 30, 2012 at 03:07:40PM -0800, AW wrote:
> Is it possible that this
> https://bugzilla.kernel.org/show_bug.cgi?id=42691
>
> is caused by the intel graphix driver?
>
> This does not crash:
> 1. reboot
> 2. log in+out again and again
>
> But this does crash quite often (after step 3):
>
On Mon, Jan 30, 2012 at 11:44:35PM -0800, Ben Widawsky wrote:
> On Wed, Dec 14, 2011 at 01:57:17PM +0100, Daniel Vetter wrote:
> > We have to do this manually. Somebody had a Great Idea.
> >
> > Signed-Off-by: Daniel Vetter
>
> Okay, my configdb access isn't working, so please forgive me if my
>
25 matches
Mail list logo
