spstarr: airlied: Xorg 1.6.1 seems to make EXA better.. donno what blew up
spstarr: rather, it's more than better!
hifi: need moar fps :(
spstarr: moar
hifi: provide moar fps!
airlied: hmm not sure why but I just added zaphod to kms, and it seems to work.
MostAwesomeDude: airlied: :3
nanonyme: Morning.
airlied: hmm xinerama craps out looks like a server bug thouh
b0le: MostAwesomeDude: when trying to run trivial/clear I get radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion: 'bo->space_accounted' failed. Aborted.
MostAwesomeDude: b0le: Huh, weird. Reliably?
b0le: yes
MostAwesomeDude: Also happens with RADEON_NO_TCL?
b0le: yep
MostAwesomeDude: Hm. I'll look into it.
b0le: and interestingly, with RADEON_SOFTPIPE, I get the same problem I have with radeon-rewrite. It is rendering (both with and without -db) into the window, but it is showing the top-left of the screen, not what is is suppoed to be showing.
MostAwesomeDude: WTF. RADEON_SOFTPIPE should always work.
MostAwesomeDude: Anything in dmesg from that?
b0le: no
MostAwesomeDude: Huh. Weird.
b0le: I don't think it is your problem, as it is happening with rewrite as well.
MostAwesomeDude: Probably.
yangman: airlied: log is actually showing failure with radeon (user seems confused about the packages); you might want to take a look: http://bugs.freedesktop.org/show_bug.cgi?id=21192
airlied: b0le: shouldn't happen with re-write what gpu you on?
airlied: MostAwesomeDude: did you add the aperture sizing code?
MostAwesomeDude: airlied: Haven't had time yet. :c
MostAwesomeDude: Been bitbaking all day and night.
airlied: well that is why he hits the assert
MostAwesomeDude: airlied: I figured.
MostAwesomeDude: Although it shouldn't happen on a one-frame clear.
MostAwesomeDude: And softpipe should work.
b0le: airlied: R430 (according to glxinfo), it is an x800. But I was referring to the incorrect rendering, not the assert.
b0le: (when I was talking about the problem with rewrite)
airlied: b0le: ah okay
b0le: MostAwesomeDude: with softpipe, it doesn't give the assert, but gives the rendering problem I was having with rewrite. Sorry if that wasn't clear before.
MostAwesomeDude: b0le: Hm. Sounds like a problem further up the line.
MostAwesomeDude: glxgears should render completely correctly with softpipe.
airlied: it sounds like some DRI2 issue, maybe with new X server.
b0le: Could it be related to the "fix front-buffer rendering" commits?
airlied: most likely
airlied: okay server fix, zaphod/xinerama still lives.
b0le: reverting the commits in the xserver (regarding front-buffer rendering) fixed the rendering (not the assert with gallium-r300, just incase there is any doubt)
MostAwesomeDude: b0le: 'k. Will look at when I have time.
airlied: b0le: I pinged idr in dri-devel
glisse: airlied: you know any very simple X app which trigger composite rendering in exa ?
airlied: glisse: hmm I normally run an xterm + metacity, the metacity title bar triggers it :)
glisse: i guess i will do my own app, i need to dump ib and i am not feeling like going through hundred of them
airlied: glisse: I think otaylor used to have some simple ones
airlied: using pycairo
glisse: we already are in 2.6.30rc ?
nanonyme: rc2, I think.
airlied: glisse: yes
nanonyme: (If you were asking what's already released)
glisse: i thought that it tooks longer before hiting rc :)
airlied: glisse: two weeks for release to rc1 always
airlied: then every 1-2 weeks after that
glisse: so 2.6.30 will be release this summer ? that doesn't gives much times to test newttm if we ever want to try submit it for 2.6.31
airlied: glisse: it does't need to be perfect
airlied: we just have to be happy the API is supportable
airlied: its not insane or really insecure
airlied: it won't be on by deafult
airlied: oh and it doesn't regress anythnig when its off :)
glisse: airlied: i doubt i would regress anythings given i don't touch old path :)
airlied: mainly just init, irq, suspend/resume
airlied: glisse: I think we should probably stage a tree, need to get TH to split up TTM maybe
airlied: or do it ourselves
glisse: airlied: well we could already queue drm core patchset
glisse: they are sane imho
glisse: my glisse-drm-next branch got them all
glisse: then i don't see how to split ttm
glisse: beside not submit *helper* files
airlied: not adding userspace api crap :)
airlied: until openchrome goes in
glisse: i think all these is in *helper* files
glisse: or *user*
airlied: ah cool, don't want them then
airlied: I'd be happy to pull something into drm-next in the next week or two.
airlied: from then on we'd just pull patches in on top
glisse: well i really would like to fix this x1900 and then ask for tester :)
b0le: to test newttm, does it require glisse's tree of ddx, mesa and libdrm as well?
glisse: so far it works on all my card except x1900
glisse: b0le: just kernel should be enough
nanonyme: I assume you have more than one x1900. :)
glisse: haven't tested yet if cs3 fix mmap caching works for me
glisse: nanonyme: i got pretty much all radeon chipset
glisse: except rs400,rs480,rs740
glisse: and rs600
glisse: which happens to be among the most problematic piece of hw :)
airlied: glisse: not sure it worked for me :)
airlied: glisse: hehe.. I think I'm missing the same chips you are :)
airlied: I have an rs4xx motherboard with no CPU, no RAM, no video output connectors (they need a jumper cable)
airlied: I must try and ebay another oen see if I do better
glisse: airlied: i got most of my hardware from sidewalk of Paris :)
airlied: you'd think there would be lots of rs4xx :)
glisse: few years ago their wasn't any kind of recycling
airlied: on sidewalks
nanonyme: Heh, that sounds like quite some dedication to development. ;)
osiris__: airlied: when applying agp mode quirks shouldn't we break the loop if we have found one?
airlied: osiris__: probably makes sense alright.
mroconnor: 1if i am having trouble w/ the cairo git repo what is the best channel to seek help?
airlied: #cairo?
mroconnor: that works lol
mroconnor: thanks airlied
mroconnor: its early
cire: is there a known issue with xorg 1.6 Dual Head with radeon? (6.12.2)
cire: One of my two screens always stys blank. xrandr tells me both were on.
airlied: cire: what gpu?
cire: R600 (Radeon HD 3600)
cire: or RV635
cire: xorg 1.5 worked fine
cire: so I don't know where the problem lies (xorg or radeon)
cire: or both :)
cire: airlied: I was away for some minutes, so both screens were in power save mode. I came back, moved the mouse, and now both are working fine
osiris__: agd5f: does the non TCL hw support the perspective divide operation?
cire: I don't want to interrupt you with problems you are not responsible for, so if this might be an Xorg problem you just can tell me. But if you think it might be a radeon problem I can give you further information. (calling system settings again made both screens in Clone Mode, now)
airlied: cire: agd5f might have an idea he sees more of those things :)
cire: okay. I will prepare some logs and so on and post pastebin uri here
cire: airlied: which bugtracker should I search for this issue?
airlied: cire: bugs.freedesktop.org file it if you can't find it
cire: thank you, I'll have a look
cire: I think it is https://bugs.freedesktop.org/show_bug.cgi?id=19439
cire: so I have to wait for a new release.
airlied: cire: that shoudl be fixed in 6.12.2
doncarlos: hello airlied, i just test the rawhide live cd and the computer freezed as soon as i start glxgears or try to enable compiz.
doncarlos: i have a radeon X700
glisse: doncarlos: pcie ?
doncarlos: yep
cire: It's a completely weird behaviour. xrandr --output DVI-0 --left-of DVI-1 and vice versa, even --right-of doesn't work. Either only one screen is on, or both with clone mode.
glisse: cire: do you have virtual set ?
cire: yes
doncarlos: i ssh'ed to the sick machine and tried to get the log files, but there does nothing appear
doncarlos: the computer freezes at once. :(
doncarlos: btw. i use 64 bit
cire: glisse: http://pastebin.com/m7991337d
cire: ohh, there's a typo. I'll recheck.
doncarlos: glisse, airlied: is there anything i can do in order to help?
glisse: doncarlos: well sounds like hardlockup
doncarlos: yes
glisse: maybe wait a bit until newttm bits are ready to be tested
cire: correcting the typo (LeftOfOf -> LeftOf) didn't change anything
cire: after restarting my X one screen stays blank
glisse: there is gpu reset in them and it forbids outside of gart access so should help with hardlockup
cire: but xrandr tells me it was connected and running
doncarlos: i think i was able to test the new boot-splash screen. did i already use the newttm, but it's not ready yet?
glisse: very unlikely you did use newttm i am pretty much the only one using it right now :)
cire: in KDE4 Display Settings, both screens are in one. (detect devices returns DVI-0 AND DVI-1 on the working screen)
doncarlos: :D hehe , i tested only the rawhide live cd
doncarlos: when a hard lockup happens, a normal user can't help? :(
glisse: doncarlos: if you willing to compile rawhide kernel try setting (3 << 1) in pcie setup for pcie_cntl
doncarlos: can i disable kms and dri2 on the livecd, maybe with a kernel parameter?
glisse: there is much one can do without recompiling kernel and touching code
glisse: doncarlos: you can add nomodeset=1 to kernel command line
glisse: livecd should give you the oportunity to do that at the very begining
doncarlos: kernel compiling is still a bit too high for me i think, but i compile x drivers regular
doncarlos: i will test nomodeset=1
doncarlos: yep, there is the very old splash-screen
cire: I will file a bug now.
doncarlos: glisse: was the crash expected? or should it just work?would it make sense to file a bug?
glisse: doncarlos: crash is never expected :)
doncarlos: hm, and with newttm the graphics system will probably become more stable?
glisse: well i hope that disabling out of gart access would at least prevent hard lockup
glisse: haven't got any so far on my side
b0le: well, I just tested newttm, and I get a lockup when trying to boot.
glisse: b0le: disable fbcon
doncarlos: would be nice. with nomodeset=1 glxgears works btw
glisse: it's due to fbcon looping somewhere
doncarlos: but after enabling desktop effects it locked up again. but this time with a "beep" from the computer. :D
airlied: doncarlos: was that the test liveCD or the beta?
doncarlos: hm, i think the beta
doncarlos: how can i find out easily?
airlied: rpm -q kernel might tell me.
glisse: b0le: also reporting log/dmesg is always helpfull
doncarlos: ok, just restarting
airlied: doncarlos: though there might be updated live images soon
airlied: that fix a lot of the problems found during the test days
doncarlos: grub says "welcome to fedora 11 beta"
doncarlos: :) nice
b0le: glisse: I should probably build fbcon/radeon as modules, right? I haven't bothered previously, since I can't find a way to unload them anyways, they seem to depend on eachother - do you know a way around that? (as it would be nice to be able to switch between kms/non-kms dri1/dri2 without restarting)
airlied: b0le: you can unbind the fbcon vt and rmmod radeon
airlied: you just won't get text mode back
glisse: b0le: just doesn't enable fbcon
glisse: right now there is problem with fbcon & newttm
glisse: fbcon will enter infinite loop
glisse: haven't bothered with that yet
glisse: of course infinite loop in kernel is bad
glisse: and you can rmmod radeon just fine
b0le: ok, thanks.
glisse: and modprobe radeon modeset=0
glisse: to go back to dri1
doncarlos: glisse: kernel-2.6.29-0.258.2.3.rc8.git2.fc11.x86_64
doncarlos: great numers, impressive
cire: when filing a bug, what stands "alias" and "url" for?
cire: also: is it possible to attach more than one file?
doncarlos: with kms vt switching is awesome fast, only the one with the xserver needs some time to finish the painting.
doncarlos: cire: i am not sure, but alias could be a nickname for the bus report, so you can find it in the future more easily and url could link to a webpage.maybe to a forum, where you reported the bug before. and i do also not know yet hoe to upload many files at once.
cire: thank you, I found it.
cire: This is my first bug report, so I hope I didn't make anything wrong, or forgot something important.
doncarlos: no worries, someone will tell you if that is the case :)
cire: hehe
cire: https://bugs.freedesktop.org/show_bug.cgi?id=21199
cire: could you have a look at it?
cire: if you'd expect something more?
cire: is google crawling the bugzilla repo? I don't want my mail adress get crawlable :)
cire: s/repo/list
b0le: glisse: what would cause "[drm:radeon_cp_getparam_kms] *ERROR* invalid ioctl with kms radeon_cp_getparam_kms" in dmesg (and x fails to start because "Screen(s) found, but none have a usable configuration")
glisse: b0le: out of date ddx
glisse: don't know if airlied picked up the needed ddx patch
b0le: ok, I'll try your tree then.
glisse: otherwise i have radeon-gem-cs3 branch in my repo which have everythings
b0le: it works now, both with and without kms (only tested compiz with glxgears though)
twoerner: are there any news on the mesa 3D stuff for r6xx++ ?
nanonyme: twoerner: Guess not. Then again, a few days here or there. It's probably in a quite critical stage so might as well leave them to concentrate on the driver instead of asking all the time. (and yeah, I'm a hypocrite)
twoerner: nanonyme: thanks for the graceful answer - maybe you should also stop asking for it ;-)
nanonyme: twoerner: That is, six days ago bridgman said it might be coming out in a week and that the legal process was nearing completion. (He also said that the initial driver would be very slow at first iirc)
nanonyme: I suppose the same process we had with EXA all over again. ;)
twoerner: nanonyme: ok - i do not care it if will be slow at first if at least there is something
twoerner: nanonyme: jup, i think it will be like the EXA stuff - or the R300 stuff
glisse: b0le: what gpu btw ?
nanonyme: twoerner: Well, you probably remember when we got EXA near the New Year: it got *lots* of corruption and was painfully slow. :)
glisse: twoerner: there is already enough information available for someone to write a 3d driver
nanonyme: glisse: The programming guide doesn't yet exist though, does it?
glisse: so i wouldn't worry about not seeing anythings, it's just a matter of time
glisse: nanonyme: there is register info and r600 demo and isa documentation
twoerner: nanonyme: but i was happy to use it
twoerner: glisse: if i only had the time to do that :-)
glisse: so programming guide would be definitly helpfull but is not stricly needed
nanonyme: glisse: Yups. It's just that imo there's not that much sense in someone starting a driver before the legal process finishes and the initial Mesa driver gets public. Much more sensible to build on what already exists. :)
twoerner: glisse: writing a new driver from scratch is really a lot of work
glisse: nanonyme: depends, i believe for starting to write gallium driver you don't need to wait
nanonyme: Well, that's a good point.
glisse: twoerner: this is why we are understaffed but usually it's easier if first bits are written by one people
nanonyme: It could even now be started even though it can't really be tested before the KMS and memory manager code gets a bit further.
glisse: i will definitly work on that once i got everythings working on previous hw
glisse: hopefully this week
nanonyme: Sure sure, no rush. ^^
glisse: writting gallium driver is the fun part
glisse: kernel is nice but boring because harder to debug
b0le: glisse: R430
nanonyme: I'm trying to get some studies done, that's harder if I have good 3D drivers and can play games. ;)
app4des: guys XV_VSYNC and EXAVsync don't work with the r6xx and r7xx chipsets or I am doing something wrong?
agd5f: app4des: exavsync isn't implemented yet for r6xx/r7xx
agd5f: the xvvsync should work
app4des: agd5f they both don't work to me
agd5f: app4des: are you using a compositer?
app4des: agd5f, yes exa compositor.. let me try without comp
agd5f: yeah, won't work with compositer
app4des: agd5f, previous cards work with compositor though?
app4des: agd5f, pre r6xx i mean
agd5f: app4des: sort of depending on how it was done
MrCooper: probably thanks to exavsync
agd5f: render based compositing and exavsync
sroland: agd5f: new tex video code is nice.
app4des: agd5f, yeah, exavsync would be the cause it worked then, thx. Is exavsync going to be implemented soon on r6xx+ ?
agd5f: sroland: thanks
sroland: agd5f: one question though do you really need to enable all 3 blend stages on r100?
sroland: maybe it doesn't change perf though anyway
agd5f: sroland: not sure about that. I haven't had a chance to test
agd5f: app4des: it could be, it's a bit tricker on r6xx since we accumulating verts rather than blits
cire: agd5f (bug 21199): you told me to revert a commit and use git, but at the moment I just use sidux binary packages. I never compiled xorg from sources.
agd5f: cire: ok
agd5f: cire: does xset dpms force off followed by moving the mouse enable both screens?
cire: at the moment both are on. I'll restart X to get one off and try it.
agd5f: cire: are both attached when you start up?
agd5f: star up X
app4des: agd5f: thx, btw, another problem that I encountered I don't know it if it radeon driver specific though. while I am in an lcd monitor with max 1280x1024, while I was changing drivers between radeon and radeonhd to test some things, the max resolution was locked to 1024x768. After doing some restarts and power off I still couldn't get the native resolution. Only after I turn off my system for 5+ minutes the native resolution was available again.
app4des: Do you know what that could be?
app4des: wtf, did that message not appear correctly or it is my client?
agd5f: app4des: looks ok
app4des: ok
cire: agd5f: restarting X (only 1 screen), then applying "xset dpms force off" now got me correct DUAL HEAD
cire: (after moving mouse)
agd5f: app4des: did ddc fail to get an edid in those cases?
cire: they are both attached all the time
app4des: agd5f, I really don't know, and I can't replicate it
agd5f: cire: ok. sounds like that commit. I don't understand why I'm not hitting it anymore though
agd5f: app4des: probably related to how the two drivers do ddc
agd5f: cire: I'll take a look
cire: thank you!
cire: for now, xset seems to be a (dirty) workaround ;)
app4des: agd5f, ok, the strange thing is that it insisted between restarts and fast power offs > on. Only after a long cooldown it was solved
agd5f: app4des: probably a gpio was in a bad state
agd5f: and it wasn't reset until the power was cut
agd5f: and the capaciters drained
app4des: agd5f, I know that something like that happened, I just mentioned it just in case
agd5f: app4des: no worries :)
kdekorte: cire, I've had to "reboot" my display on a few occasions where it starts flashing on/off every 20 seconds or so. I've seen it happen with the intel and the radeon driver, so it is not unheard of
spstarr_work: checks on airlied's progress while I slept
cire: agd5f: I am new to reporting bugs in bugzilla, but why is my attached log-file now marked as a patch?
agd5f: cire: so that I can view it as text in my browser
agd5f: it's just teh mime-type
cire: ahh, okay, I set it wrong. Sorry
agd5f: no worries
cire: shall I answer to your question? Does xset dpms....
agd5f: cire: that's ok. I put that there for others who might see the bug
cire: ok
agd5f: actully, go ahead and answer it
agd5f: so we have a reference for others
GerbilSoft: ack, i just tested out the new DynamicPM option, and it caused a very weird image onscreen
GerbilSoft: specifically, every 8 columns seemed to be duplicated into the next 8 columns, and the image was stretched out to be twice as wide as the monitor (so the second half didn't show up at all)
GerbilSoft: system is a ThinkPad T60p with M56 (FireGL V5200)
agd5f: GerbilSoft: what options did you enable?
GerbilSoft: DynamicPM
agd5f: does it help if you enabled "ClockGating" too?
GerbilSoft: this is with the latest commit (4b3a378)
GerbilSoft: let's find out
GerbilSoft: nope, ClockGating doesn't help
agd5f: GerbilSoft: did it corrupt immediately when you started X, or only when the code kicked in?
GerbilSoft: immediately when i started X
GerbilSoft: it also corrupted the console when i switched, but the corruption disappeared immediately after hitting Ctrl-C in console to kill X
agd5f: GerbilSoft: did you enable "ForceLowPowerMode"?
GerbilSoft: no, i didn't
agd5f: GerbilSoft: try commenting out line 619 of radeon_pm.c and then shutdown and reboot your laptop
agd5f: RADEONSetClockGating(pScrn, info->pm.clock_gating_enabled);
GerbilSoft: kernel panic :(
agd5f: I think you've hit something else
agd5f: this shouldn't affect the kernel at all
GerbilSoft[panic: seems that hitting ctrl-alt-backspace while testing dynamicpm causes a panic
GerbilSoft: but besides that
GerbilSoft: any other suggestions?
agd5f: did commenting out that line help?
GerbilSoft: which line
agd5f: try commenting out line 619 of radeon_pm.c and then shutdown and reboot your laptop
agd5f: RADEONSetClockGating(pScrn, info->pm.clock_gating_enabled);
GerbilSoft: ok, and then test that with what options in X enabled?
agd5f: doesn't matter
GerbilSoft: ok
GerbilSoft: testing
GerbilSoft: agd5f: didn't help
dileX: while compling latest airlied drm-radeon-kms stuff: I got following error for mesa/mesa/radeon-rewrite: /usr/include/drm/radeon_cs.h:185: error: 'RADEON_GEM_DOMAIN_VRAM' undeclared (first use in this function)
agd5f: GerbilSoft: does it work if you don't enable any of the new power options?
GerbilSoft: it works if dynamicpm is off and clockgating is on
GerbilSoft: or dynamicpm is off and clockgating is off
GerbilSoft: but not if dynamicpm is on
dileX: mesa/mesa/radeon-rewrite is (git20090412.1fd76ae)
agd5f: GerbilSoft: does dynamicpm off and forcelowpowermode on work?
GerbilSoft: let me check
GerbilSoft: er i already tested that
GerbilSoft: no, it doesn't
agd5f: GerbilSoft: can you send me your video bios?
GerbilSoft: how do i dump it?
dileX: libdrm-dev is (2.4.4+modesetting~gem+git20090414.529848c-1~dileX+1)
dileX: any idea?
agd5f: GerbilSoft: cd /sys/bus/pci/devices/
agd5f: echo 1 > rom; cat rom > /tmp/t60p.rom; echo 0 > rom
GerbilSoft: ok dumped
GerbilSoft: it's 64k
agd5f: perfect. email it to me
agd5f: alexdeucher at gmail
GerbilSoft: ok, hold on
GerbilSoft: currently running as root, need to switch users
GerbilSoft: sending
MrCooper: agd5f: so, let's try switching to EXA by default and see what happens? :)
agd5f: MrCooper: sounds good to me :)
GerbilSoft: sent
GerbilSoft: leaving now
GerbilSoft: have to go to java class :(
nanonyme: Anyone wouldn't happen to know a good EXA benchmark utility?
chithead: gtkperf? :)
nanonyme: Hmmhmm. Now just need something to compare to. :)
kdekorte: nanonyme... I have some stored here on different machines.. run it with gtkperf -c 500 -a and I can tell you how it compares to what I have
nanonyme: http://pastebin.ca/1392932 on a RadeonHD 3870.
kdekorte: nanonyme: http://pastebin.com/m4dca0d39 3650 card
kdekorte: pretty comparable numbers
kdekorte: my r500 card is on Fedora 10 is in the 140sec range
kdekorte: I expect it to go down, when I upgrade it to F11 mainly due to text handling
nanonyme: Well, I have F11. :)
kdekorte: Me too on the numbers I posted
nanonyme: Oh, right.
kdekorte: 32 or 64bit?
nanonyme: Athlon AMD64 3500+.
nanonyme: And a 64bit, yes.
kdekorte: hum... your machine should be slightly faster, what is the real clock speed of that cpu
MrCooper: kdekorte: why do you expect it to go down 'due to text handling'?
kdekorte: and what screen rez are you running at... I have dual head
kdekorte: MrCooper, doesn't the xserver in F11 have better font caching? Which is where the F10 machine is reallly slow
nanonyme: 1280x1024 single display, CPU MHz 2200.
kdekorte: Ah my CPU is slightly faster at 2.4Ghz
MrCooper: kdekorte: ah, I read 'go down' as 'become slower'
nanonyme: Yeah, I noted these tests seem to be quite CPU-intensive.
nanonyme: I had my CPU usage at 100% through the benchmarking.
kdekorte: same here
kdekorte: I'll post my r500 chip here in a sec, on a 2.17Ghz laptop
kdekorte: http://pastebin.com/m7787fbc9
kdekorte: As you can see the r500 is much slower
kdekorte: The lines being slow is what amazes me, cause I did the same test in 2008 (f9 I believe) and ht elines were only 8.66 seconds
mjg59: agd5f: Hm. You set the PCIE lanes on dynamic power?
mjg59: agd5f: Do you only go into the dynamic power mode on DPMS?
agd5f: mjg59: yeah
mjg59: Ok
agd5f: block handler check for dpms
mjg59: Ah, got it
agd5f: if you have better ideas, I'm all ears
mjg59: Well, ideally ALPM would work...
agd5f: ALPM?
mjg59: Or do I mean aspm? I always get those confused
mjg59: The one where PCIe goes into link power saving states when idle
agd5f: like acpi d-states?
mjg59: They're called l-states
mjg59: But yeah
Esmil: I saw you all running gtkperf. Here are my stats if anyone is interested: http://pastebin.com/mb2f1dfb
nanonyme: Damn those Core 2 CPU's. :P Way too fast for their own good. ;) (We also came to the conclusion that gtkperf mostly depends on CPU)
Esmil: Ahh.. I was wondering why mine was so much faster
Esmil: X1400 is r500 right?
mjg59: Yes
Esmil: Cool
Zajec: I get corruptions when using ForceLowPowerMode... is anything like that known for you?
Zajec: bottom part of cursor is corrupter, bottom part of almost every icon on desktop and part of my KDE clock
Zajec: bottom part of clock actually
arekm: is that newly merged power stuff a full power management?
Zajec: yes
Zajec: well, it isn't full
Zajec: but newly merged
Zajec: actually newly commited :)
arekm: does it give serious power saving in typical usage? like 10-15W? :>
Zajec: how can I check?
arekm: using powertop
chithead: if you have a notebook, you can find out by checking /sys/class/battery or /sys/class/power
arekm: http://www.lesswatts.org/projects/powertop/
Zajec: arekm: will try later... for now I'm sure my fan is stopped for the first time :)
arekm: I'll try now then
Esmil: Hmm.. I just installed the latest git version and enabled ForceLowPowerMode, but I get exactly the same gtkperf results..
kdekorte: Esmil, if your cpu is pegged it might be that the video card is not working that hard
Esmil: Ahh right
arekm: agd5f: would be cool if these options could be switched runtime, so - on battery: save energy, otherwise full performance
kdekorte: is an updated libdrm recommended for use with the driver in git... my r500 is really slow now
arekm: 19W with dynamicpm on and clockgating on (28W without these)
arekm: forcelowpowermode + clockgating 19-20W and a corruption
arekm: (small corruption)
Zajec: arekm: oh, so I'm not the only one with corruptions, good :)
Zajec: arekm: what is your card?
kdekorte: Without power management, I was getting corruption on r500 until I enabled compositing in metacity
kdekorte: and my r500 is way faster now with the latest drivers.. gtkperf -c 500 -a went from 170 to 49
arekm: Zajec: mobile hd 3400
Roberth1: hello Ive been having som issues with dual monitor setup and resolution on my tv after 6.12.2
Roberth1: first of all, 1360x768 is the resolution my tv uses
Roberth1: BUT
Roberth1: when I apply that resolution to the tv, it doesnt appear correct, some of the screen is going beyond the display border
Zajec: arekm: same in my case
arekm: Zajec: but dynamicpm and clockgating worked without corruption and gave +- the same power usage
Zajec: didn't test that yet
Zajec: will experimet later
Roberth1: and I revert back to 6.12.1 and every thing works as it should
Roberth1: and I can get dual monitor setup working on 6.12.2, if I enable both my tv and my monitor, monitor wont get any picture and my tv's resolution doesnt appear correctly
nanonyme: Hmm, is that power management thing only relevant to pre-r600 cards?
Zajec: nanonyme: no
Zajec: nanonyme: R1xx-R7xx
Zajec: it works fine with M82 :)
Zajec: well, almost... some little corruptions visible
nanonyme: Right right.
agd5f: arekm: problem is there's no dynamic driver attribute system. you could hack something up with randr, but it'd be a hack
agd5f: arekm: I hope to make it more dynamic in the drm
agd5f: and expose stuff via sysfs
agd5f: for those of you with corruption with ForceLowPowerMode, you might want to try increasing the number of pcie lanes in the low power mode
kdekorte: I got dynamicPM enabled on my r500 and I have the picture double wide seems like bands of 8 are duplicated
Zajec: agd5f: but ideally it should work with 2, right?
Zajec: there is some little bug still in code, am I right?
arekm: agd5f: is there anything else that's missing from complete power management on radeons now? (aka, improvement is huge (cool!) but still far from integrated gpus)
Zajec: agd5f: should value be power of 2?
kdekorte: for the power management to work should we be using libdrm master or r6xx-r7xx-support?
Zajec: kdekorte: sounds like weird dependenct
aneas: my xserver crashes when i activate SWCursor. log with SWCursor on: http://pastebin.com/m66d8ae6b log with SWCursor off: http://pastebin.com/ma207861
aneas: i dont expect help, just wanted to tell someone :)
agd5f: Zajec: yeah
agd5f: kdekorte: it's be in the kms code when it's implemented
agd5f: arekm: there's lots of stuff, unfortunately, powermanagement is probably the most complex and trickey part of the chips
spstarr_work: agd5f: your PM code is for r3xx+?
agd5f: spstarr_work: r1xx-r7xx
spstarr_work: oh nice work!
spstarr_work: looks at cgit for your changes
nanonyme: Too bad it won't probably get to Fedora 11. :)
spstarr_work: agd5f: this is in the drm or ddx?
spstarr_work: nanonyme: but i'll be onto rawhide (Fedora 12) anyway
nanonyme: Sure.
agd5f: spstarr_work: ddx
spstarr_work: F11 is just a temporary 'stable' usable env
spstarr_work: ok
spstarr_work: found http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/
spstarr_work: looks
nanonyme: spstarr_work: Will just take a while until Rawhide will start rolling again, right? (I thought it's now in a slow changing state until release)
spstarr_work: nanonyme: well once F11 is frozen they branch it off rawhide, and rawhide becomes 'F12'
spstarr_work: right now its still F11
spstarr_work: i think, i dont see f12 packages coming down the pipe yet
nanonyme: Hmm, right.
spstarr_work: they are in koji however
Zajec: agd5f: you left some garbish
Zajec: radeon_pm.c:79: warning: ‘RADEONSetMemoryClock’ defined but not used
Zajec: or... on purpose? to be used later?
agd5f: Zajec: used later
nanonyme: spstarr_work: Hrm, I also heard that during a release everyone using Rawhide will be forced to the new release and you have to manually go back to Rawhide. :)
Zajec: so current ForceLowPowerMode doesn't touch memort clock?
agd5f: I didn't mess with teh memory clock this time around
Zajec: ok
spstarr_work: nanonyme: when fedora-releases it usually switches you off rawhide
spstarr_work: yes
spstarr_work: so you get off the exit in a highway :)
kdekorte: yeah, DynamicPM seems to be borked on r5xx at least with my setup
spstarr_work: fedora-releases RPM even
Zajec: increased lanes to 2^2
agd5f: messing with the memory clock is a lot more complex
spstarr_work: nanonyme: this is done for safey, so your machine 'becomes' F11 effectively
nanonyme: Yeah. :)
GerbilSoft: agd5f: any luck with the vbios?
nanonyme: It's imo quite okay.
spstarr_work: and usually during early rawhide.. you dont want to use F12 yet...
spstarr_work: but it all depends on what people decide they want to blow up/break ;)
Zajec: 4 lanes, no corruption
kdekorte: Zajac, how do you set the lanes?
Zajec: manually in code
Zajec: hard-coded other value
Zajec: checkout RADEONPMInit in radeon_pm.c
Zajec: easy to understand code
Zajec: (4 places of setting lanes)
Zajec: but I think fan is working faster now... ;/
Zajec: still slower that without PM of course
spstarr_work: isn't it nice to see PM support and glisse's GPU reset support coming too
spstarr_work: :)
spstarr_work: the puzzle pieces begin to reveal a beautiful picture
Zajec: GPU reset? what do you mean?
spstarr_work: (a 3D AMD logo) ;)
spstarr_work: Zajec: if the GPU wedges the (DDX) can reboot the video without killing X
agd5f: GerbilSoft: not yet
GerbilSoft: agd5f: k
GerbilSoft: it's probably a memory clock issue
Zajec: spstarr_work: funny :)
agd5f: GerbilSoft: not touching the mclk yet
spstarr_work: Zajec: thats such a good thing
GerbilSoft: oh? then it's something else
GerbilSoft: but whatever, i have next to no experience in video driver development :P
kdekorte: ok, I found this to be interesting... r500, if I use libdrm master and xorg-x11-drv-ati master I get corruption when not using composite
Zajec: spstarr_work: yeah, for developers, i'm sure it is
spstarr_work: Zajec: it means two things, we can get crash dumps easier too
kdekorte: if I switch to libdrm r6xx-r7xx-support branch and recompile -ati the corruption goes away
spstarr_work: Zajec: and users!
agd5f: GerbilSoft: try replacing line 631 with info->pm.mode[1].sclk = 12900;
GerbilSoft: i'll try that out in a bit
GerbilSoft: doing other stuff right now
Zajec: spstarr_work: can help with dumping crashlog? interesting
spstarr_work: Zajec: well, if your system wedges, the logs might not be written to disk
agd5f: GerbilSoft: you might also try repalcing line 633 with info->pm.mode[1].pcie_lanes = 16;
spstarr_work: assuming you totally lose control and cant even do sysctl magic to sync disk
agd5f: in case the pcie lane changes is what's causing the problem
GerbilSoft: ok
GerbilSoft: i'll try that out in a bit
spstarr_work: agd5f: ForceLowPowerMode could this not be a dynamic option you can turn on/off?
spstarr_work: so PM tools can use this for aggressive PM savings?
spstarr_work: oh
spstarr_work: DynamicPM
agd5f: spstarr_work: there's no dynamic driver attribute interface at the moment in X
agd5f: you could hack randr, but it's not not really related
spstarr_work: oh
Zajec: i hate that... now I have to use both at same time: radeonhd for HDMI and radeon for PM :|
kdekorte: agd5f, what is the difference between sclk and mclk?
agd5f: kdekorte: sclk is the gpu clk, mclk is the memory clock
kdekorte: agd5f, I'm messing with the dynamicpm on r5xx and so far I can switch the lanes to 1, but the m and s clks are still in high mode
agd5f: kdekorte: adjusting mclk is a lot more complex as you have to factor in bandwidth requirements (displays, drawing engine, overlays, etc.), and change it very carefully lest you lock chip
mjg59: agd5f: Yeah, do we have anything on bandwidth calculations?
agd5f: mjg59: yeah just found some stuff yesterday
kdekorte: agd5f, well sclk is the ones that seems to give the double bands on r5xx
agd5f: kdekorte: chip may not like certain frequencies
kdekorte: I'm just removing the / 4 at this point
kdekorte: I have not tried any other values
agd5f: kdekorte: do you have a t60?
kdekorte: agd5f, yup
kdekorte: t60p
agd5f: kdekorte: try 12900 for sclk
kdekorte: ok
agd5f: or 21000 or 32400
kdekorte: better, but not correct
kdekorte: agd5f, 21000 seems ok
agd5f: kdekorte: ok, I suspect the gpu likes certain divider combinations better than others. I should probably stick to the ones in the bios tables.
kdekorte: with DynamicPM I'm maybe saving two watts
GerbilSoft: agd5f: going to try out sclk now
GerbilSoft: also for reference, my LCD's 1600x1200
agd5f: GerbilSoft: you might try 21000 and 32400 too
GerbilSoft: ok
GerbilSoft: i'll try 12900 first
kdekorte: agd5f, the screen on my laptop is 1600x1200
agd5f: kdekorte: ok cool, looks liek you and GerbilSoft have the same laptop
GerbilSoft: ok, 21000 works (with 1 PCIe lane, too)
GerbilSoft: i did get another kernel panic though - warn_slowpath() was the top function, then write_vga()
GerbilSoft: (this was after killing X)
agd5f: GerbilSoft: I think that's something else
GerbilSoft: ok
GerbilSoft: probably is
GerbilSoft: i got that panic even with dynamicpm disabled
GerbilSoft: restarting x, brb
GerbilSoft: ok
GerbilSoft: 12900 was better than the default, but still had some artifacting
GerbilSoft: 21000 works perfectly
agd5f: GerbilSoft: cool
kdekorte: Oh, I was gonna ask GerbilSoft what branch of libdrm he was using
tormod: agd5f: I just tried latest git on my M26 (Acer TravelMate 8100) and it froze badly
tormod: I suspect the power changes. any known issues?
agd5f: tormod: any options enabled?
tormod: no
agd5f: tormod: try commenting out line 619 of radeon_pm.c
agd5f: RADEONSetClockGating(pScrn, info->pm.clock_gating_enabled);
tormod: ok will do
tormod: agd5f: ok it helped. now X starts, but the laptop freezes solid when I switch VT
Roberth1: where do I report bugs fro xf86-video-ati?
tormod: Roberth1: bugs.freedesktop.org
agd5f: tormod: comment out the RADEONSetClockGating() calls in RADEONPMEnterVT() and RADEONPMLeaveVT() and RADEONPMFini()
agd5f: in radeon_pm.c
tormod: thanks
agd5f: tormod: I'll commit a fix
Roberth1: how do I specify which version of the driver?
agd5f: Roberth1: just mention it in the comments
Roberth1: okay
tormod: agd5f: success, thanks
agd5f: kdekorte: does sclk/2 also work?
agd5f: info->pm.mode[0].sclk / 2
kdekorte: I didn't try it...
kdekorte: would you like me to?
agd5f: kdekorte: if you could
kdekorte: give me a couple mins
agd5f: no problem
kdekorte: agd5f, actually I have a large download going... so gonna be about 30 mins
agd5f: kdekorte: no worries. whenever you get a chance
kdekorte: agd5f, is there a way to compile mesa so that it doesn;t use DRI2?
nanonyme: Is it still *that* unstable? o.O
kdekorte: no, I don't have the prereqs installed to compile mesa with dri2proto so by upgrading my driver and libdrm I lost 3d
nanonyme: Eek, that's not fun. :/
agd5f: kdekorte: it shouldn't use if it the driver doesn't support it
kdekorte: Well I can't compile mesa... and I can't see how to turn it off
kdekorte: it fails with an error that DRI2PROTO 1.99.3 is not found, I have 1.99.1
kdekorte: agd5f, just an FYI that sclik / 2 seems to work ok
agd5f: kdekorte: cool. thanks!
kdekorte: agd5f, does the card startup in low power mode and get switched to high.. is so I think you should reverse that
agd5f: kdekorte: should start out in default power state
agd5f: kdekorte: I think we either need to step down gradually to a lower state, or there is something about sclk/4 that the engine doesn't like
kdekorte: I enabled EXA and it made performance go to hell
agd5f: kdekorte: what option? forcelowpowermode or dynamicpm?
kdekorte: I don;t thinkn that either of those matter, but I'm using dynamicpm
agd5f: ok
kdekorte: I;m on Fedora 10 (Xserver 1.5.3)
kdekorte: and I think that is part of my problem
kdekorte: I upgraded libdrm, the linux-core stuff and the ati driver
kdekorte: Ah... now I got it working good, had to add "nomodeset" to my kernel
kdekorte: even got xv and 3d back
bug1: Hi all, is this channel for radeonhd as well ?
MostAwesomeDude: #radeonhd
bug1: k, thanks
spstarr: hello airlied
agd5f: MostAwesomeDude: so only thing left for Xv stuff is integration with bicubic
MostAwesomeDude: agd5f: Right.
MostAwesomeDude: I'm still thinking that super shaders are the way to go.
agd5f: yeah, just gotta merge the two shaders
agd5f: shouldn't be too hard
agd5f: I'm tempted to merge the current code since it adds xv attributes like brightness and hue, etc.
MostAwesomeDude: Yeah, which is quite nice IMO.
agd5f: but it can get a bit confusing when switching between bicubic and non-bicubic since the attributes only apply to the non-bicubic output
onestone: agd5f: isn't it possible to convert the resulting bicubic filtered RGB pixel to HSV then change brightness hue or saturation and then convert it back to RGB
agd5f: onestone: I was thinking of just doing the csc first then doing the filter on the results
MostAwesomeDude: onestone: The easier thing to do is do YUV->RGB with attribs and then bicubic on the results.
agd5f: onestone: btw, if you are interested: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=tex_vid2
onestone: agd5f: do we get filtered yuv values?
agd5f: onestone: what do you mean?
onestone: agd5f: bilinear interpolated
agd5f: yeah
MostAwesomeDude: IIRC the texture samplers don't really care about the pixel formats.
MostAwesomeDude: So YUV gets sampled with filter same as RGB.
agd5f: yeah
agd5f: for planar we just treat it as 3 A8 textures
onestone: ok. It quite cheap on the instruction level so if you place it at the right positions you should have almost no performance inpact because of the 1:4 (or 8?) TEX:ALU ratio
MostAwesomeDude: Right.
agd5f: for packed we use the native packet format textures, but we could also use an 8 and 8_8 textures
agd5f: er 8_8_8_8 and 8_8 textures
agd5f: like in the r6xx/r7xx code
airlied: christ fast user switching is nice when it goes fast
spstarr: heh
onestone: agd5f: to you know how fast 3 A8 lookups are compared to one YUV->RGB lookup?
agd5f: onestone: not offhand
onestone: agd5f: because with bicubic we would endup in 14 tex instructions, and this could get really slow if the A8 lookups are not fast
agd5f: why do we need so many?
onestone: agd5f: bicubic needs 2 helper tex lookups and 4 video tex lookups = 2 + 3 x 4 for the yuv case
agd5f: wow
onestone: agd5f: and each video tex lookup is bilinear filtered = 16 pixels get combined into 1 resulting bilinear filtered pixel
spstarr: moar features
agd5f: onestone: I guess we'll have to try it and see how it performs
onestone: agd5f: is there a way to detect that rendering is to slow and automatically disable bicubic in this case?
spstarr: airlied: when are you planning to sync ddx in git with fedora? or is those features for F12?
airlied: spstarr: which features?
spstarr: PM
spstarr: airlied: agd5f has been very busy :)
airlied: well we ship kms
airlied: spstarr: so they don't really help
spstarr: hmm
airlied: for f12 I want r600 kms as well by default
spstarr: so all this PM stuff in DDX has to be reimplemented for kms?
spstarr: for the drm driver
airlied: yes
spstarr: doh
spstarr: I guess however, because he has all the registers setup, most of this can be dropped into kernel with changes
airlied: we can do a lot better pm in the kernel
airlied: since it has a better view of things
spstarr: true, but there's still register specific stuff for the gpus
airlied: mjg59 had some dynamic PM attempts in F-11 at one point
airlied: it clocked the gpu up/down when stuff was drawing
airlied: just needed more complicated code to work out the minimum clocks it needed for scanout
spstarr: I see
airlied: but I probably won't ship userspace PM until its been in git a few more days :)
spstarr: but it can't cook if nobody tests it ;)
airlied: well F11 is frozen, F12 isn't being built
airlied: so nobody can test it anyways
spstarr: hmm, only bug fixes for F11 then?
spstarr: airlied: how goes your AGP woes on the T42?
airlied: spstarr: it went somewhere else :(
spstarr: the T42?
spstarr: (so soon?)
airlied: someone dropped their laptop somewhere.
spstarr: not good...
spstarr: airlied: hmm, can it be fixed or is it dead, dead
airlied: spstarr: well I can probably get it back when they get a replacement for their laptop
airlied: just not sure how long that will take
spstarr: hmm, airlied it might be a good idea to disable kms for RV350 and or other AGP then for F11?
spstarr: then for F12 turn it on once that bug is figured out
airlied: spstarr: does bad things happen in pcimode?
spstarr: i can give it ago
spstarr: radeon.agpmode=0 ?
spstarr: testing...
manpoole: okay just wondering before i go to 9.05 of ubuntu how is the ati 1650 playing with the new xorg?
manpoole: 9.04
spstarr: [ 1.590984] [drm] Forcing AGP to PCI mode
spstarr: ok let's see
spstarr: i am in XRender right now (OpenGL with kwin still fails)
spstarr: trying to get the corruption to happen now
manpoole: okay just wondering before i go to 9.04 of ubuntu how is the ati 1650 playing with the new xorg?
MostAwesomeDude: manpoole: Same as before.
spstarr: MostAwesomeDude: should i test the gallium driver yet?
spstarr: i can build it
MostAwesomeDude: spstarr: If you like, but be prepared for disappointment. :3
manpoole: is there flickering in opengl apps while running compiz?
spstarr: i'll wait then :)
MostAwesomeDude: spstarr: Actually, now that I think about it... It should be stable enough to not lockup on most of the mesa test apps.
MostAwesomeDude: It's still not rendering a lot of things right, but it's getting there.
spstarr: airlied: *no* corruption so far
spstarr: tries compiz
spstarr: hmm i crashes DRI driver
spstarr: switching from XRender (kwin) -> compiz-gtk initially
spstarr: 3: /usr/lib/dri/r300_dri.so(radeonDestroyBuffer+0x34) [0x239c7d]
spstarr: 4: /usr/lib/dri/r300_dri.so(radeonDestroyContext+0xf4) [0x25b3a8]
spstarr: 5: /usr/lib/dri/r300_dri.so [0x233e82]
spstarr: 6
spstarr: but X restarted and i tried again, it was ok.. let's see how compiz holds up with PCI mode
airlied: spstarr: yeah just fixinf that
spstarr: oh :)
spstarr: tries a VT switch
spstarr: :)
spstarr: airlied: X is using < 12% cpu , we're accel
spstarr_home: i'll wait.. now i can't enable it without locking up or X dying
spstarr_home: dri: attempt to actually refcount the __DRIDrawable
dileX: airlied: can you have a look into
airlied: dileX: you installed libdrm_radeon branch + header files?
dileX: airlied: I have built against libdrm-dev (2.4.4+modesetting~gem+git20090414.529848c-1~dileX+1)
dileX: airlied: wrong GIT-branch of libdrm? yes, libdrm-dev is installed
airlied: it looks like a wrong radeon_drm.h
dileX: OK, I compare the one from libdrm-source with the one in /usr/src/include
dileX: linux-core?
dileX: $ find libdrm-2.4.4/ -name radeon_drm.h
dileX: libdrm-2.4.4/linux-core/radeon_drm.h
dileX: libdrm-2.4.4/bsd-core/radeon_drm.h
dileX: libdrm-2.4.4/shared-core/radeon_drm.h
dileX: grr, symlinks
dileX: the radeon_drm.h differ
dileX: airlied: thx