On Mon, Apr 02, 2012 at 02:44:14PM -0700, Andrew Lutomirski wrote:
> On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter wrote:
> > On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
> >> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter
> >> wrote:
> >> > Inspired by the recent ppgtt reg
On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter wrote:
> On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
>> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter
>> wrote:
>> > Inspired by the recent ppgtt regression report, where switching of
>> > dmar only for the gpu seems to fix th
Reported-by: Konstantin Belousov
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8a62285..785f67f 100644
--- a/drivers/gpu/drm/i915
On Mon, 2 Apr 2012 23:32:00 +0300, Konstantin Belousov
wrote:
> Hi,
> it seems that in case of any i915_gem_init_aliasing_ppgtt() failure,
> after the commit d3ae08109d628d26615d7f7f4d8d53cdd8d71fd0, the struct_mutex
> lock leaks from i915_load_gem_init().
Right, I should have caught that before
Hi,
it seems that in case of any i915_gem_init_aliasing_ppgtt() failure,
after the commit d3ae08109d628d26615d7f7f4d8d53cdd8d71fd0, the struct_mutex
lock leaks from i915_load_gem_init().
pgpfjErQveOiu.pgp
Description: PGP signature
___
Intel-gfx mailing
On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote:
> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter wrote:
> > Inspired by the recent ppgtt regression report, where switching of
> > dmar only for the gpu seems to fix things completely, I've looked
> > again at the semaphores+vt-d s
On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter wrote:
> Inspired by the recent ppgtt regression report, where switching of
> dmar only for the gpu seems to fix things completely, I've looked
> again at the semaphores+vt-d situation.
>
> Contrary to my earlier testing a few months back my system is
Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.
Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when di
It exists way back to gen2, bug got moved around on gen4 a bit.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_irq.c |3 ++-
drivers/gpu/drm/i915/i915_reg.h |1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --g
On Fri, 18 Nov 2011 18:24:17 -0800
Ben Widawsky wrote:
> This code is currently living on my personal git repo:
> git://people.freedesktop.org/~bwidawsk/drm-intel forced_throttling
>
> Since these are RFC, I haven't spent too much time cleaning things up.
> Feel free to comment on typos, comment
On Mon, Apr 2, 2012 at 08:08, Daniel Vetter wrote:
> ... and add support to decode MI instructions with functions.
>
> Signed-Off-by: Daniel Vetter
>
---
> intel/intel_decode.c | 77
> -
> 1 files changed, 75 insertions(+), 2 deletions(-)
>
> di
On Mon, Apr 2, 2012 at 08:30, Oliver Seitz wrote:
>
> Video tearing in windows is a known issue on SandyBridge
>>
>
> And also on IvyBridge, I presume. Then I'll try to be patient until
> there's a new implementation of vsynced update logic in the driver :-)
>
There are some improvements on the
Video tearing in windows is a known issue on SandyBridge
And also on IvyBridge, I presume. Then I'll try to be patient until
there's a new implementation of vsynced update logic in the driver :-)
Thanks for the explanations and all the good work!
Kiste
_
... and add support to decode MI instructions with functions.
Signed-Off-by: Daniel Vetter
---
intel/intel_decode.c | 77 -
1 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index df9b704.
On Mon, Apr 2, 2012 at 12:40, Oliver Seitz wrote:
>
>> The only workaround is [...] to only use fullscreen DRI video
>> applications
>>
>> (OpenGL or libva decoders) that use SwapBuffers.
>
>
> Yes, works perfectly while only one screen is connected. That means, this
> definition of "fullscreen"
The only workaround is [...] to only use fullscreen DRI video applications
(OpenGL or libva decoders) that use SwapBuffers.
Yes, works perfectly while only one screen is connected. That means,
this definition of "fullscreen" is "the whole framebuffer", and not "the
content of one display"?
On Sat, 31 Mar 2012 19:52:09 +0200, Oliver Seitz wrote:
[snip]
> If, however, two screens are next to or on top of each other, playing
> video on one of the screens can show some tearing. It is not always seen
> with normal video, a special test pattern is helpful. Also, it does only
> tear in
On Mon, 2 Apr 2012 10:08:35 +0200, Daniel Vetter
wrote:
> Totally unexpected that this regressed. Luckily it sounds like we just
> need to have dmar disable on the igfx, not the entire system. At least
> that's what a few days of testing between Tony Vroon and me indicates.
>
> Reported-by: Ton
Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.
Reported-by: Tony Vroon
Cc: Tony Vroon
Bugzilla: https://bugzilla.kernel.org/show_b
After a few unattended hours Xorg was still running,
but only a terminal window had survived the night :-(
Xorg: git, a few days old, kernel: 3.3.
Xorg.0.log: Nothing unusual
dmesg:
[156859.078080] [drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate
offset for bo 0
[156869.197310] [dr
On Mon, 02 Apr 2012 10:36:44 +0200, Knut Petersen
wrote:
> After a few unattended hours Xorg was still running,
> but only a terminal window had survived the night :-(
>
> Xorg: git, a few days old, kernel: 3.3.
>
> Xorg.0.log: Nothing unusual
>
> dmesg:
>
> [156859.078080] [drm:drm_gem_creat
On Mon, 2 Apr 2012 10:12:31 +0200, Lukas Hejtmanek wrote:
> On Mon, Apr 02, 2012 at 08:32:50AM +0100, Chris Wilson wrote:
> > Even after you stop the video? All it sounds like so far is that it is no
> > longer rendering video frames. Also check your Xorg.log and video player
> > for diagnostics.
On Mon, Apr 02, 2012 at 08:32:50AM +0100, Chris Wilson wrote:
> Even after you stop the video? All it sounds like so far is that it is no
> longer rendering video frames. Also check your Xorg.log and video player
> for diagnostics.
Xorg.log contains (however this may be consequence of SAK (sysrq-k
On Mon, 2 Apr 2012 01:00:46 +0200, Lukas Hejtmanek wrote:
> Hello,
>
> should the hangcheck mechanism work on Sandy Bridge when XVideo causes GPU to
> hang? I can repeatedly hang GPU playing video for at least 1 hour
> continuously. Mouse cursor moves but nothing else.
>
> However, I got no mes
24 matches
Mail list logo
