https://bugs.freedesktop.org/show_bug.cgi?id=38800
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #50 from Alex Deucher 2011-07-11 14:28:11 PDT
---
upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7eff394670366a42935bfbaef67a6f7185627d7
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #50 from Alex Deucher ag...@yahoo.com 2011-07-11 14:28:11 PDT ---
upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7eff394670366a42935bfbaef67a6f7185627d7
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #49 from Alex Deucher 2011-07-08 11:21:51 PDT
---
(In reply to comment #48)
> Review of attachment 48897 [details]:
>
> Other than that typo
> Reviewed-by: mario.kleiner at tuebingen.mpg.de
I just sent out a fixed version, forgot
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #48 from Mario Kleiner
2011-07-08 11:16:38 PDT ---
Review of attachment 48897:
--> (https://bugs.freedesktop.org/review?bug=38800=48897)
Other than that typo
Reviewed-by: mario.kleiner at tuebingen.mpg.de
:::
https://bugs.freedesktop.org/show_bug.cgi?id=38800
Michel D?nzer changed:
What|Removed |Added
Attachment #48883|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #46 from Simon Farnsworth
2011-07-08 07:25:15 PDT ---
(In reply to comment #43)
> Created an attachment (id=48897)
View: https://bugs.freedesktop.org/attachment.cgi?id=48897
Review:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
Michel D?nzer changed:
What|Removed |Added
Attachment #48892|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #45 from Michel D?nzer 2011-07-08 07:20:44
PDT ---
Review of attachment 48897:
--> (https://bugs.freedesktop.org/review?bug=38800=48897)
Yeah, that's better than my patch, thanks. :)
Reviewed-by: Michel D?nzer
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #44 from Simon Farnsworth
2011-07-08 07:17:59 PDT ---
Created an attachment (id=48898)
View: https://bugs.freedesktop.org/attachment.cgi?id=48898
Review: https://bugs.freedesktop.org/review?bug=38800=48898
The register access
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #43 from Alex Deucher 2011-07-08 07:12:49 PDT
---
Created an attachment (id=48897)
View: https://bugs.freedesktop.org/attachment.cgi?id=48897
Review: https://bugs.freedesktop.org/review?bug=38800=48897
thoroughly clean up
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #42 from Michel D?nzer 2011-07-08 05:18:32
PDT ---
Created an attachment (id=48892)
View: https://bugs.freedesktop.org/attachment.cgi?id=48892
Review: https://bugs.freedesktop.org/review?bug=38800=48892
Add missing register
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #41 from Simon Farnsworth
2011-07-08 04:32:57 PDT ---
Created an attachment (id=4)
View: https://bugs.freedesktop.org/attachment.cgi?id=4
Review: https://bugs.freedesktop.org/review?bug=38800=4
dmesg snippet showing
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #40 from Michel D?nzer 2011-07-08 03:05:20
PDT ---
Created an attachment (id=48883)
View: https://bugs.freedesktop.org/attachment.cgi?id=48883
Review: https://bugs.freedesktop.org/review?bug=38800=48883
Use new frontbuffer fence,
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #39 from Simon Farnsworth
2011-07-08 02:41:15 PDT ---
(In reply to comment #37)
> Maybe we should try and sort out why there is so much latency in the interrupt
> handler for Simon rather than rewriting the entire thing. Or we
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #39 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-08 02:41:15 PDT ---
(In reply to comment #37)
Maybe we should try and sort out why there is so much latency in the interrupt
handler for Simon rather than rewriting
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #40 from Michel Dänzer mic...@daenzer.net 2011-07-08 03:05:20 PDT
---
Created an attachment (id=48883)
View: https://bugs.freedesktop.org/attachment.cgi?id=48883
Review: https://bugs.freedesktop.org/review?bug=38800attachment=48883
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #41 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-08 04:32:57 PDT ---
Created an attachment (id=4)
View: https://bugs.freedesktop.org/attachment.cgi?id=4
Review:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #42 from Michel Dänzer mic...@daenzer.net 2011-07-08 05:18:32 PDT
---
Created an attachment (id=48892)
View: https://bugs.freedesktop.org/attachment.cgi?id=48892
Review: https://bugs.freedesktop.org/review?bug=38800attachment=48892
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #45 from Michel Dänzer mic...@daenzer.net 2011-07-08 07:20:44 PDT
---
Review of attachment 48897:
-- (https://bugs.freedesktop.org/review?bug=38800attachment=48897)
Yeah, that's better than my patch, thanks. :)
Reviewed-by: Michel
https://bugs.freedesktop.org/show_bug.cgi?id=38800
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Attachment #48883|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #48 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-08
11:16:38 PDT ---
Review of attachment 48897:
-- (https://bugs.freedesktop.org/review?bug=38800attachment=48897)
Other than that typo
Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #38 from Mario Kleiner
2011-07-07 14:51:16 PDT ---
(In reply to comment #37)
> Maybe we should try and sort out why there is so much latency in the interrupt
> handler for Simon rather than rewriting the entire thing. Or we could
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #37 from Alex Deucher 2011-07-07 14:25:29 PDT
---
Maybe we should try and sort out why there is so much latency in the interrupt
handler for Simon rather than rewriting the entire thing. Or we could just use
the pflip interrupts
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #36 from Mario Kleiner
2011-07-07 14:06:51 PDT ---
(In reply to comment #35)
> Hmm, but V_UPDATE irq is not supported on R500, if i look at the correct
> manual, which is still in widespread use for many serious applications (and on
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #35 from Mario Kleiner
2011-07-07 13:39:39 PDT ---
Hmm, but V_UPDATE irq is not supported on R500, if i look at the correct
manual, which is still in widespread use for many serious applications (and on
my main laptop for
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #34 from Mario Kleiner
2011-07-07 12:06:40 PDT ---
On Jul 7, 2011, at 5:18 PM, Alex Deucher wrote:
> 2011/7/7 Michel D?nzer :
>> On Don, 2011-07-07 at 11:00 -0400, Alex Deucher wrote:
>>> On Thu, Jul 7, 2011 at 10:45 AM, Mario
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #33 from Simon Farnsworth
2011-07-07 10:46:36 PDT ---
(In reply to comment #31)
> (In reply to comment #30)
> > So wait for bo to be idle before waiting to be out of vblank
>
> Bad idea I'm afraid: Consider the case where the ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #32 from Jerome Glisse 2011-07-07
07:11:43 PDT ---
Well i can think of similar bad case in the other way.
-wait for vblank
-wait for bo put us in next vblank
-program reg flip happen on this frame
-irq reporting report on next
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #31 from Michel D?nzer 2011-07-07 06:49:55
PDT ---
(In reply to comment #30)
> So wait for bo to be idle before waiting to be out of vblank
Bad idea I'm afraid: Consider the case where the ioctl is called outside of
vblank, but by
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #30 from Jerome Glisse 2011-07-07
06:36:38 PDT ---
This flip stuff is hairy. I think best is :
flip ioctl:
- pin new front
- delay work to bo fence (if no fence use the oldest alive fence)
- return
fence handler:
- on flip work
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #29 from Michel D?nzer 2011-07-07 01:47:49
PDT ---
Thanks for explaining the problems with doing everything directly in the ioctl,
Mario. Guess it was too good to be true...
I agree it should be a good idea to defer to an interrupt
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #29 from Michel Dänzer mic...@daenzer.net 2011-07-07 01:47:49 PDT
---
Thanks for explaining the problems with doing everything directly in the ioctl,
Mario. Guess it was too good to be true...
I agree it should be a good idea to
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #30 from Jerome Glisse gli...@freedesktop.org 2011-07-07 06:36:38
PDT ---
This flip stuff is hairy. I think best is :
flip ioctl:
- pin new front
- delay work to bo fence (if no fence use the oldest alive fence)
- return
fence
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #32 from Jerome Glisse gli...@freedesktop.org 2011-07-07 07:11:43
PDT ---
Well i can think of similar bad case in the other way.
-wait for vblank
-wait for bo put us in next vblank
-program reg flip happen on this frame
-irq
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #34 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-07
12:06:40 PDT ---
On Jul 7, 2011, at 5:18 PM, Alex Deucher wrote:
2011/7/7 Michel Dänzer mic...@daenzer.net:
On Don, 2011-07-07 at 11:00 -0400, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #35 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-07
13:39:39 PDT ---
Hmm, but V_UPDATE irq is not supported on R500, if i look at the correct
manual, which is still in widespread use for many serious applications (and on
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #36 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-07
14:06:51 PDT ---
(In reply to comment #35)
Hmm, but V_UPDATE irq is not supported on R500, if i look at the correct
manual, which is still in widespread use for many
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #37 from Alex Deucher ag...@yahoo.com 2011-07-07 14:25:29 PDT ---
Maybe we should try and sort out why there is so much latency in the interrupt
handler for Simon rather than rewriting the entire thing. Or we could just use
the pflip
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #38 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-07
14:51:16 PDT ---
(In reply to comment #37)
Maybe we should try and sort out why there is so much latency in the interrupt
handler for Simon rather than rewriting the
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #28 from Alex Deucher 2011-07-06 20:07:58 PDT
---
(In reply to comment #27)
> (In reply to comment #22)
> > FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
> > seemed to work ok on 7xx+.
>
> Thanks for
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #27 from Mario Kleiner
2011-07-06 18:43:42 PDT ---
(In reply to comment #22)
> FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
> seemed to work ok on 7xx+.
Thanks for the info Alex. Can you define
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #26 from Mario Kleiner
2011-07-06 18:02:26 PDT ---
Ok, i looked at the patch. The way it is now it won't work reliably and is
vulnerable to the races we tried to remove in the current implementation.
First, as far as i understood,
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #25 from Alex Deucher 2011-07-06 14:52:46 PDT
---
You can select where you want the double buffered update to take place by
adjusting the D*MODE_MASTER_UPDATE_MODE regs (pre-avivo has similar bits).
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #24 from Jerome Glisse 2011-07-06
14:35:49 PDT ---
So rereading the spec it's all about computing vblank lenght and adding it to
timestamp at vblank interrupt.
Seems like the most reliable solution
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #23 from Jerome Glisse 2011-07-06
14:25:54 PDT ---
So what exactly the timestamp should correspond to ? For me vblank is good
enough and looking at specification its says that it's when the hw register are
using the new value. So
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #22 from Alex Deucher 2011-07-06 14:13:27 PDT
---
FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
seemed to work ok on 7xx+. Also, I can see problems where you might not get
interrupts for some flips if
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #21 from Mario Kleiner
2011-07-06 13:54:14 PDT ---
@Simon: Michel and your testcode is right, the pageflip is only programmed
about 2 scanlines after the end of vblank, so the crtc waits for another full
refresh cycle before
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #20 from Simon Farnsworth
2011-07-06 07:24:10 PDT ---
So, this is a gross hack to demonstrate that it's the delaying of the pageflip
that's hurting me:
[sfarnsworth at f12simon airlied-drm-fixes]$ git diff
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #19 from Simon Farnsworth
2011-07-06 03:19:46 PDT ---
I'm using the preferred mode from the panel's EDID, which xrandr says is:
1920x1200 (0x54) 154.0MHz +HSync -VSync *current +preferred
h: width 1920 start 1968 end
https://bugs.freedesktop.org/show_bug.cgi?id=38800
Michel D?nzer changed:
What|Removed |Added
CC||mario.kleiner at tuebingen.mpg
https://bugs.freedesktop.org/show_bug.cgi?id=38800
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #19 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-06 03:19:46 PDT ---
I'm using the preferred mode from the panel's EDID, which xrandr says is:
1920x1200 (0x54) 154.0MHz +HSync -VSync *current +preferred
h:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #20 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-06 07:24:10 PDT ---
So, this is a gross hack to demonstrate that it's the delaying of the pageflip
that's hurting me:
[sfarnsworth@f12simon airlied-drm-fixes]$ git diff
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #21 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-06
13:54:14 PDT ---
@Simon: Michel and your testcode is right, the pageflip is only programmed
about 2 scanlines after the end of vblank, so the crtc waits for another
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #22 from Alex Deucher ag...@yahoo.com 2011-07-06 14:13:27 PDT ---
FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
seemed to work ok on 7xx+. Also, I can see problems where you might not get
interrupts for
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #23 from Jerome Glisse gli...@freedesktop.org 2011-07-06 14:25:54
PDT ---
So what exactly the timestamp should correspond to ? For me vblank is good
enough and looking at specification its says that it's when the hw register are
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #24 from Jerome Glisse gli...@freedesktop.org 2011-07-06 14:35:49
PDT ---
So rereading the spec it's all about computing vblank lenght and adding it to
timestamp at vblank interrupt.
Seems like the most reliable solution
--
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #25 from Alex Deucher ag...@yahoo.com 2011-07-06 14:52:46 PDT ---
You can select where you want the double buffered update to take place by
adjusting the D*MODE_MASTER_UPDATE_MODE regs (pre-avivo has similar bits).
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #26 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-06
18:02:26 PDT ---
Ok, i looked at the patch. The way it is now it won't work reliably and is
vulnerable to the races we tried to remove in the current implementation.
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #27 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2011-07-06
18:43:42 PDT ---
(In reply to comment #22)
FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
seemed to work ok on 7xx+.
Thanks for the
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #28 from Alex Deucher ag...@yahoo.com 2011-07-06 20:07:58 PDT ---
(In reply to comment #27)
(In reply to comment #22)
FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
seemed to work ok on 7xx+.
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #17 from Simon Farnsworth
2011-07-05 10:57:45 PDT ---
I added "video=LVDS-1:d" to my kernel command line, which changes xrandr output
to:
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
LVDS
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #16 from Michel D?nzer 2011-07-05 10:37:21
PDT ---
(In reply to comment #15)
> Whatever resolution I choose, perf top shows me that 50% of my used CPU time
> is
> spent in r600_fence_finish from the r600g DRI driver.
That makes
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #15 from Simon Farnsworth
2011-07-05 09:56:41 PDT ---
Redoing my benchmarking with the resolution knowledge in mind:
Whatever resolution I choose, perf top shows me that 50% of my used CPU time is
spent in r600_fence_finish from
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #14 from Simon Farnsworth
2011-07-05 09:01:34 PDT ---
We've got some form of unexpected resolution dependent behaviour here, that
Intel doesn't show.
My target is always 60fps, to match the screen refresh rate of 60Hz.
On Fedora
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #13 from Simon Farnsworth
2011-07-05 05:24:19 PDT ---
Created an attachment (id=48768)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48768)
drm.debug=0xf dmesg snippet, showing timings of page flips
PID 955 is Xorg, PID 1360
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #12 from Simon Farnsworth
2011-07-05 05:18:12 PDT ---
I can't persuade the tracepoints Michel recommended to do anything - no data
gets recorded by perf when I run my test programs. I've attempted to record the
data with:
perf
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #12 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-05 05:18:12 PDT ---
I can't persuade the tracepoints Michel recommended to do anything - no data
gets recorded by perf when I run my test programs. I've attempted to
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #14 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-05 09:01:34 PDT ---
We've got some form of unexpected resolution dependent behaviour here, that
Intel doesn't show.
My target is always 60fps, to match the screen
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #15 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-05 09:56:41 PDT ---
Redoing my benchmarking with the resolution knowledge in mind:
Whatever resolution I choose, perf top shows me that 50% of my used CPU time is
spent
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #17 from Simon Farnsworth simon.farnswo...@onelan.co.uk
2011-07-05 10:57:45 PDT ---
I added video=LVDS-1:d to my kernel command line, which changes xrandr output
to:
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200,
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #11 from Michel D?nzer 2011-07-04 09:30:56
PDT ---
Note that as you say it's not hitting even 10% CPU load, it's probably not a
simple CPU bottleneck but some kind of timing / timeout issue. The tracepoint
events listed by
perf
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #10 from Jerome Glisse 2011-07-04
09:19:39 PDT ---
Profilling is likely the solution to get meaningfull data. However it won't
work on x86-64 unless you build everything with frame pointer.
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #9 from Simon Farnsworth
2011-07-04 06:27:19 PDT ---
Updating to git master (on top of airlied's drm-fixes) has improved things, but
I'm still not there. I have gone to the following commits in each interesting
tree:
dri2proto:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #8 from Simon Farnsworth
2011-07-04 04:22:55 PDT ---
Moving up a kernel revision, to airlied's drm-fixes
6002525170df5f72c92ab946b6ebf1656aaec74d hasn't helped. I'm going to try and
get a full X11 stack, including new Mesa, running
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #8 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-07-04
04:22:55 PDT ---
Moving up a kernel revision, to airlied's drm-fixes
6002525170df5f72c92ab946b6ebf1656aaec74d hasn't helped. I'm going to try and
get a full X11 stack,
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #9 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-07-04
06:27:19 PDT ---
Updating to git master (on top of airlied's drm-fixes) has improved things, but
I'm still not there. I have gone to the following commits in each
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #11 from Michel Dänzer mic...@daenzer.net 2011-07-04 09:30:56 PDT
---
Note that as you say it's not hitting even 10% CPU load, it's probably not a
simple CPU bottleneck but some kind of timing / timeout issue. The tracepoint
events
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #7 from Simon Farnsworth
2011-07-01 09:57:33 PDT ---
Also, just in case there's oddities lurking with multihead, I've confirmed via
XRandR that only VGA-0 is enabled, and that the screen and CRTC are both at
1920x1200.
--
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #6 from Simon Farnsworth
2011-07-01 09:54:25 PDT ---
Created an attachment (id=48657)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48657)
An adapted test program, showing that it's not the wait for the swap events
that slows
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #6 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-07-01
09:54:25 PDT ---
Created an attachment (id=48657)
-- (https://bugs.freedesktop.org/attachment.cgi?id=48657)
An adapted test program, showing that it's not the wait
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #7 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-07-01
09:57:33 PDT ---
Also, just in case there's oddities lurking with multihead, I've confirmed via
XRandR that only VGA-0 is enabled, and that the screen and CRTC are
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #5 from Simon Farnsworth
2011-06-30 10:10:36 PDT ---
More digging - I changed drm.debug to 0xf, and I can see [22545.268466]
"drm:evergreen_page_flip], Update pending now high. Unlocking vupdate_lock." in
the dmesg output - I take
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #4 from Simon Farnsworth
2011-06-30 08:09:03 PDT ---
Added more logging - I'm clearly wrong, because I see that I enter the
following codepath around line 1100 of radeon_dri2.c in
radeon_dri2_schedule_swap, which converts DRI2_SWAPs
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #3 from Simon Farnsworth
2011-06-30 05:20:41 PDT ---
I turned on verbose logging by adding -logverbose 65535 to my X startup line,
and I can see the following in the log:
[ 3640.369] (II) RADEON(0): radeon_dri2_schedule_flip:619
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #2 from Simon Farnsworth
2011-06-30 03:53:31 PDT ---
Created an attachment (id=48590)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48590)
Xorg.log from AMD system
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #1 from Simon Farnsworth
2011-06-30 03:53:11 PDT ---
Created an attachment (id=48589)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48589)
dmesg from AMD system
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #1 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-06-30
03:53:11 PDT ---
Created an attachment (id=48589)
-- (https://bugs.freedesktop.org/attachment.cgi?id=48589)
dmesg from AMD system
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #2 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-06-30
03:53:31 PDT ---
Created an attachment (id=48590)
-- (https://bugs.freedesktop.org/attachment.cgi?id=48590)
Xorg.log from AMD system
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #3 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-06-30
05:20:41 PDT ---
I turned on verbose logging by adding -logverbose 65535 to my X startup line,
and I can see the following in the log:
[ 3640.369] (II) RADEON(0):
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #4 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-06-30
08:09:03 PDT ---
Added more logging - I'm clearly wrong, because I see that I enter the
following codepath around line 1100 of radeon_dri2.c in
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #5 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-06-30
10:10:36 PDT ---
More digging - I changed drm.debug to 0xf, and I can see [22545.268466]
drm:evergreen_page_flip], Update pending now high. Unlocking vupdate_lock. in
93 matches
Mail list logo
