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
inline comments are not correct... I'll try to review it again when my
acce
Hi all,
I'm using Alienware M17x R3 laptop with i7 2720QM CPU and AMD Radeon HD
9660M discrete card. The laptop is A+I mux'd architecture (i.e. manually
switching between integrated/discrete graphics card).
Unfortunately, AMD's close-source Linux driver doesn't support this arch
any more, and the
On 01/30/12 11:14, Eric Anholt wrote:
On Mon, 30 Jan 2012 09:41:50 -0800, Chad Versace
wrote:
If the pci_device's actual gen was> 4, then we stupidly set
bufmgr_gem->gen = 6.
Might be worth a note to say that no behavior should change. Still,
Reviewed-by: Eric Anholt
Right, I'm curious
Hi!
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):
1. reboot
2. play SecondLife again and again
3. log out or resume fr
On Wed, Dec 14, 2011 at 01:57:32PM +0100, Daniel Vetter wrote:
> Like for shmem_pwrite_slow. The only difference is that because we
> read data, we can leave the fetched cachelines in the cpu: In the case
> that the object isn't in the cpu read domain anymore, the clflush for
> the next cpu read do
On Wed, Jan 25, 2012 at 02:04:00PM +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 reba
Am 2012-01-12 23:45, schrieb Jesse Barnes:
>> Tested with the (attached, hopefully correct) patch and it still works. :-)
>
> Yay, thanks a lot! I'll send it upstream now.
The gentoo-devs still haven't fixed that yet ... in their
gentoo-sources-3.2.1-r2, my reported bug is still unreplied
On 01/30/2012 11:14 AM, Eric Anholt wrote:
> On Mon, 30 Jan 2012 09:41:50 -0800, Chad Versace
> wrote:
>> If the pci_device's actual gen was > 4, then we stupidly set
>> bufmgr_gem->gen = 6.
>
> Might be worth a note to say that no behavior should change. Still,
>
> Reviewed-by: Eric Anholt
On Sun, Jan 29, 2012 at 05:37:45PM +, Chris Wilson wrote:
> On Wed, 14 Dec 2011 13:57:16 +0100, Daniel Vetter
> wrote:
> > This will also come handy for the gen6+ swizzling support, where the
> > driver is supposed to control swizzling depending upon dram
> > configuration.
> >
> > v2: CxDRB
On Sun, Jan 29, 2012 at 05:36:04PM +, Chris Wilson wrote:
> On Wed, 14 Dec 2011 13:57:15 +0100, Daniel Vetter
> wrote:
> > It looks like the desktop variants of i915 and i945 also have the DCC
> > register to control dram channel interleave and cpu side bit6
> > swizzling.
> >
> > Unfortunat
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 with a bunch of patches to no longer force
> > > batchbuffer (in most cas
On Mon, 30 Jan 2012 09:41:50 -0800, Chad Versace
wrote:
> If the pci_device's actual gen was > 4, then we stupidly set
> bufmgr_gem->gen = 6.
Might be worth a note to say that no behavior should change. Still,
Reviewed-by: Eric Anholt
pgp09cHYO2QgC.pgp
Description: PGP signature
___
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 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 whi
On Mon, 30 Jan 2012 16:55:49 +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 my i
Hello all,
Once more i came to you guys, requesting help for a problem on the i915 drivers.
For testing the new interlace mode on kernel 3.3.0-RC1+, i compiled the kernel
source. But when running it the colors on the TV look strange.
Maybe some one can see some strange stuff on my intel registe
On Mon, Jan 30, 2012 at 15:41, Chad Versace wrote:
> If the pci_device's actual gen was > 4, then we stupidly set
> bufmgr_gem->gen = 6.
>
> Signed-off-by: Chad Versace
>
Reviewed-by: Eugeni Dodonov
I was thinking on maybe making this more future-proof to help the possible
>=7 gen devices, but
If the pci_device's actual gen was > 4, then we stupidly set
bufmgr_gem->gen = 6.
Signed-off-by: Chad Versace
---
intel/intel_bufmgr_gem.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2b4fab1..26e3a5c 10
On Mon, Jan 30, 2012 at 07:59:45AM -0800, Eric Anholt wrote:
> On Sun, 29 Jan 2012 16:52:05 +, Chris Wilson
> wrote:
> > The original intention of comparing the bo against the mappable GTT
> > limits was to prevent a subsequent faulting of the bo into the GTT from
> > clearing the entire GTT
On Sun, 29 Jan 2012 16:52:05 +, Chris Wilson
wrote:
> The original intention of comparing the bo against the mappable GTT
> limits was to prevent a subsequent faulting of the bo into the GTT from
> clearing the entire GTT in vain. However, that was clearly a cut'n'paste
> mistake as a CPU map
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 my intel-gtt rewrite we don't actually put a
dummy pte in that last page
The locking in our setup and teardown paths is rather arbitrary, but
generally we try to protect gem stuff with dev->struct_mutex. Further,
the ums/gem ioctl to setup gem _does_ take the look. So fix up this
benign inconsistency.
Noticed while reading through code.
Signed-Off-by: Daniel Vetter
-
21 matches
Mail list logo
