z3ro: hmm new headphones sound a lot different... although considering my old ones were held together with tape... :P
spstarr: z3ro: I went though 4 headsets.. the each ended their life with tape until they shorted out ;(
spstarr: in 3.5 years
z3ro: yeah. I usually end up standing on the cable, then standing up and ripping the cable out of the headphones. =/
z3ro: luckely they are only cheap $30 things usually.
spstarr: z3ro: it usually gets to the point where I have to bend the wire in different directions to fix the short
spstarr: at this stage, the headset is begging me to put it out of it's misery ;)
z3ro: heh :P
spstarr: until one side of the headset loses audio and i only get unisound ;(
z3ro: hmm is fd.o git down or something? having trouble pulling.
z3ro: although it's possible it's just my crappy connection.
spstarr: THEN i rip out the cable in a tear of murderous anger :D
spstarr: goes to sleep
hifi: I keep the cable on my desk so I couldn't stand on it when I'm getting up
hifi: though another thing is when you walk away headphones on and realize it when you pull down your stereos
hifi: or pull your soundcard off the pci slot (yeah, that can happen) and crash your computer
hifi: somehow my headphones have always survived but my other gear isn't so lucky
hifi: haven't used headphones for a while, I can use speakers at home
z3ro: yeah, I'm going to love that when I move. :)
z3ro: brb, going to see if I can push some packets to a r6xx card.
z3ro: ah damn. forgot to hack the drm.
z3ro: anyone know about: [drm:radeon_cp_buffers] *ERROR* Process 17406 trying to get 3 buffers (of 0 max)
z3ro: this is on the r6xx-support branch, so maybe it doesn't setup dma buffers yet?
dogson: is there any plans to support hdmi audio on RS690?
z3ro: hmm I guess X isn't setting up the drm properly... I tried manually initializing it, but that seems more trouble than it's worth.
z3ro: agd5f: do you have a patch somewhere for the DDX to bring up the DRM on r6xx?
z3ro: hmm weird... forcing DRI on works, but then the X server segfaults in libdrm
z3ro: er, libdri, I mean.
dogson: sorry about that
agd5f: z3ro: the current r6xx-drm bits don't work. We have an internal tree that's fixed
z3ro: agd5f: hmm I see. I guess that won't be released until the docs are?
z3ro: I was kind of hoping to do a bit of messing around with some of the packets in the meantime. :)
mikkoc: git down?
logari81: what is vblank_mode? googlearth tells me to set it on a X1950pro, Xserver 1.5.2
adamk: logari81, You can set that via driconf... It's the "Synchronization with vertical refresh" option. There is a way to set it as a variable before launching an app (maybe 'vblank_mode=1 googleearth' ?) but I'm not sure I remember exactly how.
adamk: Are you actually getting something like 'do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.' ?
adamk: And then "Try adjusting the vblank_mode configuration parameter.'
logari81: adamk: exactly
adamk: Yeah, try 'vblank_mode=0 googleearth' or 'vblank_mode=1 googleearth'... I think sync to vblank is broken in the r300 driver in Mesa7.2...
logari81: adamk: already have tested "vblank_mode=0 googleearth" with small improvement on the performance, unfortunately its not my machine and I can't test the rest right now, but thank for the tips
logari81: what else could cause performance issues with googleearth?
adamk: logari81, Make sure that "disable low-impact fallbacks" is enabled in driconf, too.
logari81: adamk: that's what i also thought about, but normally googleearth warns me about it, in this case it didn't
logari81: I ll try it also anyway
icewaterman: i have new insight on the regression with the textures i was talking about.
icewaterman: it seems my radeon x1600 pro is not affected, my x1200 (onboard) and my x850xt are affected on the other hand
icewaterman: http://home.arcor.de/irc-stuff/pics/texture_issue_radeon_linux.png <-- that seems to apply to x1200 and x850xt while it doesnt with x1600 (same driver)
luke-jr: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
luke-jr: [mi] mieqEnequeue: out-of-order valuator event; dropping.
luke-jr: (hard lockup ☹)
luke-jr: 01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL MobilityT2] (rev 80)
luke-jr: it also locks up on any suspend/resume
luke-jr: Linux yoko 2.6.26-gentoo-r2 #1 PREEMPT Fri Oct 31 01:09:39 CDT 2008 i686 Intel(R) Pentium(R) M processor 1.80GHz GenuineIntel GNU/Linux
luke-jr: X.org 7.4, mesa 7.2
fat_chris: airlied, I'm having some issues with KMS
fat_chris: first of all it doesn't always work so i get no video at all
fat_chris: if it does work, sometimes when i start X it hard locks
owen_: fat_chris: airlied isn't going to be awake at this hour of the day
owen_: fat_chris: what hardware?
fat_chris: and if i'm in X and it's working, it randomly locks up for a couple of seconds
fat_chris: x1900 xt
owen_: fat_chris: Hmm, weird, that's something I'd expect to work well
owen_: fat_chris: how hard a lock is it? can you ssh in to the machine from another machine?
fat_chris: but can't do anything actually at the machine
owen_: fat_chris: If you can attach to gdb and get a backtrace (gdb /usr/bin/Xorg -p `/sbin/pidof Xorg`) and get a backtrace, that can be useful information for a bug report
owen_: If you can't, or the backtrace shows it inside the kernel., then doing 'echo t > /proc/sysrq-trigger' may dump useful stuff into your dmesg
fat_chris: do this when it locks up yeh?
owen_: fat_chris: Yes
fat_chris: ok it hasnt hard locked but when i started X the monitor no longer recieves a signal
fat_chris: ill run the command now
fat_chris: "gdb: option '-p' requires an argument" ?
fat_chris: my dmesg out put is here: http://pastebin.com/m37e4d50b
luke-jr: owen_: any ideas for me?
owen_: fat_chris: did you get some sort of message about 'pidof command not found' ?
fat_chris: at first yes as it was /bin not /sbin
owen_: luke-jr: No ,not really. though the same advice about how to get useful information for debugging that I gave to fat_chris pplies
fat_chris: X wasnt running i figured to thats why pidof Xorg didn't return anything
owen_: fat_chris: X wasn't running?
owen_: fat_chris: if X segfaulted, and died leaving your computer frozen, you should have interesting stuff at the end of /var/log/Xorg.0.log
fat_chris: nope theres nothing interesting in there at all
fat_chris: last line is "(++) using VT number 7"
owen_: fat_chris: So, you start X, X exits silently, and then your system is hosed?
fat_chris: yes, but this doesn't happen every time and not always the same way
fat_chris: sometimes i get to kdm but it will be the wrong resolution and when i try to switch to console or kill X then "no signal" is all i see
owen_: fat_chris: Anything unusual about your monitor?
fat_chris: not really
owen_: fat_chris: DVI? vga?
fat_chris: im figuring it's because im not on fedora as i dont get these problems on fedora rawhide on the same computer and monitor
fat_chris: dvi -> hdmi
owen_: fat_chris: that strikes me as unusual :-)
owen_: fat_chris: So, a custom build breaks, but KMS in F10 works?
owen_: fat_chris: ah, didn't catch that. What that probalby means is that airlied has fixed something, and you don't have the fixes. Trying to keep all the different kernel trees straight and what is in what is pretty hard
fat_chris: at the weekend i even tried using a fedora patched kernel but it was the same
fat_chris: if not worse
fat_chris: well im using zen-sources from git which im pretty sure is up to date with the drm bits
owen_: fat_chris: airlied may have some ideas (he's in .au, so will be around in 4-5 hours) I was going to tell you to file a bug in fedora bugzilla with as much information as you have, but if it works for you with F10, well,then don't do that :-)
fat_chris: ah ok
owen_: fat_chris: you could compare that to the gpu/drm bits in the drm-rawhide branch of airlied's 'drm-2.6' tree on kernel.org, which is *pretty much* what is in rawhide
fat_chris: im pretty sure it has everything except the last 2 commits
fat_chris: the best person to talk to about it would have been rmh3093 as he maintains zen-sources i think but he left
hifi: any tweaks to get more out of R300 (9600)
hifi: getting really low fps at quake 2 (arount 30)
luke-jr: yay, another freezeup -.-
tlp: hifi: might try 'man radeon' -- there are some performance suggestions in there
tlp: I don't know if any helped my R500.
amf: I'm a little unclear about the X1650 (RV535), it's listed both in the radeon/radeonhd driver man pages. The former seems to support Xvideo, x.org loaded the radeonhd driver, thus giving me no Xvideo... is the radeon driver only for the AGP version?
jcristau: both should support xvideo..
adamk: They both support almost the exact same features at this point.
amf: xvinfo returns nothing... I am using PCIE
adamk: amf, Then perhaps you are using an older version of the driver.
rmh3093: do any of you know where to get egl
adamk: Can you pastebin your /var/log/Xorg.0.log file?
amf: adamk: I have radeonhd 1.2.3 from git
jcristau: amf: what kernel?
amf: adamk: http://pastebin.com/m79659df4
amf: jcristau: Linux an 2.6.26-1-amd64 #1 SMP
jcristau: 453. (WW) RADEONHD(0): DRI support has been disabled at compile time
amf: jcristau: I'm still getting DRI failed in configure, I have the dri headers... is there anything else special I need (package wise)?
legume: amf: With current gits I found that radeon is better than radeonhd for 3D and exa on my X1600
amf: legume: I'm assuming you had to force x to use that driver?
tlp: legume: Is the git driver for radeon 'xf86-blah-ati'?
tlp: -ati being the important part.
amf: tlp: It is
tlp: wasn't sure if it was the same driver
nulleke: When I use metacity composite extension 3d content (like glxgears) always stays on top. Is this normal? I use the radeon driver.
legume: amf: I just edited /etc/X11/xorg.conf
oga: nulleke: yes. it's because of how DRI interacts with composite. DRI2 will fix it.
tlp: Is DRI2 a distant project, or is it under way?
nulleke: oga: Ok. I'll wait for DRI2
legume: amf: Driver "ati" and Option "AccelMethod" "EXA" are all you should need in the device section
adirex: Hi everyone, I'm trying to setup HDMI audio output for Mobility Radeon HD2400. I have the latest radeonhd driver installed from source, alsa compiled with all codecs and all cards, but when I type "aplay -l" the HDMI output is not listed. Any ideas on how to solve this?
yangman: adirex: HDMI audio isn't enabled by default. look at the HDMI option in radeonhd man page
adirex: yangman, if you are talking about the setting in xorg.conf, so I have it enabled: Option "Audio" "on" \ Option "HDMI" "all" but still it does not work
yangman: adirex: aplay -l not listing it is an alsa issue. radeonhd doesn't deal with the audio chip itself, just enabling it to send data through the outputs
yangman: adirex: in any case, this is more appropriate for #radeonhd
luke-jr: desperately need help--this freeze occurs pretty often ☹
adirex: yangman, thanks
adirex: yangman, one small question, how can I find out the version of my radeon driver?
fat_chris: luke-jr: i see you're on gentoo, see if xorg-server-1.5.2-r1 from the x11-overlay helps
luke-jr: fat_chris: will I need to rebuild drivers?
luke-jr: * Overlay "x11-overlay" does not exist!
fat_chris: its just called x11
fat_chris: you wont need to rebuild drivers
rmh3093: fat_chris, he's just suggesting to use xorg-server from the x11 overlay, you dont need to use the ati driver from there
fat_chris: you mean luke-jr? :p
luke-jr: # version with _massive_ EXA patches from git master
luke-jr: # could very well kill kittens, DO NOT USE
luke-jr: is scared
fat_chris: haha its not that bad, working alright here anyway
luke-jr: fat_chris: promise it won't kill my kittens?
fat_chris: well, no promises ;)
luke-jr: do I need to reboot?
fat_chris: no just restart X
luke-jr: I don't know if that will work XD
luke-jr: fat_chris: will it fix the suspend issues too?
fat_chris: no idea
fat_chris: try it and see
fat_chris: you can always downgrade
luke-jr: fat_chris: my biggest fear is it wiping my HD
fat_chris: i don't think there's a chance of that happening
luke-jr: but it will kill kittens?
airlied: fat_chris: is your DDX kms compliant?
airlied: it sounds like it might not be.
fat_chris: im not sure what that means
airlied: fat_chris: where did the 2D driver you are using come from?
fat_chris: i got the -ati driver from fedora
airlied: okay that should work.
airlied: it sounds like it might be getting stuck in vt switch somewhere.
fat_chris: indeed, ive been trying to compile zen-sources with the updated drm but it wont compile and i have a feeling that will fix it
rmh3093: airlied, he is using my ebuilds
rmh3093: he was
tlp: Wayland sounds neat.
rmh3093: tlp, i tried building that just a min ago
rmh3093: i think it need a special dri lib
fat_chris: im still using libdrm and mesa from your ebuilds
rmh3093: and does ot seem to work with radeon yetr
tlp: I ought to try the kms stuff on my card, see if it explodes.
fat_chris: rmh3093, any ideas why zen wont compile even with the "'blk-core.c' fix." commit
rmh3093: fat_chris, that should be in the zen chan
fat_chris: yeh good point
fat_chris: airlied, any reason why this would happen? "[drm] TMDS-10: set mode 0"
fat_chris: i get this at the end of dmesg after just shutting down X and now i get "no signal" again
airlied: fat_chris: what X server you using?
fat_chris: 1.5.2 with some exa patches
rmh3093: airlied, so im using the new code you pushed yesterday and the mem leak is gone which is nice cause X dont restart randomly now, however, now every once and a while it seems to lock up for a second then go back to being normal
fat_chris: i also have the same problem as rmh3093
airlied: rmh3093: yup there is a 3 sec pause issue I'm trying to track down.
airlied: its not very reproducible here.
airlied: I got it once yesterday across 3 machines testsing
rmh3093: i seemed pretty reproducible here, let me see if i can get a routine for you to try
rmh3093: ehh i cant remember what I was doing before
owen_: airlied: I'm getting the pauses a lot modesetting off on r300. (With modesetting on, I'm not staying up long enough to know...)
spstarr_work: rmh3093: yes
spstarr_work: airlied: thats the stalls I noticed
spstarr_work: owen_: stalls?
owen_: spstarr_work: I didnt' investigate whether there was dmesg output, but the pointer and everything else locks up for a coupel of seconds
owen_: the pointer locking up is quite interesting, since it means that it isn't just a drm ioctl blocking
spstarr_work: i recalled that (see my stall msgs in log)
spstarr_work: this is without composite on
owen_: airlied: On a more positive note (r500 performance problems, not r300/agp misbehavior), I have a question or two aboutt RADEON_DFS_CS() when you have a minute
rmh3093: spstarr_work, im using gnome composite manager
spstarr_work: rmh3093: im using without in this case
fat_chris: i get the pauses whether im using composite or not
spstarr_work: i guess a drm ioctl must be blocking? not async?
spstarr_work: since video is not async
spstarr_work: sequential events i think?
rmh3093: airlied, ok im getting that pause
rmh3093: i had a compile going on gnome-terminal w/ transparent background
rmh3093: and switching between open windows
airlied: owen_: DFS_CS?
airlied: I can't see how the pauses could be happening under no kms though.
airlied: the ones I can produce here are fence waits that don't seem to end so they hit the 3 sec timeout
Ferocanis: should the current driver source from git build right now?
Ferocanis: because it's not for me =/
Ferocanis: wait a second...
Ferocanis: should the repository be git://people.freedesktop.org/~airlied/xf86-video-ati ?
jcristau: try git://anongit.freedesktop.org/xorg/driver/xf86-video-ati
Ferocanis: didn't think so....
owen_: airlied: I can't swear that the hangs were without KMS, I'll pay better attention next time
Ferocanis: i'm using an overlay in gentoo, i guess airlied's repository is someone's idea of bleeding edge
owen_: airlied: In terms of the other stuff, I was looking into compiz performance on r500 which was really slow to me
airlied: owen_: we don't have zero copy TFTP.
owen_: airlied: And what I saw that was alll the time was going in DownloadFromScreen ... yes, no zero copy TFP
airlied: until DRI2 appears.
owen_: airlied: but we've never had TFP and it was fine
airlied: we have zero-copy TFF without kms
owen_: airlied: So, i think the non-zero-copy TFP is particularly slow for some reason
airlied: TFP is always slow without zero-copy.
owen_: airlied: Oh? hmm
owen_: airlied: It still feels to me that the DownloadFromScreen is reading from uncached memory or something
fat_chris: Ferocanis, which overlay are you using?
airlied: owen_: DFS_CS is reading from uncached memory
airlied: owen_: I don't think I can blit into cached memory.
owen_: airlied: I was seeing all the time being spent in memcopying from the scratch buffer to system memory, and none in moving texture data around elsewhere, so that memcopy is apparently much slower than anything else
airlied: yup the temp bo is uncached, but DFS has always been like that.
owen_: airlied: Hmm, then why not just read straight out of vram? is acceldfs buying anything?
Ferocanis: fat_chris: emerge pulled the one from zen-overlay, there's one in the x11 overlay too =/
airlied: owen_: it does buy something, VRAM is slower.
airlied: as you have to cross the bus.
Ferocanis: fat_chris: same version and everything. i'm looking into how to choose one over the other
fat_chris: use the one from x11
owen_: airlied: Presumably once it is in system memory, its' pretty much like the intel case. For intel, they are adjusting the mappings on the fly, right?
fat_chris: the one in zen is for kms
airlied: owen_: no you can't really do that.
airlied: owen_: Intel is a different case.
Ferocanis: fat_chris: yeah, i intend to... i suppose i could mask the one in the zen overlay
airlied: they don't have to deal with AMD CPUs for one thing.
airlied: I do wonder if I could get PCIE blit to cached mem working but I suspect pain and suffering.
airlied: it would be easier to help finish DRI2
Ferocanis: never mind, that doesn't work...
owen_: airlied: So you don't think you can blit to cached memory, then just flush caches before reading?
airlied: because really the CPU doesn't want to see the data, its GetImage followed by TFP.
airlied: owen_: no I know you can't do that.
owen_: (I say cavalierly "just flush caches", which presumably is incredibly grotty and awful and cpu specific if possible at all)
airlied: owen_: if can't be made work, AMD CPUs will overwrite the GPU data with the flushed cache data.
fat_chris: Ferocanis, is there even a way to mask something from a specific overlay?
airlied: and they can also speculatively read stuff so explicit flushing is meaningless.
owen_: airlied: But the cpu isn't writing into this memory, right?
Ferocanis: fat_chris: there's a profiles/package.mask in the overlay, but /etc/portage/package.unmask overrides that =/
airlied: owen_: if it has a mapping it can specualte reads, then flushing will push out the cache data.
owen_: airlied: well, memory barriers presumably can take care of speculative reads
airlied: owen_: nope.
owen_: airlied: But yeah, does sound like it's far harder than zero copy TFP...
airlied: owen_: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/061/6148/6148s1.html
owen_: airlied: so, do we want to ship KMS on for anything for F10? r300 - badly unstable. r500 - compiz not usable
airlied: on PCIE at least I can do snooped entries for the GPU, but I've no idea how stable it will be.
airlied: owen_: compiz not useable doesn't worry me.
airlied: we don't enable compiz by default for lots of reasons.
airlied: I'm still not sure why your r300 is unstable.
airlied: what kernel/-ati are you using?
owen_: -68 for the kernel, -41 for -ati
airlied: please try -73
owen_: I'm actually getting solid system locks both with and without kms, though more frequently with kms
airlied: or later.
airlied: the out of bounds memory access were bad and could mess things up.
owen_: OK, will do
fat_chris: Ferocanis, put in your own overlay and call it 9999-r1 :p
Ferocanis: fat_chris: overlaytastic XD
owen_: airlied: I'm somewhat worried about having compiz performing really badly ... we don't ship it that way by default but certainly a good number of people use it that way, and so there is going to be a big "kms is really slow" meme
owen_: (or "f10 is really slow")
owen_: then again, we have been making enough buz about the kms boot, that I guess we need *one* piece of hardware anyways where we can demo it
airlied: owen_: I'm not being held ransom by a piece of crap like compiz for any bad review :)
jcristau: and then they'll all switch to ubuntu ;)
airlied: we have always said compiz without DRI2 is pointless
Ferocanis: *cough* compiz is pointless *cough*
owen_: jcristau: By all accounts, they have there own major X performance problems with 8.10
owen_: airlied: Hey, it's not just Compiz, it's also gnome-shell!
airlied: owen_: metacity compositing should be okay.
owen_: (OK, turning off kms is the least of a incipient gnome-shell developers problem right at the moment)
owen_: airlied: but pointless exactly as much as compiz without DRI2 :-)
spstarr_coding: owen_: you're having the same unstableness with me on rv350 :)
spstarr_coding: at least it's consistent ;)
airlied: owen_: I thought DRI2 would have arrived by F10 :)
Ferocanis: airlied: how's direct rendering with the RS690?
airlied: Ferocanis: fine.
owen_: airlied: gnome-shell is building off metacity + clutter compositing, which is pretty much like compiz. Well, worse, at the moment, since it can't actually use TFP at all on ATI, so it's GetImage. Though without zero-copy-TFP, that's not much different...
airlied: owen_: is it aGL compositor?
airlied: ah clutter compositing
owen_: (the non-TFP at all is very fixable, I just need to hook up ARB_texture_rectangle again in clutter ... they removed it because they thought everybody had texture_non_power_of_two)
spstarr_coding: this clutter stuff
airlied: owen_: wow way to fail at GL.
airlied: I thought of some hacks to get zero-copy TFP back but they were all dirty.
airlied: I would need to finish the GEM mesa also.
owen_: airlied: krh claims that once we have GEM mesa, dri2 is trivial. we'll see.
airlied: owen_: yup it should be.
airlied: you just pass the handle.
airlied: we could change desktop effects box to have a warning if kms is enabled :)
owen_: spstarr_coding: the fact that all T42's behave the same is nice, but unless I ship mine to airlied doesn't do us much good. I feel pretty useless at debugging this intermittent kernel hang stuff.
spstarr_coding: im just staying in non-kms + EXA without composite, his newest changes in DDX fixed memory badness
owen_: spstarr_coding: (partly because it always happens when I'm trying to do something else...)
airlied: spstarr_coding: is yours still crap when it runs in PCI mode?
spstarr_coding: airlied: in PCI mode, it locked once i remember, X crashed
spstarr_coding: i didnt attach X to try again since
spstarr_coding: X actually crashed and restarted
airlied: wierd.. so not a gpu hang then most likely.
spstarr_coding: ive been busy in KDE land.. and im still in there
spstarr_coding: http://www.sh0n.net/spstarr/oddcolor.png :)
spstarr_coding: well, fighting with Layouts
owen_: airlied: The 3-minutes-of-testing conclusion is that -73 is *much* stabler for me
owen_: airlied: Since with -68 it woudl have been 3 seconds of testing
owen_: Errr, spoke to soon
owen_: airlied: got it to hard lock again
owen_: (maybe much stabler anyways, maybe jsut was doign the wrong thing for 3 minuts)
airlied: is it a hard lockup? or just 3 second pauses?
owen_: airlied: Hard lock up
owen_: airlied: like the pauses, the mouse cursor is stuck (so the sigio handler also blocked)
owen_: airlied: not sure, I forgot to check the IP address before it hung
owen_: airlied: Let me try to reproduce again
airlied: owen_: if its sshable echo t > /proc/sysrq-trigger would be useful
owen_: That time it rebooted
owen_: airlied: (so obviously not ssh'able...)
airlied: owen_: ouch thats pretty bad, so maybe no kms on AGP r300 then.
owen_: airlied: also less frequent crashes without kms, though :-(
spstarr_coding: owen_: i haven't crashed yet in 3 days since DDX mem fix changes w/o kms
spstarr_coding: just standard EXA and MigrationHeurisic smart
spstarr_coding: owen_: what size is your virtual screen set to?
spstarr_coding: I am using 1400 x 1050, the same size as panel to save offscreen mem
airlied: owen_: without kms you should be as stable as F9 was, maybe something else busted.
owen_: spstarr_coding: 1400x1050
spstarr_coding: owen_: ok
owen_: airlied: The non-kms instability is very recent
spstarr_coding: airlied: you made some good fixes for the DDX
spstarr_coding: owen_: you are getting X crashing with new DDX?
owen_: )probably obvious by now but the DDX fixes don't fix the glyph corruption problems)
airlied: owen_: hmm I wonder if some upstream kernel changes are bad.
owen_: spstarr_coding: Define new? this is -41
spstarr_coding: no X crash / gpu wedge yet
airlied: owen_: -41 reneables that speed op optmisiation.
owen_: spstarr_coding: You were fooling aroudn with agp settings... are you using anything but the default
spstarr_coding: owen_: 4x AGP by default
owen_: sure, blame me :-)
airlied: in an attempt to make firefox fast again :)
owen_: airlied: You are still defaulting to agp off, right?
airlied: owen_: for kms yes
airlied: non-kms does what it always did.
airlied: owen_: you've always ran with EXA enabled I assume.
owen_: airlied: Yeah
airlied: no wonder fglrx dropped r300 support :)
spstarr_coding: airlied: they did?!
spstarr_coding: then im fucked and under your mercy
spstarr_coding: gee, wonderful :P
Ferocanis: hmm... my screen stays blank when X starts
Ferocanis: i don't *think* it's a radeon issue either
airlied: latest X server?
airlied: X -retro
airlied: or are you running morethan X :)
Ferocanis: is this a new X thing? no more friendly screen with the X-shaped cursor?
Ferocanis: just X as far as i'm aware!
airlied: Ferocanis: pretty much.
Ferocanis: i'm trying to test my newly generated config
airlied: X -retro gives the old behaviour
owen_: airlied: Well, no luck intentionally crashing non-kms
Ferocanis: hmm... also my keyboard an mouse are disabled by default? o_O
legume: Section "ServerFlags"
legume: Option "AllowEmptyInput" "off"
legume: to fix key/mouse
rmh3093: airlied, how is it that your rawhide branch compiles, when i use your kconfig i get undefined symbols
rmh3093: i need to add select FB_CFB_FILLRECT
rmh3093: select FB_CFB_COPYAREA
rmh3093: select FB_CFB_IMAGEBLIT
Ferocanis: yeah, just read up on it now... that's a bit silly
Ferocanis: thanks airlied, legume
airlied: rmh3093: ah I think radeon needs to select them.
airlied: we build fbcon into Fedora kernels so I get them for free
rmh3093: yeah i add it in my kernel
rmh3093: well even I build fbcon
rmh3093: the kernel does not automatically select them
rmh3093: some other fb driver must be pulling them in
airlied: rmh3093: yup we probably also have lots of fb drivers selected.
rmh3093: is anyone gonna be writing a generic fb driver for kms? or are all the drm drivers just gonna emulate their own fb
airlied: rmh3093: its probably going to be some generic code with some driver specific bits in it.
airlied: it might end up being driver specifc though.
airlied: some parts are a bit messy to do generically like buffer alloc/pinning etc.
spstarr_coding: ugh, where'd otaylor go
spstarr_coding: wanted see if he gets corruption with flash
rmh3093: airlied, ping
airlied: rmh3093: pong
rmh3093: the radeon drm driver also needs SELECT I2C
rmh3093: and/ or I2CALGO something
rmh3093: in the Kconfig that is
airlied: ah yes.
rmh3093: I2C_ALGOBIT is what i was thinking
MostAwesomeDude: airlied: I haven't started hacking tonight, but I was thinkin', and it occurred to me that maybe I'm just not reading back the right address from the card.
spstarr_coding: otaylor: ping
spstarr_coding: otaylor: do you get corruption with flash?
spstarr_coding: if you install adobe flash rpm
otaylor: spstarr_coding: Not usually.
spstarr_coding: otaylor: like this: http://www.sh0n.net/spstarr/corruption.png
spstarr_coding: pretty bad..
otaylor: spstarr_coding: I've actualy seen more stuff like that with normal images than flash
spstarr_coding: otaylor: interesting
spstarr_coding: in kms none of that occurs
MostAwesomeDude: jnoah1984: Y helo thar. :3
MostAwesomeDude: jnoah1984: So, as I was saying, it's mostly just about making sure that the fogcoords get from point A (Mesa vertex memory) to point B (rasterizer/scan converter) to point C (fog HW/fragment program).
MostAwesomeDude: The big problem is that there's multiple ways for each bit of the path, and each way is different.
jnoah1984: sounds fun
MostAwesomeDude: So, I discovered last week that fixed-function vertex fog coords just kinda magically work for some cases.
MostAwesomeDude: Makes WoW work, at least, from what I heard.
MostAwesomeDude: Unfortunately, it breaks custom fragment programs.
MostAwesomeDude: airlied: dev_priv->ring_rptr->handle on CPU memory should be the same as RADEON_CP_RB_RPTR_ADDR on VRAM, yeah?
airlied: pretty much.
airlied: just get the u32 * vs void * right :)
MostAwesomeDude: Yeah, I did.
MostAwesomeDude: (u32)(cardptr + i) is probably not right?
MostAwesomeDude: Or do I pass (cardptr + i) and let DRM cast it for me?
MostAwesomeDude: Gah, I feel like such a newbie. :c
RTFM_FTW: heheheh I just scared the shit out of someone with the very concept of bit-level operations on the GPU
jnoah1984: Where can I get the ATi/AMD docs?
jnoah1984: lol, should have figured. MostAwesomeDude had sent it to me a while ago, but I had since lost it.
airlied: otaylor: off the top of your head, nothing should care what the contents of VRAM are initially for EXA type things..
airlied: that pixmap corruption is simple a pixmap with the VRAM zeroing in it, instead of whatever should be in there.
otaylor: airlied: pixmaps are initially undefined, certainly
otaylor: airlied: which pixmap corruption isn particular?
airlied: otaylor: the one one in xchat/firefox
airlied: I think now we are just seeing blank space instead of the corruption :)
otaylor: airlied: Hmm.
otaylor: airlied: But you said you saw that without the glyph cache, so it's unlikely to be a "draw the wrong bounds" problem, since the code paths are pretty different with and without the cache
airlied: yup... I suspect its something lower level, probably me doing something stupid again...
luke-jr: your nicks are the same length, both lowercase, and the same colour
luke-jr: it really looks like it's one guy talking to himself -.-
otaylor: luke-jr: use a proportional width font then ... "airlied" is distinctly narrower for me :-)
luke-jr: proportional width fonts don't fit IRC
jnoah1984: I just use pidgin and everyone has different colors
luke-jr: jnoah1984: everyone?
luke-jr: thinks using an IM client for MUC is lame
jnoah1984: luke-jr: ok, well, just about. There are something like 70 different colors at least
luke-jr: same here, but those two just happen to have the same colour :/
jnoah1984: MostAwesomeDude was talking to me the other day and he was saying that he was having issues with fogcoords. I thought I'd try and help, but to be honest I am a complete n00b when it comes to this. Even so, I'd like to dig in, get my hands dirty and give it an attempt. I have the docs, but I need a bit of direction. Could I get that from someone?
jnoah1984: btw, no I'm not an ubuntu n00b, not that bad. I actually do use Gentoo
jnoah1984: I have been programming for a long while now, but nothing like this
jnoah1984: long while being 6+ years with C++
jnoah1984: And currently I am using a R350 (Radeon 9800PRO 256MB AGP)
z3ro: jnoah1984: well, I'm not sure how MAD is working out the fog coords, but I would start with dumping fglrx and cross referencing with the docs.
z3ro: also ask him what he's done already or already figured out.
jnoah1984: Yeah, can't get him on the phone right now... hmm. I'll keep trying I guess.
z3ro: he left a little while ago, but should be back soon
z3ro: btw http://dri.freedesktop.org/wiki/ReverseEngineering are the reverse engineering/dumper tools we have...
z3ro: revenge is probably the easiest one for 3d related stuff.
z3ro: it dumps the packets that are sent to the card via the RB and IB's (ring buffer and indirect buffers)
z3ro: these are the PM4 packets that are explained in the docs (r5xx programming guide)
z3ro: but basically they are equivilent to register writes.
jnoah1984: alright, thanks
z3ro: no problem. if you have any questions, just ask here (but sometimes it might take a while to get a reply if people are sleeping, so just idle :)
jnoah1984: Does fglrx 8.10 work with xserver 1.5?
rx__: errr.. oh yea 8.10 ubuntu driver
jnoah1984: lol, archlinux went by that and so does the download page at amd/ati driver page
luke-jr: boycott supporting blobs!
jnoah1984: The Ubuntu driver is 8.54.3, but on the ATi/AMD page it's 8.54.2... Will that be an issue?
luke-jr: jnoah1984: don't use fglrx
rx__: 8.54.2 doesn't support xserver 1.5
rx__: but anyway you're in the channel for the open source radeon driver
jnoah1984: ya, trying to use revenge, but thanks
rx__: oh revenge
z3ro: rx__: you probably want to run it like: revenge --pci-e --debug
z3ro: or --agp if your card is agp
z3ro: er yeah
z3ro: damn I must still be asleep
jnoah1984: z3ro agp wouldn't it be? I'm using r350 agp
z3ro: jnoah1984: yeah
z3ro: I really should add pci-id based detection sometime.
luke-jr: wouldn't disassembly be easier?
z3ro: jnoah1984: you'll need to write a test for fogcoords too. but thats pretty easy. just have a look at gl_*.c
z3ro: luke-jr: disassemble the blob? I'm not quite that masochistic... :P
luke-jr: z3ro: I've tried to disassemble entire firmwares..
luke-jr: static linked
luke-jr: though they were MIPS and might be less painful than x86
z3ro: fglrx is pretty huge. iirc it's at least several megabytes for the userspace blob.
jnoah1984: What's with the Ubuntu/source package in the fglrx installer? What source are they adding? Is it just misleading?
luke-jr: automate it I guess
jnoah1984: yay, MAD is back
luke-jr: who's mad?
jnoah1984: MostAwesomeDude (he's on aim right now, I suspect he'll be here in a few)
luke-jr: uh oh
z3ro: bbl, going to watch some american dad and mythbusters. :)
luke-jr: why are you teaching AOL users to use IRC?
tlp: jnoah1984: I think bits of fglrx are open source.
tlp: not sure what specifically
jnoah1984: luke-jr, he is in here a lot...
luke-jr: then why does he use AOL?
luke-jr: or you, for that matter ? -.-
rx__: american dad.. hah :)
jnoah1984: luke-jr, ask him yourself
luke-jr: MostAwesomeDude: AOL is bad.
MostAwesomeDude: luke-jr: Huh?
MostAwesomeDude: I'm not on AOL...
luke-jr: AOL, AIM, same crap
tlp: who cares.
MostAwesomeDude: I dunno what you guys were talking about.
spstarr_desk: that'a boy krh!
tlp: spstarr_desk: just read about it?
tlp: seems neat.
jnoah1984: what am I missing out on?
spstarr_desk: i think its not a bad idea, X11 is a good thing
MostAwesomeDude: 'k, read the log.
MostAwesomeDude: jnoah1984: x.org/docs/AMD .
MostAwesomeDude: luke-jr: fglrx is roughly 12 million lines of code. Too big to RE.
jnoah1984: Since Ubuntu has the 8.54.3, but ATi only has the 8.54.2 driver, should I drop down to xserver 1.4 or...
jnoah1984: ATi's download page*
MostAwesomeDude: z3ro: I'm missing the *big* picture still. Each time I unbreak one path, another path breaks. :c
MostAwesomeDude: airlied: Well, I've tried a handful of different things. It's almost like the writebacks just aren't happening. Either that, or the description of ZPASS is somehow off.
MostAwesomeDude: I need a revenge.
MostAwesomeDude: should just shut up and get Xserver 1.4 again
jnoah1984: MostAwesomeDude, what about the 8.54.3 driver? Ubuntu *exclusive*?
rx__: it's not ubuntu exclusive
rx__: the tarball is publicly available
jnoah1984: oh, ok
rmh3093: yeah wayland will be nice, Xorg takes to long to load
MostAwesomeDude: rx__: Linky? I'll totally try it. :3
rx__: it used to be public
rx__: un momento
MostAwesomeDude: checks local Ubuntu mirror
luke-jr: wishes someone would sue Canonical for GPL violation already.
MostAwesomeDude: luke-jr: Can you name a violation?
luke-jr: MostAwesomeDude: any binary module
spstarr_coding: it makes me wonder why krh decided to do this..
MostAwesomeDude: rx__: Rock. Although the debs should work on Debian?
spstarr_coding: unless he assumes there is a serious deadend in the current Xorg display server(?)
luke-jr: what did krh do?
rx__: MostAwesomeDude; should.. untested.. i only use it on gentoo
spstarr_coding: luke-jr: Wayland
luke-jr: which is?
MostAwesomeDude: rx__: I'm on my Debian box, so yeah. Thanks. :3
spstarr_coding: its a prototype right now of a X server with direct rendering goodness, input and some other things
spstarr_coding: luke-jr: so that means it has no EXA, XAA (i haven't seen the code)
jnoah1984: MostAwesomeDude, your on your Debian box right now? What happened to your laptop?
airlied: spstarr_coding: its not an X server
MostAwesomeDude: jnoah1984: It's in the shop, remember?
luke-jr: different from X.org how?
spstarr_coding: airlied: its not an X Server, but it is a display server in general
spstarr_coding: airlied: nothing to stop him from rendering X onto this display server
luke-jr: and by definition, anything with a mid-point is indirect…
spstarr_coding: "I see of X are in the sense of running an X server on top of Wayland" right, thats exactly what I wanted to see us go towards
spstarr_coding: kernel drm drivers with kms + 'a display server' + running X on top of such display server
MostAwesomeDude: Well, since nobody's said it...
MostAwesomeDude: As long as we're re-writing an X implementation from the ground up, might as well start examining the X12 wishlist. :3
luke-jr: that reeks of Mac's setup
luke-jr: please don't lose the network layer :x
spstarr_coding: MostAwesomeDude: Im not qualified to know if we need a revision to the X protocol
spstarr_coding: luke-jr: the network layer is useless, use VNC/NX etc
spstarr_coding: why bother with running an X app over SSH
MostAwesomeDude: spstarr_coding: I know at least a few people have mentioned it. I don't know what's on the list, though.
MostAwesomeDude: I'm sure that, at the least, Xfixes, Damage, Composite, etc. deserve a once-over, as does GLX.
spstarr_coding: luke-jr: it used to be a nifty thing to do, but when Xorg abandoned LBX (since SSH did better compression?)
luke-jr: spstarr_coding: VNC is inefficient, NX is proprietary
spstarr_coding: im not sure how much NX is proprietary when the lib are GPL
luke-jr: the lib itself is useless
spstarr_coding: luke-jr: the libs are the server
luke-jr: it still doesn't work
spstarr_coding: if we want network transparency I'd like Xorg to adopt a 'NX' like solution
spstarr_coding: no more DISPLAY=goobar:0.0 xeyes
luke-jr: network transparency is all I don't want disappearing at this point
luke-jr: specifics (protocol) are changable
luke-jr: ssh -Y and -X work fine without messing with env vars
spstarr_coding: luke-jr: well, it would be nice if the X server/display server or the X11 protocol could fall back to non-network mode - not using - unix sockets
luke-jr: nothing wrong with unix sockets
spstarr_coding: from what it looks like hes taking the reverse approach get X onto something instead of rendering something onto X
spstarr_coding: oh MostAwesomeDude i didn't notice you on /. :)
MostAwesomeDude: spstarr_coding: I'm incognito. :3
spstarr_coding: adds you as a friend
MostAwesomeDude: rx__: Is there some magic trick to getting fglrx-installer to work? I'm not finding an executable...
spstarr_coding: done ;)
spstarr_coding: I really think gutting the X server display and keeping the ability to run X11 apps natively on a display server is the way to go, we utilize a modern display server and keep X11 support, win win to me :)
spstarr_coding: mods your post up
MostAwesomeDude: jnoah1984: 'k, thanks.
spstarr_coding: MostAwesomeDude: whats interesting to me is, The Berlin Consortium (aka Fresco) was a new display server, but it used GGI and other ugly things, with the changes going on today, Wayland might have a better chance if it goes anywhere
spstarr_coding: cairo didn't exist for rendering
jnoah1984: Wow, it makes a module tailored to your kernel, how nice...
jnoah1984: does it require GCC3?
jnoah1984: sorry, does the fglrx custom kernel module builder thingy require gcc3.?? rather than gcc4?
spstarr_coding: jnoah1984: are you capturing registers from fglrx?
terracon: spstarr_coding: hey how's it going
jnoah1984: spstarr_coding: no, try to make a fglrx 8.54.3 module
spstarr_coding: terracon: stability with some minor flash video corruption, nothing much
spstarr_coding: jnoah1984: erm this isn't fglrx #ati might help better :)
jnoah1984: fglrx in general requires gcc3 though, right?
luke-jr: spstarr_coding: supposedly it's reverse eng efforts
spstarr_coding: never used it, can't use it anyway cause my GPU was dropped ;)
spstarr_coding: luke-jr: that would help
jnoah1984: spstarr_coding: luke-jr is correct
spstarr_coding: jnoah1984: yeah so you're going to use it to get register info :)