about the tv-out not working we will be able to
> test/revert and find another fix for it. Meanwhile:
>
> Reviewed-by: Rodrigo Vivi
Tested-by: Peter Clifton
I've been carrying that patch around in my own builds for my GM45 for
what feels like forever now (since before it was re
able to take is actually
hooking up the S-Video output of this laptop and making sure the patch
did not stop it detecting a connected TV. I don't actually own a TV, but
could get access to one.. if I had an S-Video cable I could do the test!
--
Peter Clifton
Electrical Engineering Division,
En
Without this, querying the backlight value returns half of the value it
has been set to. Hilarity ensues, as my user-space likes to query first
before incrementing / decrementing brightness, leading to brightness
collapsing to near as I try to adjust.
--
Peter Clifton
Electrical Engineering
On Sat, 2010-12-18 at 21:42 +, Chris Wilson wrote:
> On Sat, 18 Dec 2010 20:02:21 +0000, Peter Clifton wrote:
> > Hi Chris,
> >
> > I bisected the suspend regression I mentioned, and came to this commit:
> >
> > commit 0cdab21f9a1fca50dd27e488839f5a65
it.
Best regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
___
On Mon, 2010-11-22 at 17:41 +, Chris Wilson wrote:
> On Mon, 22 Nov 2010 17:32:18 +0000, Peter Clifton wrote:
> > I've just rebuilt (a backport) of drm-intel-next to try the fix for
> > tiling registers on resume. Since you added a Reported-By for me, I
> > guess
On Mon, 2010-11-22 at 17:19 +, Chris Wilson wrote:
> On Mon, 22 Nov 2010 17:13:21 +0000, Peter Clifton wrote:
> > Was this intentional?
> >
> > + a17577c...5f75377 drm-intel-next -> drm-intel/drm-intel-next (forced
> > update)
>
> Yes. 2 patches were
Was this intentional?
+ a17577c...5f75377 drm-intel-next -> drm-intel/drm-intel-next (forced update)
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the
value, and the fence had no effect.
>
> It was a good catch. Applied one final tweak to use macros to generate
> the various read/write routines and applied to -next.
> -Chris
Chris, does this sound like it might be behind the bug I mentioned on
IRC?
--
Peter Clifton
Elect
After some discussion with Eric on IRC, this is what I came up with
(which appears to work!)
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
>From 18072c138b7cca626f8b45dfae2c6cb29a91a
he PCB layout I've been testing it with privately.
Steps to reproduce are:
1. Load the board.
2. Drag the white / black (depends on your theme) circular control on
the left hand bar. This is a track-ball.
3. Drag like crazy, perhaps stop for a little bit. Drag again.
Eventually it hangs when
On Tue, 2010-11-09 at 18:22 +, Peter Clifton wrote:
> commit 53984635a659e360f206a81ada4ae813152d72f1
> Author: Daniel Vetter
> Date: Wed Sep 22 23:44:24 2010 +0200
>
> drm/i915: use the complete gtt
>
> At least the part that's cur
I increase hangcheck
timer to over a second).
Best regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone,
On Tue, 2010-11-09 at 10:52 +, Peter Clifton wrote:
> On Sun, 2010-11-07 at 10:25 +, Chris Wilson wrote:
> I've not tried that yet, but the PRM does state that BLT pitch is in
> DWORDs.
Gah.. the PRM is badly written in places! In one place it states DWORDs,
then in anoth
On Sun, 2010-11-07 at 10:25 +, Chris Wilson wrote:
> On Sat, 06 Nov 2010 10:04:31 +0000, Peter Clifton wrote:
> > Fixes corruption with glBufferSubData on my machine,
> >
> > Can someone review and push?
>
> Oddly, the pitch for BLT is in bytes and it should be su
Fixes corruption with glBufferSubData on my machine,
Can someone review and push?
(Resent with code comment fixed)
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal
Fixes corruption with glBufferSubData on my machine,
Can someone review and push?
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223
my PCB program is
benchmarking. With it, the X11 server graphics almost completely freeze
up.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1
On Fri, 2010-11-05 at 11:44 +, Peter Clifton wrote:
> I take bets its "something I've done wrong", as usually seems to be the
> way, but for now - if I just use glBufferSubData to upload changed data
> only, I get rendering corruption. It works fine with
> LIBGL_A
On Fri, 2010-11-05 at 10:35 +, Chris Wilson wrote:
> On Fri, 05 Nov 2010 10:21:07 +0000, Peter Clifton wrote:
> > I was playing with my VBO code, and noticed this sysprof trace
> > (non-interesting stuff pruned):
> >
> > drm_ioctl
me curious. Presumably I have too many
pages of data actively being used by the GPU (or mapped).
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44
On Tue, 2010-11-02 at 21:31 +, Peter Clifton wrote:
> Running with debug options set to always flush after each primitive
> fixes the issue, as does a judicial insertion of glFlush into my
> rendering code after changing the stencil test state, but before drawing
> more geome
f stall missing / cache coherency problem?
Anyway.. you guys know more how this works than I do, so any pointers
would be greatly appreciated. I'll let you know if I narrow it down any
further.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
isation at the map stage. Fixed now, so my non
display-list code is much faster again.
I guess it kind of begs the question why the compiled display list needs
4 or 5 batches to do what my own code manages in 1.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
Univer
ite figure out what synchronisation issue I
was running into with my app though. With a single wait_for_rendering /
synchronisation per frame, I can't quite contrive how the GPU would get
stalled at all during a sequence of consecutive frames.
--
Peter Clifton
Electrical Engineering Di
On Sun, 2010-10-31 at 20:54 -0700, Eric Anholt wrote:
> On Sun, 31 Oct 2010 01:15:34 +0000, Peter Clifton wrote:
> > For instance, in intelClear() we call it - AIUI, flushing rendering
> > before code execution continues. Nasty ;(
>
> I don't see flushing in intel_prep
our test at low screen-res with
this app running (once per core):
int main( int argc, char **argv )
{
while (1);
}
(gcc loop.c -o loop)
Do you get the high frames per second (non-full-screen) then?
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge
On Sun, 2010-10-31 at 08:10 +, Chris Wilson wrote:
> On Sun, 31 Oct 2010 02:24:06 +0000, Peter Clifton wrote:
> > Hi guys,
> >
> > I thought I'd attach this, as it is now gone 2AM and I doubt I'm going
> > to finish it "tonight". I was hopi
d
synchronising with frames. I applied a VERY dirty kludge for testing.
Does anyone know if you can pass userdata parameters to a hrtimer? From
the API, it looked not - although in that case, how do you avoid needing
horrid global state variables?
Regards,
--
Peter Clifton
Electrical Engine
I got one the first time I tried it). Never mind.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +
state ought to be relevant to the hang assuming you've not
rebooted or had any subsequent hangs.
Best wishes,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signa
e multiple batches which come under the same request... or a separate
IOCTL to turn on / off logging).
Also.. I'm not sure how the locking would work if userspace is reading
out the debugfs file whilst another frame is being executed. (We'd
probably need a secondary logging buffer allocatin
ough?
Right 4AM, my sanity is gone.. sorry for all the noise ;)
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748
On Sat, 2010-10-30 at 03:34 +0100, Peter Clifton wrote:
> sudo intel_reg_write 0x21D0 0x1000207
> Value before: 0x307
> Value after: 0x207
>
>
> This boosted FPS of my displaylist frame benchmark from 35fps to 37fps.
>
> This was clearing bit 8 of ECOSKPD, which is c
state according to the G45 PRM.
I have bit 12=0, bit9=1
This does match the expected default setting though.. is there a typo in
the PRM (Vol1a, P.322.) mixing bits 9 and 12 around in the table?
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9
On Sat, 2010-10-30 at 01:54 +0100, Peter Clifton wrote:
DOH!
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone
nel to sync up the
graphs with actual rendering commands / batchbuffers. Perhaps there is
somewhere in MMIO space I can write to to pass some information to the
polling userspace program which looks at the instdone regs, but perhaps
there is a "clever" way.
Best wishes,
--
Peter Clift
On Sat, 2010-10-30 at 00:08 +0100, Peter Clifton wrote:
> It is pretty hard to make out, but I _think_ I'm seeing the GPU starved
> at certain points. It looks like the URB busy flag at 100% for these
> portions of the profile. I've highlighted them in RED as the bad stalls
the tool's source-code or OO
Spreadsheet, let me know and I'll send them.
Regards
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1
though it comes with more than half the ram
I have in this laptop, and probably costs about 1/2 - 3/4 what the
laptop did).
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No sig
hard for me to do), is
compare some benchmarks against the Win32 drivers for the chip to sanity
check whether the Linux drivers + mesa are in the same ball-park or not.
If they are, I guess there won't be a silver bullet fix anywhere.
Best regards,
--
Peter Clifton
Electrical Engineering Div
Others might disagree, but from your video I wouldn't be 100% sure that
I could restrict the search to the graphics driver only.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173
C6
Your BIOS reports the following C-states : C1 C4
:(
I'll wait your suggestions based on the above before I try poking the
register.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (
... to prevent flush processing of an idle (or even absent) ring.
This fixes a regression during suspend from 87acb0a5.
Reported-and-tested-by: Alexey Fisher
Tested-by: Peter Clifton
Signed-off-by: Chris Wilson
It fixed my suspend.
> - after one day, applications
work from everyone at Intel, the mesa developers, and those
working on all the other OSS drivers is really really bringing the Linux
desktop up to scratch. Very very many people have a lot to be thankful
to you guys for.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
kit redrawing.
I sometimes wonder if it is just memory bandwidth constraining things..
perhaps I need to look to the chipset docs and see if there are any
performance diagnostic regs there as well.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9,
ly not up to coding this all, but if the idea sounds feasible,
I'd love to know, so I might be able to have a tinker with it.
Best regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)
On Sat, 2010-10-23 at 10:10 +0100, Chris Wilson wrote:
> On Sat, 23 Oct 2010 05:07:57 +0100, Peter Clifton wrote:
> > Although I don't doubt that it is incorrect for some reason. My logic
> > was this.. the mm.flush_rings is supposed to be |='d with the object's
>
On Sat, 2010-10-23 at 04:35 +0100, Peter Clifton wrote:
> Lost of bisecting and backporting later.. and I've identified the bad
> commit:
>
> 9220434a8768902cd9cf248709972678b74aa8c1 drm/i915: Only emit a flush
> request on the active ring.
A minimal
On Fri, 2010-10-22 at 20:29 +0100, Chris Wilson wrote:
> On Fri, 22 Oct 2010 20:10:44 +0100, Peter Clifton wrote:
> > As an additional data-point, with the bug manifesting, if you go to
> > "expose" mode, (Win+E for default config), you find the corruption is
> >
On Fri, 2010-10-22 at 23:48 +0100, Peter Clifton wrote:
> Non-fastforward of drm-intel-next
>
> Hi Chris,
Sorry.. meant to 'CC you, and appear to have dropped your email in the
subject line.
I hope this doesn't get you too much more spam through the address being
prominen
e forced update, we have this delta. Was it intentional?
(Attached).
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab ph
On Fri, 2010-10-22 at 20:29 +0100, Chris Wilson wrote:
> On Fri, 22 Oct 2010 20:10:44 +0100, Peter Clifton wrote:
> > As an additional data-point, with the bug manifesting, if you go to
> > "expose" mode, (Win+E for default config), you find the corruption is
> >
m.
I thought I'd tried reverting to an older ddx, but thinking more
carefully, perhaps I didn't go back very far. I'll try poking at the 2D
driver. Certainly it is quicker to do that than keep rebuilding drm and
rebooting.
Thanks for the pointer.
--
Peter Clifton
Electr
On Fri, 2010-10-22 at 14:39 +0100, Chris Wilson wrote:
> On Fri, 22 Oct 2010 13:53:16 +0100, Peter Clifton wrote:
> > Hi guys,
> >
> > I was wondering whether anyone has tried the latest stack of drivers
> > with compiz running?
> >
> > I'm running
On Fri, 2010-10-22 at 14:39 +0100, Chris Wilson wrote:
> On Fri, 22 Oct 2010 13:53:16 +0100, Peter Clifton wrote:
> > Hi guys,
> >
> > I was wondering whether anyone has tried the latest stack of drivers
> > with compiz running?
> >
> > I'm ru
On Tue, 2010-10-12 at 18:45 +0100, Peter Clifton wrote:
> Using glxgears as a tool to exercise the GPU with some simple rendering,
> I have noted a strange cliff in the intel_gpu_top output when resizing
> the glxgears window:
>
> Below a certain size e.g.:
>
> -
ne_definitions(uint32_t devid)
gen4_instdone_bit(I965_ROW_1_EU_3_DONE, "Row 1, EU 3");
gen4_instdone_bit(I965_SF_DONE, "Strips and Fans");
gen4_instdone_bit(I965_SE_DONE, "Setup Engine");
- gen4_instdone_bit(
On Thu, 2010-10-07 at 12:41 +0100, Peter Clifton wrote:
> On Wed, 2010-10-06 at 15:27 -0700, Eric Anholt wrote:
>
> > Of this, I'd say that you're spending a surprising amount of time in
> > texture fetch. Finding ways to reduce texture bandwidth may pay off,
>
I can't quite
imagine why, but perhaps mesa is using the texture unit for some
operations.
Thanks for the hint on the busy / stalled figures. That helps interpret
things!
Best wishes,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ
Message Arbiter row 1: 11%: ▌
SVDR CS CR: 6%: ██▌
EM1 CS CR: 5%: ██▏
SVSM CS CR: 2%: █
Best regards,
--
Peter Cli
On Tue, 2010-08-24 at 00:33 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 00:16:37 +0100, Peter Clifton wrote:
> > I noticed that the patch changes the semantics of some of the wait_for
> > calls. Previously, many were called with a zero msleep parameter -
> > meaning the
t waiting to enable LVDS pipe");
>
> intel_lvds_set_backlight(dev, dev_priv->backlight_duty_cycle);
> @@ -123,7 +123,7 @@ static void intel_lvds_set_power(struct drm_device *dev,
> bool on)
>
> I915_WRITE(ctl_reg, I915_READ(ctl_reg) &
>
On Thu, 2010-07-22 at 17:34 -0400, Andrew Lutomirski wrote:
> [resend b/c I used the wrong from address last time]
>
> I have a 10 bit/channel monitor (DisplayPort) which works quite nicely
> in 8 bit mode. I saw some patches from Peter Clifton related to 10
> bit support go in aw
my GM45 laptop.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab pho
Fixes up include paths for i915_trace.h by setting additional CFLAGS
for i915_trace_points.c to include the $src directory. The required
TRACE_INCLUDE_PATH is then "."
Signed-off-by: Peter Clifton
---
drivers/gpu/drm/i915/Makefile |2 ++
drivers/gpu/drm/i915/i915_trace.h |
-by: Eric Anholt
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, a
---
drivers/gpu/drm/i915/intel_display.c | 38 ++---
drivers/gpu/drm/i915/intel_drv.h |2 +-
2 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e8191a..16cc13c 10
---
drivers/gpu/drm/i915/i915_reg.h |7 ++-
drivers/gpu/drm/i915/intel_display.c | 33 ++---
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab1bd2d..7a0c6ac 100644
--
Store the full precision, even if we only use the high byte
when programming the palette registers.
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
drivers/gpu/drm/i915/intel_drv.h |2 +-
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drive
On Mon, 2010-04-26 at 10:29 -0400, Adam Jackson wrote:
> On Sat, 2010-04-24 at 17:25 +0100, Peter Clifton wrote:
>
> > I noticed an anomaly in the register settings on my GM45, according to
> > PIPEBCONF, it is set in 10-bit palette mode, yet the KMS code programs
> > the
We're programming an 8-bit palette, so ensure we set the hardware
up appropriately. Also, rename the palreg variable pal_reg for more
consistency with the rest of this file.
---
drivers/gpu/drm/i915/intel_display.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --
g code to review the patch.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab p
;t do a blit is sufficient, but it "seems
to help" here. Perhaps Chris can comment.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)
the Cantiga platforms
seem to require a "0" in the state-change detection enable bits, but I
see I got no credit for that detective work in the eventual patch Zhao
Yakui worked up once with access to the HW specs / BIOS code.
PS.. Wouldn't it be nice to get some of that referen
el which could be "fixed", but sadly litte data is available
from the panel manufacturer).
Regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the la
.
Signed-off-by: Chris Wilson
I've also attached a cosmetic clean-up in the same area.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 7
Patch attached.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
>F
based method to detect TV-out, not the state-change
interrupt based method.
It is (just) possible that the state-change detection logic is separate
to that used for polling the status, and the two are conflicting. Some
hardware guys at Intel will probably have to confirm this.
--
Peter Cli
80 matches
Mail list logo
