On Mon, 2010-10-25 at 12:44 -0700, Eric Anholt wrote:
> So, what if the problem is that our URB allocations aren't big enough?
> I would expect that to look kind of like what I'm seeing. One
> experiment would be to go double the preferred size of each stage in
> brw_urb.c one by one -- is one st
On Tue, Oct 26, 2010 at 3:42 AM, Peter Clifton wrote:
> On Tue, 2010-10-26 at 02:57 +0200, Seblu wrote:
>> I make an another video, which show suspend to ram issue with this
>> lastest kernel and how it's perfectly functionnal with 2.6.35.7.
>>
>> http://videobin.org/+2a5/2kp.ogg
>>
>> can i do so
>>-Original Message-
>>From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On
>>Behalf Of Clemens Eisserer
>>Sent: 2010年10月25日 18:31
>>To: intel-gfx
>>Subject: Re: [Intel-gfx] [PATCH] drm/i915: set scan-b
On Tue, 2010-10-26 at 02:57 +0200, Seblu wrote:
> I make an another video, which show suspend to ram issue with this
> lastest kernel and how it's perfectly functionnal with 2.6.35.7.
>
> http://videobin.org/+2a5/2kp.ogg
>
> can i do something more to help your troubleshoot this issue?
If you h
On Tue, Oct 26, 2010 at 1:47 AM, Peter Clifton wrote:
> For future reference.. its probably not a good idea to let that
> condition persist. There is a chance it might damage the LCD if it is
> powered but not being driven properly.
ok
> Do you have this commit from drm-next recently?:
>
> commit
On Tue, 26 Oct 2010 01:14:04 +0100
Peter Clifton wrote:
> On Mon, 2010-10-25 at 13:20 -0700, Jesse Barnes wrote:
> > On Mon, 25 Oct 2010 13:11:24 -0700
> > Jesse Barnes wrote:
> >
> > > There are some bits in the GMCH to control memory behavior during CPU
> > > C-states. Can you dump the 16 bi
On Mon, 2010-10-25 at 13:20 -0700, Jesse Barnes wrote:
> On Mon, 25 Oct 2010 13:11:24 -0700
> Jesse Barnes wrote:
>
> > There are some bits in the GMCH to control memory behavior during CPU
> > C-states. Can you dump the 16 bits at MCHBAR address 0xf08? You
> > should be able to do that by doin
On Tue, 2010-10-26 at 01:19 +0200, Seblu wrote:
> i've tryed last git kernel with edp-fixes from
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git,
> i've the following result :
> http://videobin.org/+2a3/2kn.ogg
For future reference.. its probably not a good idea to let that
On Tue, Oct 12, 2010 at 1:56 PM, Chris Wilson wrote:
> On Tue, 12 Oct 2010 12:44:18 +0200, Seblu wrote:
>> Hi Chris,
>>
>> Did you receive my previous mail about 2.6.36-rc2 issue, do you thinks
>> this can be fix before 2.6.36 release ?
>> Do you need more investigation / test from me ?
>
> That
Am Montag, den 25.10.2010, 13:23 -0400 schrieb Chun-Yu Shei:
> On 10/24/2010 2:36 PM, Paul Menzel wrote:
> > Am Sonntag, den 24.10.2010, 13:03 -0400 schrieb Chun-Yu Shei:
> >
> >> I'm currently running xf86-video-intel 2.13.0 with an i5-540M, and I've
> >> been experiencing a strange issue where a
On Mon, 25 Oct 2010 13:11:24 -0700
Jesse Barnes wrote:
> On Sat, 23 Oct 2010 13:02:35 +0100
> Peter Clifton wrote:
> > I think Keith was thinking that there are some parts of the chipset
> > which are shared between the GPU and CPU (memory controllers?), and the
> > CPU entering a lower frequenc
On Sat, 23 Oct 2010 13:02:35 +0100, Peter Clifton wrote:
> Hi guys,
>
> This is something I've noted before, and I think Keith P replied with
> some idea of what might be causing it, but I can't recall exactly. I
> just thought I'd mention it again in case it struck a chord with anyone.
>
> I'm
On Sat, 23 Oct 2010 13:02:35 +0100
Peter Clifton wrote:
> I think Keith was thinking that there are some parts of the chipset
> which are shared between the GPU and CPU (memory controllers?), and the
> CPU entering a lower frequency state could have a detrimental effect on
> the graphics throughpu
On 10/24/2010 2:36 PM, Paul Menzel wrote:
Am Sonntag, den 24.10.2010, 13:03 -0400 schrieb Chun-Yu Shei:
I'm currently running xf86-video-intel 2.13.0 with an i5-540M, and I've
been experiencing a strange issue where after a day or two, I can no
longer play videos smoothly in Flash 10.2 beta, as
On 2010.10.25 09:22:41 +0100, Chris Wilson wrote:
> You can't do this here, changing the AGP type of a potentially bound
> object without any locking.
>
> Move this into intel_pin_and_fence_fb_obj(), give it a decent name and
> make it robust.
oh, right, thanks for point this out.
>
> int i915_
Hi,
> We only need front buffer to be uncached.
> I think that will not affect performance since GPU will seldom read
> back from front buffer.
> We will measure performance on that.
At least here I have a couple of apps reading back from frontbuffer,
and performance on i945
Hi Chris,
We only need front buffer to be uncached.
I think that will not affect performance since GPU will seldom read
back from front buffer.
We will measure performance on that.
Thanks
Zou Nan hai
>>-Original Message-
>>From: intel-gfx-bounces+nanhai.zou=intel
Its not there in Q3 as was said before. Is there any work in progress??
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[I haven't seen my first email arrive yet...]
On Mon, 25 Oct 2010 09:42:31 +0800, Zhenyu Wang wrote:
> Display engine on Sandybridge is not coherent with LLC, so
> try to always bind display buffer as uncached on Sandybridge.
> This fixed screen artifacts seen by using blit engine on Sandybridge.
On Mon, Oct 25, 2010 at 02:15:45 -0400, marcus cox wrote:
> would this process work with your drivers as well?
>
> if not, what is the exact process, or where on your site can i find it.
>
No. You just get the drivers from your distribution, so stuff works out
of the box without having to go do
20 matches
Mail list logo
