Hi-
Something in the range ^8aa7500 40c7f2112ce18fa5eb ^b04d0a90908c
causes by Q67 Sandy Bridge box to lock hard about one second after I
start GNOME. It locks so hard that the reset button doesn't work and
netconsole doesn't say anything.
I'm about to have trouble finishing the bisection becaus
Hi Chris,
How about Boqun's BSD irq fix patch?
That patch is important for smooth H.264 decoding on G45 and GM45.
Thanks
Zou Nanhai
>>-Original Message-
>>From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.free
On Thu, 12 May 2011 22:17:12 +0100, Chris Wilson
wrote:
> From: Daniel Vetter
>
> Signed-off-by: Daniel Vetter
> Signed-off-by: Chris Wilson
This change seems correct. Would be nice if this code printed out the
actual fence register contents (perhaps in addition to what the fence
management
On Thu, 12 May 2011 22:17:14 +0100, Chris Wilson
wrote:
> The computation of the first-level watermarks for g4x and gen5+ are
> based on the same algorithm, so we can refactor those code paths to
> use a single function.
g4x_compute_wm0 takes a plane. ironlake_compute_wm0 takes a pipe. The
chang
On Thu, 12 May 2011 22:17:21 +0100, Chris Wilson
wrote:
> Superseded by the tracking the render generation in the chipset
> capabiltiies struct.
>
> Signed-off-by: Chris Wilson
Yes please.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpeuMOv8EOAa.pgp
Description: PGP signature
On Thu, 12 May 2011 22:17:20 +0100, Chris Wilson
wrote:
> From: Daniel Vetter
>
> A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
>
> Userspace was broken and assumed 8 rows. Chris Wilson noted that the
> kernel unfortunately can't reliable check that because libdrm rounds
>
On Thu, 12 May 2011 22:17:24 +0100, Chris Wilson
wrote:
> Make the audio property creation routine common and share the single
> property between the connectors.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpOZCsSEw5Jy.pgp
Description: PGP signat
On Thu, 12 May 2011 22:17:18 +0100, Chris Wilson
wrote:
> As we cannot wait upon an object to be released by the GPU once we have
> disabled pagefaults, process any pending retirements first in the hope
> that we move any potential relocations off the active list.
This seems to indicate a probl
On Thu, 12 May 2011 22:17:23 +0100, Chris Wilson
wrote:
> Signed-off-by: Chris Wilson
Can you justify this change with performance data?
--
keith.pack...@intel.com
pgpwnyNWMT1aq.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@
On Thu, 12 May 2011 22:17:22 +0100, Chris Wilson
wrote:
> ... as they only had a single PCI-ID each, and so using the pci-id is
> easier than using a capability bit.
This doesn't seem useful to me; it only saves a couple of bits in the
struct and replaces that with compares. Meh.
Nacked-by: Ke
On Thu, 12 May 2011 22:17:16 +0100, Chris Wilson
wrote:
> - I915_WRITE(GMBUS0 + reg_offset, 0);
> + intel_i2c_reset(dev_priv->dev);
This looks like an unrelated change. Please split this out.
--
keith.pack...@intel.com
pgp2uVPK5zOxO.pgp
Description: PGP signature
___
On Thu, 12 May 2011 22:17:19 +0100, Chris Wilson
wrote:
> - return -ENOSPC;
> + return -EDEADLK;
Would be nice to have the kernel print out a debugging message at this
point -- the only way to hit this is from a bug in user or kernel code.
--
keith.pack...@intel.com
On Thu, 12 May 2011 22:17:13 +0100, Chris Wilson
wrote:
> Instead of scanning through the static array using strcmp to find our
> matching tv_mode, just keep a direct link around. The historical reason
> for the strcmp was to match the connection property "tv format", but now
> that property is t
On Thu, 12 May 2011 22:17:17 +0100, Chris Wilson
wrote:
> Toggle the Software Clear Interrupt bit which resets the controller to
> clear any prior BUS_ERROR condition before we begin to use the
> controller in earnest.
Looks reasonable, except for the bad register offsets (see reply to
previous
On Thu, 12 May 2011 22:17:16 +0100, Chris Wilson
wrote:
> Keith complained that GMBUSx + reg_offset was ugly. An alternative
> naming scheme which is more consistent with the reset of the code base
> is to store the address of the GMBUS0 and then reference each of the
> GMBUSx registers as an of
On Thu, 12 May 2011 22:17:11 +0100, Chris Wilson
wrote:
> Convert our open coded offset_in_page() to the common macro.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpjf0bivf3pS.pgp
Description: PGP signature
___
On Thu, 12 May 2011 22:17:10 +0100, Chris Wilson
wrote:
> + pages = kmalloc(n*sizeof(struct page *),
> + GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
> + if (pages == NULL) {
> + pages = drm_malloc_ab(n, sizeof(struct page *));
> + if (pages ==
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files changed, 20 insertion
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/dr
Am Freitag, den 29.04.2011, 22:16 +0200 schrieb Paul Menzel:
> Am Montag, den 25.04.2011, 22:13 +0100 schrieb Chris Wilson:
> > On Mon, 25 Apr 2011 18:58:01 +0200, Paul Menzel
> > wrote:
> > > > >> On Wed, Mar 23, 2011 at 14:08:24 +, Chris Wilson wrote:
> > > > >>> commit 29c5a587284195278e23
Instead of scanning through the static array using strcmp to find our
matching tv_mode, just keep a direct link around. The historical reason
for the strcmp was to match the connection property "tv format", but now
that property is translated for us into an index by the drm core.
Signed-off-by: Ch
The read back of the available FIFO entries is vital for system
stability, but extremely costly. However, we only need a guide so as to
avoid eating into the reserved entries and since we are the only
consumer we can cache the read of the count from the last write.
Signed-off-by: Chris Wilson
Rev
Replace the three nearly identical copies of the code with a single
function. And take advantage of the opportunity to do some
micro-optimisation: avoid the vmalloc if at all possible and also avoid
dropping the lock unless we are forced to acquire the mm semaphore.
Measuring the impact of the opt
Keith complained that GMBUSx + reg_offset was ugly. An alternative
naming scheme which is more consistent with the reset of the code base
is to store the address of the GMBUS0 and then reference each of the
GMBUSx registers as an offset from GMBUS0.
Signed-off-by: Chris Wilson
---
drivers/gpu/dr
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index afdbbd9..b92e8ea 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i
... as they only had a single PCI-ID each, and so using the pci-id is
easier than using a capability bit.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |2 --
drivers/gpu/drm/i915/i915_drv.c |9 +++--
drivers/gpu/drm/i915/i915_drv.h |6 ++
3 file
Toggle the Software Clear Interrupt bit which resets the controller to
clear any prior BUS_ERROR condition before we begin to use the
controller in earnest.
Suggested-by: Ben Widawsky
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_i2c.c | 12
1 files changed, 8 insert
As we cannot wait upon an object to be released by the GPU once we have
disabled pagefaults, process any pending retirements first in the hope
that we move any potential relocations off the active list.
References: https://bugs.freedesktop.org/show_bug.cgi?id=35733
Signed-off-by: Chris Wilson
Rev
Make the audio property creation routine common and share the single
property between the connectors.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/intel_dp.c| 15 ++-
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/d
From: Daniel Vetter
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Userspace was broken and assumed 8 rows. Chris Wilson noted that the
kernel unfortunately can't reliable check that because libdrm rounds
up the size to the next bucket.
Signed-off-by: Daniel Vetter
Signed-o
Superseded by the tracking the render generation in the chipset
capabiltiies struct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
in
From: Daniel Vetter
This happens in two cases:
- userspace got its fence accounting wrong or
- the kernel got its fence accounting wrong.
In both cases there's absolutely no point in calling evict_everything,
that will not magically bring back the missing fence. So return a
different (hopefully
The computation of the first-level watermarks for g4x and gen5+ are
based on the same algorithm, so we can refactor those code paths to
use a single function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 88 --
1 files changed, 20 inser
Rather than proceed on and silently return false by default, mention why
we rejected the presence of an EDID as implying the presence of a VGA
monitor. (The question arises whether there is a broken EDID which falsely
reports a digital connection when attached by VGA.)
Signed-off-by: Chris Wilson
Convert our open coded offset_in_page() to the common macro.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89b7
From: Daniel Vetter
Signed-off-by: Daniel Vetter
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c0ce5e4..48f7e257 1006
Hi Keith,
These are the small patches above and beyond what you have already chosen
to include that I think will be useful for 2.6.40.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-
On Wed, 2011-05-11 at 23:22 +0200, Knut Petersen wrote:
> Yes, there is
> >15400.00.54 GetProperty
> >15500.00.54 QueryPointer
> but we also see
>
> 815.01.21 X protocol NoOperation
NoOp isn't a round trip, it does not generate a reply. That test
measures how
> Oh, damage. A compositing WM? If you turn off compositing, do you see
> similar performance levels to xorg-1.6?
> -Chris
>
That makes difference 16.300 reps speed up to 1.280.000 reps ... 78.5
times faster.
I think I will rerun the tests.
cu,
Knut
On Thu, 12 May 2011 10:24:00 +0200, Knut Petersen
wrote:
>
> > Please do something like 'perf record -f -g -a x11perf -d :0 -worect10;
> > perf report | head -150' and paste the output.
> > -Chris
> >
> Attached find the perf log
Oh, damage. A compositing WM? If you turn off compositing, do you
> Please do something like 'perf record -f -g -a x11perf -d :0 -worect10;
> perf report | head -150' and paste the output.
> -Chris
>
Attached find the perf log
Knut
# Events: 19K cycles
#
# Overhead CommandShared Object
On Thu, 12 May 2011 09:19:39 +0200, Knut Petersen
wrote:
>
> >> 12Operation
> >> -- -
> >> 965000.0 0.016 10x10 wide rectangle outline
> > Something is still not quite right here. This should be mostly CPU bound,
> > and even my Atom gets 734k.
> >
>> 12Operation
>> -- -
>> 965000.0 0.016 10x10 wide rectangle outline
> Something is still not quite right here. This should be mostly CPU bound,
> and even my Atom gets 734k.
>
> Can you check that (a) it is CPU bound and (b) the worst offenders
> ac
43 matches
Mail list logo
