Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-16

Search This Log:


airlied: okay all the fixes should be in drm-radeon-next
airlied: I've pushed hdmi audio to Linus as well, so please test and report and serious issues in it
cxo: does that include the allocate bug?
cxo: you mean drm-core-next
cxo: nvm needed refresh
dileX_: hmm, v5 of Zajec's pm-patch hangs here on rv515
dileX_: mjamm drm-linus
soreau: MostAwesomeDude: I just finished updating everything, booted into latest drm-radeon-testing kernel and I still get the "radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed." message. Strangely, it does not give the message on first fail (since the radeon kernel module is loaded ?), just fails silently, then second time and all times thereafter gives this message
soreau: Not sure if that has to do with anything (doesn't give the message first time running neverball after reboot) but figured I'd relay my observations
cxo: lane
cxo: just built the entire stack
cxo: didnt airlied work on the fix
Nightwulf|work: hi all
dileX_: hi Nightwulf|work
Nightwulf|work: hi dileX_
Droste: anyone awake?
airlied: cxo: drm-radeon-next or -testing should have all the fixes
dileX: drm-linus: patch-series and single-patch (for 2.6.33)
airlied: make suer you have the latest one, it takes a few mins to mirror out
Droste: http://pastebin.com/m5418bc47 <-- just got this kernel bug. latest git libdrm, mesa, ddx and latest drm-next kernel
airlied: shoudl be fixed in drm-radeon-next, i need to regenerate drm-next
Droste: ok :-)
dileX: Droste: had that error too - fixed in latest drm-2.6 GIT branches
Droste: is it worse to use atom bios? because i just checked whether it is used or not and "cat /sys/module/radeon/parameters/r4xx_atom" is set to 0 (radeon x850pro r420)
airlied: Droste: if stuff works without it, then no need to use it
airlied: on r4xx we only need it for one or two things
Droste: ok, so nothing to be worried about. good :-)
dileX: drm-linus: single patch against vanilla 2.6.32
DanaG: interesting... just did hwinfo --framebuffer on my r350... and of course, it calls the thing... "ATI R350".
Zajec2: wohoo
Zajec2: i've been experiencing some random rare locks ups with KMS
Zajec2: not possible to debug due to being rare
Zajec2: and now I've find someting that triggers lockup in few minutes :)
DanaG: hmm, could you leave a serial console open on the thing?
dileX: [07:31:15] hmm, v5 of Zajec's pm-patch hangs here on rv515
dileX: Zajec2: ^^
Zajec2: DanaG: yeah, but i guess i would need to have console running with maximum drm debug for hours (day?)
Zajec2: oh...
DanaG: ATI FireGL unknown (R423) UR (PCIE),
DanaG: ATI FireGL unknown (R423) UT (PCIE),
DanaG: unknown? weird.
DanaG: those are among the reported supported cards.
DanaG: interesting... man pages still say XAA is default for radeon.
Zajec2: dileX: what's last working version of patch?
DanaG: hmm, and I never did find out very well what "backingstore" is.
Zajec2: dileX: did any work on you finally?
Zajec2: *for you
MostAwesomeDude: DanaG: Backing store is an optimization similar to the builtin optimizations of compositing, but in a non-composited environment.
MostAwesomeDude: Ignore it
DanaG: ah, so irrelevant if composite is enabled, anyway? cool.
dileX: Zajec2: v4 is OK, but no up-/down-clocking. changes in r100.c regulates pm also for rv515?
Zajec2: dileX: no really...
Zajec2: dileX: let me check...
dileX: (reboot)
DanaG: wow, this is just classic:
DanaG: RandR 1.2 enabled, ignore the following RandR disabled message.
DanaG: RandR disabled
DanaG: heh, I'd think it'd be more elegant to have it not print the second line at all. Or at least change it: xrandr 1.1 disabled; superseded by driver.
Zajec2: dileX_: ok, it depends on mode_fixup your gpu is using
Zajec2: trying to find it...
dileX: Zajec2: booted into drm-linus kernel. will apply v5 in build-dir and re-compile radeon k-m
Zajec2: dileX: ok, i now see legacy modesetting is used when chipset is not AVIVO...
Zajec2: just let me check AVIVO condition
Zajec2: er, not reall
Zajec2: sec
Zajec2: ok, now I'm sure... when rdev->bios && rdev->is_atom_bios, then legacy *is not* used
Zajec2: dileX: so V4 vs. V5 should not change anything for you
Zajec2: ah moment... irqs!
Zajec2: i thought about mode fixup only
dileX: V5 let hang system when radeon is loaded with kms/dynclks
dileX: could enable drm-debug and look
Zajec2: yeah, i've modified rs600.c to callback and actually *do* reclock work
Zajec2: before that patch it was not working for you
Zajec2: calling from IRQ
dileX: test v5 with drm-linus (reboot)
Zajec2: thanks
Zajec2: dileX_: are you here? could you eventually test http://estudent.put.poznan.pl/rafal.milecki/do.not.really.reclock.patch ?
ernstp: with firefox 3.5 on linux I get ~3 fps here http://alteredqualia.com/visualization/evolve/
ernstp: top shows the xserver at 75% cpu at the same time
ernstp: it must be doing something stupid, like reading pixels from the framebuffer, right?
dileX_: Zajec2: debug.txt: http://pastebin.ca/1716790
DanaG: oh yeah, it seems r350 does not do dynamic clocks at all.
DanaG: Even in Windows, I believe.
ernstp: it's really fast with shadowfb
DanaG: Considering the age, I wouldn't expect it to.
DanaG: I get 11.4 mutations per second.
ernstp: DanaG, using kms?
ernstp: I get abuot 30-40 fps in Windows with Firefox 3.5 so there's definitively something wierd going on
ernstp: and 75% xorg cpu point to graphics
ernstp: might not be anything the radeon driver can do about it though
DanaG: that's "mutations per second"; not sure about frames per second.
DanaG: The hardware I'm on right now: Athlon XP 2.2GHz, Radeon 9800 Pro.
ernstp: DanaG, right, I'm talking about mutations per sec also
ernstp: DanaG, are you using KMS? Compiz?
DanaG: Yes to both.
DanaG: What image? Default Mona Lisa one?
ernstp: yes
dileX_: Zajec2: trying patch
hifi: 3.5 mps
hifi: firefox 3.5, ubuntu, compiz, kms
hifi: and some crappy X1550
ernstp: right, same setup as me
ernstp: except I have a 4770
ernstp: you also have high xorg cpu usage?
ernstp: hifi: ^
hifi: yeah
hifi: 90 something percent
hifi: on chromium it's super fast
ernstp: yeah, I get 60 fps :-)
hifi: 109 mutations per second
ernstp: nice
DanaG: weird... for me, it claims to be drawing... but is being just white, and not actually making visible progress.
ernstp: DanaG, which browser?
DanaG: # Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7pre) Gecko/20091215 Ubuntu/10.04 (lucid) Shiretoko/3.5.7pre (.NET CLR 3.5.30729)
DanaG: 50% cpu usage by Xorg; 30% by firefox.
DanaG: +/- 10 on each.
dileX: Zajec2: with your last patch no hanging while loading radeon w/ dynclks
Zajec2: dileX: ok, then my design looks more alright...
Zajec2: just AtomBIOS call causes problem, hmm...
Zajec2: dileX__: could you show dmesg | grep drm?
dileX: Zajec2: but no upclocking w/ glxgears (but that was expected)
Zajec2: dileX: you have to get downclocked first and i think even that didn't happen :)
dileX: Zajec2: dmesg:
dileX: might be
Zajec2: dileX: let me think...
Zajec2: dileX: big thanks for your testing :)
dileX: n.p.
Zajec2: dileX: did you ever tried LowPowerMode with radeon/radeonhd?
dileX: LowPowerMode? how to try that?
DanaG: Disable kms and add ForceLowPowerMode to xorg.conf.
Zajec2: it's not non-KMS xorg.conf option
DanaG: er, double-negative slip there.
Zajec2: DanaG: yeah, thanks, *Force*....
dileX: which section in xorg.conf
Zajec2: Device
Zajec2: Section "Device"
DanaG: Option "ForceLowPowerMode" "on"
Zajec2: DanaG: ++
DanaG: there's also
DanaG: Option "ClockGating" "on"
DanaG: not sure what that does.
dileX: hmm, I have...
Zajec2: DanaG: it makes hardware disable unused hardware blocks
dileX: Option "DynamicClocks" "on"
DanaG: weird... didn't the name of that thing change, or something?
hifi: dileX: it seems to break if you change images
Zajec2: er, not sure about DynamicClocks...
hifi: I menat DanaG
dileX: $ grep ForceLowPowerMode /var/log/Xorg.0.log
dileX: (WW) RADEON(0): Option "ForceLowPowerMode" is not used
soreau: MostAwesomeDude: FWIW, I get the same message on some xscreensavers like pipes for one
Zajec2: dileX: it's non-KMS only
dileX: ah OK
Zajec2: radeon.modeset=0
DanaG: http://pidgin.im/shared/img/logo.pidgin.png
DanaG: try that.
dileX_: # grep -i power /var/log/Xorg.0.log
dileX_: (**) RADEON(0): Option "ForceLowPowerMode" "on"
dileX_: (II) RADEON(0): Dynamic Power Management Disabled
dileX_: (II) RADEON(0): Force Low Power Mode Enabled
dileX_: (II) RADEON(0): Power Mode Switch
dileX_: (II) config/udev: Adding input device "Power Button" (/dev/input/event5)
Zajec2: hm, so it seems to be working with ddx... weird
Zajec2: at least we know it can be achieved and I've some bug in patch...
Zajec2: dileX: could you try http://estudent.put.poznan.pl/rafal.milecki/downclock.once.patch
Zajec2: 1) on top of previous OR
Zajec2: 2) with dynclks=0
dileX: try with dynclks=0 - in KMS?
Zajec2: yes
Zajec2: this new patch with dynclks=0 in KMS
dileX_: Zajec2: dmesg (modeset=1 and dynclks=0) (hmm, without new patch)
Zajec2: dileX_: it looks alright
Zajec2: [drm] radeon: power management initialized
Zajec2: but not enabled
MostAwesomeDude: airlied: Wrapping the fence_ring_emit with RESYNC seems to work; Fx hasn't caused a lockup yet.
MostAwesomeDude: I'll leave it on overnight to be sure.
dileX_: Zajec2: trying now with downclock.once.patch
Zajec2: dileX_: ok, but please use dynclks=0 with this new
airlied: MostAwesomeDude: keep smashing it
airlied: if it lasts longer, send the patch
MostAwesomeDude: Gladly.
DanaG: Oh yeah, it would be nice enough even having just downclock-once for now, in the to-be-upstreamed stuff. If it can be stable.
airlied: I'm sorta tempted to take a patch that'll let you do dynamic force low power mode in debugfs
Zajec2: DanaG: don't worry, I believe we will get stable dynamic reclocking soon :)
Zajec2: dileX_: ? :)
DanaG: Bonus points if you add a way to say, "when on battery, don't upclock".
airlied: it might give the dual-head ppl something to playwith
dileX_: Zajec2: dmesg
DanaG: Or rather, have a way to say "don't upclock"... but leave the "when on battery" bit to userspace.
dileX_: (modeset=1 and dynclks=0)
Zajec2: dileX_: no crash?
dileX_: no
Zajec2: dileX_: cat radeon_pm_info please
dileX_: # cat /sys/kernel/debug/dri/0/radeon_pm_info
dileX_: state: RADEON_PM_STATE_DISABLED
dileX_: default engine clock: 392000 kHz
dileX_: current engine clock: 337500 kHz
dileX_: default memory clock: 300000 kHz
dileX_: current memory clock: 297000 kHz
Zajec2: ok, so it works
Zajec2: that means we do something wrong when calling radeon_set_engine_clock in queued work handler
Zajec2: airlied: is AtomBIOS parser/executer thread safe?
airlied: if I had to guess I'd say not ;-)
Zajec2: i guess we may try to execute two commands at same time in dileX_ case
Zajec2: problaby in every case, but maybe I've more luck about time
Zajec2: too bad I don't have locking machine :/
dileX_: Zajec2: needs changes in rv515.c?
Zajec2: at least I've good tester :)
Zajec2: dileX_: it my suspection it right, we need change in atombioc
airlied: Zajec2: yeah probably should use a mutex around it,as long as we call it in a process context
dileX_: Zajec2: earned half of a breakfast?
dileX_: (afk)
Zajec2: :)
Zajec2: hm, it has some struct atom_context *ctx
MrCooper: MostAwesomeDude: it should really only be necessary once when starting the CP
Zajec2: but maybe atombios commands are not supposed to be run parallelly
mrmcq2u: how do I check to see if kms is enabled?
dileX: dmesg | grep -i kms
dileX: dmesg | grep -i "kernel modesetting"
dileX: [drm] radeon kernel modesetting enabled.
dileX: [drm] radeon: Initializing kernel modesetting.
mrmcq2u: [ 11.785980] [drm] radeon defaulting to kernel modesetting.
mrmcq2u: [ 11.785987] [drm] radeon kernel modesetting enabled.
mrmcq2u: [ 11.792748] [drm] radeon: Initializing kernel modesetting.
mrmcq2u: So it wasn't enabled but now it is?
mrmcq2u: and dri2?
dileX: mrmcq2u: you need more then drm-radeon-kms enabled kernel
dileX: libdrm with libdrm_radeon created
dileX: ddx 6.12.99 from git
dileX: and xorg-server >= 1.6.2 IIRC
mrmcq2u: using lucid
dileX: lucid? ubuntu upcoming release
dileX: there is a special repo called xorg-edgers IIRC which has latest radeon WIP development stuff for ubuntu
mrmcq2u: not sure whether its a good idea running xorg-edgers on a development release
dileX: both are WIP :-)
dileX: mrmcq2u: there is a build-howto (see topic) explaining how to get involved in radeon WIP development
Zajec2: dileX: it's more complex :|
dileX: hehe
Zajec: dileX: we have wrong design related to AtomBIOS :|
dileX: currently, I excluded radeon pm patch from my patch-series
Zajec: we call AtomBIOS commands from functions that are atomic... and we never know when AtomBIOS will decide to sleep: http://estudent.put.poznan.pl/rafal.milecki/dmesg.mutex.lock.fail.log
Zajec: and as well i can not use mutex for it ;/
dileX: yeah, this x1300 is a real special hardware one. I was able to fix with one grub-dev finally my graphical boot-menue issue. looks now sexy to see a background wallpaper in grub2.
dileX: maybe, you ask agd5f later
Zajec: yeah, when he will be around
dileX: agd5f reads backlog
Zajec: agd5f: we need mutex for AtomBIOS as we can call clocks setting functions from async work handlers
Zajec: agd5f: so I added mutex to AtomBIOS, but it seems to be invalid
Zajec: agd5f: it seems we call AtomBIOS in some atomic: http://estudent.put.poznan.pl/rafal.milecki/dmesg.mutex.lock.fail.log
Zajec: agd5f: we should do so as we never know if AtomBIOS will decide to sleep
Zajec: agd5f: any idea?
dileX: Zajec: maybe its a good idea you offer your patch to see ppl how you wanted to implement mutex-for-AtomBIOS?
Zajec: dileX: probably it is :) http://estudent.put.poznan.pl/rafal.milecki/atombios.mutex.patch
Zajec: agd5f: http://estudent.put.poznan.pl/rafal.milecki/atombios.mutex.patch
zhasha: eosie: ping
zhasha: MostAwesomeDude: ping?
zhasha: I feel strangely alone now
dileX: Zajec: this patch running on your r600(?) or you need no additional patch?
dileX: (I mean its rv515 or r500 specific)
marcel_: hi. is the radeon driver able to manage a triplehead setup with two graphiccards?
Terman: just a short question regarding the autofoo option --...-experimental api: with radeon leaving staging in 2.6.33 (IIRC), is it still considered experimental?
adamk: Terman: Apparently it is :-)
adamk: Terman: Most development seems to focus on KMS these days, though.
Terman: adamk: never underestimate the lazyness to change something as unimportant as a configure option ;-)
Zajec: dileX: pm patch works for me fine for days
Zajec: (weeks?)
evil_core: Zajec: Can I use less power on r500?
evil_core: I am not using KMS, but all pm settings to radeon are set in /etc/X11/xorg.conf
Zajec: evil_core: you can test, but we have some known issue
Zajec: I think i know what is this
Zajec: but not sure how workaround/fix it
Zajec: let me listen agd5f's opinion
TBBle: The radeon experimental API in libdrm hasn't changed in a fair while, as far as I know. 2.4.13 or so, according to the Debian packaging anyway.
MrCooper: airlied: I presume you're aware it might be tricky/ugly to preserve libdrm_radeon ABI if the API exposes internals as it currently does?
octe: i/wind21
toee: yes
toee: i have a problem with radeon KMS. until recently gtkperf would take 5 or 6 seconds to complete. now it is absolutely glacial and takes like 20 seconds
toee: i'm using git master of xf86-video-radeon and libdrm, and drm-next of kernel
TBBle: I was actually wondering, is the libkms thing I saw floating around earlier intended to generically wrap-up and replace the libdrm_vendor libs? Unless I didn't see it in libdrm, but somewhere else, and am confused...
glisse: MrCooper: what internal get used ?
MrCooper: struct radeon_cs e.g.
Zajec: glisse: could you check history for my AtomBIOS atomicy problem?
glisse: i guess we should add inline accessor function
Zajec: glisse: (mutexes, atomic, pm)
Zajec: today
MrCooper: e.g. MAX_SPACE_BOS can't be changed without breaking ABI
Zajec: wrote it on IRC
glisse: Zajec: we should not call atombios from atomic path
MrCooper: glisse: inline functions would still make the users depend on internals
BioTube: they'd need to be inlined at linktime to avoid that issue
MrCooper: doesn't even help
MrCooper: the point of an ABI is that you can replace one part without touching the other
MrCooper: and ABI breaks are a packager's nightmare
mwk: what is R700_rlc.bin and why isn't it in drm-radeon-next?
BioTube: mwk: firmware for the interrupt controller and the kernel's stopped accepting new firmware
mwk: so where do I get that?
mwk: or, alternatively, why not finding R700_rlc.bin == a nice backtrace in logs?
glisse: mwk: shouldn't happen with lastest drm-radeon-testing
BioTube: mwk: you can find the firmware here: http://marc.info/?l=dri-devel&m=125960757404659&w=2
mwk: glisse: my dmesg disagrees :/
glisse: mwk: pastebin
mwk: 0x04.net/~mwk/dmesg.txt
mwk: be warned: it's quite a crazy configuration.
Zajec: glisse: http://estudent.put.poznan.pl/rafal.milecki/dmesg.mutex.lock.fail.log does it mean AtomBIOS call from atomic?
mwk: also, that's drm-radeon-next merged with nouveau master
glisse: Zajec: ok that's a usecase we likely never think of
glisse: need to ask to kernel guru if module init is atomic but it seems so
mwk: ok, everything works after downloading firmware, thanks
mwk: yay my dual-head is back
mwk: ... I take it back, it all exploded
mwk: logs spammed with [drm:r600_irq_process] *ERROR* Unhandled interrupt: 230 0
mwk: then 3 GPU softresets
mwk: and counting...
kdekorte: mwk, might try the drm-radeon-testing branch and see if you have any better luck. I'm using it here dual head on an rv635 and it seems great
mwk: kdekorte: it's exactly the same as drm-radeon-next atm
kdekorte: Which card do you have?
mwk: RV790
kdekorte: might try rebuilding everything, doing make distclean before every build. I know in the past that has fixed weird problems I have encountered
kdekorte: try doing libdrm and the ddx first and see if that fixes anything..
kdekorte: since those build pretty quick
mwk: make distclean on... what?
spreeuw: on your tree
Ronis_BR: can anyone who can supend / resume on a RS780 send me kernel .config?
mwk: kernel?
mwk: ok, there it goes...
Ronis_BR: mwk: yes
Ronis_BR: I can't resume and I want to test everything, starting with kernel :)
kdekorte: mwk, actaully I recommend running make distclean on libdrm and xf86-video-ati and not on the kernel, since the kernel takes so long to build
kdekorte: And then rebuilding libdrm and xv86-video-ati on your machine... and don't forget to add --enable-radeon-experimental-api when you rerun configure on libdrm
kdekorte: Ronis_BR, I can send you my config, but I only have an rv635
Ronis_BR: kdekorte: ok!
fscan: uh ... [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
fscan: radeon 0000:03:00.0: object_init failed for (6766592, 0x00060004)
fscan: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (6766592, 4, 4096)
fscan: mutter[2276]: segfault at 20 ip 00007fd05da7f9e3 sp 00007fffbf30c770 error 4 in r600_dri.so[7fd05da21000+2a7000]
kdekorte: Ronis_BR, who so you want me to send it to you?
kdekorte: so how.... jeesh
fscan: just happendend ... some windows with garbage ... but seems to be recovering
Ronis_BR: kdekorte: can you pastebin? DCC is problematic here :D
kdekorte: Ronis_BR, http://pastebin.com/m39cad6d1
Ronis_BR: kdekorte: thanks!
Ronis_BR: kdekorte: btw, libdrm is beign built with --enable-nouveau-experimental-api --enable-radeon-experimental-api
Ronis_BR: do the first will bring problems?
Ronis_BR: will the first bring problems*
kdekorte: Ronis_BR, unknown, I only have radeon cards
agd5f: Ronis_BR: separate driver for nv cards, doesn't matter
Ronis_BR: agd5f: thanks
Ronis_BR: kdekorte: man, are you using KMS?
kdekorte: Ronis_BR, yup
Ronis_BR: kdekorte: ok
Ronis_BR: agd5f: should I enable AGPGART?
kdekorte: Ronis_BR, it should be enabled in that config I believe
Ronis_BR: yes it is
Ronis_BR: I'm looking for diferences
kdekorte: I started with the Fedora 12 .config file and added things as needed
Ronis_BR: ok
Ronis_BR: I won't use because it is too much things enabled :D
kdekorte: Usually took the defaults, except for the recent nouveau module, was set to N my default, I set it to m
fscan: is this something to worry about? : [drm:r600_irq_process] *ERROR* Unhandled interrupt: 21 4
fscan: didn't see this before the last git pull
fscan: and i think the last commit (enabling pm) is freezing my system randomly .... i reverted it and test if it happens again
cxo: has the allocate bug been fixed yet?
kdekorte: how can you tell if radeon power management is working?
kdekorte: nm, I found it
kdekorte: Anyway, doesn't appear to do much... other than slow the card down by 5khz
kdekorte: err 5000kHz
edgecase: ok here's something that i've been wondering for some time... is there an alias for the legacy VGA IO and memory in the PCI decoded resources?
ajax: no.
ajax: in that they're not claimed by any BAR, that is.
edgecase: right, but is there an alias decoding for them ?
ajax: there is a magic decode flag on PCI bridges that says whether VGA cycles are passed to devices behind the bridge
edgecase: yes i know of that one
ajax: and VGA decode is implicitly controlled by the memory and i/o decode enable bits on a device
edgecase: and of course a GPU can be accessed natively thru the BAR decoded io and mem
ajax: oh, you mean "do the vga registers exist aliased somewhere on radeon devices"
edgecase: yes
ajax: i'm almost certain they do, let me check though
edgecase: well radeon IO ports need a different driver than nvidia, but both have VGA emulation registers,
edgecase: i'm just wondering if the legacy VGA emulation registers are accessible without the legacy *decoding*
edgecase: it's amazing how long PC makers are supporting DOS without even trying to clean up the legacy
edgecase: i did an experiment with Linuxbios (now coreboot) where I didn't setup the Hypertransport VGA mappings, and inited an x300 using an emulator and only part of the GPU bios
edgecase: then loading radeonfb. worked fine
ajax: huh. not seeing it in the X driver.
edgecase: yeah xorg has the vga ports optional, VGAAccess "false" or some such
ajax: well, the vgahw layer in X defaults to i/o port access, but you can give it an mmio base instead.
edgecase: so linux could support radeon without legacy ports, using framebuffer, but that's not a generic solution, but if there's an alias for VGA ports, that's the beginning of a solution
edgecase: orly? interesting
edgecase: i wonder if it's something that might even get omitted from chip docs, "who would want that?"
ajax: yeah. look for callers of vgaHWSetMmioFuncs(). problem is, radeon is not a caller of it, so while i was hoping to use that as documentation...
edgecase: right
ajax: i've got real docs somewhere though, one sec.
edgecase: the concept is teaching linux vga console driver where alternate decode is for various cards.
edgecase: i mean the PC industry dropped the ball here, by not making the PCI VGA device class expose where the alternate VGA decode is in a BAR
edgecase: and just leaving the default at the well-known legacy decode
ajax: so at least according to the rv630 doc (and i don't think this bit's been changed in ages), they're aliased relative to "GpuF0MMReg", whatever that is.
ajax: and, in fact, they're in radeon_reg.h already
ajax: RADEON_GENENB and friends
ajax: thanks freenode, you're the best.
ajax: edgecase: they're in radeon_reg.h already. look for RADEON_GENMO_RD and friends.
edgecase: ajax, nice. will i understand what i find there?
ajax: edgecase: maybe? it looks like they're just mapped straight at the same addresses they would be in i/o space, in the register BAR
edgecase: ok
edgecase: i will have to try an experiment then, with linux vga-console driver using those. any idea what radeon chips support that?
rindolf: Hi all.
rindolf: How do I enable XComposite or whatever the KDE desktop effects require on radeon?
rindolf: I can't see anything here - http://www.x.org/wiki/radeonBuildHowTo
intgr: Hi, are there any patches for enabling KMS support for RV770 (HD4870)?
kdekorte: intgr, should be in the drm-radeon-testing kernel
intgr: The radeonBuildHowTo page claims for r600/r700: "kernel has to be from Dave Airlied's drm-next branch that will be merged to 2.6.32"
intgr: I'm on 2.6.32.1 now
intgr: Hmm
kdekorte: Well that kernel should have some support, did you enable KMS in the .config
kdekorte: CONFIG_DRM_RADEON_KMS=y
intgr: Maybe the Kconfig description is out of date, but it claims "Work is underway to provide support for R6XX, R7XX"
intgr: But yes I did enable that now. I'll give it a shot.
stikonas: intgr: nobody claims that R6XX and R7XX support is finished, it is still underway
intgr: stikonas: Ah ok, I assumed that means it's not included yet. :)
stikonas: it is included
intgr: Ok thanks
stikonas: but some features are missing, eg powersaving
olaf_: when i play video trough textured video xv , i got a [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (208896, 0, 4096)
olaf_: ati 4650 + last gits except kernel (git11) , this new "bug" is registered ?
fscan: olaf_: i think latest drm-radeon-testing should be ok
edgecase1: ajax, freenode flailing, do you know what radeon chips have those registers?
eosie: MostAwesomeDude: I think the hardlock in piglit/glsl1 was caused by using a shader which failed to compile... there is an assertion for a month or so and it aborts gracefully with --enable-debug
eosie: fscan: no, it's not, latest drm-radeon-testing fails to allocate a small BO in nexuiz
MostAwesomeDude: airlied, MrCooper : It locked up.
MostAwesomeDude: It did not survive running glxgears all night.
fscan: eosie: hmm, didn't try nexuiz, but the other allocate errors are gone for me at least.
fscan: eosie: so far
MrCooper: MostAwesomeDude: FWIW the issue worked around by the CP resync token seemed pretty specific to 2D solid fills, so glxgears lockups might be something else
bjaglin: hi
bjaglin: anyone here managed to get dynamic clocking with Zajec's patch just by adding radeon.dynclks=1 to the command line? i just built 2.6.32+drm-radeon-testing+patch and i only get "power management initialized" in dmesg
MostAwesomeDude: MrCooper: Yeah, Fx seems a lot better-behaved, at least.
fscan: MrCooper, MostAwesomeDude : i don't know what version you are using, but i had a lockup with the latest git commit (enable pm default)
fscan: reverted this and no lockup so far
MostAwesomeDude: fscan: I'm dealing with rv410 issues.
fscan: MostAwesomeDude: oh, ok
dileX_: bjaglin: seems to work with r600. here with rv515 (r500) no up-/down-clocking.
dileX_: bjaglin: see thread
bjaglin: dileX_: yeah i was just trying to reload the module as suggested, and i do get /sys/module/radeon/parameters/dynclks=1, but no log in dmesg except pm initialized, and radeon_pm_info says state: RADEON_PM_STATE_DISABLED
bjaglin: i am running on a RV250, is that R100?
bjaglin: i saw there were recent changes to handle R100
Zajec: bjaglin: it's disabled on your hardware due to lack of testing
Zajec: bjaglin: you can test it by removing chip family condition in radeon_pm.c
Zajec: see first function in this file
Zajec: dileX_: i've something I'd like you to test
Zajec: dileX_: give me moment
dileX_: Zajec: hehe. OK.
Zajec: is there way to see mutexes in system?
bjaglin: Zajec: ok, i'll stat up a build. anything special i should log or check when it's done?
Zajec: i need to know what mutexes are currently used by radeon
Zajec: which are (un)locked
Zajec: bjaglin: first check if this won't crash ;)
Zajec: bjaglin: that's first good sign :)
Zajec: (when it doesn't :P )
Zajec: then mount debugfs
bjaglin: bjaglin: that's in my skills :)
Zajec: and cat debugfs/dri/0/radeon_pm_info
dileX_: bjaglin: should have all info.
bjaglin: dileX_, Zajec: will do, as soon as my old thinkpad is done with building
dileX_: bjaglin: you are on latest drm-radeon-{testing,next}?
bjaglin: dileX_: i think i pulled drm-linus from airlied which was even more recent this morning
bjaglin: so i guess i should be up to date, no?
dileX_: bjaglin: yeah, that is what I am using
dileX_: I made an isolated single-patch against vanilla-2.6.32
MostAwesomeDude: MrCooper: Just got another lockup, no 3D. I'm tempted to say that the patch does nothing.
MostAwesomeDude: Or maybe it doesn't cover all the cases.
MrCooper: or maybe you really need to do it only once on CP start?
MostAwesomeDude: Maybe. Where would that be, exactly? cp_init?
MrCooper: dunno, whatever does similar stuff to what does it in the non-KMS code :)
bjaglin: Zajec: like that http://pastebin.com/m11bbfcc5, no where else ?
kdekorte: Zajec, do you need to enable something to get the power management code working?
Zajec: bjaglin: you can leave if (radeon_dynclks != -1 && radeon_dynclks and just modprobe with dynclks=1 then
Zajec: bjaglin: you can set that option as boot time, at modprobe time or in configuration
Zajec: kdekorte: just apply patch and use dynclks
agd5f: Zajec: you may want to use a different module option so people can enable clock gating separately from the reclocking stuff
Zajec: agd5f: as you wish
agd5f: edgecase1: IIRC, all radeons
Zajec: agd5f: but... how to call it? i guess it should be dynclks actually ;)
agd5f: Zajec: pm
agd5f: ?
Zajec: ok
edgecase1: terrific!
Zajec: bjaglin: boot time, type in grub radeon.dynclks=1
Zajec: bjaglin: modprobe time: modprobe radeon dynclks=1
Zajec: for configuration use "option" in some file in modprobe.conf
Zajec: err, modprobe.d?
bjaglin: Zajec: ok
bjaglin: Zajec: is the code for clock gating in old cards supposed to be different? Is that the case in UMS?
mimikry: i heard interrupts are working on R600 now. so i think that also vblank is working on R600 now. is it enough to test fedora rawhide (nightly live cd) for this? i currently use fedora12, where vblank does not work yet
cxo: well its not stable,
cxo: there is some random allocate bug that causes firefox, mplayer etc.. among other things to crash continuously
mimikry: i have to say i'm really happy with fedora12. it's awesome and i will switch to fedora13 if it's ready. i only want test, because it's great to see how fast things are working
agd5f: bjaglin: the old clockgating code is still there in kms
agd5f: bjaglin: the clock gating code shuts off clocks to blocks when they are not in use. Zajec's code changes the engine clock when the card is idle
bjaglin: agd5f: oh ok, so dynclks corresponds to the DynamicPM xorg option in UMS?
bjaglin: that would make sense...
agd5f: bjaglin: no. it's the ClockGating option
agd5f: although with Zajec's patch it adds functionality similar to DynamicPM
agd5f: but more dynamic
bjaglin: so the basic clock gating code is always on in both KMS/UMS, independently of any parameter/xorg flag?
agd5f: bjaglin: no. with UMS it's ClockGating (formerly DynamicClocks), with KMS it's dynclocks. neither is on by default
dileX_: drm-linus in upstream :-)
bjaglin: agd5f: i read your post there http://www.botchco.com/agd5f/?p=45 but i am still confused. In UMS, clockgating(5) and dynamicpm(1) are two different features configurable separately, but in KMS, dynclks enables both clockgating(5) and a new strategy for dynamicpm(1) ? Is that why you suggested to Zajec to set up two flags?
agd5f: bjaglin: yes
bjaglin: agd5f: it would indeed help :)
evil_core: File radeon_dma.c function radeonReleaseDmaRegions line 340
evil_core: Leaking dma buffer object!
rindolf: Hi all.
evil_core: hi all also
evil_core: GLSL will slow down mine card drastically?
honk: bjaglin: should have all info. <-- is anything wrong if I dont get any output at all from "dmesg | egrep -i 'dynamic clocking|power management'", even though radeon.dynclks is set? ^^
rindolf: I wanted to thank all the radeon developers and support people for helping me with: http://bugs.freedesktop.org/show_bug.cgi?id=25671 . Now my X setup is working very nicely and I also have some 2-D/3-D acceleration.
evil_core: I got 20-40FPS in UT2K4 when all is set to highest/UXGA
rindolf: evil_core: Unreal Tournament?
evil_core: yes
dileX_: honk: what says 'cat /sys/module/radeon/parameters/dynclks'
honk: 1
cxo: -1
Zajec: honk: you really should get power management in dmesg
bjaglin: honk: do you have an old card?
Zajec: honk: even with old card, as we initialize PM on all cards
honk: Zajec: yeah that's what I thought. but I dont get anything
honk: and.. errh.. 4850
Zajec: dynamic clocking needs uncommenting something on old cards
DanaG: How about Desktop R350?
bjaglin: true, i was getting the pm init from the beginning
spreeuw: nice unreal anthology only 20 euro
evil_core: # cat /sys/module/radeon/parameters/gartsize
evil_core: 1024
evil_core: I got really so high GART?
spreeuw: 512 her
spreeuw: but I have 1024MB ram
spreeuw: video ram
evil_core: I set it manually, but setting anything higher than 256M in xorg.conf was disabling DRI onstable driver
edgecase1: Zajec, worth trying PM on Radeon Mobility M7 LW [Radeon Mobility 7500] [1002:4c57] ?
airlied: MrCooper: true, might be worth tracking down a few of those, I'd liek to drop the #define wrappers as well
evil_core: spreeuw: omg, really 1GB onboard?
spreeuw: yep 4670
airlied: since that stuff gets really messy on ABI
spreeuw: pcie
spreeuw: so not sure if i use gart at all
evil_core: because mine 256MB RV5200 shows in windows 512MB
honk: Zajec: any ideas what I could check? ;P
honk: (or do I need to enable the debug output for radeon in the kernel?)
Zajec: edgecase1: you can try... but we've some serious issue with AtomBIOS currently :/
evil_core: isnt that turbocache or something, or maybe you are AMD/redhat dev that got that for free?
Zajec: honk: what is your dmesg? pastbin it please
Zajec: dmesg | grep drm
spreeuw: [drm] Detected VRAM RAM=256M, BAR=256M
spreeuw: hey thats not correct
spreeuw: wheres my 750 extra?
Zajec: agd5f: ping
honk: http://pastebin.ca/1717327
dileX_: Zajec: ppl love you :-)
Zajec: once I get that fixed they maybe will consider that :)
Zajec: problem is that whole driver design it wrong for us :/
arekm: agd5f: hi, what was the url with radeon firmware?
evil_core: spreeuw: I dont get it in dmesg :(
spreeuw: [drm] RAM width 128bits DDR
spreeuw: [drm] radeon: 256M of VRAM memory ready
spreeuw: [drm] radeon: 512M of GTT memory ready.
Zajec: honk: i'm really consufes
spreeuw: still lacking 256 if I can add these
Zajec: arekm: try http://radeonhd.org/?page=archive_display&c=radeon&m=12&y=2009&d=2009-12-16
Zajec: it was posted today
cxo: is consufes too
Zajec: honk: it makes no sense :/
honk: I built drm-radeon-testing earlier today as well as mesa, ddx and libdrm ^_^
Zajec: honk: it must be recent as it loads firmware...
evil_core: (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
evil_core: (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
Zajec: and i do can see radeon_pm_init in rv770.c
honk: like I said: everything built today after I saw the new commits :]
twnqx: is happy honk is at the front line so he doesn't have to be
evil_core: (II) RADEON(0): [drm] Initialized kernel GART heap manager, 264241152
evil_core: its GART size?
arekm: Zajec: there was some other url that mailing list
arekm: s/that/than/
BioTube: arekm: BioTube: mwk: you can find the firmware here: http://marc.info/?l=dri-devel&m=125960757404659&w=2
arekm: http://people.freedesktop.org/~agd5f/radeon_ucode/
arekm: found it
honk: Zajec: yeah, the call is there in the source I built from ;P
honk: so I guess I didnt mess up my git checkout after all ^^
Zajec: honk: can you mount debugfs?
Zajec: honk: do you have radeon_pm_info in debugfs?
honk: debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
honk: yeah
Zajec: wow, then you really should see some info...
honk: ./dri/0/radeon_pm_info
honk: ./dri/64/radeon_pm_info
Zajec: moment will check if someone modified source
evil_core: isnt firmware provided with kernel?
BioTube: evil_core: it's closed to new firmware
Zajec: honk: ah, it's my patch that adds DRM_INFO("radeon: power management initialized\n");
Zajec: honk: so it's normal
Zajec: honk: you just don't have my patch applied
evil_core: BioTube: stable version, or generally? Should I care about uograding it for r500?
honk: uhh, I see
honk: I assumed that output was in drm-radeon-testing, too :]
BioTube: evil_core: AFAIK, no new firmware's allowed
BioTube: at all
evil_core: sounds strange
airlied: cxo: are you running drm-radeon-next yet?
honk: Zajec: thanks :)
Zajec: airlied: do you have 5 minutes?
dileX_: honk: you need v5 of Zajec pm patch on top of drm-radeon-next (only to clarify)
honk: dileX_: yeah, now I know ;]
evil_core: somebody told me that I can switch on the fly between Mesa and Gallium w/o restarting within one xorg session, can I get more info about that?
honk: [drm] radeon: dynamic clocking enabled
honk: I thought it was part of the last rounds of commits, some of 'em dealt with pm after all ^_^
spreeuw: (II) RADEON(0): VRAM usage limit set to 218959K
spreeuw: so this is 2d memory only or something?
airlied: Zajec: maybe, breakfast time ;-)
Zajec: airlied: would be great if you could spare little time
Zajec: airlied: in radeon initializaion we use AtomBIOS
Zajec: and AtomBIOS can sleep
Zajec: while initializations has to be atomic
Zajec: that's serious issue I think not easy to fix
Zajec: radeon_kms.c::radeon_driver_load_kms >> calls >> radeon_device_c::radeon_device_init >> calls >> r600.c::r600_init >> calls >> radeon_clocks_init which finally uses AtomBIOS :|
airlied: why do inits have to be atomic
Zajec: airlied: http://estudent.put.poznan.pl/rafal.milecki/dmesg.mutex.lock.fail.log
Zajec: kernel says so :|
Zajec: (i think) check dmesg please
airlied: you jsut aren't initing the mutex early enough
airlied: or at all maybe
airlied: bt atom_execut_table is reentrant
Zajec: emm, you think so?...
airlied: so you can't use a mutex
Zajec: maybe....
Zajec: but I would expect some NULL reference then in dmesg...?
Zajec: anyway, hope you're right
Zajec: going to test :)
airlied: like the one in that oops?
airlied: BUG: unable to handle kernel NULL pointer dereference at (null)
airlied: looks like one to me
Zajec: .....
Zajec: omg :|
Zajec: i shouldn't devel any code with that reading skills :
airlied: though you'll hit a reentrancy loop esp at init
airlied: as it exceutes tables inside tables
spreeuw: (WW) RADEON(0): Option "VideoRam" is not used
spreeuw: (II) RADEON(0): VRAM usage limit set to 218959K
spreeuw: ..ok
Zajec: discredited
Zajec: airlied: i won't
Zajec: don't worry :)
Zajec: airlied: you see... i think about more complex things... just these basic are too hard for me ;)
spreeuw: should one pass module options to drm then or something since KMS?
airlied: spreeuw: what are you trying to do?
Zajec: dileX_: give me 5 minutes for patch
spreeuw: airlied: where can i reliably read out the amount of videoram?
spreeuw: I have 1Gb
spreeuw: but xorg seems to think 256
spreeuw: GB
airlied: spreeuw: you can't use more than 256 at the moment
airlied: until glisse finishes writing it
spreeuw: ok
Zajec: let me test AtomBIOS patch :)
evil_core: (II) RADEON(0): AtomBIOS requests 20kB of VRAM scratch space
evil_core: (II) RADEON(0): AtomBIOS VRAM scratch base: 0xfffb000
evil_core: (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead
evil_core: (II) RADEON(0): Detected total video RAM=262144K, accessible=262144K (PCI BAR=262144K)
evil_core: I get some performance impact by this mysterious "scratch space" ?
airlied: evil_core: no
evil_core: gallium on r500 makes often hardcrashes, or only games crashes/looks bad?
evil_core: because If its reliably stable on r500, and I can use Mesa/Gallium concurently than I can only win
agd5f: Zajec: pong
dileX_: Zajec: compiling new upstream kernel :-) (takes a while - dont hurry)
Zajec: agd5f: ok, i think we have that almost done
Zajec: dileX_: could you test V5 together with http://estudent.put.poznan.pl/rafal.milecki/kernel/0001-drm-radeon-kms-prevent-parallel-AtomBIOS-calls.patch ?
evil_core: I got corruption looking like interlacing(both horizontal and vertical) while playing CodeMonkeys using XV fullscreen. (in window it works OK, other movies also look OK)
evil_core: and mplayer devs told me thats radeon bug then
dileX_: saw this in a patch
dileX_: - printk(KERN_ERR "bad: scheduling from the idle thread!\n");
dileX_: + pr_err("bad: scheduling from the idle thread!\n");
dileX_: Zajec: think there should be pr_info as well
dileX_: (dunno if this only for upstream)
Zajec: em, sorry?
dileX_: airlied agd5f ^^
Zajec: dileX_: where did you see it?
dileX_: Zajec: as an alternative to printk(KERN_INFO "[drm][dbg] mutex initialized\n");
airlied: dileX_: yes thats normal I think
airlied: we should use the new ones
Zajec: dileX_: ahh
Zajec: dileX_: ignore this, it's just for you this printk
Zajec: dileX_: i don't want this if this will work and if i'll send final version to dri-devel@
darkbasic: Zajec: hi! can you tell me what card have you tested the kms power management patch on?
dileX_: Zajec: test later. apply against build-dir should be fast
Zajec: rv620
agd5f: Zajec: you mutex shouldn't be global as you may have multiple instances of the driver
Zajec: huh, didn't think about such case
dileX_: Zajec: v2 :-)
samitheberber: where I can get ARB_shader_objects OpenGL extension?
Zajec: dileX_: you can test this, I don't think you use 2 radeons :P
Zajec: agd5f: but... doesn't every kernel module has it's now (memory?) space?
dileX_: (not in my notebook)
Zajec: *now -> own
agd5f: Zajec: the module may load for multiple cards. global vars are shared
Zajec: ah, so I should keep mutex per-GPU... do you mean that?
eosie: samitheberber: you don't really need this extension, you need OpenGL 2.0
eosie: unless you wanna have GLSL in GL1.x
samitheberber: eosie: but r300 only has 1.5 at the moment
agd5f: Zajec: just make it part of the atom struct
eosie: samitheberber: the r300 gallium driver has GLSL quite working, but that driver is not ready yet
samitheberber: so this project has to do it?
eosie: yep
samitheberber: ok :)
Zajec: agd5f: ah, so I should keep mutex per-GPU... do you mean that?
Zajec: how can I force software rasterizer?
airlied: Zajec: put it in the atom context struct
Zajec: LIBGL-ALWAYS-SOFTWARE... something like that, i just don't remember it's name
airlied: LIBGL_ALWAYS_SOFTWARE
Zajec: =1?
samitheberber: jep
Zajec: oki
evil_core: eosie: what means "not ready yet"?
MostAwesomeDude: evil_core: It's unstable.
eosie: some features hasn't been implemented yet etc.
evil_core: but it often make hardcrashes?
eosie: it's good enough for xmoto ;)
eosie: and openarena at low resolutions
cxo: airlied, i built everything like 1min after you commit'd it, but i guess someone beat me to it, and found the alloc bug was still there, i havent confirmed for myself, just saw someone report it in the channel
airlied: cxo: the mirror takes about 5-10 mins ;-)
cxo: i was watching it on git web or whatever its called
airlied: ah cool
airlied: wierd I'll have to keep looking to see if I can se it today
darkbasic: someone with r600 (I have a Radeon 3870) can play nexuiz without kms? I can't, while I can with kms
evil_core: eosie: so its much more slower than radeon driver?
MostAwesomeDude: darkbasic: Why do you not want KMS?
darkbasic: MostAwesomeDude: I just want to do some benchmarks with ums and kms
eosie: evil_core: yes, it is... though it shouldn't be a big deal to make it fast
darkbasic: I opend a bug on dri-devel but developers seem to be not so interested in ums
agd5f: darkbasic: worked last time I tried
darkbasic: agd5f: I have a friend with r600 who can play nexuiz with ums too, but I can't
darkbasic: it stops while loading the map
MostAwesomeDude: darkbasic: UMS regressions for r6xx are kind of hard to care about, especially given the limited exposure of r6xx UMS.
eosie: evil_core: the driver is actually quite good if you don't an unimplemented feature
agd5f: darkbasic: sometimes it takes a while to load the map
agd5f: sound funkiness
darkbasic: agd5f: isn't an hour enough? with kms it takes just few seconds
agd5f: darkbasic: not sure what's up in your case. is 3d working otherwise?
eosie: evil_core: *if you don't *hit* an unimplemented feature
darkbasic: agd5f: yes, some games like nexuiz work fine
darkbasic: *like neverball, sorry
agd5f: darkbasic: what mesa are you using?
darkbasic: agd5f: git master
agd5f: darkbasic: if it used to work, can you bisect to see what broke it?
darkbasic: agd5f: never worked
darkbasic: agd5f: btw current git master works fine for a friend ([Enrico]) who has another R600 card
Zajec: dileX_: let me know if you manage to test this, please
Zajec: dileX_: i compile kernel on my new Samsung R522, hopefully I'll hit some issue with PM
Zajec: (so I'll able to debug it and fix)
Zajec: dileX_: i'm afraid we are getting closer to end of merge window :|
Zajec: shower
Zajec: dileX: let me know if you manage to test this, please
Zajec: dileX: i compile kernel on my new Samsung R522, hopefully I'll hit some issue with PM
Zajec: dileX: (so I'll able to debug it and fix)
Zajec: dileX: i'm afraid we are getting closer to end of merge window :|
dileX: Zajec: dmesg
dileX: Zajec: backtrace :-(
dileX: # cat /sys/kernel/debug/dri/0/radeon_pm_info
dileX: state: RADEON_PM_STATE_ACTIVE
dileX: default engine clock: 392000 kHz
dileX: current engine clock: 337500 kHz
dileX: default memory clock: 300000 kHz
dileX: current memory clock: 297000 kHz
dileX: running glxgears no upclocking
dileX: Zajec: downclocking engine seems to work?
dileX: Zajec: more dmesg (upclocking?)
Zajec: dileX: what the...
Zajec: dileX: did you try checkouted kernel without my 2 patches? are you sure that this bug/crash/whatever is caused by my patches?
dileX: $ cat .pc/applied-patches
dileX: 0001-drm-radeon-kms-add-dynamic-engine-reclocking-v5.patch
dileX: 0001-drm-radeon-kms-prevent-parallel-AtomBIOS-calls.patch
Zajec: dileX: but did kernel work better before applying my patches?
dileX: what do you mean with better?
Zajec: withought WARNING: at kernel/sched.c:2044 set_task_cpu+0x31/0x140()
Zajec: i don't think WARNING: at kernel/sched.c:2044 set_task_cpu+0x31/0x140() is caused by my patches
dileX: this is upstream :-)
Zajec: yeah
Zajec: i think it's related to just updating kernel, but not applying my patches
dileX: could try against 2.6.32
bjaglin: Zajec: looks like your patch is working just fine on my RV250, down and upclocking when running/stopping glxgears :)
Zajec: wow
Zajec: that's great :)
dileX: Zajec: building vanilla kernel
Zajec: bjaglin: you just uncommented that one line?
dileX: bjaglin: fine
dileX: which line?
Zajec: dileX: he uses RV250 so he needed to enable pm manually
bjaglin: Zajec: yes, and using command line parameters modeset and dynclks it worked out of the box
dileX: Zajec: thought commented line in your last patch
bjaglin: is there some more specific testing i could do?
soreau: With latest libdrm, mesa, ddx, X seems to freeze when booting with nomodeset on either 2.6.32 or latest drm-radeon-testing
soreau: Alt+Sysrq still works though
airlied: wierd we haven't really git the non-kms path with any patches
Zajec: bjaglin: no, that's great if it doesn't crash and if this even down/up clock :)
soreau: airlied: Oh wait.. I probably shouldn't be trying to use gallium with ums xD
soreau: tries again
bjaglin: Zajec: my idle GPU temperature is down to 48 degrees, same as with UMS, which is 6 degrees less than KMS unpatched, that's great, thanks! :D
Zajec: :) it should be better later
cxo: what is the power management policy by default?
airlied: none so far
airlied: since the code isn't finished
cxo: will it be tied to cpu_power interface?
cxo: (when its complete)
Zajec: didn't check that interface
Zajec: don't know i
Zajec: t
bjaglin: airlied: i still have two KMS regressions compared to UMS on my RV250 using drm-radeon-testing and latest ddx : https://bugzilla.redhat.com/show_bug.cgi?id=539936 and https://bugzilla.redhat.com/show_bug.cgi?id=531825. Is there any work ongoing on that or was it supposed to be fixed?
bjaglin: TV out seems to work now though (https://bugzilla.redhat.com/show_bug.cgi?id=497055)
airlied: bjaglin: s/r one should have been fixed but it might need more work for certraing chips
bjaglin: https://bugzilla.redhat.com/show_bug.cgi?id=539936 is actually a more serious regression since it was working in 2.6.31 (but smaller resolution were just centered, i dont know if that's how it is supposed to be)
airlied: I'll take a look at the resolution change on my M7 see if it happens
airlied: I noticed something regressed on it recently so need to track it down
cxo: Zajec, i was referring to CONFIG_CPU_FREQ
dileX: drm-vmware-staging in linus-tree
airlied: finally, no more outstanding trees
airlied: does happy danve
dileX: cxo: good question CONFIG_CPU_FREQ*
cxo: it only seems obvious right
cxo: why would you want your gpu clocked max and have your cpu at idle, its not going to happen
airlied: if your GPU is doing stuf
airlied: and your CPu is waiting
airlied: your obvious seems stupid to me
cxo: how often does that happen? and how long does that scenario last for?
agd5f: cxo: a gpu-bound 3d app
cxo: like?
airlied: I'd also expect a lot of time the cpu will wait for gpu or vice versa
airlied: so one would be powered up while the other is powered down
cxo: define 'lot of time'?
agd5f: cxo: unless there are fallbacks, the cpu will mostly just be copying command buffers for the GPU to consume
agd5f: and the GPU will be running full out
cxo: you guys need to look at it from a user's point of view
airlied: cxo: compositined desktops for example
cxo: even glxgears needs the cpu maxed out to perform faster
airlied: cpu will be idle but submit commands to gpu to do stuff, and go back to sleep
agd5f: cxo: so they have 3d perform badly?
airlied: while gpu does stuff
cxo: but the cpu continuously spikes, with compiz
airlied: cxo: simply put cpu freq scaling and gpu scaling are in no way interrelated
airlied: unless they share the same clocks
cxo: I understand why you say that
airlied: which we haven't seen yet though may come at some point
cxo: I'm not talking about blindly clocking the cpu depending on what the cpu governor tells you to do
cxo: ^clocking the gpu
airlied: cpu power governance is much more advanced than gpu
cxo: i'm talking about following the same interface. ie so if the user sets "ondemand", both the gpu and cpu follow the same policy, in essence a single interface from the user's point of view
bjaglin: airlied: i just checked the resolution thing on my RV250, and the only difference is that xrandr allows only the native mode in 2.6.31 while a lot are available in 2.6.32+, and only the smallest ones are problematic (<=800x600 from what I can tell). So when I run etracer, in 2.6.31 it takes the center of the screen but runs fine, while in 2.6.32+ it just messes up the display with horizontal lines and glowing patterns
evil_core: cxo: only clocking down, because otherways cat /dev/urandom > /dev/dsp will put gfx_card to highest ;)
airlied: newer cpus generally shouldn't use anything but ondemand
cxo: anyhow... i'm going to try the latest git
cxo: i really hope that alloc bug has gone, its really damn annoying cos its so random
cxo: airlied, what about newer gpus?
Zajec: could someone fix:
Zajec: drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_busy_ioctl’:
Zajec: drivers/gpu/drm/radeon/radeon_gem.c:271: warning: ‘cur_placement’ may be used uninitialized in this function
airlied: Zajec: its been fixed upstream
evil_core: Zajec: some randomness adds fun ;)
airlied: for a while now
Zajec: airlied: oh, i'm outdated :|
evil_core: airlied: anyway, why you told me I shouldn't use bfs?
soreau: airlied: Well even without gallium, it still hangs when X goes to start.. I am able to ssh in and grabbed dmesg, nothing out of place looking to me http://pastebin.com/m6f306bd7 ps showed X wasn't running and I grabbed Xorg.0.log but it wasn't even the right one (kernel was different)
soreau: This is with nomodeset on 2.6.32 or drm-radeon-testing, rv350
soreau: hmm..
soreau: wtf
soreau: I am still using gallium
soreau: I wonder where I set it now..
evil_core: how to switch between gallium and ums?
MostAwesomeDude: Gallium depends on KMS. I'm not sure what you're asking.
airlied: evil_core: because I've heard bfs problems before with drm
twnqx: Oo
twnqx: Linux dnnote 2.6.31.6-KMS-BFS
twnqx: (mine), not a single problem during the month i run it
twnqx: it's a bit old, obviously.
evil_core: I know there were problems with xorg deprecated mouse/keyboard divers, so I switched to evdev and no problems at all, except dri not working with kms and lack of GLSL
moobie: Hello
moobie: How is pm support with r700 kms?
evil_core: and this Xv thing, bu its strange its affecting only one movie
bjaglin: Zajec: i can see from the posts in dri-devel that people get the current memory clock, which I don't http://pastebin.com/f5b269f3f . Is that due to my old chip?
soreau: Well I managed to disable gallium, and the 'freeze' still happens but I am able to ssh in and start kdm, but then after logging in, X is very fragile returning me back to the kdm login screen while starting compiz
soreau: ugh, I just wanted to test something with dri1 but I guess it wont be happening today
Zajec: bjaglin: yes
bjaglin: Zajec: lspci: http://pastebin.com/f1c22dc0f
Zajec: bjaglin: we can't read memory clock on older chips (nor change it)
bjaglin: ok
soreau: It's like after X dies, switching to VT just remains a lower bpp image of what X displayed last
soreau: and can't get to tty
agd5f: bjaglin: I don't think I ever implemented get_memory_clock for the older asics
Zajec: hm, maybe it's just about setting this function in ASIC
Zajec: bjaglin: could you test some patch if I write it?
bjaglin: Zajec: sure
Zajec: agd5f: do you think we can also set memory on older chipsets? or just read?
evil_core: rovclock!
evil_core: it worked on r250 (9200), not sure about memory, but probably too
agd5f: Zajec: we could, but it's a lot of work
Zajec: i thought it's implemented
DanaG: hmm, last time I tried rovclock, it caused a hard-lockup.
agd5f: Zajec: engine clock only. memory clock involves readjusting the memory dlls and such
agd5f: don't use rovclock, it doesn't do the right thing
airlied: gallium shouldn't affect X starting
DanaG: Doesn't do the right thing?
DanaG: hmm, I just downclocked ram from 330 to 300, and core from 370 to 270. seems fine.
agd5f: DanaG: it doesn't deal with the eng/mem post divider at all
agd5f: so you aren't really getting what you think you are getting
Zajec: what is rovclock?
DanaG: you mean it's not really changing speeds?
agd5f: DanaG: it's not changing the to the speed you think it is
evil_core: all will desynchronized
DanaG: I did try to set core to 300 and memory to 300... and the act of setting memory to 300 set the core to 270.
DanaG: Or at least, that's the final result of rovclock -i.
evil_core: like via + athlon with different SFSB was eating your data on HDD ;)
Zajec: bjaglin: http://estudent.put.poznan.pl/rafal.milecki/kernel/legacy.get.memory.patch
agd5f: DanaG: the older chips shared a common ref divider for both engine and memory IIRC
Zajec: err
Zajec: bjaglin: wait moment
Zajec: wrong patch
Zajec: bjaglin: refresh http://estudent.put.poznan.pl/rafal.milecki/kernel/legacy.get.memory.patch
Zajec: bjaglin: now uploaded correct version
Zajec: bjaglin: just apply, compile, cat radeon_pm_info
bjaglin: Zajec: will do, i will come back with results tomorrow
Zajec: bjaglin: ok :)
dileX_: Zajec: no upclocking here
mentor: What DRM version is 2.6.32?
bjaglin: Zajec: are you using the /lib/modules/*/extra thingie instead of recompiling the whole kernel when making a small change? I am quite new to the linux kernel...
evil_core: yes
evil_core: DRM in the past was prvided and developed as external modules, not a kernel branch
dileX_: Zajec: radeon_pm_info and dmesg:
bjaglin: i need to give a try
bjaglin: is there any performance benefit of building-in radeon into the monolith?
airlied: not really
evil_core: for gfx no
Zajec: dileX: it looks nice, clean
Zajec: dileX_: does it upclock when you start glxgears?
airlied: you also waste RAM on firmwares the kernel can't free I think
dileX_: Zajec: unfortunately, no
evil_core: but with only ndrivers bootup will be much quicker
evil_core: and hotplugging devices
Zajec: dileX: ok, give me some minutes
cxo: Looks like that alloc bug has gone
cxo: knocks wood
mishehu: lights wood on fire
dileX_: [drm][dbg] mutex initialized
dileX_: [drm] radeon: dynamic clocking enabled
dileX_: [drm] radeon: power management initialized
mishehu: ...using my 4890 to start the fire
Zajec: dileX: it looks fine
bjaglin: would you recommend a particular website or book to get some insights in the kernel and/or module development?
Zajec: bjaglin: do you want to learn kernel programming? ldd3
cxo: runs his box nude
evil_core: pervert
bjaglin: Zajec: thanks
mishehu: cxo: how old is your box?
cxo: old enough to be legal, young enough to run hot
mishehu: hahah
cxo: (hd4870,x3,2gb,etc..)
mishehu: was afraid you were a pedo-file.
mentor: Hmmm, my xf86-video-intel is saying: "[KMS] drm report modesetting isn't supported." but cat /sys/module/radeon/parameters/modeset: "1". :(
mishehu: ok, so with an hd4890, can I get 3D hardware support? I'm not completely clearn on whether I need the stable branch or the bleeding-edge with KMS... I currently have 6.12.4 of the xorg driver installed on my machine.
mentor: hmm
tormod: mentor, intel? radeon?
evil_core: mentor: whats your problem? KMS ws
evil_core: works*
mentor: tormod: Er, shockingly radeon.
cxo: mishehu, its best you use linux-2.6.32 + drm-next-radeon and mesa,libdrm and xf86-video-ati from git
mishehu: cxo: so all the bleeding edge stuff
honk: yes
cxo: well not all... but some
Zajec: dileX_: can you start glxgears and do "cat radeon_fence_info"
tormod: mentor, "my xf86-video-intel is saying" :) but make sure radeon.ko is loaded before starting X
Zajec: dileX_: can you start glxgears and do "cat radeon_fence_info"
mishehu: ok that was odd...
mentor: tormod: Oh sorry, my fingers wandered off
BioTube: meshehu: you mean the netsplit? happens all the time
mentor: evil_core: DRI then later fails with (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
dileX_: # cat /sys/kernel/debug/dri/*/radeon_fence_info
dileX_: Last signaled fence 0x00021779
dileX_: Last emited fence f65b7a20 with 0x0002177A
dileX_: Last signaled fence 0x00021779
dileX_: Last emited fence f65b7a20 with 0x0002177A
dileX_: Zajec: ^^
mishehu: BioTube: that looked more like a channel join than a typical netsplit
tormod: mentor, what I said
evil_core: mentor: then disable kms
evil_core: options radeon modeset=0 dynclks=1 gartsize=1024
mishehu: I normally don't automatically have irsii show me the names of all channel users when a netsplit ends.
Zajec: dileX_: can you do it once more? using "0" instead of "*" is fine
mentor: evil_core: I'm not sure that's what I want to achieve...
mishehu: cxo: anyway, you are prescribing that I choose the route of pain in order to get 3d rendering on my card :-)
honk: Zajec: oh btw, how much is the clock supposed to be scaled? as much as on fglrx, or just a little bit? :]
evil_core: mentor: with kms you get slower opengl
mishehu: i don't know yet if I can even try out kernel 2.6.32 yet... last I checked I'm still waiting on support for something before I switch.
evil_core: and it doesnt work for me with 2.6.32
Zajec: honk: that's decision for later
dileX_: Zajec:
Zajec: honk: i don't thin we will use fglrx algorithm
honk: Zajec: nah I meant right now ;)
mentor: evil_core: noted
Zajec: honk: almost nothing
honk: I'm trying to figure out if it's working as intended
Zajec: honk: it downclocks by 50MHz
honk: good, that's the answer I wanted to hear =D
cxo: mishehu, you chose that path the day you thought you will use an ATi graphics card on linux
Zajec: dileX_: ahh, that's pretty easy :)
Zajec: dileX_: it doesn't upclock because you GPU is boring ;)
dileX_: oops, typo "Last emited fence..." <--- emit*t*ed
Zajec: dileX_: there aren't 3 not processed fences :)
evil_core: mentor: I am not a dev, I updated all to master except kernel, but airlied got identical hardware and says it works, but slower with KMS so I dot bother
evil_core: xterm + screen is enough for me ;)
Zajec: dileX_: sec
dileX_: Zajec: this x1300 is evil (I said to you)
biker_rat: My card only works with the git snapshot on fedora 12 or archlinux. Do you have a release date in mind for 613 driver?
Zajec: dileX_: can you install openarena?
kdekorte: evil_core, for me KMS 3d is faster than DRI1
Zajec: dileX_: hehe :P fast as devil :P
dileX_: Zajec: I have OA
Zajec: dileX_: great, moment please
mentor: evil_core: As I say, I'm not sure that's what I'm trying to achieve; noted.
mishehu: cxo: I was hoping for less pain than fglrx ever was :-)
mishehu: fglrx was always teh suck
mishehu: and didn't support xrandr either
Zajec: does anyone know how to make dmesg display time?
evil_core: I got R500/ FireGL V5200/X1600
Zajec: it doesn't display it always
Zajec: like in dileX_'s case
Zajec: he doesn't get prefix in dmesg with time
dileX_: debian-kernel has it as default
kdekorte: mishehu, to try out easy r6xx support boot the fedora 12 live cd... usually it just works, and then install "mesa-dri-drivers-experimental" and you should get full 3d working... I hope that goes away soon
kdekorte: the extra package not 3d working
Zajec: dileX_: i've compiled kernel myself on openSUSE and have that also
evil_core: mentor: I too ;) If it would be like in the past compiling new modules and reloading them, then no problem. But rebuilding all kernel and rebooting machine to see thats maybe owrking is not what I want
Zajec: dileX_: not sure how to tell you to enable it
Zajec: googling
cxo: mishehu, building that stuff is really easy, i built the entire stack a few times a day, mesa,drm,xf86-video-ati, together take less than 2mins to compile on my machine (2.6ghz x3)
evil_core: cxo: not kernel. And reaplying all patches manually (I was adding to SPEC file simply them)
dileX_: Zajec: CONFIG_PRINTK_TIME?
Zajec: yeah
Zajec: just found it
Zajec: sec ago :P
DanaG: weird... openarena gives me this vertically stretched texture mostly-transparently overlaid on the screen.
DanaG: And in the lower-left, there's a solid square of that texture.
dileX_: # zgrep -i config_ /proc/config.gz | grep ^# | grep -i time
Zajec: :)
Zajec: google: kernel printk time :P
evil_core: DanaG: same with nfshp2 under wine
Zajec: dileX_: please apply http://estudent.put.poznan.pl/rafal.milecki/kernel/reclock.info.patch and enable CONFIG_PRINTK_TIME
evil_core: or maybe not, but some square
DanaG: interesting... "bloom" is what seemed to be doing it.
mentor: Right
biker_rat: Any clue, when 613 driver?
mentor: The advice about making sure the radeon kernel module is loaded before X starts is good advice.
dileX_: Zajec: that means full recompilation I guess?
evil_core: yes
evil_core: bbut you dont have to make clean at least
evil_core: so it will depend more on hdd speed
Zajec: dileX_: hm...
Zajec: dileX_: maybe it would work when recompiling just modules...
evil_core: if printk() is a macro, not function, than maybe
evil_core: but I doubt that output format depend on printk internally
dileX_: (full compilation)
DanaG: weird... I have the same monitor connected to the computer via both dvi and vga... and oddly enough, only DVI shows the cursor.
DanaG: VGA has cursor missing.
DanaG: (Desktops are in clone mode.)
bjaglin: Zajec: i built your patch as an external module, installed, changed /etc/depmod.conf to give priority to extra for radeon, did depmod -a, and verified that modinfo radeon returns the one in extra, but i can see from the printout that the built-in one is still preffered. is there something i am missing?
bjaglin: initramfs maybe?
Zajec: uhh, don't know
Zajec: didn't play with built-in modules
Zajec: can't help, sorry
bjaglin: that was it, i had to update the reference in the ramfs...
bjaglin: anyway, here is what i get http://pastebin.com/f6582a443
bjaglin: Zajec: no up/down clocking for the memory as expected, but the current is not the default
Zajec: bjaglin: that's normal and expected
Zajec: bjaglin: hardware can not be set to exact value
Zajec: bjaglin: it's always little higher or lower
Zajec: bjaglin: thanks for testing
bjaglin: Zajec : np, thanks for your patch, and if you have anything else to test on legacy chipsets, i am in, now that i know how to build radeon as an external module ;)
evil_core: Zajec: can I build drm/kms modules for mine 2.6.32?
evil_core: from drm-radeon-testing or something
Zajec: evil_core: drm-radeon-testing is 2.6.32 based
Zajec: so you may try
evil_core: I dont understand one thing, DRM is SAREA, so buffers are initialized during xorg start
evil_core: Gallium3D/DRI2 are TTM/GEM based, so buffers are dynamically allocated when needed
evil_core: so how both Gallium and UMS can work in one x session?
Zajec: checking http://dri.freedesktop.org/wiki/SAREA ...
Zajec: does SAREA is still "happening" with KMS?
AStorm: hi there
airlied: no SAERA with DRI@
Zajec: hey :)
airlied: DRI2
AStorm: why don't we have OpenCL or such yet? or the GPU assembly docs so we could replace the damned firmware blobs ;p
MostAwesomeDude: evil_core: DRI1 has SAREA, DRI2 doesn't.
AStorm: write the proper card kernel to run stuff
MostAwesomeDude: evil_core: Also note that Radeon-Gallium drivers will completely revert to software rendering if DRI2/KMS isn't there.
MostAwesomeDude: AStorm: Why?
MostAwesomeDude: What's wrong with the firmware? Are there bugs in it?
AStorm: it's closed and doesn't run nice apps yet
AStorm: ;)
AStorm: fixing both would be best, maybe we could optimize it as well ;p
AStorm: I bet there are no actual secrets to be had from it
AStorm: just legalese junk
MostAwesomeDude: AStorm: The firmware has nothing to do with "run[ning] nice apps."
evil_core: firmware are needed because devices doesnt got one built-in like winmodems?
AStorm: exactly
AStorm: but it could be open too
AStorm: it's not.
MostAwesomeDude: Well, okay, here's the case for keeping it closed:
evil_core: how it differs from VBIOS?
AStorm: evil_core, you mean AtomBIOS which is actually flash on the chip
AStorm: and contains info on setup
MostAwesomeDude: It's proprietary and might divulge information about the structure of the hardware which the author (AMD/ATI) isn't legally permitted to advertise.
MostAwesomeDude: The case for opening it:
MostAwesomeDude: We might find bugs in it which explain hardware errata. Also it appeases RMS.
evil_core: AStorm: dunno why its called Atom, and how it differs from firmware
AStorm: MostAwesomeDude, ha ha, actually, the high level structure is marketed anyway ;>
AStorm: and low level structure is not a problem for a real competitor like nVidia to find out anyway
AStorm: evil_core, the "firmware" is the card kernel
AStorm: the shader pipeline program
MostAwesomeDude: AStorm: nVidia is *not* the point. It's not about competition, it's about rights. MS, S3, SGI, et al. are more likely.
MostAwesomeDude: ...
evil_core: AStorm: so pre-shader cards doesnt need firmware?
MostAwesomeDude: No, the firmware is *not* shaders!
AStorm: no
DanaG: Is SGI still around?
AStorm: it is the kernel to run the shaders
AStorm: and schedule the many cpus
MostAwesomeDude: No, the firmware is not a kernel!
AStorm: that's what I meant by "shader pipeline"
AStorm: so what is it then ;p
MostAwesomeDude: No, it's not a context switching program!
AStorm: so what the hell is it then
AStorm: does it do anything
AStorm: ;p
MostAwesomeDude: The firmware is for a command processor; a small chip that drives the DMA to and from host memory and copies packets into card registers.
MostAwesomeDude: It's needed for non-MMIO operation.
MostAwesomeDude: It's also needed on r600 to reach the acceleration core, which isn't in MMIO range.
AStorm: the one for _irq ;p
AStorm: what about for the other two files
AStorm: s/for//
MostAwesomeDude: For IRQs? Same thing; the command processor on r600 is more complex, so it's broken up into a couple pieces onboard.
MostAwesomeDude: Nothing acceleration-related.
AStorm: extra lol
airlied: the IRQ firmware is the CP firmware in reverse
AStorm: so what there is to hide?
airlied: instead of taking stuff from the CPU and giving it to the GPU it does the opposite
airlied: AStorm: its not about hiding, its about the effort of opening not being worth it
AStorm: heh
MostAwesomeDude: AStorm: It's a matter of legal liability on their part.
airlied: there also isn't any open compiler for that processor
AStorm: so they don't produce that chip or something?
airlied: or open assembler
AStorm: true.
AStorm: that is the actual problem
MostAwesomeDude: MS and AACSLA take this kind of thing seriously.
MostAwesomeDude: *That's* the problem.
DanaG: I'm curious... does that command-processor have a known architecture?
AStorm: not exactly.
DanaG: Or is it one completely original to ATI?
AStorm: yes, it is ATIs
MostAwesomeDude: It *might* be ATI's.
AStorm: it might look like a typical CPU design of course
MostAwesomeDude: It might be some other manufacturer.
AStorm: huh.
DanaG: With licensed bits from god-only-knows-where? And then you have to ask those people for permission for releases.
airlied: its also insanely simpler you could probably RE it all in a week
AStorm: now that'd be a reason - being bound by someone else's NDA
MostAwesomeDude: Moreover, I really doubt that we could possibly find bugs in the FW. It's been picked-over by lots of people with plenty more experience in that specific field.
MostAwesomeDude: We've got the same updates in the FW as fglrx had.
AStorm: no no
AStorm: I'm not talking about bugs, that's unlikely
MostAwesomeDude: I bet that if you went and hacked up Win32 fglrx, you'd see the same FW.
AStorm: I'm talking about optimizations
AStorm: although the assembler would be necessary first
MostAwesomeDude: It might not be intelligent enough for an assembler of any complexity.
evil_core: MostAwesomeDude: QuadBuffers, etc isnt the reason for binary blob?
AStorm: so machine code then
AStorm: whatever we can program in
MostAwesomeDude: It might just barely have the smarts to grab the PCI bus, find a point in main memory, and copy bits of it out to the GPU.
AStorm: a DMA processor for the GPU
AStorm: in other words.
AStorm: hmmph
MostAwesomeDude: evil_core: Nope, the firmware blobs we have these days are only for very specific low-level functions. You can see all of the accel stuff in the accel docs.
philv: The GPU's ISA is published, FWIW
MostAwesomeDude: AStorm: Kind of. The DMA engine itself is separate and can be programmed in MMIO mode, IIUC.
DanaG: iiuc? first time I've seen that used.
DanaG: "if I understand correctly."
MostAwesomeDude: Well, I read through the DMA code a few nights ago, and it looked like it should all work in MMIO mode.
MostAwesomeDude: Although, at least in KMS, we always try to get the CP up and running.
evil_core: TurboCache works under linux?
airlied: AStorm: you'd be optimising the wrong thing
AStorm: airlied, I suspect so
AStorm: :)
AStorm: there are other, more pressing things to do
MostAwesomeDude: evil_core: You mean that thing for IGP, using system memory to aid the video card?
AStorm: I thought it was some kind of GPU kernel, guess I was wrong a lot
MostAwesomeDude: Nope. For Matrox and ATI, the firmware's fairly essential.
MostAwesomeDude: For nV cards, it isn't, but marcheu and darktama don't want to have non-context-switching init.
evil_core: MostAwesomeDude: I got UXGA T60p with V5200, and I heard that I can acess only 3.5GB because of memory mappings for devices
evil_core: it got 256MB, but under windows it shows 512MB
MostAwesomeDude: I don't blame 'em, although I wished we knew how to do the r600 context switching. (Even if it *is* kind of faultyish.)
philv: It's slow and buggy from what I've heard. A lot of state to save. :\
MostAwesomeDude: evil_core: Yeah, you need PAE on, or to use amd64.
evil_core: I am usin c2d and 64bit PLD
MostAwesomeDude: Then there shouldn't be any problems.
evil_core: but in T60x was BIOS limitation up to 30GB, but I got hacked BIOS
evil_core: 3GB*
AStorm: evil bios as is your nick ;)
evil_core: I wonder I can only get 3.5GB and not 3.74GB if gfx card would allocate 256MB for TurboCache
AStorm: because it allocates 256 MB for MMIO
AStorm: I bet the bios sets the card in the autocopy mode or sth
evil_core: yeah, but I got 4GB
AStorm: some such junk, where the card keeps the turbocache and VRAM in sync
AStorm: (one-way sync that is, unless a flush is made)
DanaG: hmm, on my system with 4 gigs of RAM, I never did notice much difference between 32-bit and 64-bit Linux.
AStorm: DanaG, and you shouldn't
AStorm: except less disk access because of extra cache
dileX_: Zajec: around?
AStorm: and maybe faster video encoding
AStorm: or raytracing
evil_core: I heard that PAE sucks
AStorm: PAE is some 10% memory performance tax
AStorm: not a whole lot
evil_core: because of performance
AStorm: it's not *that* bad
AStorm: it's more work for the memory controller
evil_core: but I wonder if currently every process doesnt got his own memory mapping later translated
DanaG: About the most I've noticed is that some software breaks under 64-bit.
Zajec: dileX_: pong
dileX_: [ 295.344771] [drm] radeon_atom_set_engine_clock: 392000 kHz
dileX_: [ 295.729024] [drm] radeon_atom_set_engine_clock: 342000 kHz
dileX_: [ 366.348231] [drm] radeon_atom_set_engine_clock: 392000 kHz
dileX_: [ 366.849849] [drm] radeon_atom_set_engine_clock: 342000 kHz
evil_core: DanaG: not much
dileX_: Zajec: glxgears running
Zajec: dileX_: so it upclocked for a short moment
Zajec: that's fine with glxgears
Zajec: dileX_: could you try openarena?
evil_core: bb, lynx, links-hacked, link2, generally terminal/svgalib/ggi apps
evil_core: and tuxracer :/
dileX_: Zajec: jupp
evil_core: and any tuxracer clone sucks
cxo: wants to know his atom engine clock thing too
dileX_: Zajec: hmm
Zajec: dileX_: ?
dileX_: [ 484.057936] [drm] radeon_atom_set_engine_clock: 392000 kHz
dileX_: [ 484.458991] [drm] radeon_atom_set_engine_clock: 342000 kHz
Zajec: that is old
Zajec: nothing after that?
Zajec: ah no
Zajec: itsn't old sorry
Zajec: dileX_: is that all from drm after 366?
Zajec: no more drm radeon_atom_... messages after 366 second?
dileX_: no
Zajec: :(
Zajec: unless there is some bottleneck and GPU just does not need upclocking, we have some issue :|
[Enrico]: try to rise settings
dileX_: will upgrade mesa
Zajec: dileX_: you could compare benchmark result with dynclks and without dynclks if you still have "power" to play with that
dileX_: after reboot
dileX_: 5min for mesa
evil_core: you can always rmmod -f radoen, it works for me
dileX_: if KMS is loaded - a bit tricky
mishehu: cxo: I run slackware, so it's a little more involved. and I have to wait for edward shishkin to release a new page for reiser4 before I can up to 2.6.32.
adamk: Why is it more involved in Slackware? I'm using all the latest/greatest bleeding edge code in Slackware 13.0.
dileX_: Zajec: :-)
dileX_:
cxo: sounds like a Van Dame movie... latest greatest bleeding edge
adamk: Shoot... gotta go.
mishehu: adamk: ot
dileX_: (anholt OA demo)
mishehu: adamk: it's certianly more involved than "apt-get"
Zajec: dileX_: it upclocks for a very short time
Zajec: dileX_: could you benchmark with and without dynclks?
evil_core: so lpw delta sucks
dileX_: Zajec: yeah
Zajec: dileX_: would be great
evil_core: low*
evil_core: It would be ideally to downclock to 5 or 10% when using 2d only
Zajec: evil_core: that will come later
Zajec: evil_core: and will be quite easy (at least first time)
Zajec: calculating minimum engine using clocks info will be easy
Zajec: later we will need to port radeonhd's AtomBIOS powermanagement_info reading
Zajec: little harder
DanaG: _moep_: how do you have such a "Dead" IPv6 address?
DanaG: that' can't be accidental.
DanaG: (05:12:44 PM) _moep_ [n=irc@2001:638:904:ffc2:dead:dead:dead:dead] entered the room.
DanaG: not just dead, but dead dead dead dead.
Ghworg: Presumably he picked it out of all the IPs with the prefix he got from his IPv6 provider
Ghworg: You don't get just one IPv6 address, you get given a prefix containing a bunch
dileX_: Zajec: oa_dynclks-0.txt dmesg_dynclks-0.txt: http://pastebin.ca/1717676
dileX_: Zajec: oa_dynclks-1.txt dmesg_dynclks-1.txt: http://pastebin.ca/1717677
Zajec: dileX_: so it looks there really is not need to upclock your engine
Zajec: dileX_: which means for me that PM does right thing not upclocking it
evil_core: maybe run nexuiz instead of glxgears ;)
Zajec: evil_core: that was openarena test
evil_core: dont like it
Zajec: dileX_: interesting what is bottleneck then...
dileX_: Zajec: forgot to mount debugfs
evil_core: quake3 original is way better
evil_core: or warsow
dileX_: Zajec:
dileX_: Zajec: so there is upclocking
evil_core: Zajec: we should shift timezone to UTC+8 ;)
Zajec: :P
cxo: i only get 15fps on demo1 (Nexuiz, 1280x1024, maxed)
dileX_: Zajec: so I think your patch is OK
Zajec: dileX_: but check time for dmesg messages... it upclocked on 305.2 and downclocked on 305.5
cxo: someone told me its cos one of the function it (and alienareana) uses has not been accelerated yet
Zajec: dileX_: so it almost wasn't upclocked
Zajec: dileX_: but also there wasn't reason for it
Zajec: dileX_: so that's fine
Zajec: dileX_: :)
Zajec: dileX_: you made great testing for me today
Zajec: dileX_: many, many thanks :0
dileX_: Zajec: was a pleasure
dileX_: now, building 2.6.32-git13
evil_core: I can make tests tomorrow If wil be not so much sick
evil_core: I got R500, R200 and mach64 :)
Zajec: would be great if you could :)
Zajec: e, maybe just skip mach64 :P
evil_core: I would be happy with dynamic memory allocation for mach64
Zajec: it's 15 years old, isn't it? ;)
Zajec: hehe :P
evil_core: becaus it got 2MB
evil_core: so I can run X at 800x600 with dri or 1024x768 w/o DRI
evil_core: perfectly would be xrandring when want to play game or run video
dileX_: Zajec: pushed 0001-drm-radeon-kms-prevent-parallel-AtomBIOS-calls.patch to dri-devel?
evil_core: it is, it got pentium2 350MHz, but 100MHz FSB
Zajec: i did
evil_core: old, good noiseless compaq sitting in kitchen acting as terminal, AP and somebody play games/video on it :)
evil_core: but 800x600 in fuckin web_two_zero is a nightmare :/
DanaG: ooh, informative: http://www.phoronix.com/forums/showthread.php?t=21003&page=2
evil_core: ATI rulez becau it got good 2d performance on R500
evil_core: but on R200 it sucked
evil_core: heroes3/wesnoth was lagging
evil_core: but it was 2 years ago, so maybe EXA currently changed it
evil_core: I love "legacy games"
evil_core: We should go bac kto 8bit indexed mode
evil_core: back*
dileX_: hmm, [PATCH] drm/radeon/kms: enable memory clock reading on legacy
Zajec: dileX_: ?
dileX_: Zajec: shall I test that, too? or is that for old radeon gfxcards?
Zajec: older
dileX_: not needed for me
Zajec: yup
Zajec: dileX_: you are on RV515, right?
dileX_: Zajec: yes
cxo: how do you read the gpu clock from userspace?
evil_core: cxo: /proc
cxo: you're going to have to be a little more specific
Zajec: for now only debugfs
Zajec: mount -t debugfs debugfs /debugfs/
evil_core: I am going sleep, be all
Zajec: cat /debugfs/dri/0/radeon_pm_info
Zajec: bye :)
cxo: why does it need to be replicated in /proc anyways
Zajec: dileX_: sorry, but which part is your firstname? :0
cxo: default engine clock: 815000 kHz
cxo: current engine clock: 814060 kHz
dileX_: Zajec: yes thats important. sedat is firstname (if lastname was firstname I had to change gender/sex :-))
Zajec: :)
Zajec: :P
cxo: so do i have like mad power savings by using 940 less clocks ?
Zajec: i always had problems with connecting that der/die/das with nouns :)
dileX_: simple "the" is best
Zajec: ;)
dileX_: le/la in french reduces to 50/50 chance
cxo: sex is physiological, gender is psychological
dileX_: cxo: thx
Zajec: cxo: you don't use PM, it's just that GPU can not be set to exact value of clock
dileX_: cxo: but both would be correct
cxo: Zajec, should i give it more juice!?
Zajec: cxo: when you say GPU to be 600MHz, it will always be sth like 599,4MHz
Zajec: sure, like my patches ;)
cxo: hey do you guys know how to view (like telnet) a git repos?
Zajec: web interface?
cxo: i tried git web--browse but it doesnt work
cxo: weird cos it says firefox is supported in the man page
cxo: someone needs to do a firefox addon for git
Zajec: i use http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
cxo: oh :) i need to get a file from GTK+
cxo: i wonder if i can pass my own path to that webpage
cxo: no you cant :) /pub/scm is hard coded
Zajec: nope
dileX_: cxo: tig
dileX_: cxo:
cxo: thats not what i meant, thats kinda like what mc is to bash
cxo: i'm looking for a way to connect to a remote repository and just look at it, like ssh or telnet does for
dileX_: Zajec: v6: dynclks=X -> dynpm=X (X=0,1) :-)
Zajec: yup
mentor: http://git.gnome.org/cgit/gtk+/
mentor: ?
amarks: Zajec: can V6 go on top of 2.6.32 stock kernel?
amarks: i assume so
dileX: amarks: hi. v5 did
amarks: ok i'll try it
dileX: amarks: for rv515 I need in addition "drm/radeon/kms: prevent parallel AtomBIOS calls"
amarks: i have an rv790
dileX: (no need then)
amarks: ok ta
amarks: ok that did not apply cleanly
dileX: amarks: I have a drm-linus single patch against vanilla-2.6.32, interested?
amarks: sounds dangerous :)
dileX: no
dileX:
amarks: how up to date is it
dileX: (applies cleanly)
dileX: todays drm-linus
dileX: 19 hours ago drm-linus
amarks: which version of pm does it have?
dileX: only pm init
dileX: you need v6 on top
amarks: k
amarks: i really don't want to take 33 rc1 so i'll try yours
amarks: if it breaks can i blame you? :)
amarks: dileX: is this patch for 2.6.32 or 2.6.32.1 ?
dileX: amarks: I applied against 2.6.32.1 (but should not matter, .1 has no gpu/drm patches)
amarks: ok
amarks: dileX: what distro r u using?
dileX: Debian/sid (i386)
amarks: what is the syntax of the kernel parameter for dynpm? i see it's off by default
dileX: amarks: modeset=1 dynpm=1
amarks: well nothing totally catastrophic with no pm, thought i'd boot and make sure
amarks: i put dynpm=1 but debugfs shows pm is disabled
amarks: dileX_: ?
amarks: dileX_: pm no go
dileX: amarks: how are you testing?
amarks: i put dynpm=1
amarks: debugfs shows disabled
dileX: in KMS
amarks: yeah
dileX: what says dmesg?
dileX: # dmesg | grep radeon | grep power
dileX: [ 59.504001] [drm] radeon: dynamic power management enabled
dileX: [ 59.504003] [drm] radeon: power management initialized
amarks: i do not get line 1
amarks: only line 2
dileX: cat /sys/module/radeon/parameters/dynpm
dileX: 1
soreau: it would seem recordmydesktop sucks.. anyone else tried it with dri2 by chance?
amarks: dileX: -1, so what was wrong with the kernel parameter dynpm=1 ?
amarks: don't u need radeon.dynpm=1 or something?
dileX: as grub-cmd-line?
dileX: I am entering init-3, unload radeon and load via 'sudo modprobe -v radeon modeset=1 dynpm=1'
amarks: yes grub
dileX: as grub-cmd-line: modeset=1 dynpm=1 (other distros and kernel radeon.$parameter=0,1
amarks: well dynpm=1 on grub line no workie
dileX: you add modeset=1 to grub?
amarks: i have kms as default
amarks: so not required
dileX: me too
amarks: why r u putting modeset=1 then?
dileX: I am booting with nomodeset in init-3
amarks: brb
dileX: wow
dileX: $ openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
dileX: 840 frames 10.2 seconds 82.1 fps 4.0/12.2/56.0/5.4 ms
dileX: r300g st/dri on upstream kernel
dileX: MostAwesomeDude: ^^
cxo: is anholt your own demo?
dileX: cxo: no
dileX:
dileX: mesa: commit 09cef45393c14d2b02529cb3cbea194bdfc06bf3 (r600 : clean a bit to prepare to enable gl2.)
cxo: are you using compiz?
amarks: dileX: ok it's active, needed radeon.dynpm=1
dileX: no, e17
dileX: amarks: fine
cxo: e17 :)
amarks: dileX: but it's only downclocked 50mhz
dileX: cxo: no XXXmas gift
cxo: i only get 47fps, r700, kms, compiz
cxo: but i get over 200fps if i disable compiz :)
dileX: my last info: e17 final should come wirh Xmas - but seems to be some severe bugs. will see.
cxo: all my apps are gtk, seems like a waste to install anything other than gnome
amarks: dileX: how much does yours downclock?
dileX: less
amarks: hmm
dileX: amarks:
amarks: what is your default clock?
dileX: default engine clock: 392000 kHz
amarks: oh right
amarks: so yours is only dropping 50mhz too
cxo: I'm having mplayer crash continuously recently, anyone else having that?
amarks: i've seen mplayer with double free errors
amarks: many times
dileX: Zajec: why dont add reclock.info.patch?
cxo: well this only started happening after all that alloc bug business
cxo: if i go back to 2.6.32 its fine
amarks: dileX: so 50mhz downlock is all you are seeing?
Zajec: patch downclock only by 50MHz, on every hardware
Zajec: that's temporay\
amarks: oh ok
dileX: amarks: oui
amarks: Zajec: let's go baby, agggressive downclock :)
dileX: parallel youtube-video in ffx: 840 frames 12.5 seconds 67.3 fps 4.0/14.9/151.0/8.5 ms
Zajec: night
dileX: speedup by "r300g: add acceleration of the clear, surface_copy, and surface_fill functions"?
dileX: eosie: great job!
cxo: i looked at the time, it was 9:30, and i said to myself, i would stop coding at 1pm, and now i look at the clock and its 11:15pm
cxo: s/1pm/10pm
eosie: dileX: what's the overall speedup?
eosie: in OA
dileX: eosie: yepp. 20fps -> 63-80fps
dileX: r300g dri/st
eosie: cool
dileX: yeah
eosie: however the performance still sucks due to disabled texture tiling
dileX: couldnt follow demo :-)
cxo: wants r700 speedup and glsl
amarks: did you ask santa nicely?
cxo: had that guy locked up in the basement for years
eosie: I bet you were raping him all the time
cxo: gross
ConnorBehan: I just upgraded kernel 2.6.31 to kernel 2.6.32 which has drm-next and my glxgears framerate has gone from 200fps to 1fps
amarks_: dileX: does nexiuz work for you?
ConnorBehan: is this due to missing firmware? what firmware files should I have?
dileX: whats nexiuz? a game?
eosie: nexuiz
eosie: yes, it's a game
amarks: dileX: yeah, it just crashed my box
eosie: though I would be surprised if it worked
amarks: blanked the display, box responds to ping but can't ssh in
amarks: eosie: worked in 2.6.31 vanilla pretty well
eosie: you don't mean r300g, do you?
cxo: ConnorBehan, yes, you need a new firmware file
amarks: no r700
cxo: ConnorBehan, dmesg | grep radeon
ConnorBehan: cxo: it says requesting radeon/R520_cp.bin which I have installed
cxo: oh you're on an older card, never mind
cxo: try update your userspace as well, drm,mesa,xf86-video-ati
DanaG: mmmm, serial console. can't beat that.
cxo: DanaG, you're such a baudass!
cxo: giggles at his own dry humour
DanaG: well, it IS good for grabbing stuff even when net is down,
DanaG: .
DanaG: "stuff" being console output.
DanaG: oh, and having a heartbeat LED like on my laptop, is nice, too.
ConnorBehan: cxo: drm is part of the kernel so it can't be the problem and mesa is 7.6... should it be 7.7?
cxo: when i say drm, i mean "libdrm", i was referring to the name of the repos
cxo: DanaG, http://www.youtube.com/watch?v=DTlS2fgFZrE
ConnorBehan: ooh I'm an idiot
ConnorBehan: ok I will compile everything from git
cxo: dont forget to build it in that ^^ order too
agd5f: MostAwesomeDude: we don't actually use the context switching
agd5f: airlied: any thoughts on what do when kms loads on a card without any monitors attached? e.g., two cards in system, but only one in use. right now it oopses.
airlied: it throws a warnig, it shouldn't actually oops
airlied: I've had a few ideas none good, hotplug at least lets us think abuot it a bit more
airlied: just allocate 1024x768 fb and do nothing is one option
airlied: or we wake up every 5-10 secs poll and go backto sleep
airlied: it sorta depends on whether you are the only card also
DanaG: hmm, will KMS be getting fbset abilities?
agd5f: yeah
airlied: DanaG: when someone figures out the hard bits
airlied: like wtf to do with two monitors
DanaG: cool.
DanaG: hmm, could you virtualize the two monitors as two different /dev/fbN devices?
airlied: DanaG: not without losing the console on one
DanaG: ah.
airlied: and generally I'd like the console to be everywhere
airlied: because otherwise ppl miss stuff
DanaG: What do you do with two monitors right now?
DanaG: checks...
agd5f: DanaG: clone mode
DanaG: ah. Perhaps it'd have to be panning-mode?
airlied: its kinda clone mode
airlied: we run both at native resolutions in console mode
airlied: but with the console bounded by the smallest common size
DanaG: That's cool.
DanaG: Is it then aspect-scaled to full, or just boxed?
airlied: boxed
airlied: you get borders but at least you get console
airlied: and no mode flicker when X starts
DanaG: oh yeah, weird thing: running just plain "xrandr" on this R350, makes the screen go black for about half a second.
agd5f: DanaG: if you have nothing connected to one of the analog outputs, it will do load detection to see is there is a monitor there
agd5f: which requires a crtc
DanaG: ah, I have dvi and vga connected, but not s-video.
DanaG: And only dvi blinks.
agd5f: yeah, in your case load detecction uses the crtc that happens to be driving the dvi port
DanaG: How does it decide which one to use?
agd5f: DanaG: it's hardcoded to crtc1 at the moment
DanaG: heh, xrandr --panning confuses gnome and compiz and such.
DanaG: Makes the desktop stick out beyond the "cube"
DanaG: weird... I started getting it saying "invalid time" on xrandr.
DanaG: And something was spamming my consoles and syslog with the output of sysrq help.
DanaG: SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount force-fb(V) show-blocked-tasks(W) dump-ftrace-buffer(Z)
DanaG: ah, it's serial console.
DanaG: "period of no transmission".
DanaG: it takes it to mean sysrq.
wsnelr: Should I be able to have Xorg 1.7.1 detect a Radeon HD 2400 Pro card with the current Linus git tree, and Mesa 7.6? I'm willing to keep pushing for more recent versions of software but I'm having trouble doing that 2.6.31.y git pull with the drm-next merge according to the radeonBuildHowTo page
wsnelr: This is with xf86-video-ate 6.12.4 by the way.
wsnelr: I see it now, I'm missing radeon/R600_rlc.bin