surfer: sup
MostAwesomeDude: Nothin'.
dmb: i found a hard lock by disabling 3d acceleration in driconf and running google earth :D
MostAwesomeDude: dmb: That's no hardlock, that's a space station!
dmb: ohs!
z3ro: MostAwesomeDude: iirc I didn't write the frag.pos part of the VP code. I did a rework on that code, though.
MostAwesomeDude: But seriously, I'm fairly certain that it's just going VERY VERY slow.
z3ro: let me have a look...
MostAwesomeDude: z3ro: 'k.
MostAwesomeDude: All I can tell you for sure is that frag.pos doesn't work.
MostAwesomeDude: And that pos as texcoord is prolly the right way.
MostAwesomeDude: And that part of VP looks...um...iffy. To say the least.
MostAwesomeDude: I mean, I'm no expert, but I wouldn't think modifying the actual Mesa program in-place is the cleanest way.
z3ro: MostAwesomeDude: yeah, I considered just throwing that part of the code out at one point.
MostAwesomeDude: z3ro: And now I'm makeing the same consideration. :3
MostAwesomeDude: *making, even.
dmb: MostAwesomeDude, i couldn't go into a vt to kill it, so i assumed it was locked
MostAwesomeDude: dmb: Huh.
MostAwesomeDude: But yeah, I would say off-hand that it's a Bad Thing to disable 3D and then try and run something so intensive.
MostAwesomeDude: Unless it worked before.
MostAwesomeDude: In which case there's a big problem with the fallback.
z3ro: sighs... I'm going to be so happy to leave my job and get overseas.
z3ro: at this point, I've realized that the general population is completely stupid.
z3ro: "I want a cable.
z3ro: of course I'd probably get fired, so...
z3ro: ends rant.
MostAwesomeDude: XD
MostAwesomeDude: Where do you work?
MostAwesomeDude: airlied: We don't do NPOT?
hifi: z3ro: I'd just answer that for the sake of it :)
MostAwesomeDude: knows why his game side-project isn't drawing right. :3
airlied: MostAwesomeDude: we don't do ARB_texture_non_power_of_two
airlied: MostAwesomeDude: my first attempt at hacking it failed.
Zajec2: z3ro: ping?
MostAwesomeDude: airlied: It's up to Mesa, isn't it?
MostAwesomeDude: Like, Mesa's supposed to pad the texs out?
airlied: MostAwesomeDude: no I think the driver needs to do somethings
MrCooper: MostAwesomeDude: padding wouldn't cut it for things like wrapping modes
moondrake: z3ro: you'll find (after staying for +2 years) that most people overseas are also stupid.
MostAwesomeDude: MrCooper: Poxies.
MostAwesomeDude: adds NPOT to the list
MostAwesomeDude: Is there a list of extensions, features, etc. that are in each OpenGL version?
MostAwesomeDude: That I somehow missed when reading up at opengl.org and oss.sgi.org?
eboettcher: MostAwesomeDude: can r3xx do NPOT?
MrCooper: eboettcher: only ARB_texture_rectangle
eboettcher: I thought so...
MostAwesomeDude: My exhaustive research indicates that r3xx-r5xx are all capable of NPOT, at least through fglrx.
MrCooper: MostAwesomeDude: it shouldn't expose non_power_of_two before r500; it did at some point, but it made some apps unusable due to software fallbacks
airlied: you might be able to do npot on r300 with frag shader tricks..
airlied: the hw might work correctly.
airlied: but not sure how fglrx can expose it otherwise
MrCooper: airlied: you'd have to handle wrapping and mipmapping in the shader
MostAwesomeDude: Hm.
MrCooper: airlied: it may have changed, but it used to be that it advertised version 2.x but didn't put non_power_of_two in the extension string
MostAwesomeDude: MrCooper: Well, unusable/unstable is the fglrx way of life.
airlied: MrCooper: ah that would make more sesnse.
MostAwesomeDude: As for r5xx, what exactly changes that makes NPOT more palatable?
MrCooper: MostAwesomeDude: hardware support for mipmapping and wrapping? :)
MostAwesomeDude: MrCooper: Ah.
MostAwesomeDude: doesn't know [expletives deleted] 'bout NPOT
dav7: MostAwesomeDude: was that a script?
MostAwesomeDude: dav7: I certainly hope not.
MostAwesomeDude: One could say that we are all scripts.
dav7: lol
dav7: no, I meant this:
dav7: [18:31:46] * MostAwesomeDude doesn't know [expletives deleted] 'bout NPOT
dav7: ^ was that a script?
MostAwesomeDude: No, that was no script.
dav7: oh, ok :P
MostAwesomeDude: Just me typing at my typically atypical speedy rate.
dav7: heh :P
dav7: okay, well, I was just wondering if someone could help me get the radeon driver working on my X1550 (RV505)?
dav7: I've built X, DRM, Mesa and radeon itself from git... everything compiled, but it's all in /opt/gfx-ati/.
dav7: what do I do now?
dav7: you might like to refer to http://phoronix.com/forums/showthread.php?p=35032 for more info.
MostAwesomeDude: XD, bridgman was helping you? That's pretty awesome. I didn't know he lurked the forums.
dav7: he does, apparently. :D
MostAwesomeDude: Um, you could always reconfig everything with --prefix=/usr and install directly over everything else. That's what I do here on Gentoo.
MostAwesomeDude: But then again I don't know much about Arch.
dav7: well
dav7: hmm
MostAwesomeDude: Everything except Mesa is safe to install directly into your base system.
MostAwesomeDude: Mesa might clobber fglrx files.
dav7: what do I do with Mesa...oh
dav7: I don't care for fglrx :D
dav7: and if it asplodes something, I can just reinstall... IF :P
MostAwesomeDude: dav7: It shouldn't asplode.
dav7: well okay
dav7: so that'd be err
dav7: types madly
MostAwesomeDude: It might have a different videomode if you have a really exotic monitor and haven't ben using xrandr.
dav7: well, fast, anyway
dav7: err
dav7: gah
MostAwesomeDude: ?
dav7: I must have 1400x1050@84Hz ><
dav7: said mode isn't in my monitor's EDID data
dav7: and said resolution isn't... "normal"
MostAwesomeDude: Hmm.
MostAwesomeDude: Well, you can always force it.
dav7: it's 1Hz above what I'm assuming some table lists
MostAwesomeDude: Laptop?
dav7: I have a modeline
dav7: no, 19" CRT
MostAwesomeDude: ...Ah.
MostAwesomeDude: That IS exotic.
dav7: lol
dav7: I had to edit /etc/ati/amdpcsdb for 84Hz to work XD
dav7: hides
MostAwesomeDude: ...I have no idea what /etc/ati is for.
MostAwesomeDude: Prolly fglrx crap.
dav7: oh, the latest versions of fglrx copy your xorg.conf glop to /etc/ati/amdpcsdb
dav7: >.>
dav7: so you have to run aticonfig with some option to "sync" amdpcsdb with xorg.conf
dav7: >.> <.<
dav7: which rewrites (read: reformats) xorg.conf!
dav7: all that pretty tabulating I did... :(
dav7: anyway
MostAwesomeDude: Huh.
dav7: well aticonfig rewrites your xorg.conf, re-formatting (ie re-identing) everything
dav7: I'd indented xorg.conf with tabs and such
MostAwesomeDude: Of course.
dav7: but to sync amdpcsdb with xorg.conf [and make fglrx "see" your new settings] I'd have to re...layout... xorg.conf.. anyway.
dav7: thinks
MostAwesomeDude: Well, try not to worry about it.
dav7: won't :P
MostAwesomeDude: You will soon be in a happy place.
dav7: lol
MostAwesomeDude: A place where stuff just sort of magically works.
dav7: \o/
dav7: lol
MostAwesomeDude: A place we call...um...
MostAwesomeDude: Uh...
MostAwesomeDude: Um, "here", I guess.
dav7: hahah
dav7: for x in drm mesa xf86-video-ati xserver; do cd $x; ./autogen.sh --prefix=/usr; make install; cd ..; done
dav7: should that do it?
MostAwesomeDude: Wrong order.
dav7: oh.
dav7: can has sort?
MostAwesomeDude: First, go into DRM, rebuild that.
dav7: right...
dav7: so the order should be err
MostAwesomeDude: Don't forget to go into linux-core and build and install the kernel mods.
dav7: I did that
dav7: I followed this:
MostAwesomeDude: Then, X.
dav7: http://wiki.x.org/wiki/radeonhd:DRI
dav7: I followed that, making silent changes where required
dav7: (it covers building X)
MostAwesomeDude: Yes, it does.
dav7: :D
MostAwesomeDude: Oh yeah, you're coming from fglrx.
dav7: so I built linux-core
MostAwesomeDude: So Mesa, then X.
dav7: yea...
MostAwesomeDude: And drivers last.
dav7: !
dav7: ok
MostAwesomeDude: Don't forget to rebuild any X drivers you need.
dav7: drm mesa xserver xf86-video-ati
dav7: ?
MostAwesomeDude: Yes
dav7: okay
MostAwesomeDude: Like, I have to rebuild keyboard, mouse, evdev, synaptics, ati.
dav7: ><
MostAwesomeDude: And radeonhd if I feel like it.
dav7: okay, running...
dav7: wait, err I'm in X right now
dav7: :S
dav7: lol
dav7: waits for somegting to asplode violently
dav7: something*
dav7: wait
dav7: oops
dav7: wasn't root
dav7: ><
dav7: decides to quit X, be root, then recompile.
dav7: lol
MostAwesomeDude: dav7: Stuff won't explode or anything.
dav7: heh, right
dav7: well I'm in the console right now
dav7: on vt2
dav7: switches to vt1 and compiles
dav7: running, take #2./
dav7: uh oh
dav7: dri2proto not found
MostAwesomeDude: Really?
dav7: drm builds okay
dav7: yeah, I need to grab that
MostAwesomeDude: How'd you build X before, without dri2proto?
dav7: I have no idea
dav7: checking for DRI2PROTO... configure: error: Package requirements (dri2proto >= 1.1) were not met:
dav7: No package 'dri2proto' found
dav7: gpm ftw
dav7: grabs that
dav7: ah, I had an older version or something
dav7: BEEEEEP, error
dav7: finds it
dav7: gah
dav7: ../../../bin/minstall ../../../lib/libglut* /usr/lib
dav7: Unknown type of argument: ../../../lib/libglut*
dav7: gmake[2]: *** [install] Error 1
dav7: T.T, help
dav7: pokes MostAwesomeDude
dav7: hi :P
MostAwesomeDude: Yo.
dav7: lol
MostAwesomeDude: Um.
MostAwesomeDude: make clean?
dav7: mk
dav7: done, now `make'?
dav7: runs make
MostAwesomeDude: I just realized that as I'm spinning Compiz around, the cursor in kdevelop blinks at me.
dav7: lol
MostAwesomeDude: As if to say, "Corbin, Corbin, come type code on my spinning surface."
dav7: yup! :D
MostAwesomeDude: God, I love Linux.
dav7: haha
dav7: lol
dav7: I wish I could say I loved it too
dav7: ><
dav7: well I mean
dav7: X, at least.
dav7: ugh
MostAwesomeDude: No worries. That first time building your own X stack is tough.
dav7: ugh
dav7: yup =P
dav7: hands out free ssh in exchange for anyone who wants to help
dav7: gah, warnings
MostAwesomeDude: Hey, if I can do it, you can do it.
dav7: mk
dav7: :P
airlied: agd5f: you know anything about potential powerpc atombios roms?
airlied: are the tables always in little endian?
MostAwesomeDude: airlied: I have a bit of code here that adds an anisotropy override to driconf, so you can force a higher (or lower) anisotropy than apps request. Good idea or bad idea?
dav7: MostAwesomeDude: mesa seems to have built :P
dav7: MostAwesomeDude: good idea, with an option to enable/disable it. :P
MostAwesomeDude: dav7: Right, that's the idea.
MostAwesomeDude: Right now you can set anisotropy, but apps can always override it.
MostAwesomeDude: I was thinking like the control in the Catalyst/Hydra panel.
dav7: great idea
dav7: hmm, does anyone have a GUI for the free/open source drivers yet?
dav7: MostAwesomeDude: currently ./autogen.sh'ing xserver
dav7: MostAwesomeDude: gah
dav7: Requested 'xextproto >= 7.0.3' but version of XExtProto is 7.0.2
dav7: Requested 'xproto >= 7.0.13' but version of Xproto is 7.0.11
dav7: Requested 'inputproto >= 1.9.99.1' but version of InputProto is 1.4.2.1
dav7: MostAwesomeDude: I have those in ../, how do I note this? I forgot which var to export.
dav7: 870 export ACLOCAL="aclocal -I /opt/gfx-ati/share/aclocal"
dav7: 874 export PKG_CONFIG_PATH=/opt/gfx-ati/lib/pkgconfig
MostAwesomeDude: dav7: PKG_CONFIG_PATH
dav7: right,
dav7: .*
dav7: MostAwesomeDude: what should I set it to? setting it to /usr/lib/pkgconfig didn't work. :(
dav7: wait a second
dav7: I need to reinstall those packages with --prefix=usr
dav7: heh
MostAwesomeDude: dav7: --prefix=/usr
dav7: oh, right, of course
MostAwesomeDude: Or you will have truly cryptic errors like "Cannot find path 'usr/lib/pkgconfig'"
dav7: now it wants pciaccess
dav7: can someone throw the git checkout URI for pciaccess in this direction? :P
dav7: (please :D)
MostAwesomeDude: One sec.
dav7: thanks \i/
dav7: \o/*
MostAwesomeDude: git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
dav7: woo
dav7: oh
MostAwesomeDude: Man, can't wait for synaptics to be in-tree.
dav7: libpciaccess, I have that already
dav7: >.>
dav7: why?
dav7: ./autogen.sh = WIN
dav7: now it's make install'ing
dav7: should I have rebuilt X? :s
dav7: wait, it seems to actually BE rebuilding. >.>
dav7: MostAwesomeDude: okay xserver built, now radeon?
dav7: rather xf86-video-ati
dav7: builds that
MostAwesomeDude: Yes.
dav7: that's built
dav7: I guess this is the part where I wince and run startx right? :P
dav7: oh, right
dav7: /home/dav7/ati/xf86-video-ati -> modprobe -r fglrx
dav7: and...
elbeardmorez: dav7: google 'gitweb' ..and 'component' that's how I find the git urls..
dav7: /home/dav7/ati/xf86-video-ati -> nano /etc/X11/xorg.conf
dav7: elbeardmorez: right
dav7: http://rafb.net/p/LIid4P23.html
dav7: ^ is that "pretty good" for an xorg.conf?
dav7: what should I scrap/keep/delete etc?
dav7: decides to comment everything except "DRI" out
dav7: err
dav7: Parse error on line 9 of section Files in file /etc/X11/xorg.conf "RgbPath" is not a valid keyword in this section.
dav7: what do I do now? :<
dav7: elbeardmorez, MostAwesomeDude: ^
dav7: isn't RgbPath like, required?
MostAwesomeDude: dav7: One sec. Don't think so.
dav7: oh ok
moondrake: dab7: remove it?
dav7: done
MostAwesomeDude: Nope, mine's commented out.
dav7: tries startx again
dav7: !
dav7: wow
dav7: that was insanely weird XD
dav7: awesome in fact... no, not what you think.
dav7: ROFLs then compiles the keyboard and mouse drivers
MostAwesomeDude: ?
dav7: well
dav7: I couldn't like move the mouse or type
dav7: but switching to another terminal worked :>
dav7: as in, CTRL+ALT+F1 from inside X
dav7: haha
dav7: compiles keyboard driver
dav7: KEYBOARD WORKS
dav7: I'M IN X RIGHT NOW (albeit at an odd resolution)
dav7: works on getting the mouse moving :P
MostAwesomeDude: Whoohoo!
dav7: I have keyboard and mouse
dav7: let's try glxgears
dav7: they don't move
dav7: IT'S USING 100% CPU
dav7: HELP
MostAwesomeDude: Kill it!
dav7: well, was :P
MostAwesomeDude: With fire!
dav7: hah
dav7: lol
MostAwesomeDude: Um, sounds like you're not on a direct path.
dav7: well now what? T.T
dav7: nope :(
dav7: tries glxinfo
MostAwesomeDude: What's LIBGL_DEBUG=verbose glxinfo say?
dav7: BEEP BEEP BEEP
dav7: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_Dispatch)
dav7: libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
dav7: I have an RV505...
dav7: 1400x1050 74.8* 60.0
dav7: it has weird ideas about my video card. O.o
dav7: er, screen
dav7: 1024x768 85.0 85.0 75.1 75.0 70.1 60.0
dav7: very odd ideas
dav7: it listed a refresh rate... twice?
MostAwesomeDude: Hmm.
dav7: wonders if that's 85.0978154768768434Hz and 85.0982346598734658234Hz =P
MostAwesomeDude: Well, that top modeline looks right-ish.
dav7: well
dav7: can has 10 more Hz? please? :P
dav7: er
MostAwesomeDude: Um, the libgl error...you DID install Mesa, right?
dav7: I think so
dav7: what's a surefire way to check?
dav7: returns to the console
MostAwesomeDude: Well, in the Mesa dir, do "make && make install"
dav7: although 74.8Hz looks fine, if a bit oddly placed
MostAwesomeDude: And it should just scroll by really quickly.
dav7: I like "make; make install" better :P can I use that? XD
MostAwesomeDude: dav7: Sure, I guess.
dav7: mk
dav7: watches it... compile.
dav7: ><
MostAwesomeDude: doesn't want to talk about semantics of shells at 1 in the morning
dav7: gah
dav7: I hope you're not staying up just to help me
dav7: ok
dav7: MostAwesomeDude: installed
dav7: let's take #2
dav7: in X now, same issue....
dav7: :(
moondrake: doesn't glapi_dispatch come from libGL?
dav7: I wouldn't know
moondrake: maybe fglrx stuff still litering around
dav7: hmmm...
MostAwesomeDude: dav7: I'm an occasional insomniac. I'm usually up 'til 3ish this time of year.
dav7: let me poke around a bit
dav7: hah
dav7: well okay :P
MostAwesomeDude: dav7: Could you grep your Xorg.log and see if AIGLX is loading?
MostAwesomeDude: It's at /usr/var/log/Xorg.0.log
MrCooper: yeah, that's probably the wrong libGL
dav7: ok
dav7: http://rafb.net/p/4QwWyn19.html
dav7: ^ output of `locate libGL'
dav7: what do I nuke?
dav7: err
dav7: checks Xorg log
moondrake: grep for the missing symbols
moondrake: and see which one provides it :)
dav7: (**) AIGLX enabled
dav7: (II) AIGLX: Screen 0 is not DRI2 capable
dav7: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
dav7: (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
dav7: T.T
MostAwesomeDude: dav7: Do "ldd /usr/bin/glxinfo" and see which one it is.
dav7: mk
MostAwesomeDude: Then nuke it, "make install" Mesa again.
dav7: okay, that was the /usr/lib one
MostAwesomeDude: Hmm.
MostAwesomeDude: This is all very, very strange.
dav7: yeah... :P
dav7: *cries*
dav7: SAME ISSUE
dav7: AGAIN
dav7: ><
MostAwesomeDude: Did you do ldconfig /usr/lib? I think Mesa's supposed to do it, but I can't remember.
dav7: does so
dav7: done
agd5f: airlied: I doon't know that we make any cards for ppc with atombios. IIRC, the mac cards have some OF rom
dav7: tries X again
dav7: nope
dav7: still no go
dav7: anyone want to ssh and have a go...?
moondrake: just grep glapi_Dispatch in the mesa made libGL, does it contain it?
dav7: okay
dav7: /home/dav7/ati/mesa -> grep glapi_Dispatch /usr/lib/libGL.so*
dav7: Binary file /usr/lib/libGL.so matches
MostAwesomeDude: ...Don't tell me that xserver's broken the AIGLX ABI again...
moondrake: well, then be sure that that is the libgl that links with your apps:)
dav7: hmm
MostAwesomeDude: Okay, try this.
dav7: yea?
MostAwesomeDude: "LD_PRELOAD=/usr/lib/libGL.so glxinfo"
MostAwesomeDude: That should work.
dav7: okay
dav7: wow, what an interesting response:
dav7: -> LD_PRELOAD=/usr/lib/libGL.so glxinfo
dav7: name of display: :0.0
dav7: R500 support requires a newer drm.
dav7: libGL error: Calling driver entry point failedlibGL error: reverting to (slow) indirect rendering
dav7: display: :0 screen: 0
dav7: direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
dav7: meep
MostAwesomeDude: ...
dav7: ......
MostAwesomeDude: Did you load the new DRM? I'm guessing no.
MostAwesomeDude: Okay, so you made install in linux-core in the drm folder, right?
dav7: ....err
dav7: make -C linux-core
dav7: ^ in the drm folder, I did that
dav7: hmm
MostAwesomeDude: You need to "make -C linux-core install" too.
dav7: ooh
dav7: !!!!!!!!! that wiki page didn't say that
dav7: done
MostAwesomeDude: Okay.
MostAwesomeDude: Now, remove fglrx (if it's loaded) and load some REAL DRM.
moondrake: well make install is not enough anyway, you have to nuke your old drm.ko, and depmod -a and modprobe the new one
dav7: okay... umm
MostAwesomeDude: "modprobe -r fglrx; modprobe -r radeon; modprobe -r drm"
dav7: ooh
dav7: wow ok
MostAwesomeDude: "depmod -a"
MostAwesomeDude: "modprobe radeon"
dav7: now
dav7: startx, take 51,236.
dav7: :P
dav7: sorry, had to go do something quikcly
dav7: quickly*
dav7: returned, DRM IS STILL NOT WORKING?!?!
dav7: wait a second...
dav7: the DRM provider name is err
dav7: server glx vendor string: SGI
dav7: I'm betting that's supposed to be Mesa. right/
dav7: ?*
MostAwesomeDude: dav7: SGI is Mesa.
dav7: oh
dav7: well that's a good thing... I think
MostAwesomeDude: Okay, so do the LD_PRELOAD trick again.
dav7: I've been doing that this whole time
MostAwesomeDude: Really?
MostAwesomeDude: And if you add in LIBGL_DEBUG=verbose?
moondrake: a) perhaps the new drm got installed in a different dir compared to your distro's old drm, or b) the error means libdrm instead of kernel drm module
dav7: hmm
MostAwesomeDude: moondrake: All possible.
dav7: MostAwesomeDude: let me pastebin the output of verbose DEBUG
MostAwesomeDude: I'm actually interested now; this is very interestink.
dav7: =P
dav7: you can ssh if you want...
MostAwesomeDude: dav7: That's a Bad Thing.
dav7: oh?
dav7: meep
dav7: http://rafb.net/p/g76Bma25.html
MostAwesomeDude: "R500 support requires a newer drm."
dav7: moondrake: what does the drm module "look" like?
dav7: MostAwesomeDude: :\
MostAwesomeDude: That would be the problem.
dav7: it would?
MostAwesomeDude: The Mesa DRI won't load if the DRM is not new enough.
dav7: oh.
MostAwesomeDude: 1.29 to be precise, the version from git.
dav7: !
dav7: so...
moondrake: dav7: look like? dunno drm.ko in /lib/modules/
dav7: ah
dav7: drm.ko
dav7: /lib/modules/2.6.25-ARCH/kernel/drivers/char/drm/drm.ko
dav7: =P
MostAwesomeDude: And radeon.ko
moondrake: there should be only 1 for your kernel,
moondrake: otherwise it is hard to tell which one gets loaded
dav7: there's only the one
dav7: trying to remove it tells me that it's in use
MostAwesomeDude: Dunno 'bout you guys, but my DRM modules get installed to /lib/modules/`uname -r`/extra/
moondrake: ok thats fine then. so the error probably means your mesa was not build again a new enough libdrm
dav7: oh wow...
MostAwesomeDude: dav7: "find /lib/modules -name drm.ko"
moondrake: MostAwesomeDude: and that (the difference in dirs) is a source of much trouble :)
dav7: heh
dav7: MostAwesomeDude: mk
dav7: MEEP
dav7: MEEP
dav7: MEEEEP
dav7: /lib/modules/2.6.25-ARCH/extra/drm.ko
dav7: /lib/modules/2.6.25-ARCH/kernel/drivers/char/drm/drm.ko
dav7: MEEeeeEeeeEEP
dav7: T.T!
moondrake: o..well, so figure out which is the new one and remove the old one
dav7: sure, let me do that right now, since I like so totally know which one is the right one ^_^
dav7:
dav7: seriously, what now? T.T
MostAwesomeDude: Wait.
MostAwesomeDude: Okay.
moondrake: ls -l?
MostAwesomeDude: So don't delete it.
moondrake: it shows dates
dav7: ooh, yes
moondrake: and it should be installed today
MostAwesomeDude: The in-tree one is in kernel/drivers/char/drm/
dav7: -rw-r--r-- 1 0 0 164K 2008-06-11 18:01 drm.ko
moondrake: yes probably
dav7: from extra/
MostAwesomeDude: You should move it to kernel/drivers/char/drm/drm.ko.backup
MostAwesomeDude: Same with kernel/drivers/char/drm/radeon.ko
MostAwesomeDude: (So glad I work on kernel dev!)
dav7: -rw-r--r-- 1 0 0 88K 2008-05-16 22:55 drm.ko
dav7: MostAwesomeDude: ..right.
dav7: MostAwesomeDude: so move the ones in char/drm to .ko.backup and move the ones from extra/ to char/drm/
dav7: MostAwesomeDude: ?
moondrake: we need versioned kernel modules; this is almost dll hell :D
dav7: then reboot, to clear out the old drm module, and take #2?
dav7: moondrake: YES PLEASE
moondrake: dav7: modprobe -r should remove the old one?
dav7: /lib/modules/2.6.25-ARCH/kernel/drivers/char/drm -> modprobe -r drm
dav7: FATAL: Module drm is in use.
dav7: pokes the kernel
moondrake: remove radeon first?
dav7: ooh. ok.
MostAwesomeDude: dav7: Remove radeon first.
dav7: done!
dav7: done!
dav7: okay, so now.. move the ones in char/drm to .ko.backup and move the ones from extra/ to char/drm/?
moondrake: no need to move them from the dir
dav7: well, the first move implies rename.
moondrake: but rename is needed
moondrake: rename the old ones
dav7: so... that's a yes? ok.
MostAwesomeDude: dav7: You don't have to move the ones in extra
MostAwesomeDude: Just depmod -ae after you move the old ones.
dav7: oh...
dav7: well I already did >.>
dav7: so now what? depmod -a?
MostAwesomeDude: Yes.
dav7: mk
dav7: done
dav7: now... modprobe radeon drm
dav7: then startx? :DD
MostAwesomeDude: Yes.
dav7: mk
dav7: meep
dav7: /lib/modules/2.6.25-ARCH/kernel/drivers/char/drm -> modprobe radeon drm
dav7: FATAL: Error inserting radeon (/lib/modules/2.6.25-ARCH/kernel/drivers/char/drm/radeon.ko): Unknown symbol in module, or unknown parameter (see dmesg)
dav7: !
dav7: :(
dav7: oh
MostAwesomeDude: Dude, one module per call.
dav7: modprobe radeon drm makes radeon think drm is a parameter to it
dav7: heh
MostAwesomeDude: "modprobe radeon"
MostAwesomeDude: And radeon will automatically load drm.
dav7: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
dav7: direct rendering: Yes
dav7: :D!
dav7: now, we have another problem: screen resolution
dav7: haha glxgears won't move
dav7: oh, and screen refresh rate
MostAwesomeDude: ?
dav7: how do these get fixed?
MostAwesomeDude: Um, xrandr. The manpage should explain everything.
dav7: 1400x1050 74.8* 60.0
agd5f: what modde do you want?
dav7: xrandr -s "1400x1050@84Hz" won't work, since I have that in xorg.conf and that hasn't work.
agd5f: dav7: use the xrandr 1.2 interface
dav7: agd5f: 1400x1050 at 84.0Hz. 83Hz seems to be what drivers prefer.
dav7: how do I do that?
dav7: -> xrandr --version
dav7: Server reports RandR version 1.2
dav7: that seems good...?
agd5f: dav7: what does the output of xrandr look like?
dav7: among others, it lists
dav7: 1400x1050 74.8* 60.0
dav7: that's 9.2Hz below what I'd like. :P
agd5f: which output?
agd5f: VGA-0? DVI-0?
dav7: VGA-0.
dav7: well this only has DVI outputs but I'm using a CRT with a DVI-VGA converter.
agd5f: ok, looks like you don't have a mode for 1400x1050@84
dav7: well the fglrx driver's been managing one...
agd5f: dav7: you can add one
dav7: how?
dav7: I have an appropriate modeline, if that counts/helps.
agd5f: dav7: the output of xrandr should tell you what output is active
agd5f: it will be DVI-0 or DVI-1
dav7: DVI-1 disconnected (normal left inverted right x axis y axis)
dav7: DVI-0 connected 1400x1050+0+0 (normal left inverted right x axis y axis) 360mm x 256mm
agd5f: ok so DVI-0
agd5f: btw, why 84 hz and not 85?
agd5f: xrandr --newmode "1400x1050_84.00" 175.75 1400 1504 1648 1896 1050 1053 1057 1105 -hsync +vsync
dav7: it seemed... "odd". my eyes are probably the most picky you'll ever see (no pun intended). both 83 and 85 Hz seem to burn my eyes, while 84Hz seems closer to something that 1280x1024@85Hz produced.
dav7: ooh, ok
agd5f: xrandr --addmode DVI-0 "1400x1050_84.00"
dav7: done, and done
agd5f: xrandr --output DVI-0 --mode "1400x1050_84.00"
dav7: small issue
dav7: 1400x1050_84.00 83.9
dav7: this is my modeline:
dav7: ModeLine "1400x1050@84.0Hz" 177.0 1400 1504 1656 1912 1050 1051 1054 1102 -hsync +vsync
agd5f: dav7: xrandr --newmode "1400x1050@84.0Hz" 177.0 1400 1504 1656 1912 1050 1051 1054 1102 -hsync +vsync
agd5f: repeat
dav7: mk
dav7: yup :P
moondrake: you are not actually implying you can see a difference between 83.9 and 84?
dav7: I'm pretty sure I *might*
dav7: I don't know
dav7: OOH
dav7: IT SWITCHED MODES
dav7: likey... :D
agd5f: this will all go away when you restart X unless you add it to your xorg.conf
dav7: oh ok
moondrake: dav7: I'm a biologist, I am pretty sure no human is capable of that.
dav7: well okay :P
dav7: -> LIBGL_ALWAYS_INDIRECT=1 compiz --replace
dav7: compiz (core) - Fatal: Root visual is not a double buffered GL visual
dav7: ...problem.
agd5f: see this page for how to make it permanent: http://wiki.debian.org/XStrikeForce/HowToRandR12
dav7: thanks
dav7: quick question
dav7: with the fglrx driver, my display seems sharper and more... crisp.
dav7: with the radeon driver, and additionally when using my intel card, I find the display less crisp.
dav7: what might be the reason/cause for this?
agd5f: hard to say. crisp is pretty vague
glisse: maybe dpi
dav7: hmm
agd5f: could be dpi or slightly different pll
agd5f: you might compare some similar modelines
dav7: this is the best way I can describe it: the pixels seem to be more "focused", and the edges of [non-antialiased] fonts are much sharper, with less blend into the colors they are on top of.
agd5f: dav7: are you using exa?
dav7: err
dav7: I'd assume so...?
moondrake: gamma can help as well
agd5f: do you have this option in your config: Option "AccelMethod" "EXA"
agd5f: if not you're not
dav7: no
dav7: oh ok
dav7: Option "XAANoOffscreenPixmaps" "True"
dav7: ^ should I have that, btw?
MostAwesomeDude: I do remember that fglrx bumped font sizes immensely. I had to relearn how to read normal-size text when I switched to radeonhd.
dav7: no, no no
dav7: it didn't resize fonts
dav7: my fonts are the same *size*
dav7: their edges are just... sharper
dav7: it's as if the CRT itself isn't being driven fast enough or something
MostAwesomeDude: Font or glyph AA?
dav7: font. non-anti-aliased font.
dav7: aww, great.
dav7: I didn't configure my mode properly...
dav7: there
dav7: or not
MostAwesomeDude: No, I mean, that might be it.
MostAwesomeDude: Oh, but you're on a CRT. Nevermind.
dav7: :P
agd5f: dav7: try some other similar modelines, might be pll variance
dav7: "pll"?
agd5f: pixel clock
dav7: ooh
dav7: that sounds very fitting
dav7: (to my description/situation)
dav7: do you think it'd be a good idea to switch out to fglrx, run gtf, grab its output, then try that?
agd5f: I doubt both drivers calculate the divers exactly the same
dav7: I'd agree
agd5f: dividers
dav7: I have this...
dav7: ModeLine "1400x1050@84.0Hz" 177.0 1400 1504 1656 1912 1050 1051 1054 1102 -hsync +vsync
dav7: Option "PreferredMode" "1400x1050@84.0Hz"
dav7: ...in xorg.conf
dav7: but it isn't taking effect...?
agd5f: dav7: won't make a difference, the mdoes will be teh same, but the dividers may be different
dav7: right.
agd5f: dav7: is that in your monitor section?
dav7: yes
dav7: let me pastebin my xorg.conf
dav7: http://rafb.net/p/YF7O4O73.html
agd5f: you also need to associate that monitor section with the output you want to use it with
dav7: ooh, right
dav7: yeah, I think I've done that
agd5f: doesn't look like it
dav7: oh...?
agd5f: either change the monitor Identifier to "DVI-0"
agd5f: or
agd5f: add Option "Monitor-DVI-0" "Monitor0" to your device section
dav7: ah
dav7: ok
dav7: thinks the Identifier route is cleaner
dav7: yay, fixed
dav7: okay now, last issue: compiz fusion (:D)
elbeardmorez: agd5f: :) ..POUNCE..
dav7: MEEP
dav7: I just did
agd5f: elbeardmorez: yes?
elbeardmorez: agd5f: secondary agp card ..not set to 'primary' in bios. ..remember I showed you a log where you said it looked as though the card hadn't been posted at all..
dav7: LIBGL_ALWAYS_INDIRECT=1 LD_PRELOAD=/usr/lib/libGL.so compiz --replace --sm-disable and it asploded X
dav7: the background went all weird
dav7: gah, dinner
dav7: be back soon
agd5f: elbeardmorez: vaguely. did you try the latest git code? also what chip
agd5f: ?
elbeardmorez: agd5f: i bisected git back to your entry on ..just trying to find my notes
elbeardmorez: agd5f: with me crashing x so well / often, thought I'd lost it. Oct 10 'Xpress desktop chips seem to have proprietary connector'.. ..I have everything working now but was just hoping you might be able to fill in a few 'gaps'.
elbeardmorez: ..the working of my card all seemed to depend on the state that it was left in after I killed an xserver..
elbeardmorez: ..the driver up until your commit would let me kill an xserver and then 'recover' ..ie start another xserver using the card..
elbeardmorez: ..after yourcommit the card appeared 'locked' ..and I got those messages saying 'no connectors definately availble; ..and above that it would list my three connector types as 8 8 11 13 ..all unknown
elbeardmorez: ..there's an entry in git-log anout 'you guys' still not knowing what connector type 8 is.. ..could it be a normal connector but 'locked' ??
elbeardmorez: ..anyway, this behaviour changed, but only with a new xserver.. ..I've got 7.3 running along side now, and with the latest drm and radeon code, I still have this 'unknown device' issue..
elbeardmorez: ..so my q is: ..what part of X, module etc. interacts so diferently in in the new xorg git, in order for me to be able to consistently kill and restartt xservers using my card...
elbeardmorez: ..as i can happily do now..
elbeardmorez: ..because I would have thought.. that all changes to 'locking / unlocking connectors on a radeon card' would be revealed / evident when I change the radeon driver code / drm code only. ..nothing to do with xserver version
glisse: agd5f: 2d/3d engine interaction are definitly painfull, waiting for idle in many place doesn't solve hardlockup
elbeardmorez: glisse: is this the 'RADEONWatiorIdleCP idle reset loop issue that's all of a sudden back?? I had it yesterday, came here and moaned, but then it disappeared and i've been stable ever since. [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f58fa200 f58fa200' ..those were the repeated system messages. I had all 'performance' options off for testing...
elbeardmorez: ...purposes, and consistently got these lockups.. ..but thinking 'try exa instead', i realised all my video options were commented out, and restoring these solved the issue, xaa and exa are both fine.. would seeing the options added help?
glisse: elbeardmorez: no i am talking about hard lockup where you only can shutdown your computer
dav7: glisse: and can't ssh?
glisse: dav7: i do mean hardlockup
dav7: glisse: right. I understand, I get them [reproducibly] when I try to make my integrated (Intel) video work at the same time as my ATI card.
dav7: if I select Integrated in the BIOS then try to boot X with the BusID and Driver set to those of my X1550, I get a hardlock.
dav7: same if I select PCI and boot the integrated video.
elbeardmorez: glisse: the repeated idle messages eventually do hard lock the computer (can't ssh) ..but whilst they were steadily filling the log file.. I run two card.. .the radeon went dead.
dav7: however... in winfailure, both would work happily together...!!
dav7: 3 screens ftl... ahh, those were the days... :P
dav7: ftw*!
dav7: err
dav7: something's up with this...
dav7: I'm trying to run VDrift, a racing simulator. it worked fine in fglrx until the stupid driver decided to asplode and segfault everything that wanted acceleration.
dav7: now vdrift is bugging out with:
dav7: EXCEPTION: Error initilizing VDrift: Surface creation failed.
dav7: augh
dav7: this new build of X won't work with fglrx
dav7: so I can't get that modeline
dav7: which was the best for this monitor
dav7: GRRR
dav7: okay that's it
dav7: I'm reinstalling my distro's X.org build
MostAwesomeDude: 'k.
MostAwesomeDude: Good luck.
dav7: lol
dav7: hi again
MostAwesomeDude: Okay, sleep for good this time. Night, guys.
dav7: how can I output my screen's current modeline?
airlied: agd5f: I've checked in a bunch of atom endianness fixes.
MrCooper: airlied: ugh, just get rid of those bitfields? :)
airlied: MrCooper: they are in the atom code .. I hate doing anything big to it.
MrCooper: k
airlied: I'm thinking of dropping the atombios wrapper code as I can't see a great use for it.
airlied: but I said I'd at least get endianness right.
adamk: I have an rs485, with the latest mesa/xserver/drm/ati from git, but can't get direct rendering to work. Yet I can't tell from the /var/log/Xorg.0.log file why it's not getting enabled. Any thought? http://pastebin.ca/1044711
airlied: I'm not sure the atom engine bits are right yet, I need to put a real r500 cards into my g5 isntead of my broken r420
adamk: Hmmm... The kernel module loads if I modprobe it first but doesn't get loaded when I start the X server.
adamk: Alright, so even after updating everything to git from this morning, I still have the same problem...
dump_01: hi
dump_01: im using freebsd 7.0 and radeon xpress 1100 integrated card on my laptop
adamk: Yay.
adamk: I'm using an xpress 1100 under Fedora 9.
dump_01: can use some glx? is it works?
adamk: dump_01, Theoretically, yes. I can't seem to get direct rendering working, though.
dump_01: so sad.. how to help to develop direct rendering driver for frebsd?
dump_01: sorry for my english :(
adamk: dump_01, Well, the driver already works on FreeBSD. The latest versions of mesa/xserver/drm/ati from git all compile on FreeBSD. Most likely my problem is a configuration issue, I think.
dump_01: hm... its hard to deal with git to me.. how to use git?
adamk: You could try it yourself by building all the necessary parts from git.
adamk: dump_01, Here's a tutorial on building the latest mesa/drm from git: http://dri.freedesktop.org/wiki/Building
adamk: You would need to do the same with the xserver and the ati driver.
adamk: Well I have swrast_dri.so installed now, so at least X isn't failing any more, but direct rendering still won't get enabled in the X server.
z3ro: anyone know how to figure out where high usage of memcpy/memset is coming from using oprofile? I'm trying to work out whether this is my program, or mesa, or some other lib.
z3ro: but oprofile just says libc.so, which obviously isn't very helpful.
glisse: z3ro: try callgrind
glisse: from valgrind
glisse: i use it with kcachegrind for graphical analysis of data
Zajec2: z3ro: ping...
z3ro: Zajec2: pong (sorry, I wasn't here very much tonight)
Zajec2: z3ro: sure, np, just wanted to ask about valgrind again... yeah i'm probably boring about that ;)
Zajec2: did you try to reconfigure patchev valgrind to make in compile "mmt" tool?
Zajec2: *patched
z3ro: haven't really had a chance to look at it again yet, but I'm reasonably sure I'm not working tomorrow so I can look then.
Zajec2: ok, would be great :)
z3ro: possibly tonight if I get to it before 3am or so. :)
z3ro: glisse: hmm kcachegrind looks interesting
z3ro: although I generally don't like gnome/kde progs since they depend on so many bloated libs. but this looks like a good tool.
glisse: z3ro: well its a graphic tool for parsing result of callgrind
z3ro: glisse: does callgrind cause much of a performance hit?
adamk: brb
glisse: z3ro: like valgrind when tracing memory
glisse: but you won't see it in result
glisse: in my experience optimizing bottleneck callgrind showed did gave me a great perf boost
z3ro: thats good to know. I've done some optimization based on oprofile, but no huge boosts.
z3ro: right now I'm starting to think it's memory management related.
z3ro: eg, my total lack of memory management beyond simple malloc/free/memset/memcpy wrappers.
z3ro: the engine easily eats 60% memory during normal rendering. something I need to fix...
z3ro: oh fucking sweet... my isp just decided to change me to a 30gb plan, and make me pay 10$ every 5gb
z3ro: nice how they just go and change my plan without telling me anything.
sn9: cable or fiber?
sn9: (no dsl provider would slam like that; not even at&t/yahoo)
z3ro: it's dsl
z3ro: all I can get here.
sn9: are you within _one_ thousand feet of the CO?
z3ro: CO?
sn9: central office
z3ro: hmm I doubt it.
z3ro: the scumbags known as telecom have a monopoly by owning the phone lines, which is a direct result of the goverments stupidity.
z3ro: so they can charge whatever they like really.
z3ro: or rather, telecom charge the ISP's whatever they like, which is why the prices are so insane.
sn9: because you can only approach thirty gigabits per second within one thousand feet (300m)
z3ro: no, 30gb data usage.
sn9: "loop length" or "loop distance"
z3ro: I used to be on a 100-something (120 iirc) per month plan, they changed me to 30gb/month behind my back, and since I've used about 80gb this month already, I have a really expensive bill now. :(
sn9: i hope that's gigabYtes, then
rschmidt: my ISP did something similar in 2003... I was a heavy downloader on an unlimited plan, and then boom! they sent me a bill for $600 (regular cost was $45)
sn9: rschmidt: dsl also?
rschmidt: yeah
z3ro: I think I see whats happened. they are trying to phase out the "heavy" plans, and replace them with some crappy "20gb/month" plan (thats their idea of heavy?)
z3ro: so they have moved me over without saying anything.
z3ro: and the plans page says you can't move back to those old plans.
z3ro: in which case, I'm not paying the bill and finding a new isp.
rschmidt: that's what I did
z3ro: (actually the new isp would be just as crap, but I guess it's the principle of the thing)
sn9: are you by any chance both australian or something?
rschmidt: hey, they'll never change if you let them keep doing this
rschmidt: no, I'm Canadian... why?
z3ro: I'm .nz.
sn9: because i've often heard complaints about optus
rschmidt: make sure you tell them when you cancel your service
sn9: but come to think of it, i've also heard very bad things about telus in canada
rschmidt: my problem was with Sympatico, but they're about the same...
z3ro: rschmidt: well, I'll give them a chance to sort it out (bill me as if I was still on the old plan, and change me back immediately)
z3ro: but failing that, no money for them, and new isp for me.
rschmidt: z3ro: Well, I wish you luck, but from my experience, there's almost no chance they'll do that...
rschmidt: when I called them, it was all "Pay up or we'll send a collection agency after you"
z3ro: rschmidt: yeah I've had fun experiences in the past with a different isp (usually at least 3hr wait, after being transfered around a few times)
sn9: z3ro: got any of those .nz-only rotary phones left?
rschmidt: which they never did, of course, but they weren't interested in lowering charges or bargaining or anything like that at all.
z3ro: sn9: haha
sn9: different from any other rotary phones in the world
rschmidt: ... do they go up to 11?
z3ro: rschmidt: I'm no lawyer, but I'm pretty sure it would be illegal somehow to change a service behind the customers back without telling them.
sn9: rschmidt: they go 9-8-7-6-5-4-3-2-1-0 instead of 1-2-3-4-5-6-7-8-9-0
rschmidt: z3ro: yeah, in my case, it was illegal, and they ended up getting so many complaints they dropped all the bills for that period and tried to beg us to come back
rschmidt: actually, the same company is facing a class-action lawsuit for breach of contract, invasion of privacy, and false advertising
z3ro: it might get messy though, because they have been sending me "you've gone over this 5gb block" messages, but I've been kind of lazy about reading email this month
rschmidt: hahah
rschmidt: they're all the same
rschmidt: my ISP was complaining that they had warned me a bunch of times, but when I signed up I had about a dozen e-mail addresses and specifically asked them to send my correspondence to a non-ISP address
rschmidt: which they never did, and then of course, I was "supposed to read my inbox" all the time.
sn9: my isp always has trouble getting the message of "when you call me back, call my cell, not the dsl line"
rschmidt: it's absolutely laughable
z3ro: I think they should be renamed to IDSP: Internet (Dis-)Service Provider ;
rschmidt: I work in an office where we do tech support for people trying to use wifi services in hotels in North America.
rschmidt: Every time we call people back on their cell phone, or just call them back at all, people are frankly amazed.
z3ro: I guess you deal with a lot of moronic people too?
rschmidt: Personally? No, I run a department that builds digital signage appliances. But I have dealt with moronic people in the past... and usually they're just scared of breaking something.
sn9: no, you need smarts to be scared
rschmidt: heheh
z3ro: lucky you. :P most of the people I have to deal with can't grasp the concept that an ethernet and phone cable are not the same thing.
sn9: z3ro: do you deal with them over the phone, or over the ethernet? :D
z3ro: sn9: hehe :P
z3ro: well on the phone isn't so bad. people are much more annoying in person. :P
rschmidt: hey, I once talked to a woman who was convinced that her old Mac laptop was wifi compatible despite the fact that she didn't have a wifi card, because "it's wireless, so it doesn't need anything to work"...
sn9: she was missing the internal wifi card?
rschmidt: yeah, this was a pre-wifi model
sn9: so, 1998 or earlier...
rschmidt: oh yeah, truly ancient
sn9: did she happen to mention what color it was?
rschmidt: I believe it was white... but it was a long time ago.
sn9: all white mac laptops had a wifi connector
sn9: under the keyboard
rschmidt: hey, all I can say is that I got hundreds of other macs connected, but in this one, there was no wifi adapter to be found...
rschmidt: maybe it was just broken.
adamk: "09eb220971b5d2bfd7d1ff6f552060967a133152 is first bad commit"
sn9: they all shipped with the antenna, but a great many shipped without the actual adapter
adamk: FYI, that commit breaks the driver on my machine.
adamk: http://pastebin.ca/1044945 is the backtrace.
z3ro: adamk: probably best to file a bug on bugzilla with all the info
rschmidt: z3ro: anyway, good luck with your ISP issues, hope you find a decent one that won't try to rape you at every given opportunity :P
sn9: speaking of white mac laptops, is agd5f any closer to tvout on r128 (for my white mac linux laptop)
sn9: ?
z3ro: rschmidt: yeah hopefully if I argue enough... but I suspect it will be an uphill fight.
z3ro: at least I've got a phone headset lying around so I don't actually have to sit there holding the phone while they put me on hold.
agd5f: sn9: I have an r128-support tree somewhere where I ported r128 support into radeon. tv-out sort produced a signal, but no picture
sn9: so, r128 might finally be folded into radeon? yippee!
adamk: Done: https://bugs.freedesktop.org/show_bug.cgi?id=16308
adamk: Includes error from Xorg, backtrace from gdb, and the bad commit from git-bisect :-)
adamk: Hmmm... I didn't describe my hardware.
sn9: agd5f: you do the savage driver, too, right?
rschmidt: z3ro: it almost certainly will be, but if you remain firm and don't let yourself be cowed, you'll probably get out of it
agd5f: sn9: yeah, although I haven't really messed with it in ages
sn9: is it at all possible for savage tv-out to use a res other than 640x480?
sn9: didn't seem to support xrandr last i checked
z3ro: rschmidt: yeah
sn9: agd5f: or would that ever happen?
agd5f: sn9: I don't think so. IIRC they don't have a scaler
agd5f: for tv-out
sn9: well, i tried it under windows, and it scaled
sn9: agd5f: IX/MX variety
agd5f: sn9: probably could then
sn9: agd5f: so, when can r128-support in radeon be merged for testing?
sn9: the dri hardlocks in the r128 driver have to go
agd5f: sn9: I doubt it'll get merged anytime soon. you'd need to port over all the dri stuff. I never got to that
sn9: awwwwwwwwwwww
sn9: as long as i'm asking about how ati and s3 things are going, might as well ask libv about the KM400 and the RS780...
surfer: i think the rage128 is older than i am
surfer: u can upgrade for like $30 bro
surfer: heh
sn9: surfer: in laptops?
rschmidt: regardless, there's no good reason (other than lack of time / resources) not to support older cards... a lot of people can only get their hands on older hardware
sn9: better late than never
otaylor: though there is some real question as to whether 3d on a r128 is useful for anything...
rschmidt: I dunno, I think there's always a potential use or two... embedded devices, for example
rschmidt: not everything needs to be displayed at 60 FPS in 1600 x 1200
otaylor: rschmidt: Not so much power as feature set... max texture size, etc.
sn9: texture sizes are somewhat dependent on vram
sn9: there were r128 cards with 32M
rschmidt: otaylor: I agree that it's somewhat limited in today's context... I just don't agree that those limitations make the 3d useless
otaylor: rschmidt: Well, if you want to play 1998-vintage games
rschmidt: hey, some friends of mine still play Dr. Mario on an 8-bit Nintendo... who am I to judge?
otaylor: sn9: there's also genreally hardware limits. Probably 512x512 for a r128 (without checking)
sn9: the 128 in r128 stood for 128 bits
otaylor: sn9: the 128 bits probably had something to do with the memory bus (at least as much as it had anything to do with the card architecture)
sn9: that i don't remember
otaylor: sn9: In any case, you aren't going to be able to run compiz on one usefully :-)
sn9: or at all, probably
sn9: that's the specific reason i chose 32768 as the cutoff point for compiz in my ubuntu post-install script: http://linuxmafia.com/isos/hardy/fresh-ubuntu-hardy
sn9: i have a 32M r128 card from gigabyte lying around somewhere
sn9: it's the card on which i first discovered the r128 dri hardlocks
sn9: http://china.giga-byte.com/VGA/FileList/Manual/manual_ag32s_121_e.pdf
agd5f: r128 had 2k textures IIRC, but the main problem is lack of NPOT textures
adamk: Any ideas why I'm not getting direct rendering on my Xpress 1100? http://pastebin.ca/1045108
agd5f: adamk: add Option "DRI" "TRUE" to teh device section of your config
agd5f: make sure you have the latest drm bits
adamk: I definitely have the latest mesa/drm/xserver/ati installed.
adamk: Well that did it.
adamk: Is that only necessary for Xpress GPUs?
Rioting_pacifist: im getting "(If you want to find out why, try setting LIBGL_DEBUG=verbose)" from glxinfo how do i set libgl_debug?
dmb: LIBGL_DEBUG=verbose glxinfo
surfer: fuck!
surfer: X keeps fucking crashing
surfer: where would it dump the core file?
surfer: i'm pretty sure i got x to run with core dumps enabled
surfer: [ 7210.043038] X[6478]: segfault at 8d ip a6d49c11 sp bfb37af0 error 4 in r300_dri.so[a6c94000+229000]
surfer: can't find the core dump... gentoo turns them off by default, but i thought i had corrected that... argh
VHeinz: Hi, I'm looking for an IRC channel about the ATI windows driver.
VHeinz: Altough the thing I want to know is probably more general
bobbens: don't think that exists on freenode :)
VHeinz: mm ok. May be you know a channel on an other IRC server?
VHeinz: Is it possible to send any resolution over a DVI link, like sending 1792x1344 without any black borders? Or are there defined somewhere?
surfer: i'm going start X using startx from now on... and cut gdm out of the loop
surfer: hopefully it will provide a core dump next time it segfaults
surfer: [ 7210.043038] X[6478]: segfault at 8d ip a6d49c11 sp bfb37af0 error 4 in r300_dri.so[a6c94000+229000]
xnguard: Now I'm mildly curious to know about VHeinz' question in a general way: anyone know of a reason you can't send arbitrary geometries over DVI, other than link bandwidth limits?
egore: anyone already knows that 09eb220971b5d2bfd7d1ff6f552060967a133152 breaks my x86 box?
egore: though I don't really understand why it should happen
surfer: is that from mesa?
surfer: or xf86-video-ati
egore: xf86-video-ati
egore: airlied's endianess fixes
egore: from the commit it looks clean
egore: I'll have to check my X_BYTE_ORDER define
surfer: hmm
surfer: my binary says 6/8/08 17:37 pacific
surfer: i dont know if that was before or after
surfer: heh
surfer: i guess before
surfer: let me build it and see if i can use the latest
egore: hmpf ... my system says "if X_BYTE_ORDER == X_BIG_ENDIAN" is true
nh_: you obviously have a gender-confused x86
egore: nh_, yeah ... now I just need to figure out how to operate it back :-)
egore: but /usr/include/xorg/xorg-server.h looks sane ... how does it get mixed up?!?
egore: it should fail for the rest of xf86-video-ati then ... the code is full of these checks
egore: if I put a "รครครครค" in a "#if X_BYTE_ORDER == X_BIG_ENDIAN" block everything compiles fine. if I put it in AtomBios/includes/atombios.h it failes ... must be the order of includes then
egore: or a missing include even
surfer: well
surfer: if any of ur headers think u have big endian
surfer: i can see how that could be a problem
surfer: did u write them urself or something? heh
egore: no. somewhere it's missing the include of xorg-server.h before the include of the atombios stuff
egore: at least I think
airlied: egore: oops :)
egore: airlied, no problem as long as you can figure out how to fix it :-)
egore: airlied, I added the "HAVE_CONFIG" to the top of CD_Operations.c but it still failed for me. I thought this should have fixed it ...
airlied: egore: try adding #include "xorg-server.h" there as well
egore: bug config.h does this ...
egore: s/bug/but/
airlied: oh yeah
egore: and I verified that HAVE_CONFIG is defined
airlied: egore: fixed hopefully
egore: hmm, then I was only missing Xos.h ... will test and report :-)
egore: airlied, same needs to go into AtomBios/Decoder.c
egore: airlied, or simply in atombios.h?
egore: airlied, if you want to know my dead simple trick to test it: put garbage (like "asdasdasd") into the #if-block you don't want to enter ... if the compiler complains, something is wrong :-)
airlied: egore: I thought I did that as well :)
airlied: #warning and grep :)
otaylor: egore: there is #error "This shouldn't have been compiled" for a little more cleanliness :-)
airlied: I just forgot the grep :)
egore: airlied, otaylor: I'm a Java programmer ... what do I know about cleanliness ;-)
surfer: hm
surfer: x won't start anymore with the latest shit
airlied: egore: okay one more time then :)
adamk: surfer, Check this report: https://bugs.freedesktop.org/show_bug.cgi?id=16308
surfer: ok
adamk: surfer, Then try resetting to that commit and see if it works.
adamk: I've been here most of the day and haven't heard about the problem from anyone else, so it'd be nice to get it confirmed :-)
airlied: just pull master it should be fixed
adamk: Oh.
airlied: adamk: egore just mentioned it to me and I fixed it :)
adamk: Well I brought it up earlier today, but z3ro said to open a bug report :-)
surfer: actually
surfer: i just rebuilt the driver with whatever change just got made to decoder.c
surfer: and it works again
egone: airlied, you broke it, you fixed it :-) great job!
surfer: any idea why my normally blue folder icons sometimes turn half black?
surfer: is that a gnome thing or dose that sound like a graphics glitch
xnguard: surfer: Are you using a reasonably stable version of GNOME and support libs (gtk+, etc.)?
surfer: yea
surfer: i use gentoo ~x86
xnguard: surfer: That's not quite the same thing as stable. :) But if you're using current 2.22 and support libs... well, it could still be GNOME. But I'd vote driver glitch.
surfer: um
surfer: well ~x86 uses 2.22
surfer: so why isn't that stable
surfer: heh
surfer: i think it's a driver glitch too
xnguard: surfer: I admit, non-~ archs tend to be overconservative. But.
surfer: i'm using the tango icon set
surfer: i'll show u what i mean
surfer: http://www.webaccel.net/surfer/screen.jpg
surfer: sometimes it's just my home dir
surfer: sometimes it's other folders on the desktop
surfer: it happens kind of randomly which is why i dont think it's gnome
tulcod: surfer: gotta say it looks like an easter egg
orki: On trying to build xf86-video-ati git, I get that struct drm_modeset_ctl has no member named crtc
bgoglin: agd5f: can we expect a new ati release soon ? where "soon" means before 7.4 is out :)
orki: Do I need a newer version of some other stuff?
agd5f: bgoglin: I hope so :)
bgoglin: great
surfer: easter egg?
nh_: orki: sounds like you need to build a newer version of libdrm
airlied: bgoglin: I just read on /. 7.4 ain't ever coming out
airlied: ::-)
nh_: yeah
nh_: that /. thread made me giggle and sigh at the same time
nh_: orki: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary <-- that's the gitweb for the drm tree
agd5f: nh_: yup
airlied: I should figure out how to release things again.
surfer: airlied: any ideas on my icon glitch?
airlied: surfer: wierd, but no ideas.
surfer: maybe i should see if it happens with fglrx
surfer: or vesa
orki: nh_: thanks
orki: I have a memory leak with F9 koji radeon driver; I think airlied built it from a checkout on May 28
airlied: orki: it might be a leak somewhere else caused by the driver doing something new
orki: airlied: xrestop does not show anything gobbling up memory as X is
orki: if the memory is not visible in xrestop, my poor understanding says it is a problem within the driver
airlied: orki: no it might be a problem with X, xrestop is only for blaming apps
orki: airlied: ok, can you point me to somewhere which tells me how to start debugging this?
airlied: orki: valgrind..
orki: run X under valgrind?
orki: wow
airlied: yup :)
airlied: michaellarabel: Carl Worth works for Red Hat also
orki: airlied: is there a known suppressions file for X for valgrind before I start running X under valgrind
airlied: orki: not that I know off..
airlied: orki: the other option is to run something that triggers it and narrow it down.
airlied: also are you sure its a real leak and not some cache building up..
michaellarabel: airlied: Oops, fixed. Thanks.
orki: airlied: ok
glisse: sometimes i hate being right
glisse: agd5f: it seems that forbidding 2d blit solve my last lockup case
glisse: airlied: when we move a 3d window we don't emit anyblit do we ? (except for decoration i guess)
glisse: ah no lockup just take more time to happen :(
rx__: nice..
rx__: r6xx :)
mattst88: rx__, ehh?
airlied: the instruction set doc is public.. not programming info but at least the isa
agd5f: This document has been flaoting around with the CAL/GPGPU stuff for a while, but it's relevant to graphics as well
agd5f: the full programmming guide will be coming soon. it's big about 700 pages at the moment
GerbilSoft: what exactly is the ISA doc
GerbilSoft: doesn't have an R600, but may consider one in the future :)
agd5f: GerbilSoft: it's the shader instruction set
GerbilSoft: oh. nice
lupine_85: has an R600
lupine_85: give is a while
lupine_85: it*
GerbilSoft: has an RV530
GerbilSoft: i don't suppose GPGPU is supported on R500, is it?
lupine_85: No, that's R600+
GerbilSoft: :( oh well
airlied: it could be, but the r500 doesn't have percision
GerbilSoft: and i can't really upgrade the video chip since it's a laptop
airlied: most gpgpu people want double precisison
lupine_85: is quite looking forward to r600+radeonhd+cal... when it comes
xnguard: GerbilSoft: The official AMD line, as I understand it, is "No, but we could if someone really wanted, but no one seems to want it enough."
GerbilSoft: ok
GerbilSoft: no big deal
GerbilSoft: i don't really know of any GPGPU apps right now other than F@H anyway :D
airlied: nobody wants it due to it not really being useful without double precision numbers.
xnguard: airlied: That's a problem, yeah.
lupine_85: mm, I really want it for F@H too
lupine_85: then, I wonder how much other stuff could be offloaded to the GPU in the context of a normal linux desktop
airlied: lupine_85: you could offload graphics.
lupine_85: ...
lupine_85: I hadn't thought of that
GerbilSoft: haha
RTFM_FTW: actually I don't believe the R6xx shader pipe ISA is documented publicly
lupine_85: :D
GerbilSoft: imagine that
airlied: RTFM_FTW: the doc just got released
GerbilSoft: using a GPU to offload graphics
RTFM_FTW: interesting
lupine_85: yeah, crazy stuff
lupine_85: next, they'll be suggesting that you use the FPU to do floating point maths
GerbilSoft: what! that's crazy
lupine_85: more seriously, about the only other use for GPGPU that I've found is in building agent-based models (I did a bit - CPU only - for my dissertation)
lupine_85: there's got to be more
GerbilSoft: video encoding
lupine_85: well, that's what avivo's for, isn't it?
RTFM_FTW: airlied throw me a link to it
RTFM_FTW: since I don't see anything R6xx specific pertaining to the 3D core
airlied: RTFM_FTW: http://www.x.org/docs/AMD/r600isa.pdf
RTFM_FTW: which like I said earlier isn't publicly documented that I know of
lupine_85: hates having under-utilised hardware capabilities
RTFM_FTW: interesting
lupine_85: that said, I've had some troubles with CAL + fglrx
xnguard: Well, GPGPU sounds great for raytracing clusters, and vastly cheaper and more power-efficient than huge CPU clusters.
xnguard: In fact, I recall reading about someone building just such a cluster out of Radeon X2 cards t'other day. Not many cards, but *very* speedy.
lupine_85: since I shoehorned the beta into debian lenny, I shouldn't be too surprised, though
lupine_85: gets an X BadRequest error (147/7)
ganymede: does anyone know if calls to glVertex..() generate a system call anywhere down the line or whether that's all done in userspace?
bridgman: AFAIK everything is done in user space until it's time to submit commands to the GPU;
bridgman: the userspace mesa driver assembles buffers full of commands then calls into drm (in
ganymede: bridgman: so the commands get queued up and sent to the gpu in bulk via system call?
bridgman: the kernel) to DMA the commands to the chip etc...
bridgman: AFAIK, yes
ganymede: bridgman: okay, thanks for this clarification
bridgman: if you feel up to reading a bit, take a look through the Command Processor
bridgman: section of the 5xx programming guide; basically the drm maintains the ring buffer
bridgman: and some information like clipping rectangles (which limit the chip so that
bridgman: it only draws in the active window)
bridgman: you only need to read about 5 pages; actually Alex's blog at www.botchco.com/agd5f
bridgman: has a better explanation
ganymede: bridgman: thanks again, i will read this now
damentz: hey bridgman, i have a bug report for fglrx...
bridgman: no, really ?
bridgman: ;_)
damentz: fglrx makes mouse lag when using (low-latency) preemptible kernel as opposed to voluntary kernel preemption or no preemption
damentz: i have to recompile my kernel to use voluntary everytime my distro releases a new one
bridgman: interesting... something else to ask about ;)
damentz: i made a post in phoronix a long time ago, i didn't know what was causing it
damentz: well, now i do :)
bridgman: good find
damentz: oh here's something weird
damentz: fglrx makes my cpu meter in kde show high kernel usage in graphics intensive applications
damentz: but the open source radeon driver doesn't do that at all
damentz: like, it has 3 meters, user, system(kernel), and nice
bridgman: not so wierd; the more efficiently the driver can pack work into the GPU (ie the less
damentz: ohhh
bridgman: time you spend waiting, or the more pipelining you do) the higher the GPU and CPU
bridgman: utilization gets
bridgman: a simple driver spends more time waiting before doing the next thign
airlied: triple buffering also will max CPU
damentz: ok that makes sense
bridgman: thing
damentz: btw, with that mouse lag
damentz: it happened after version 7-11 of fglrx
bridgman: oh that *is* interesting; not with earlier versions even with the preemptible kernel ?
damentz: well, i didn't game with anything before 7-11 since it was too slow anyway ;)
bridgman: ahh, got it
damentz: 7-12 is when you guys started changing the monitor detection i think
damentz: so i was stuck on 7-11 for a while
damentz: so i couldn't get widescreen in 7-12
damentz: since i couldn't*
bridgman: yep, from about 7-8 or so we were gradually transitioning to common code inside
bridgman: the driver, although the outside hasn't changed much yet
damentz: ah
damentz: oh shoot, btw, fglrx still detects the wrong videoram on my graphics card
damentz: i hear that everyone had theirs solved, but mine still reports 128mb instead of 256
bridgman: english pages ? All the bug reports we got seemed to be running in Italian
bridgman: not sure if it was a localization thing or what; seemed odd that one language would have
bridgman: wrong numbers but OK in English
damentz: ah, i mean on phoronix
damentz: people stopped complaining
damentz: but hmm
damentz: (--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM
damentz: but lpsci reports this:
damentz: Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
damentz: Region 1: I/O ports at d000 [size=256]
damentz: and the catalyst control center reports 256mb
damentz: but gaming performance seems to be just fine
damentz: that or the driver is just efficient enough to work around videoram limitations
damentz: err, sorry i'm hitting you with all these bugs, but i seem to get the weird ones that seem like they'll never get fixed
bridgman: no worries; we weren't able to dig through as many bugs as we wanted while we were
bridgman: moving to the new code for ogl and the internals, but now we're starting to pick off
damentz: ah ok
bridgman: a lot of the big ones and should be able to start knocking off some of the wierd ones
bridgman: soon
damentz: ok cool :)
bridgman: It was just a much better use of time getting onto common code where things like
bridgman: new ASIC support could be leveraged from other teams, so the Linux team is actually
bridgman: getting to work on Linux stuff now rather than just running after the new ASIC wagon ;)
damentz: hehe
damentz: ya, that would be a little annoying for the linux guys
bridgman: yeah, it was pretty rough for a while; everyone expects the same support and the same
bridgman: features on the same ASICs, with 10x the number of different OS variants to support
bridgman: and 1% of the market share to pay for developers. Much better now
damentz: well at least linux is pretty much guaranteed to become an important competitor in gaming
bridgman: I hope we see more native games; it still bugs me that we spent all that time
damentz: i mean, benchmarks show that some linux games run faster if they're also cpu intensive
damentz: hehe ya
bridgman: on a new fast opengl driver and all I hear now is problems running windows games ;)
lupine_85: well, there was always NWN1
lupine_85: but yeah, the constantly crashing wine is painfully annoying
bridgman: we're going to try to hook up more closely with the wine folks; not sure how
bridgman: yet but should be able to improve thigns
bridgman: damentz, could you add some info to :
bridgman: http://ati.cchtml.com/show_bug.cgi?id=1037
bridgman: pls ?
ganymede: "teams?" is there also an xbox 360 team and a Wii team?
bridgman: there were; we keep all that work *very* carefully firewalled away from everything
damentz: bridgman: sure
bridgman: else; hardly anyone even knew we were working on the wii
lupine_85: but but but
lupine_85: ATi is stamped on the case
bridgman: but ?
lupine_85: plain as day
bridgman: sorry, once they started shipping it was pretty obvious; I mean for the years before that
lupine_85: ah, ok :)
bridgman: actually it was pretty obvious as soon as the web sites started dissecting the things ;)
bridgman: it's amazing how something as big as an XBOX can leak
damentz: bridgman: hmm, i'm not sure what to add, mine shows hte correct size in amdcccle but the wrong size in the most current Xorg log
damentz: 128mb, the same as everyone else
bridgman: for some reason nobody feels the 128m in the xorg log is a problem; not sure why
bridgman: It may be that we only map enough vram into CPU address space to access frame buffer,
ganymede: i've always wondered how video game system 3d graphics work. are the drivers compiled into every game? do they use opengl or inline the gpu programming routines?
bridgman: microcode etc... and DMA everything else up
bridgman: I don't know for sure but normally they use some kind of API; the xbox dev kits
bridgman: were somewhere around DX 9-1/2 I think ;)
ganymede: oh okay, then they obviously don't inline the gpu programming routines, there's still a layer between the game and the hardware
lupine_85: bridgman: I'm curious, did ATi/AMD ever consider leveraging Mesa for their fglrx OpenGL implementation?
bridgman: not sure what nintendo uses for an API but I'm sure there is one there as well
lupine_85: or would that be insanely unthinkable?
RTFM_FTW: they have an abstract framework (i.e. D3D, GL, ...) just as the desktop does to access the underlying hardware
bridgman: not insane, just not the best starting point. The big problem is that as GPUs get
RTFM_FTW: true
RTFM_FTW: direct access hardware is rare nowadays
bridgman: faster and the kind of work they do changes you really need to change the software
bridgman: architecture as well; if you look at gallium vs current mesa you can see the kind of
bridgman: changes we made with the new OGL stack
bridgman: the hard part is that "the stuff at the bottom" is totally different and the top doesn't
bridgman: change (OGL is OGL) so you kinda have to change everything in between anyways
bridgman: RTFM_FTW: yep, seems like game development has really been able to evolve over the last
RTFM_FTW: actually in a good driver you don't necessarily need to change much
RTFM_FTW: spoken from experience here
bridgman: few years; a lot more work going into "making it look real" and less "making it run"
bridgman: good or lucky ? no disrespect intended, just it seems that you need to anticipate the
bridgman: future fairly closely to make the right decisions at the time; sometimes we do, sometimes
bridgman: we don't ;)
RTFM_FTW: well what you guys are doing is vastly different from what I do :P
RTFM_FTW: I'll leave it at all
RTFM_FTW: err at that
bridgman: ok ;)
RTFM_FTW: referring to the lack of public documentation...
damentz: bridgman: http://ati.cchtml.com/show_bug.cgi?id=1037#c9
damentz: i hope that helps
bridgman: damentz: tx
z3ro: ah, nice present to wake up to on my day off. :)
Ori_B: hm. the R600 ISA thing seems to have been released.
Ori_B: nice.
Ori_B: is there enough information in it for writing a driver, though?
Ori_B: is skimming and it doesn't seem to say how you'd upload these instructions to the card.
z3ro: Ori_B: so far, it's just the ISA, no regs yet.
spstarr: is happy I found my exa code
Ori_B: z3ro: yeah, I suspected =/
spstarr: but with X needing help who cares about s3virge
Ori_B: ah well, at least it's something, and more has to be on the way =)
bridgman: Ori_B: this doc serves two useful purposes
bridgman: 1. It gets the most difficult to understand information out in developers hands now
bridgman: 2. It means we can chop another 50+ pages out of the remaining docs and get them
bridgman: out the door more easily ;)
bridgman: Seriously, nearly all of the radically different stuff is in this doc; the rest is
bridgman: mostly HW setup and not that radically different from earlier chips
Ori_B: bridgman: sure. it's not enough for a n00b like me to try adding support for my new card though. I barely understand anything =)
Ori_B: it's definitely awesome that it's out though
bridgman: don't worry, it's not enough for anyone to add support; but it lets the headaches
bridgman: start a little sooner and end a little sooner; and means you don't have to read
bridgman: 750 pages in one night ;)
bridgman: The one thing I don't think we have fully covered in either doc is the fact that
bridgman: big chunks of VAP (the block that hoovers up vertex information and feeds it
bridgman: into the graphics pipeline) have been replaced with vertex shader instructions
RTFM_FTW: bridgman do you work for ATI / AMD?
bridgman: so rather than a "highly programmable fixed function block" we now just have
bridgman: "really highly programmable"
bridgman: RTFM_FTW: yes, in the PC graphics SW group; I'm an architect there
RTFM_FTW: ah cool... so do I
bridgman: now that was a possibility I hadn't considered; best guess so far was Apple...
RTFM_FTW: heh
bridgman: email me some time; IRC handle is my last name
RTFM_FTW: that is close actually... I work in the Macintosh driver group
bridgman: ahh, now it all makes sense ;)
RTFM_FTW: in one of our east coast offices
RTFM_FTW: you can probably figure out which one :D
bridgman: yep, and might even get your name if I think hard ;)
RTFM_FTW: heh
bridgman: well, nice to meet you ;)
RTFM_FTW: heh nice to meet you too
bridgman: Matthew is going to find this hilarious
RTFM_FTW: oh?
bridgman: yeah, normally I can figure out where people work pretty easily but
bridgman: you had me stumped, so I asked him if he knew who you were
RTFM_FTW: heh
bridgman: I think he was the one who guessed Apple
MostAwesomeDude: Back.
MostAwesomeDude: Docs?
MostAwesomeDude: BRB.
bridgman: Yes, 342 new pages for you to read and enjoy.
bridgman: Sorry ;)
MostAwesomeDude: Back.
MostAwesomeDude: Downloading now.
MostAwesomeDude: Oh God, there's so much content.
moondrake: content? in what?
moondrake: studies his coffee cup
moondrake: lots of content
spstarr: heh