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
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
.
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
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
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
;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)
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
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 --
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
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
---
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
--
---
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
-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
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 |
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
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
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
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 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
Message Arbiter row 1: 11%: ▌
SVDR CS CR: 6%: ██▌
EM1 CS CR: 5%: ██▏
SVSM CS CR: 2%: █
Best regards,
--
Peter Cli
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
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,
>
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 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.:
>
> -
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 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
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 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
> >
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 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
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 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 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
>
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)
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,
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,
... 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
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 (
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
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
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
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
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
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 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
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 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
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
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
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
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: +
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
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
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 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
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
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
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,
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
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 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
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
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
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
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
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
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
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 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
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
--
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
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
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
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
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
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
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 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
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
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
80 matches
Mail list logo
