eosie: any idea how to get a cso_cache from within a driver?
lordheavy: radeon module crash while playing neverball ! http://pastebin.fr/6189
eosie: I guess not
amarks: what is
amarks: [87934.869536] [TTM] Failed moving buffer. Proposed placement 0x00060004
amarks: [87934.869538] [TTM] Out of aperture space or DRM memory quota.
amarks: the dpms fails to work, even forcing it with xset fails
koolfy: Seriously, did I do my bug report wrong ?
koolfy: Or does nobody cares about X200M anymore ?
MostAwesomeDude: koolfy: User error means that it's a bug in the 3D app.
MostAwesomeDude: I bet it still happens with LIBGL_ALWAYS_SOFTWARE=1, right?
koolfy: It doesn't happen anymore
koolfy: it just disabled my second screen, reset my WM, created no new window, is taking 99% of one of my CPUs and does not output nothing more than
koolfy: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
koolfy: Mesa: Initializing x86-64 optimizations
koolfy: Mesa: 3Dnow! detected
koolfy: is does it with any 3D application (those output messages), so that's nothing new
koolfy: at least the error I reported is gone… or it crashed somewhere before
koolfy: anyway there is NO 3D app that I know that is usable with that chipset
MostAwesomeDude: RS48x suck balls. :C
koolfy: yeah I know
MostAwesomeDude: But that specific bug looks like your app's doing something bad.
koolfy: will that chipset ever be well supported, or is it a lost cause and everyone is avoiding wasting time on it ?
koolfy: 'cause for example in warsow I get something like 2SPF (yes, seconds per frame) in the Main Menu.
MostAwesomeDude: I think every time somebody files an RS48x bug, airlied loses another couple months of life expectancy.
koolfy: nexuiz is pretty slow, and has lots of corrupted textures
koolfy: googleearth runs well, except it does not diplay cheplanet
MostAwesomeDude: So in those terms, I'd just give up.
MostAwesomeDude: On the other hand...
MostAwesomeDude: No, yeah, just buy a better chipset.
koolfy: a new laptop*
MostAwesomeDude: Oh, uf.
MostAwesomeDude: But yeah, I don't think it's gonna get much better, ever.
koolfy: damn, it's quite old, somebody should get to know it, now… Is it really SO different of others and THAT bad ?
koolfy: How come the old fglrx got to support it decently in the first place then ? :p
vomjom: btw, have the docs been released for evergreen?
MostAwesomeDude: vomjom: Nope.
airlied: koolfy: its just undocumented and very different
MostAwesomeDude: koolfy: It's just got lots and lots of quirks, and not everything was ever figured out.
airlied: koolfy: like I have an rs480 and it works mostly okay or me
vomjom: has AMD said anything about when they'll release them?
airlied: but other ppls don't work
koolfy: maybe I could figure out a way to send the frames to render to my desktop's hd4550 and download them back to my laptop via LAN :)
MostAwesomeDude: airlied: As long as we're talking about older chipsets...my rv410 still hardlocks with -145. Is there *anything* I can do to improve this?
koolfy: that would be perfect if it was even possible
airlied: MostAwesomeDude: debug it and fix it ;-)
MostAwesomeDude: airlied: Do I need to go buy a FW debugger?
airlied: MostAwesomeDude: we think the problem is an rv410 errata
airlied: the description we have is about CP DMA happening while the 2D engine is in use
airlied: I'm not sure we ever got a real workaround in place for it
MostAwesomeDude: I'd buy into that; it only locks up when inited and actually doing 2D, and appears to take longer to lock up if it's not the monitor getting heavy usage.
MostAwesomeDude: Damn, I should have asked bridgman about *that* earlier.
airlied: MostAwesomeDude: you could try adding a host clean wait to the r100_fence_ring_emit
MostAwesomeDude: airlied: I'll try that.
airlied: or maybe another wait for idle after we send the scratch reg
MostAwesomeDude: Oh, using a scratch reg to check for idle?
MostAwesomeDude: Does WAIT_UNTIL not do what we want?
airlied: in theory it does
airlied: but as you are seeing lockups, I'm not sure ;-)
MostAwesomeDude: Well, I'll do some experimenting.
MostAwesomeDude: And I'll make a mental note to ask bridgman if he happens to know more, although it sounds obscure.
airlied: the tcore quote is "Any DMA from CP to system memory while 2D engine is busy can cause a hang"
airlied: we just need to find any places we DMA to system memory, which in theory is only writing back fences regs though I'm not sure ring ptr write back isn't counted
airlied: though we don't enable that yet
airlied: my rv410 is in a box with a lack of power at the moment, I should take it into the office
MostAwesomeDude: Hm. rv410 only, though, right? Didn't affect the r420 or its brethren?
MostAwesomeDude: Well, cool.
MostAwesomeDude: I'm so excited. I might actually contribute useful things!
koolfy: isn't it always the case ?
MostAwesomeDude: Yeah, but I haven't submitted kernel patches in a long time, and this might be useful.
MostAwesomeDude: I think the last kernel patches I did were Ozzie things, svn -> git.
MostAwesomeDude: And before that it was Guitar Hero controller support. Those never got in though. :C
koolfy: that would have been a very useful thing :)
soreau: still wants to submit his N64 rumble support patch for the gamecon module :P
koolfy: would want to know one day why rumble supports works on his Ubuntu for his PSX controller, and not on his Gentoo
soreau: koolfy: Permissions.
koolfy: what does it has to do with permissions ?
soreau: Compare 'ls -l /dev/input/event*'
soreau: udev on gentoo can be uncooperative
koolfy: why would it disable the rumble but not the actual controls ? :p
soreau: you need write access for node
soreau: but that's too much, OT here
koolfy: Anyway, PSx emulators's support with the Xpress200M is pretty much zero, so problom solved
koolfy: sort of…
MostAwesomeDude: eosie: I pushed the second and third patch from your series; I need to look closer at the first one and make sure it's not too over-reaching. Also I *really* don't want that area of the driver to get cluttered; the ZTOP conditions are one of those things classic never had.
mmp: Hello; I'm just trying to use 2.6.32 (with KMS enabled) with RS690; looks like the driver fails to initialize itself...
mmp: [ 11.736040] [TTM] Failed moving buffer. Proposed placement 0x00060004
mmp: [ 11.736053] [drm:radeon_object_create] *ERROR* Failed to allocate TTM object (262144, 0x00060004, 0)
mmp: [ 11.736060] [drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
mmp: [ 11.736324] radeon: probe of 0000:01:05.0 failed with error -22
canobi: Hello! Anyone awake and willing to answer some semi-advanced driver questions? :-)
MrCooper: canobi: don't ask to ask, just ask :)
mcgreg: where is a good place to explain a problem I have with kms radeon on my r700 hardware? here itmightbe a little too long
mcgreg: it concerns switching resolutions are randr
rah: mcgreg: bugs.freedesktop.org?
chithead: you can also ask here, if you don't use newlines as substitute for punctuation :)
mcgreg: well... I'll try. chaing resolutions with randr , or any tool hat uses it , including krandr and kde itself leads my screen to some unknown frequency. swithcing back to cosole (alt f1) switches it back correctly to my native resolution 1680x1050 .. dmesg says [drm] TMDS-15: set mode 1680x1050 24 ...
mcgreg: then when I switch back to alt-f7 (XserverI) the screen remains black ... dmesg report [drm] TMDS-15: set mode 28 ... then I switch back to alt-f1 and i works again , dmesg report again [drm] TMDS-15: set mode 1680x1050 24
mcgreg: swithcing f
airlied: MostAwesomeDude: classic had ztop conditions I'm nearly sure i copied them from there
mcgreg: swithcing to al-f7 reports [drm] TMDS-15: set mode 2c ... later it is mode 2d .. and some strange stuff
mcgreg: after killing Xserver (killall Xorg) X works with the correct resaolution again ... until I try starting krandr or similiar .. again the same game
mcgreg: so .. any idea what could cuase this? I am using current git mesa/drm-master and ddx. but my kernel is .32-rc5 ...
mcgreg: should I upgrade to a more recent kernel?
canobi: OK, basically I'm trying to get the radeon driver (not radeonhd) working on my 9600 (r350) (fresh OpenSuSe 11.2 x86 install), and failing so far. The symptom is that the video mode does seem to initialize, but the screen is blank. So far I've tried setting AGPMode (tried all the values - 1,2,4, and forcing bustype to PCI with no success. The X log seems normal (i.e. no errors reported in it) - it just doesn't want to display anything. The driver is the
canobi: one released (came with the distro - 6.2.14), so I was wondering if anyone had any ideas about what else I could try.
airlied: mcgreg: worth trying drm-radeon-next, we fixed a couple of things in around dpms on/off that might help
airlied: canobi: what are you running after X?
canobi: airlined: kdm/kde
airlied: does X -retro show even the stipple?
canobi: canobi: well, let me try...
mcgreg: airlied, is there already a git reo for drm-radeon-next .. or is it a branch of drm master?
airlied: mcgreg: its a branch of my kernel repo
airlied: mcgreg: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
airlied: tv &
canobi: airlined: nope, doesn't show anything
Travis1: ok so installed Karmic 64bit. Graphics driver not working. Tried removing the "vesa" driver from my xorg.conf file and ended up with blank screen on loadup. Any help appreciated at this point
Travis1: it shouldn't be an mtrr issue since I'm running 64bit ubuntu right?
canobi: Travis1: sounds similar to what I'm experiencing, only in 32-bit
Travis1: what kind of video card do you have canobi?
canobi: Travis1: It's a sapphire desktop radeon 9600
Travis1: I don't understand what the heck is going on... I've been working on this for 3 days. I'll give it another hour or so, but unless there are any new thoughts or fixes, I'm gonna have to go back to Windows 7... sooo annoying cause I don't want to
canobi: travis: Karmic also uses 2.6.31 kernel?
spreeuw: try #ubuntu
Travis1: pretty sure that's what I'm running
spreeuw: Mesa builds again
spreeuw: the builderror of yday is gone thanks
Travis1: sorry? Are you talking to me spreeuw?
canobi: travis: Well, I'm on opensuse and there are quite a few people with the same problem. Some of them managed to get it working by changing the AGPMode option in xorg.conf, others by switching off dri or forcing bustype to pci (but the latter two options mean you'll get no 3D acceleration or it'll work slower). So try some of those if you haven't already ("man radeon" will tell you all the available options).
Travis1: what's man radeon?
canobi: travis: the man page for the radeon driver
muep_: Travis1: you can run that in the terminal
Travis1: oh ok cool. How can I check if I defo have the right drivers installed? And do you think it is worthwhile going through this guide: https://help.ubuntu.com/community/RadeonHD
canobi: Travis1: Look in /var/log/X.0.log and see what driver ("module") it's loading and if there are any errors reported.
Travis1: would that only show from the last time I logged in, or would it show the last two times? Cause the last time I logged in I had to restore the xorg.conf file with the "vesa" driver line in it just so I could load X
canobi: Travis1: Sorry, that would probably be /var/log/Xorg.0.log
canobi: travis: There are usually /var/log/Xorg.1.log Xorg.2.log, ... - they contain the logs from previous starts.
Travis1: I think the Xorg.0.log.old has info on the radeon attempt
Travis1: does that make sense? Do you think that will work if I just install the 'hardware drivers' fglrx driver?
g-zu: hi, someone broke DPI calculation again in the radeon driver
TBBle: Travis1: That last one might be worth a shot. It sounds like it matches your problem.
canobi: Travis1: It could work if you can install them. Or you can try the radeonhd driver since I think your card should be supported by that.
TBBle: canobi: Up to last night, we established that both radeon and radeonhd driver in Karmic 32-bit were failing. Radeonhd driver was crashing.
canobi: TBBIe: Ah, OK. Travis is using 64-bit though
Travis1: yeah I've installed 64bit karmic now
Travis1: yeah I've had a whole team of people helping out... hehe
Travis1: this has been such a mother of a problem
Travis1: it would be slightly irritating if that last forum post had the answer after all this. It seems so simple
canobi: Travis1: Well, it's a proprietary answer since you'll be using ATI drivers...
TBBle: Travis1: Well, that forum post would only fixed fglrx, doesn't explain the radeon or radeonHD problems. (Or at least, not specifically. Might indicate what the problem _is_, but I don't know fglrx well enough to speculate)
canobi: I wish it was that simple in my case - my card is no longer supported by ATI :-(
TBBle: Travis1: Have you tried booting with an external monitor hooked up? If it's some kind of card misprogramming issue, it might bring up the external VGA or HDMI connectors correctly if there's something plugged in at boot.
Travis1: yeah at this point I don't really care which one I get working, as long as I'm not using 'safe graphics mode'
Travis1: yeah I've booted with another monitor setup as well as with just the laptop monitor. Doesn't seem to make any change
Travis1: ok I'll try restoring my xorg.conf file back with the commented out "vesa" and I'll activate my fglrx driver from the ubuntu Hardware Drivers and follow those instructions...
Travis1: what do you think the guy means in the forum by "You might need to play with xorg.conf before aticonfig --initial will run"
Travis1: what will I need to play with in the xorg.conf file?
canobi: Travis: I have no idea, but perhaps the ATI installer will indicate the problem if it finds one....
Travis1: hmmm sure
Travis1: hey what's the code for an editor in terminal? I know I can use gedit to edit a file when in ubuntu, but if I'm in recovery mode with just a prompt, what's the code to pull up some kind of editor to change a file?
canobi: So, for us that are left in the cold by ATI, any ideas what options to tweak to try to make it work, or what diagnostics to collect that would be useful in tracing this. If you take a look at Travis' Xorg log, mine is pretty much the same - I don't see any errors reported but the screen still remains blank. Unless I'm missing something in the log.
chithead: Travis1: vi, nano, joe
Travis1: thanks man
canobi: Travis1: Go for nano or joe...
canobi: vi could be intimidating if you've never used it
Travis1: Ok so I've installed the fglrx driver now. should I delete the current xorg.conf file and just run in recovery mode and type "sudo aticonfig --initial -f" ?
Travis1: apparently that generates a xorg.conf file for the fglrx driver
Travis1: that seem like the right plan guys?>
Travis1: ok hope I'm back soon
TBBle: canobi: The thing i suggested to Travis1 yesterday was to try an older version of Ubuntu. But before that, have you tried the MTRR sanitiser thing that the RadeonHD FAQ suggests?
canobi: TBBle: Well, no, I'm not using a radeonhd driver since my card is a pre-HD one...
TBBle: Doesn't matter, the MTRR thing is suggested in the RadeonHD FAQ, but airlied thought it might be the problem Travis1 was having, so I guess it's generally applicable.
TBBle: Affects machines (particularly laptops) with >2gB of RAM.
canobi: I'll take a look at that and try it even though the machine only has 1GB of RAM.
Travis1: dammit. Card failed
Travis1: I followed the instructions...
Travis1: no black screen this time tho
TBBle: canobi: If you've only got 1gB of RAM, don't worry about the MTRR thing.
TBBle: Oh? What'd it do instead?
Travis1: just an error and loading into safe graphics mode
Travis1: the Xorg.0.log file should show you exactly what happened
TBBle: canobi: More likely to have luck with trying older Ubuntu releases.
TBBle: Travis1: Sure, let's have a look.
TBBle: Travis1: Did you try Jaunty, BTW?
Travis1: nah I didn't. That might be another step. But I'm just trying Karmic 64bit for now...
Travis1: there's the latest log
canobi: TBBle: Yes, or opensuse in my case - I know that would work. But in this case, I'd really like to track this down only I'm not sure if the distros managed to screw something up or the driver has an issue (perhaps with a new kernel). So it's a question of where to report this bug :-)
TBBle: canobi: You could try the old release, and build the newer driver for it, see if it works. If that doesn't break it, upgrade the kernel.
Travis1: is there a difference between ubuntu and kubuntu? Are they the same thing?
TBBle: kubuntu is ubuntu with KDE as the default desktop, I believe.
TBBle: Travis1: My current feeling is that your laptop manufacturer has screwed the BIOS of your video card rather badly, such that fglrx fails to run it, radeon runs it but gets a bad result and doesn't notice, and radeonhd directly accesses it and fails rather spectacularly. So unless there's a laptop BIOS update for your laptop lying around, try a Jaunty (or Intrepid, even) live-CD, and see if they can bring up the normal radeon driver in th
canobi: TBBle: True, I think I'll actually start by rebuilding the driver myself for the current release, see how that goes, maybe even try the trunk repository version and then go backwards...
TBBle: canobi: Fair 'nuff.
Travis1: TBBle so you're saying I'm pretty much screwed?
TBBle: Travis1: No. I'm saying if you can find a working version, we can work out what it's doing that the current one isn't, and hence work out how to work around your screwy BIOS. Or whatever the problem turns out to be.
Travis1: hmm sure. Ok well I'm starting the download of Jaunty 64bit
Travis1: it'll take about 1 hour
zhick: has anyone had any luck yet with kwins desktop-effects and r300g?
Travis1: ok leaving to try installing Jaunty now
Travis1: ok so now I've installed Jaunty 64bit
TBBle: Did it work?
Travis1: graphics didn't work when I was installing
Travis1: I'm currently downloading the updates
TBBle: Same problem? Clean log but black screen?
Travis1: when installing it went to black screen
Travis1: at the moment tho it loaded into safe graphics
Travis1: after installing the updates I'll try loading the proprietary drivers fglrx drivers that are recommended
Zambezi: Radeon 9250 256 MB or Radeon HD2400? I prefer HD2400 so I can use both monitors with full resolution (2048x1152), but it seems drivers are better with 9250. And I'm going to install a tv-card. Hopefully drivers will be better with Squeeze.
Travis1: will let you know how it goes...
Pallokala: Zambezi: HD2400 for sure
Pallokala: I have HD2600 with drivers from git and this is working quite well
berniyh: hi, since 2.6.32 there is that video= parameter, right?
berniyh: can I use that to set different resolution for different connectors?
uyf: does the phoronix test suite work with radeon drivers?
Zambezi: chithead: And I'm not sure Sid is something for me cause I want a stable system. But I want full resolution when I watch video. I have problems with the drivers.
Zambezi: Pallokala: Too bad 9250 won't handle 2048x1152 on both monintors. That's why I changed card.
Zambezi: I'm going to change card back to the old one and see how it'll work. Just backup first.
spreeuw: "full resolution"?
spreeuw: you have a 30"?
Zambezi: spreeuw: 2x23".
spreeuw: and you want to watch film with a bar in the middle?
eosie: MostAwesomeDude: I've am pretty sure my ZTOP conditions are correct, I've studied both r5xx docs, Depth-in-depth white paper, DX9 optimization white papers etc. all from AMD
Zambezi: spreeuw: No. I want to use them seperately, but I think I can have 2048x1152 on the first, but only 1900-something on the second.
eosie: *I am
eosie: MostAwesomeDude: the problem with the current approach in the code is that ZTOP is always disabled (not counting some ridiculous cases i.e. uninitialized registers), which is just wrong, those registers are almost always not-null, so we must check for their bits
SS3: Hello, radeon rv280 series support xvmc ?
ossman: SS3, I don't think the driver implements XvMC for any card
SS3: ossman: thanks
agd5f: Travis1: try another distro. maybe a f12 live image
agd5f: I'm pretty sure the mtrr issue is what you are hitting
agd5f: as it affects all drivers (fglrx/radeon/rhd)
amarsh04: silly question, has anyone noticed vlc to be squashing dvd video under kernel 2.6.32-rc8 with radeon or radeonhd driver, but playing same dvd video fine under kernel 2.6.31?
bridgman: maybe opengl path is available with 2.6.32 but not 2.6.31 ? are you on 6xx or higher ?
Zambezi: Radeon 9200 works better than HD2400. But will drivers in Lenny support two separate monitors? I can paste xrandr output and Xorg-log.
bridgman: by "two separate monitors" do you also mean "two separate x servers", or the randr model where the screens show different parts of a common frame buffer ?
bridgman: pretty much any driver and card combo should be able to support multiple monitors with the randr model (ie one x server across 2 displays)
Zambezi: Will dual separate monitors work with this setup? Fglrx makes computer unstable so that's not an option. Pastebin with xorg.conf, Xorg.0.log, xrandr: http://pastebin.ca/1704445
mimikry: Zambezi, I'd jsut try it :)
fabio: hi there
fabio: scrolling is slow with compiz enbled
amarsh04: bridgman, one of the Debian developers suggested a purge and re-install after removing debian-multimedia from my sources and that worked
amarsh04: radeon3200hd on the machine in question (rs780)
xeer: Hi all. On Ubuntu 9.10 2.6.31-14 with "X Error of failed request: BadRequest (invalid request code or no such operation)"
adamk: xeer: Wait, are you still using fglrx?
xeer: adamk: no, it breaks my system and flickers my terminal.
adamk: OK, then please pastebin your /var/log/Xorg.0.log file.
fabio: radeon3200hd not supported by fglrx ?
fabio: you are using XAA still?
adamk: fabio: The HD3200 is supported by fglrx. If you are having problems with fglrx, you need to ask on #ati.
fabio: i would like to have that card
adamk: xeer: You have fglrx installed.
xeer: Identifier "Card0" VendorName "ATI Technologies Inc" BoardName "RV530 [Radeon X1600]" BusID "PCI:4:0:0" Driver "radeon"
xeer: strait out of my xorg.conf
fabio: xeer: RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
fabio: you shold use EXA anyway
adamk: That's the least of his problems.
xeer: fabio: I'll have to look into that. thanks for pointing it out
xeer: I've also previously removed fglrx from synaptic
xeer: odd it is still loading..
xeer: the only references to fglrx in the log is fglrxdrm, that's the actual driver??
xeer: libfglrxdrm.so, I thought .ko was a kernel module =/
adamk: There are many parts of fglrx. You still clearly have at least two installed.
adamk: libfglrxdrm and and libglx.so
adamk: You may have other parts installed as well.
xeer: I'll see what envy can do with removing those occurrences
blaise: Aye, how can I enable shader models 2 or better? with driconf? I can't find it in there...
BioTube: blaise: for r600, it has to be compiled with -DR600_ENABLE_GLSL_TEST CFLAG
lordheavy: but shaders doesn't work very well currently
lordheavy: (for me)
blaise: oh noes, don't say that.. =(
lordheavy: it's the reason i've add (for me)
blaise: how can I tell if it's compiled with that flag?
lordheavy: with glxinfo it will be opengl 2.0 (2.1 ?)
BioTube: 2.0 Mesa 7.8-devel
blaise: OpenGL version string: 1.4 Mesa 7.5.2
blaise: freaks out
blaise: sobs uncontrolibly
blaise: so uhm, (sniff) do I need to just get the git mesa or something and recompile xf86-video-ati against new mesa?
twnqx: OpenGL version string: 1.5 Mesa 7.7-devel hmmm
BioTube: blaise: you shouldn't need to rebuild ddx
blaise: what is ddx?
twnqx: the driver.
blaise: but I will need to rebuild xorg?
lordheavy: only mesa
blaise: what about libdrm?
BioTube: it needs to be built before mes
spreeuw: libdrm, 2d driver, mesa
spreeuw: in that order
chithead: it may also be advisable to build ddx and xserver against the same version of libdrm
blaise: duh, I forgot to add the x11 overlay
eosie: you don't have to rebuild the 2d driver, just libdrm and mesa
blaise: but if I rebuild xorg then I will need to rebuild the driver yes?
blaise: or have I lost my damn mind?
lordheavy: no really needs to rebuild xorg (or if it's a *really* old xorg)
lordheavy: libdrm / mesa
lordheavy: xf86-video-ato for 2d
blaise: I have xorg-1.7.3
blaise: is that old?
lordheavy: no it's the last one
lordheavy: (before 1.8.0 release)
blaise: I'm using xf86-video-ati-6.12.4 (radeon, not ati)
blaise: and I have the radeon X1200 (RS690M)
RiotingPacifist: I seam to be stuck with a very low (maximum 1280 x 1280) screen 0 limit, how would i fix this?
blaise: that's, a very odd screen mode you have there..
blaise: very very..
bridgman: blaise, you aren't going to get GL2 / GLSL on an rs690 yet
bridgman: that has a 3D engine from the 4xx series, so it uses the "r300" mesa driver not "r600"
RiotingPacifist: it's the screen 0 maximum i don't have any display offering that but it does stop me doing dual monitor setups
bridgman: glsl support for "r300" is running a bit behind "r600"
bridgman: RiotingPacifist, adding a "Virtual" line to xorg.conf will change that
blaise: why god why!!
bridgman: exams ;)
blaise: falls to his knee's
BioTube: doesn't r300g have support for GLSL?
BioTube: or is it still in the not-working phase?
RiotingPacifist: bridgman: I don't have an xorg.conf, should i make one or just add this to hal somewhere?
bridgman: yes and no - it uses the same shader compiler as r300, and that's where the work is being done (adding support for some additional shader functions, eg flow control)
mokoloko: how "far" is r600 glsl stuff?
tormod: RiotingPacifist, make one
soreau: BioTube: Still not working quite yet
bridgman: mokoloko; richard has written initial support for flow control instructions and is going through the glsl tests fixing bugs one by one
bridgman: people are starting to enable the test flag and try games; some even sorta work
blaise: trembles as he reaches towards the sky
mokoloko: very nice! :)
bridgman: but it's still early development stages
bridgman: blaise; work had already started on 3xx-5xx glsl and Richard was familiar with 6xx so we asked him to look at 6xx/7xx glsl instead
mokoloko: what do you think we have by fedora 13(may)? :P
bridgman: it seems to be going pretty well so I imagine it will be pretty solid by F13
cire: I just read http://www.phoronix.com/scan.php?page=news_item&px=Nzc2Mg , concerning new branches for new radeon branches. I am using bleeding etch code as stated in http://wiki.x.org/wiki/radeonBuildHowTo . Do I have to change something?
cire: (kernel is drm-next, mesa, drm & xf86-video-ati is from master)
blaise: falls face first into the dirt motionless
bridgman: cire, is that the article about drm branches ?
cire: From the article: Under this new plan David will be controlling the drm-core-next, drm-radeon-next, drm-next, and drm-radeon-testing.
bridgman: yeah, ok, those are drm branches
bridgman: drm-radeon-testing is the newest stuff, I think, then it flows to drm-radeon-next and finally drm-next and into Linus's tree
bridgman: hopefully getting more mature & stable along the way
cire: yeah. At the moment I am using drm from git://anongit.freedesktop.org/mesa/drm. Is this correct right now?
bridgman: you should be able to keep using drm-next unless you want to live more dangerously and are willing to help the devs relatively more with debugging issues
bridgman: actually that's not drm any more, just libdrm (ie the userspace library which calls into drm)
bridgman: but should be fine
cire: the link I posted is not drm? So, I should use drm-radeon-next or sth. additionally?
bridgman: drm is in the kernel, so if you're getting your kernel from drm-next then you're automatically picking up pretty new drm code
cire: yeah, sorry, this came to my mind a few seconds too late (drm->kernel)
cire: thank you bridgman, it's more clear to me now
bridgman: if your focus is "using", I would stay where you are - if your focus is testing & helping development, then you could move upstream to drm-radeon-testing
cire: I think I am fine with drm-next
DanaG: How different (if at all) are drm-radeon-testing and just plain drm-next?
zhasha: eosie: got a cs file handy?
bridgman: AFAIK work is done in drm-radeon-testing, and "good looking stuff" gets moved to drm-radeon-next (in the same way good looking intel stuff moves to drm-intel-next)
bridgman: periodically airlied scoops up stuff from both and puts them in drm-next
bridgman: goes to re-read airlied's blog
zhasha: anyone got a dumped CS?
eosie: zhasha: do you mean rules-ng?
zhasha: no I mean a file with a heap of dwords in it
eosie: no, I haven't got any cs file
zhasha: can you make me one or are you not set up for it?
eosie: I can
eosie: wait a minute
eosie: zhasha: http://storm.unas.cz/cs
zhasha: eosie: I really need it unformatted
zhasha: haven't gotten around to writing an input filter for formatted CS data yet
eosie: oh sorry, I don't know how to dump an unformatted CS
zhasha: I wrote a few lines in the winsys flush function
zhasha: but I'm not really set up for r300g :/
eosie: could you elaborate on what lines you wrote?
eosie: it shouldn't be too hard to parse the formatted CS
zhasha: a for loop that wrote each dword out formatted with 0x08X
zhasha: it's not, I just haven't written the filter yet
cire: that's weird-.-- when booting up with latest drm-next, I get messed up X. (only colorful lines). libdrm, xf86-video-ati and mesa are also up to date (master). When booting standard sidux-kernel (2.6.31-6), I get X without acceleration (as expected).
zhasha: anyway, I've doctored a small CS, but it's not the same :/
cire: does anybody know those problems?
cire: also, when using drm-next, there are no errors in xorg.log
bridgman: turn off kernel modesetting
bridgman: radeon.modeset=0 in your boot string
bridgman: and see if that helps
bridgman: with kms you need to look in dmesg output for all the interesting stuff
bridgman: xorg log just says "yeah, I found kernel modesetting, nothing to do"
dmb: i know this is wrong channel, but how do you turn off modesetting with intel stuff?
airlied: nomodeset on kernel command line is generic
lordheavy: got a ttm crash with neverball http://pastebin.fr/6189 do i fill a bugreport ?
airlied: lordheavy: yup though could you try drm-radeon-testing or at least patch the radeon object rework patch
eosie: zhasha: refresh the link
lordheavy: will try these branches
cire: disabling kms helped... (although kernel said: option radeon.modeset unknown - ignoring)
cire: is kms a problem atm? It used to work, here...
zhasha: cire: just ignore the "error"
zhasha: it's not actually ignoring it
cire: yeah, I know: without that option I get colored lines instead of kdm...
cire: I just wanted to know whether this is a known problem, or my fault ;)
cire: (the broken kms)
maligor: I think I experienced the same when I had forgot to enable the kms stuff in libdrm
BioTube: cire: sounds like it's trying UMS with KMS active
BioTube: userland mode setting
cire: ahh, ok
cire: so, why should it do that...
cire: I enabled kms when compiling
maligor: if you have a extra computer, ssh in and check dmesg and the x logs?
cire: maligor: yeah, good idea. Thank you.
cire: just to ask: --enable-radeon-experimental-api is the thibng I should enable for kms, right?
cire: How do I see whether kms is working?
eosie: in dmesg
cire: okay... I just don't know what I changed, but now radeon+kms is running again...
mjr: hmh, was hd3200 usable on free drivers again?
cire: and it's faster than before. I'll reboot to verify that.
eosie: or just switch to the terminal, you'll see a difference
yacek19: Is it a proper place to ask about radeon open source driver ?
blaise: yacek19: yes
blaise: falls back over, dead once again
yacek19: ok, I have now git version of this driver, should audio over HDMI work?
cire: okay, I did a reboot and things are just fine... 2200 fps in glxgears, no artifacts when using compositing,.. cool. Thanks a lot guys.
mmp: hello, sorry for repeating the question... I tested 2.6.32 with KMS enabled; RS690 chipset (integrated Xpress 1250 Mobile); looks like the KMS-enabled driver doesn't initialize itself properly
mmp: Dec 06 10:08:31 [kernel] [ 11.736026] [TTM] Zero size memory manager type 2
mmp: Dec 06 10:08:31 [kernel] [ 11.736040] [TTM] Failed moving buffer. Proposed placement 0x00060004
mmp: Dec 06 10:08:31 [kernel] [ 11.736053] [drm:radeon_object_create] *ERROR* Failed to allocate TTM object (262144, 0x00060004, 0)
mmp: Dec 06 10:08:31 [kernel] [ 11.736060] [drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
mmp: Dec 06 10:08:31 [kernel] [ 11.736324] radeon: probe of 0000:01:05.0 failed with error -22
airlied: mmp: got the full dmesg?
mmp: yes, I can upload it in a while
mmp: airlied: http://pastebin.ca/1704658
mmp: I tried to load the driver twice; first time right at boot-time by udev; second time from runninig X server
mmp: the second time ended with kernel warning
airlied: mmp: you shouldn't do it the second way
airlied: since modesetting drivers need to load first
airlied: before X starts
mmp: yes, I realized that after that :)
airlied: so with udev loading does it work?
mmp: udev attempts to load it; and the result is failed probe
airlied: wierd it claims you have no VRAM
airlied: is there a BIOS option to reserve VRAM?
mmp: it looks like BIOS dynamically assigns some RAM to the driver, depending on total installed amount
mmp: *to the GPU
airlied: can you paste a log from nomodeset /var/log/Xorg.0.log
mmp: in a while
airlied: oh what sort of CPU have you?
airlied: realises its in the log
mmp: airlied: http://pastebin.ca/1704666
airlied: mmp: okay its an rs600
airlied: so there are some patches on the mailing list we need to test
airlied: if you are building your own kernel you can apply them and try
mmp: argh, sorry :-) RS600; I'm just overworked
mmp: yes, just point me on them
airlied: mmp: two patches from Alex Deucher, http://email@example.com/msg45185.html
airlied: maybe http://firstname.lastname@example.org/msg45116.html
airlied: mmp: I'll probably be pushing them into a git branch later today, but it would be nice to know if they helped
airlied: bbl &
mmp: I'll try, but so far I'm looking for 'download raw' button ;-)
yacek19: I have now git version of radeon driver, should audio over HDMI work?
Zajec: yacek19: no
spreeuw: I heard sonmeone had audio working though
spreeuw: at some point
politas: Hi all!
politas: Trying to find out what the status of 3D support for the HD3400 series cards is, and if it's working yet, how I get it installed on Ubuntu
BioTube: politas: it works great for me
BioTube: just follow the link in the topic, except you can use 2.6.32
BioTube: (still need to reconfigure it)
politas: I have to build it from source?
Ghworg: There is a ppac called edgars I think
Ghworg: This is it I think https://launchpad.net/~xorg-edgers/+archive/ppa
Ghworg: Can't remember what PPA stands for, but it is an independant package repo for ubuntu
DanaG: Personal Package Archive.
DanaG: also, Ubuntu does have the upstream-kernels PPA, but it's not a "real" ppa (that is, it won't work in sources.list).
DanaG: google for kernel-ppa.
airlied: mmp: drm-radeon-next has two of them
airlied: I'll push the 3rd out
mmp: airlied: ahh... ok; I didn't test them yet; looks like mainline is far behind drm-radeon-next
mmp: the patches dont seem to apply cleanly
mmp: (and I'm afraid it's not only the formatting)
blaise: wow, git libdrm, radeon, and mesa worked eith the shaders..
blaise: I can't belive it
airlied: mmp: all 3 patches will be in drm-radeon-next in a few mins anyways
airlied: mmp: I'll put a patch up for 2.6.32 that might work
airlied: mmp: http://people.freedesktop.org/~airlied/scratch/drm-radeon-next-for-rs600.patch
mmp: airlied: thanks a lot :-)
airlied: that might apply cleanly to 2.6.32
spreeuw: is there anything performance enhancing in > 2.6.32?
airlied: spreeuw: interrupts for r600 gpus might help perf, at least save us burning CPU
spreeuw: its quite stable as it is
mmp: airlied: applied cleanly
airlied: mmp: cool
spreeuw: I havent had a single crasher with git userland on 2.6.32
spreeuw: or on rc8
DanaG: oh yeah, random thing: fglrx auto-resizes on hotplug hdmi, but not on hotplug vga... what does radeon do?
DanaG: And does vga not support hotplug the same way hdmi does, or something?
spreeuw: above patch has the interrupts?
airlied: DanaG: Alex just wrote the hotplug detect support for digital outpus
airlied: VGA doesn't do hotplug without special hw
airlied: which I'm not sure radeon's have
airlied: spreeuw: no
airlied: spreeuw: they are in a testing branch still
DanaG: hmm, how much power does it take to poll a connector for load presence? You could poll vga once every, say, 3 seconds.
airlied: DanaG: polling is generally considered bad
DanaG: Even at that long of an interval?
airlied: we are thinking of doing it maybe for chips where we don't detect anything plugged in
airlied: DanaG: yup anything that wakes up is bad even 3 secs or so
DanaG: hmm, I wonder if you could combine it with a "while you're awake, anyway...".
airlied: the problem is it takes a long time to poll
airlied: doing a EDID or load detect isn't quick
bjaglin: hi! i eventually got KMS up and running on my RV250, but the performance makes it unusable, especially scrolling (gtkperf for scrolling is 6x slower in KMS compared to UMS, scrolling in firefox makes the CPU goes up around 80%). Is there something I can do? I saw http://bugs.freedesktop.org/show_bug.cgi?id=23085 and it looks like there is no workaround for now?
bjaglin: i am running 2.6.32, and xorg-edgers did not help at all
DanaG: aah, load-detect is slow? dang. Even just "is there anything there?", and not a full edid?
DanaG: Then again, just relying on hotkeys may be good enough anyway.
DanaG: oh yeah, something funny my laptop's win7-compatible BIOS does: changes fn-f4 (was xf86video) to Super-P.
airlied: bjaglin: what X server?
spreeuw: bjaglin: do you have hardware acceleration enabled
spreeuw: uh maybe that only applies with composite , nevermind
bjaglin: airlied: xserver-xorg-video-ati? it's from the ubuntu x, 6.12.99+git20090929
bjaglin: spreeuw: yes i have DRI2
spreeuw: gtkperf is a bit slower in KMS here too
airlied: bjaglin: no xorg-x11-server
airlied: or whatever they call it
airlied: really a 1.7 X server is much better for KMS accel than 1.6
spreeuw: I think I went from 5s to 10s
tormod: bjaglin, you probably have xserver 1.6
spreeuw: mostly because of the coloured circle test
spreeuw: btw the newer xorg server can be compiled without building against a mesa tree
tormod: bjaglin, you should try lucid (xserver 1.7) or add xorg-edgers (xserver git master)
spreeuw: thtas kinda handy
bjaglin: tormod: if you say so :) what is the correct package? i am getting lost with drm dri ddc etc
airlied: gtkperf for some tests is pointless
bjaglin: if xorg-edgers on karmic has 1.7, then i tried it already, xorg-edgers did not help at all
tormod: bjaglin, no you need lucid
bjaglin: i am just trying to figure out what makes my scrolling so slow, its barely usable
tormod: bjaglin, karmic xorg-edgers has only 1.6.5
bjaglin: tormod: ok, i can try on a live cd i guess... or can i build it myself?
mmp: airlied: doesn't work, at least not cleanly
tormod: bjaglin, you can try a lucid live CD and add the PPA there
mmp: airlied: after loading module, screen remains black; although from logs, initialization seems to be OK
airlied: mmp: can you post the dmesg?
mmp: anyway, I think starting Xorg caused lockup
mmp: airlied: working on it :)
airlied: mmp: Alex was still investigating I think in a bug (not sure if you were who he was talking to ;)
bjaglin: tormod: all right, i'll try that
airlied: mmp: http://bugs.freedesktop.org/show_bug.cgi?id=25408
mmp: airlied: you are the first person I talk to on #radeon (at least after a long time:)
mmp: airlied: http://www.pastebin.ca/1704782
airlied: mmp: cool it might be worth joining that bug and mentioning you are on irc, so agd5f can get feedback
mmp: okay, can do; but I'm in GMT+1, so I'll be mostly available in the evenings (at least here:)
mmp: *in evenings
airlied: ouch all that corrupted low memory stuff looks bad, I'd blame the GPU for that.
mmp: airlied: hard to say, have a look on the physical addresses
mmp: this laptop has/had problems with suspend/resume because of corrupted memory
mmp: so this may or may not be GPU-related
mmp: realizes that he needs bugzilla account to register
DanaG: hmm, does it work with vesa?
DanaG: does vesa do suspend/resume?
DanaG: oh yeah, and I realized my uefi is screwed up... the framebuffer claims to be at address 0x0.
DanaG: what the service manual says the mem map should be: www.csc.calpoly.edu/~dgoyette/memmap.png
mmp: airlied: done (Cc:-list on bugzilla); I hope I'll be able to help
airlied: mmp: can you try without the last patch?
airlied: mmp: I'll upload a new patch
airlied: mmp: http://people.freedesktop.org/~airlied/scratch/rs600_2
airlied: again on 2.6.32
mmp: airlied: ok; just a moment to unpatch&patch
airlied: I'm just wondering if the change to set the mc up like r600 did something bad
airlied: goes to fix s3tc for once and for all
mmp: brb; going to test kernel
flyback: orders cheap pci video card with tv out for testing his lcd video projects
Ronis_BR: airlied: I got kernel panic with drm-radeon-testing + linux.2.6.32 when I enable modesetting :(
airlied: Ronis_BR: do you have firmware installed?
Ronis_BR: airlied: firmware?
airlied: Ronis_BR: are you using an r600?
Ronis_BR: airlied: r700
airlied: okay you need to get the two firmware files and install them
airlied: they aren't shipped with the kenrel
Ronis_BR: airlied: I'm using 2.6.32 vanilla and everything is fine
airlied: Ronis_BR: yes the irq code isn't in that
Ronis_BR: airlied: so, need to clone git again, I'll teel you if everything is fine
Ronis_BR: thanks airlied!
airlied: Ronis_BR: the fw files are in the kernel at all
Ronis_BR: airlied: what?
Ronis_BR: airlied: so, what was the problem ?
airlied: Ronis_BR: not in the kernel at all
airlied: damn I forget the important word
Ronis_BR: airlied: wait, so fw aren't in kernel right
airlied: yup, you need to download them from the link and put them inplace manually
Ronis_BR: airlied: so I need to clone kernel again, merge drm-radeon-testing, install the new kernel and the fw files right
Ronis_BR: airlied: thanks, I'll try to see if tuxonice becomes compatible :D
airlied: well if you kept the last clone, you can just re-use
Ronis_BR: airlied: no I didn't :D
mmp: airlied: no change; maybe except that magic sysrq doesn't work
rhodan: What is color tiling?
airlied: its an optimisation used by gpus to keep chunks of color buffers close together for caching reasons
ConnorBehan: are there known problems with running xrandr --output VGA-0 --left-of DVI-0 when using modesetting and xorg-server>=1.7
mmp: airlied: btw, did you get my message?
mmp: (second patch didn't help)
airlied: mmp: yup just reading over the code trying to spot where is messes up
mmp: ahh, ok :-) I just wasn't sure
ConnorBehan: oh and does the line "vga-arbiter missing from kernel" have anything to do with being able to use xrandr or not?
airlied: ConnorBehan: no
bjaglin: airlied: i just tried xserver 1.7, and it does not seem to have any impact on my scrolling performance/gtkperf score. Any other suggestion? I was reading somewhere that the KMS hook for DownloadFromScreen was not implemented, is this still true/relevant?
airlied: bjaglin: no
ConnorBehan: do you have dualhead with xrandr working with radeon KMS and xorg-server 1.7.2?
airlied: under Fedora 12 yes works for me here fine
ConnorBehan: do you have a Virtual line in your xorg.conf?
ConnorBehan: with modeset=0 xrandr tells me that I'm trying to exceed the max display size
ConnorBehan: which sounds like it requires me to specify a virtual resolution
ConnorBehan: but with modeset=1, "xrandr --output VGA-0 --left-of DVI-0" causes an instant segfault with or without a Virtual line
airlied: ConnorBehan: no with modeset you shouldn't need a virtual
airlied: ConnorBehan: segfault where in X server?
airlied: mmp: care to try a patch on top of the first one I sent?
ConnorBehan: airlied: I haven't tried debugging with ssh yet but the minimal backtrace I got started in /usr/bin/X and then listed symbols in /usr/lib/xorg/modules/drivers/radeon_drv.so
airlied: ConnorBehan: care to post the Xorg log?
airlied: mmp: http://people.freedesktop.org/~airlied/scratch/rs600-mc-fix.patch on top of the first patch
mmp: in a whihle
airlied: mmp: thanks
airlied: back later &
mmp: (sorry delay, I just debug some (by accident computer graphics) homework
ConnorBehan: airlied: I downgraded the xserver a few minutes ago to get dualhead back
airlied: mmp: no worries gotta go to the gym anyways
ConnorBehan: when I have more time to investigate this I'll post the log... but I remember the only WW it had that 1.6 didn't was about the arbiter
ConnorBehan: and no EEs
mmp: airlied: s/uint32 /uint32_t / (line 51)
mmp: airlied: partial success -- looks like it boots (although console screen is black); I can start X server, which runs fine
mmp: unfortunately, I don't have DRI2-enabled modules
mmp: argh, X11 drivers
mmp: so I can't easily test it
mmp: (I thought KMS is already part of newer userspace :)
mmp: airlied: update: black screen was my fault; I've been missing framebuffer console driver
mmp: (or, correct me, if KMS-enabled driver can also work in pure text mode)
mmp: airlied: the patch just needs a bit cleanup to be compilable ;) but then it works
airlied: mmp: oh cool, /me fixes patch, yes fbcon is requireed
mmp: it just looks like there's some problem with mesa git repo; I can't clone it...
PyroPeter: glxgears and glxinfo output "do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly."
mmp: airlied: so I'll test it probably tomorrow...
BioTube: PyroPeter: IRQs were only recently implemented
BioTube: and they need firmware still not in any of the kernel branches
PyroPeter: Do they provide additional performance?
airlied: mmp: it can take a long time to start cloning
BioTube: PyroPeter: AFAIK, they just eliminate busy waits
PyroPeter: ok. I will just wait for them to be in the kernel branches.
PyroPeter: by the way: you are doing great stuff, I just installed kernel 32 and updated mesa and video-ati. kms works great now. ( HD 3450)
mmp: airlied: yup, just started few minutes ago
mmp: any idea whether it is sane to compile mesa with gallium3d support?
MostAwesomeDude: Not really sane, but it shouldn't suck as much these days.
mmp: MostAwesomeDude:: in terms of performance or stability?
airlied: MostAwesomeDude: swtcl works okay?
MostAwesomeDude: airlied: ctwls? Whazzat?
MostAwesomeDude: No, SW TCL's still busted, probably.
mmp: starts to get a rough idea abould gallium state
MostAwesomeDude: Yeah, don't even bother if your chipset name starts with RS.
mmp: I'm afraid it starts :)
mmp: ok, gonna try dri2 userspace; if something goes wrong, good night and thanks a lot for help :-)
eosie: sometimes plays xmoto with a gallium3d driver
bjaglin: how can software rasterizer be up to 10x faster than DRI2 with gtkperf?! I just tried drm-next looking for better scrolling performance and found some really good results, but it turned out that i had just switched back to software rasterizer :)
eosie: recompile libdrm
bjaglin: i didn't compile anything on my own, got all from repositories
airlied: gtkperf doesn't use 3D driver
eosie: MostAwesomeDude: pls read what I wrote here for you about 11 hours ago
MostAwesomeDude: eosie: I did.
MostAwesomeDude: I'll have to see for myself if it's good; when I get back in a few hours I'll test and push.
mmp: airlied: ok, so userspace doesn't seem to work correctly for me -- it rendered weird things (e.g. screen split to blocks) and then locked up...
MostAwesomeDude: Or get airlied to push it. :3
airlied: mmp: what running?
mmp: git versions of libdrm, xf86-video-ati and mesa
airlied: mmp: so X doesn't start?
mmp: X does start
mmp: gdm seems to render something, somewhere even recognizable
mmp: but e.g. screen is split to I think 8 vertical stripes...
airlied: hmm wierd
mmp: some letters from fonts were not rendered correctly, etc.
airlied: can you post the log file, and dmesg?
mmp: I'll try, but the lockup was hard, I wonder if the logs were flushed to disk
mmp: airlied: dmesg: http://www.pastebin.ca/1705007
mmp: airlied: xorg log: http://pastebin.ca/1705009
eosie: MostAwesomeDude: ok, I can wait
airlied: mmp: it works all okay with non-kms btw?
mmp: airlied: btw; when running the DRI2 setup, my wallpaper was rendered properly, so I guess raw framebuffer operations are OK (and as well display timing)
mmp: airlied: yes, running right now from it
mmp: (to my big surprise, DRI1 seems to work as well)
airlied: mmp: if you have time can you try the rs600_2 and r600-mc-fix patches
airlied: just to rule out the MC setup code
mmp: airlied: ok, in a minute..
mmp: airlied: in short: [ 12.569961] radeon 0000:01:05.0: Disabling GPU acceleration (going to upload whole dmesg)
mmp: but seems to work otherwise
airlied: okay so it turns off the accel engine so stuff works in sw only mode ;-0
mmp: airlied: http://www.pastebin.ca/1705037
mmp: airlied: but from some weird point of view it works better when compared to disabled dri :)
mmp: (not sure what acceleration is from accel engine)
mmp: airlied: I have to go offline now; it's too late :-/
airlied: mmp: no worires I'll push the VRAM fix and think about it some more
mmp: better said too early; I'll be online in ~18hrs
mmp: maybe sooner
mmp: also, if possible, the rs600_ mc_init fix :)
airlied: yup will push that also
mmp: airlied: good night and thank you :)
airlied: resurrects r100 hyperz support
airlied: just as an experiment for now
cxo: My system crashes whenever I try /usr/lib/xscreensaver/hyperspace Can someone confirm if thats a screen saver bug or driver problem? (Using r700 here)
vomjom: cxo, if your entire system crashes because of a screensaver, it's a safe bet that it's not a screensaver problem
cxo: the signal is out of r600_dri.so , i'll file a bug report if someone else can reproduce it
dmb: experiment with mach64 :P