Radeon IRC Logs For 2008-5-28

mcgreg: airlied: you merged the yesterdays current version to master now? (if I understand this correctly)
MrCooper: mcgreg: that’s right
eboettcher: arg crash in r300DestroyContext… and on that note I sleep
eboettcher: always good to wake up to a screen full of crashdump
MostAwesomeDude: Yep.
MostAwesomeDude: So, I hear we have GART issues.
MrCooper: what kind of issues?
MostAwesomeDude: Don’t know. Guess just issues.
MostAwesomeDude: Readin’ reports, people are having problems running bigger games.
MostAwesomeDude: I myself couldn’t run screensavers while compiz was running; got a cryptic error “GART is not big enough.”
MostAwesomeDude: I suppose it would help if I knew WTF a GART is.
mcgreg: I think I’ve had problems with nexuis .. was badly slow.. and after that X crashed even when I quit it
mcgreg: though this happened after I tested several 3D stuf
MrCooper: MostAwesomeDude: Option “GARTSize” “ 8″
MrCooper: MostAwesomeDude: GART stands for Graphics Aperture Remapping Table
MrCooper: it’s a mechanism to provide a linear view of scattered RAM pages to the GPU
MostAwesomeDude: MrCooper: There’s no way to just have it automatically figure out how much RAM is on the card?
MrCooper: it’s not related to that
MrCooper: the problem is we’re currently statically allocating RAM for the whole aperture, so making it too big wastes RAM
MrCooper: this will be fixed with the DRM memory manager
MrCooper: but the default should probably be increased for >= R300 anyway
MostAwesomeDude: MrCooper: $ grep -i gart /usr/var/log/Xorg.0.log
MostAwesomeDude: (II) RADEON(0): Will use 32 kb for PCI GART at offset 0x0fff8000
MostAwesomeDude: Yeah, not a lot.
MostAwesomeDude: I mean, if I have a 256MB card, how big should the GART be?
MrCooper: that’s the maximum size of the GART table, which has one 4-byte entry for each page
MrCooper: MostAwesomeDude: again, it’s not related to video RAM…
glisse: yup
glisse: just pick some big value 32Mo
glisse: or 64Mo if you plenty ram
MostAwesomeDude: glisse: I’ll try 64. I have 2G of RAM, so whatever.
MrCooper: but going beyond 32 will also require increasing the table size
glisse: MrCooper: oh i forget about this one
glisse: 🙂
MrCooper: or even better, somebody should fix that to be handled automagically 🙂
MostAwesomeDude: MrCooper: Is that a BIOS option or something?
glisse: MostAwesomeDude: no iirc it’s in the ddx
MrCooper: MostAwesomeDude: no, another secret driver option
MostAwesomeDude: Dang. We should put those in the man page.
MostAwesomeDude: has just nominated himself…
mcgreg: just check .. fglrx seems to same a GART of 256MB .. if I undersdtand that correctly -> (**) fglrx(0): ATI GART size: 256 MB
mcgreg: *checked
MrCooper: “PCIAPERSize”
MrCooper: mcgreg: it probably doesn’t allocate that much RAM up front though
MrCooper: MostAwesomeDude: I’d say Option “GARTSize” “32” is probably the least hassle for now
mcgreg: after the merge into master, master wont compile … -> radeon_screen.c: In function ‘radeonCreateScreen’:
MostAwesomeDude: mcgreg: Need to update DRM too.
mcgreg: radeon_screen.c:848: error: ‘RADEON_PARAM_NUM_GB_PIPES’ undeclared (first use in this function)
mcgreg: oh
mcgreg: ok
mcgreg: this git stuff gets me every day again 🙂
MostAwesomeDude: mcgreg: Not your fault; one of the Mesa changes depends on defines in the current DRM in git. :3
mcgreg: brb
mosgreg: I wonder if thats a “normal” behavior: when I have 3d enabled I run some games/tool … after that my 3d is dead and I see that glx indirect is running. then I’ll get a message: R500 support requires a newer drm. libGL error: InitDriver failed
mosgreg: did he DRM somehow crash?
mosgreg: the
airlied: mosgreg: 64-bit?
mosgreg: yes
airlied: sounds like the bug radeonhd ppl seeing, server or mesa issue
airlied: it doesn’t happen with latest server/mesa
mosgreg: hmm after I restarted X -> (EE) RADEON(0): Failed to determine num pipes from DRM, falling back to manual look-up!
mosgreg: airlied: using both .. git from today (mesa,xserver, ati-driver)
airlied: wierd.. I tested it yesterday on Fedora..
airlied: maybe its something newer..
MostAwesomeDude: mosgreg: When today?
MostAwesomeDude: Within six or so hours?
mosgreg: maxbe one hour ago?
mosgreg: I started my computer at 9:00 here, that was less than 2 hours ago
mosgreg: it happened already yesterday
mosgreg: well, I’ll reboot
mcgreg: re .. it still complains about DRM … strange
mcgreg: I’ll build the kernel modules once again and install them
mcgreg: hmm I dont get it. I still get , even though I just installed the new kernel modules -> R500 support requires a newer drm.
mcgreg: and mesa is built against new drm, since I couldn’t build it else …
mcgreg: brb
mcgreg: ok, got it working again.. I tested glxgears and it was okay.
airlied: mcgreg: run it twice to make sure 🙂
mcgreg: now I ran openuviverse .. still okay
mcgreg: ok.. I’ll run a tool after tool and see what happens
mcgreg: btw.. on my x1300 .. I’ll achieved about 40-50% of fglrx-speed with quake3 .. thats not that bad 🙂
mcgreg: oh .. no, not exactly. I used the wrong prefs .. it is like 60/160 .. which is about 30-40%
airlied: we should do some work on hyper.
airlied: hyperz even.
airlied: I wonder does hyperz work by chance.
airlied: mcgreg: also maybe worth checking s3tc on/off
mcgreg: I played nexuis for a few minutes .. it was actually fine, then my monitor went to sleep, just like that…
mcgreg: I couldnt do anything anymore, except for the rset button
mcgreg: vut I’ve heard this is supposed to be the GART issue?
onestone: airlied: any idea why my performance drops after suspend/resume compiz 180 -> 60 FPS glxgears 1700 -> 300 FPS?
MostAwesomeDude: Whoo. So everything seems to work.
MostAwesomeDude: Gonna go sleep now. Back later.
glisse: onestone: likely somethings isn’t restored
glisse: like pipe number
onestone: glisse: trying now current git. after the pipe number patches
onestone: still broken
adamk: Are you guys talking about the RADEON_PARAM_NUM_GB_PIPES error?
onestone: adamk: reinstall drm git
airlied: onestone: god only knows what happens over suspend/resume..
airlied: onestone: needs more testing..
onestone: airlied: if you want me to create some register dumps, then only tell me how to do it
airlied: I’m not 100% sure what regs would be interesting to see, it might be worth doing an avivotool regs all before and after suspend
airlied: and diffing the dumps
onestone: airlied: where can I downlod it?
airlied: onestone: avivo branch of http://cgit.freedesktop.org/~airlied/radeontool
onestone: airlied: ok thx will do it. I’ve found another bug here with xrandr rotation and mesaCopySubBuffer in compiz. Wrong regions get updated. Looks like inverted y handling.
airlied: onestone: cool..
onestone: airlied: do you want my dumps?
onestone: airlied: http://dev.compiz-fusion.org/~onestone/r500dumps.tar.gz
adamk: Hmmm… So I’m updating xserver from git to test out the new r500 support, and I’m getting errors about __DRI_SWRAST_IMAGE_OP_DRAW being undeclared…
MrCooper: adamk: you need to install the headers from mesa Git master
adamk: Geez.. All these changes in how to build stuff 🙂 So I need to build mesa with the linux-dri target to build the drivers… Is there a special target to install the headers?
glisse: onestone: 3d engine setup except 4270 looks the same so this is likely somethings about gpu mode like low power mode
glisse: try to find sometools, iirc there is a radeon tool to change power mode
onestone: glisse: the funny thing is that exa/xrender performance stays the same
MrCooper: adamk: just the standard install target, whatever that is
adamk: Yeah, I figured it out 🙂 Thanks.
MrCooper: np
onestone: glisse: tried the modified radeontool and there are no powermode changes
glisse: onestone: i was thinking to a completly different radeontool
glisse: dig on phoronix forum
onestone: I know
bgoglin: guys, the r500 mesa branch got merged in master right after 7.1rc1 was released, is it going to be included in the final 7.1?
z3ro_: my new demo tool is making some progress… still a lot of work to do, but I started working on some code to allow it to replay dumps from revenge.
z3ro_: eg without actually needing to hack the code
z3ro_: also another little tool which will convert cmd stream dumps into human readable format. eg e32 (CP_PACKET0(…
z3ro_: rather than e32 (0xdeadbeef)
mikkoc: MostAwesomeDude: how do you install mesa from git on gentoo?
z3ro_: mikkoc: iirc there might be an ebuild… but it’s pretty easy to just git checkout, and build manually.
z3ro_: gentoo’s opengl selection tool is a bit of a pain though.
mikkoc: z3ro_: im using the ebuild in x11-overlay
mikkoc: but appearently im doing something wrong…
z3ro_: ok. maybe ask in #gentoo how you select the branch. iirc it’s just editing a line in the ebuild.
mikkoc: r500-support is in master now
z3ro_: oh, yeah. 🙂
mikkoc: no need to select branch i think?
z3ro_: yeah, master will be fine.
TobiasTheCommie: great, before i could get tv-out to sorta work on the radon driver, now i can’t get it to work at all….
mikkoc: z3ro_: did you install mesa manually?
z3ro_: yeah
z3ro_: brb
TobiasTheCommie: ehm
TobiasTheCommie: could anyone try the latest driver and see if they have tv-out working in any way what so ever
agd5f: TobiasTheCommie: what chip d you have?
TobiasTheCommie: rv530
TobiasTheCommie: last time i tried i could get ntsc in black and white, and fubar pal(some clock frequenzy was wrong from what it looked like, but was in colour)
TobiasTheCommie: now i get naught…
TobiasTheCommie: or rather, X and xrandr thinks there is a telly, the log files all think there is a telly, i can even move windows and the mouse into the area where the telly should be, but there is nothing on it…
mikkoc: z3ro_: if you install mesa from sources, won’t you get conflicts?
TobiasTheCommie: sorry
TobiasTheCommie: my bad
TobiasTheCommie: src/radeon_tv.c: needs update
TobiasTheCommie: src/radeon_tv.h: needs update
TobiasTheCommie: i must have fiddled around in them
TobiasTheCommie: so the svn up didn’t do anything to them..
mikkoc: and i suppose you need to uninstall the mesa ebuild… what about deps?
TobiasTheCommie: sorry, git
TobiasTheCommie: haha, that was funny, it didn’t update any of the code, at all. lets see what happens now
agd5f: TobiasTheCommie: yeah the tv-out stuff is disabled on r5xx and newer chips
TobiasTheCommie: agd5f: why? i mean, ntsc worked before…
agd5f: TobiasTheCommie: problems on some chips, never sorted them out
TobiasTheCommie: ah, oki
TobiasTheCommie: just wanted to see if any of my problems had been fixed accidentally, and also checkout the dri stuff
TobiasTheCommie: so, do i have to get a new version of mesa to try hardware accel on the rv530?
GerbilSoft: TobiasTheCommie: yes
GerbilSoft: you need git master mesa and git master drm
TobiasTheCommie: ah, oki, that explains my trouble 🙂
tormod: fir3_: you asked about a live CD with latest drivers? I kind of made that, see https://wiki.ubuntu.com/XorgOnTheEdge
fir3_: tormod: tnx, i’ll give it a try
mikkoc: ok, so i treid compiling mesa from sources, without using any ebuild.. it installed stuff in /usr/local/lib/, so i copied it over /usr/lib/
mikkoc: glxinfo gives: Error: couldn’t find RGB GLX visual
mikkoc: im confused.. this is getting so frustrating
GerbilSoft: how many visuals am i supposed to be seeing via glxinfo
GerbilSoft: i only see 0x21 and 0x22
GerbilSoft: (RV530 with latest mesa/xserver)
Zajec: does using Mesa git can increase performance of my card? or using -ati git is enought? i have rs4xx
Zajec: Mobility X700
GerbilSoft: it could potentially improve performance, but most of the development i’ve seen has been for R5xx
Zajec: ok, thx
Zajec: do you know something about difference between 6.8.0 and git for rs4xx?
GerbilSoft: no, sorry
GerbilSoft: i have an rv530
GerbilSoft: haven’t used any ATI onboard chipsets
Zajec: oki
agd5f: Zajec: support for your chips should be unchanged
dmb: are the r6xx chips going to be a lot harder to code a 3d driver for then the r5xx?
dmb: when the specs get released
glisse: dmb: completly different hw
glisse: dmb: so we start from scratch
stefan1: re
stefan1: So r500-support is now merged in mesa master?
stefan1: MostAwesomeDude: Will you continue to add code to r500-support, or can I now switch to master?
Sadako: I’ve just compiled drm, mesa xf86-video-ati and xf86-video-radeonhd from git, radeonhd reports direct rendering is working, but he radeon driver from the ati package locks up my machine completely on startx
Sadako: this is with an x1950 pro agp card
mikkoc: do i need agpgart module to get 3d working?
gustaf1: 3d for me works so so. glxgears works, but stellarium segfaults, compiz complains that my resolution is too high for the 3d buffer. warsow can’t load libGL (errors include “Failed to get colorbits 24, depthbits 24, stencilbits 0”).. what other 3d apps can I try?
adamk: mikkoc, If it’s an AGP card, I imagine the answer is ‘yes’ 🙂
mikkoc: its not
dmb: glisse, oh, sounds like fun 😛
xnguard: I’ve got an X1550 I’d actually like to replace my X800GTO with, so I’m curious about git xf86-video-ati R5xx support myself.
dmb: heads to work
xnguard: mikkoc: You need GART drivers for PCIe cards, too.
adamk: mikkoc, Well then I don’t imagine it’s necessary. It’s not necessary for non-AGP r400 cards.
mikkoc: i have an x1400 on a laptop
mikkoc: so is pcie
gustaf1: earth3d dies. foobillard dies. mm3d dies. blender dies.neverputt dies.trigger dies.. not that I care much about 3d, but so far, much doesn’t work.
gustaf1: but then again, i’m on debian amd64 with X 1.4.1, radeon from git, and mesa/drm from unofficial ubuntu packages… so I should probably expect it not to work.
adamk: Yes, you should.
adamk: Mesa and the X server should both be from git, from what I’ve been told.
agd5f: stefan1: nothing else will happen on the r500-support branch. consider it dead
gustaf1: debian provides 1.4.99-packages of xserver in ‘experimental’. that’s nice, isn’t it? but they don’t provide any of the drivers, so you can’t use it…
agd5f: xnguard: should work fine. including 3D with the latest mesa/drm/xserver bits
agd5f: GART for pcie is handled by the drm directly. there is no separate chipset module
xnguard: agd5f: Okay, good to know. I’ve been replacing bits of my workstation in an effort to stabilize it, and the only constant in this machine for the last three years is the X800GTO.
agd5f: Sadako: AGP could be problematic, no one’s test it yet
adamk: agd5f, Well I tried it 🙂
xnguard: And lo and behold: this machine is now a firebreathing E8400 on a DG33FBC with 2x2GB Corsair. And it still locks up in CMOS setup after a minute or so.
agd5f: adamk: any luck?
adamk: agd5f, The x server crashed, but I want to take the same xorg/mesa/xf86-video-ati build and try on my PCIe system to see if it works there… Just to rule out user stupidity 🙂
agd5f: xnguard: could be ram timings or voltage
adamk: agd5f, In the mean time, I can pastebin my log file if you want to look.
agd5f: adamk: sure
xnguard: agd5f: Same problem from a Pentium D 820 on D945GNTLR motherboard with Crucial RAM, D945PSN motherboard with same CPU and RAM, and now a completely new board, CPU, and RAM.
xnguard: Voltages are being supplied by a very under-loaded Antec TruePower-II, and they’re dead on.
agd5f: xnguard: a lot of motherboards are very picky about what sort of dimms will work.
agd5f: xnguard: for example, if you are runnig DDR800, try switching down to DDR667
adamk: agd5f, http://pastebin.ca/1032288
xnguard: agd5f: The original Crucial RAM was picked via their RAM selector for exactly the D945GNTLR, and was confirmed compatible for the D945PSN.
agd5f: adamk: can you run X under gdb and get a backtrace?
xnguard: This is three motherboards, two sets of RAM, and two CPUs. The one major constant is the video card, and I was having problems with CMOS setup locking up (but still responding to Ctrl+Alt+Del) *before* I OCed the Radeon BIOS.
agd5f: xnguard: did you flash a different bios onto your card?
xnguard: agd5f: Same BIOS, edited for slightly higher core and RAM timings.
agd5f: xnguard: you’re asking for trouble 🙂
xnguard: agd5f: I said I was having problems well before I edited the BIOS.
xnguard: Since the machine was stable in every respect except CMOS setup, I figured I didn’t have much to lose.
adamk: agd5f, Sure. I have a few other things I need to test first, and then some actual work to get done for work, but I can try that either later today or tomorrow morning. I know there were issues with running the X server in gdb a while back, is that still the case?
agd5f: adamk: nope, works fine.
agd5f: adamk: (as root) gdb /path/to/Xorg
agd5f: then ‘run’ and when it segfaults, ‘bt’
xnguard: agd5f: I also spent a long time torturing the machine with ATI Tray tools, determined what the highest stable core and RAM clocks were, then backed both down by 15MHz and left them there. Then I added aftermarket cooling and forced the fan duty cycle to 100% in the BIOS. 🙂
stefan1: airlied: Thanks. Will switch to mesa git master then. Or wait for the -ati/libdrm/mesa update in F9 🙂
adamk: agd5f, Right, I’ll give it a shot later.
agd5f: adamk: nevermind, I see what’s happening. Is the card a secondary by any chance?
adamk: agd5f, No, it’s the only card in the machine.
agd5f: weird, it can’t seem to access the bios for some reason
adamk: Well, the only video card, anyway.
adamk: That is odd.
Ori_B: :he
adamk: Well, if anything comes to you, you know where to find me 🙂
MostAwesomeDude: Ooh. Sick =/= fun.
MostAwesomeDude: stefan1: I’m going to add code directly to master, as long as it’s not experimental code.
MostAwesomeDude: Fixes, small features, etc. will go straight into Mesa.
MostAwesomeDude: We might branch in order to make GLSL happen, like the Intel guys did.
stefan1: MostAwesomeDude: OKie.
MostAwesomeDude: I need to fix LIT ASAP, and then I don’t know exactly what’s next.
stefan1: MostAwesomeDude: stuff in master is a good thing. Probably airlied will push it to Fedora 9 RPMs then 🙂
MostAwesomeDude: stefan1: airlied probably won’t push every little thing to Fedora, although I bet that at a minimum Mesa 7.1 will be pushed.
stefan1: MostAwesomeDude: As far as I understand the master log, mesa is now at 7.1rc. So probably the r5xx stuff will make it to 7.1
MostAwesomeDude: stefan1: Yep, airlied merged r500-support to master right after Brian tagged 7.1-rc1.
spstarr_work: hmm
spstarr_work: “ATI has not released any information about the operation of all features of
spstarr_work: “powerplay”. the “dynamicclocks” code and a few over/under-clocking hacks are
spstarr_work: all that’s currently available.”
spstarr_work: http://bugs.freedesktop.org/show_bug.cgi?id=7061
spstarr_work: is this going to change also now? 🙂
MostAwesomeDude: spstarr_work: Don’t know; ask agd5f.
xnguard: stefan1: The release notes specifically note that anyone interested in stability should wait for Mesa 7.2. Is Mesa on a odds-unstable evens-stable release scheme?
spstarr_work: agd5f: ping
MostAwesomeDude: xnguard: Technically, yes, but I bet a lot of distros will be picking 7.1 up anyway due to the massive enhancements.
rx__: i believe dynamicclocks for r500 was added in
xnguard: MostAwesomeDude: *makes note* Thanks.
MostAwesomeDude: I mean, being the only distro on the block that doesn’t support r5xx Radeons? Not likely.
spstarr_work: do we have SRPMs or nightly snapshots of mesa, dri(2), and git ati driver?
rx__: 2008-04-04ATOMBIOS: Add support for DynamicClocks option3-21/+64Alex Deucher
spstarr_work: or do i have to build these manually and roll into the existing .spec files
xnguard: MostAwesomeDude: Well, 3D support continues to be one of those “ready for the desktop?” hot buttons… 🙂
MostAwesomeDude: rx__: There’s some starter stuff that uses the AtomBIOS tables, but nothing for the older cards, and it’s not configurable.
rx__: define older?
MostAwesomeDude: xnguard: Right. Ubuntu will include it next release, Fedora will push it as an update, Debian will debate its merits and demerits for two years before finally deciding to add it to experimental.
MostAwesomeDude: etc.
MostAwesomeDude: rx__: Um, pre-AtomBIOS.
rx__: oh
xnguard: MostAwesomeDude: Don’t give me more reasons to be down on Debian, please. 😉
MostAwesomeDude: xnguard: Hey, I love Debian for servers, but they can be soo slow for desktop packages.
rx__: pre-atombios i thought it just did some register writes
xnguard: MostAwesomeDude: I’ve been meaning to play with Ubuntu Server.
xnguard: *Damn*, I could use a virtualization box.
agd5f: spstarr_work: there’s an almost complete powrplay implementation for r5xx in my personal repo
agd5f: just have other priorities at the moment
rx__: agd5f; almost complete?
rx__: what’s missing?
agd5f: rx__: drivers for the temperature sensors so you can read the current temp and some of the voltage stuff
rx__: ah
agd5f: also, to mak ething dynamic, we rally need xrandr gpu objects
adamk: Cool, latest X server, mesa, drm, and xf86-video-ati from git gets me a machine check exception with my x850.
MostAwesomeDude: agd5f: Is that lm_sensors stuff, or xorg stuff?
onestone: shaping of the composite overlay window is definetly only broken on radeon
spstarr_work: agd5f: and what about r3xx love? 🙂
spstarr_work: sadly, my laptop will never have an r4,5,6xx chipset
adamk: Oh, correction. It gets me a machine check exception when I start up compiz with that combination…
adamk: Hmm.
agd5f: MostAwesomeDude: remains to be seen, if we implement in the drm, it’ll use the i2c subsystem
agd5f: spstarr_work: lack of atom makes things much harder. we’ll see how much spare time I have 🙂
spstarr_work: ‘atom’ ?
spstarr_work: doesnt know what this Atom/AtomBIOS is
rx__: just think of them as scripts that can be run
MostAwesomeDude: spstarr_work: The newer Radeons’ VBIOS has a big area called an AtomBIOS, which has all kinds of useful card-specific info.
rx__: such as Set Engine Clock
MostAwesomeDude: Dynamic clock tables, connector tables, etc.
spstarr_work: ahh
MostAwesomeDude: And the AtomBIOS interface is reasonably sane. So supporting the basics of new cards is mostly taken care of by having an AtomBIOS parser.
agd5f: spstarr_work: it’s basically a set of scripts with a common API for programming basic stuff on the cards
spstarr_work: so its like a SBIOS for video for ati
spstarr_work: SMIBIOS
MostAwesomeDude: Closer to ACPI, I think, but yes.
spstarr_work: ok
agd5f: not really. it’s scripts that are executed by the host, not real mode x86 code
agd5f: the legacy x86 portion of the bios has it’s own atom parser and it calls the scripts too
agd5f: so modesetting, asic init, etc can be shared by bios and driver
libv: agd5f: bytecode.
libv: agd5f: wake me up when your company allows us to edit those scripts.
MostAwesomeDude: libv: Could always be worse.
MostAwesomeDude: Could be defective bytecode.
libv: MostAwesomeDude: why “could” 🙂
MostAwesomeDude: libv: Well, partly because it can ALWAYS get worse, and partly because we let Intel get away with it, too.
MostAwesomeDude: But, I mean, at the end of the day, as long as it’s documented and we can fully utilize it, I don’t care if there’s microcode on the chips.
agd5f: one could edit it if they wanted. the parser is available, the format is pretty simple, it’s not a black box
MostAwesomeDude: You’d have to flash it onto the card, though, right?
agd5f: MostAwesomeDude: no
agd5f: you can jsut tell the driver to use a cusotm bios image or execute byte code directly
MostAwesomeDude: Ooh, cool.
eboettcher: is there a particular reason Mesa isn’t auto-toolified?
agd5f: eboettcher: it is, sort of
MostAwesomeDude: eboettcher: It’s a pain in the ass?
eboettcher: agd5f: well on the top level yes
eboettcher: but below that there isn’t the stuff there that we could do if it were like ‘make tags’ 😛
xnguard: This seems like a bad time to convert Mesa to auto***** when other projects are throwing it away in favour of cmake.
agd5f: eboettcher: brianp wanted to stick with the old system, and he’s the maintainer so…
eboettcher: xnguard: the only cmake stuff I’ve seen is kde 😛
xnguard: brigandine ~ # emerge –depclean –verbose –pretend cmake
xnguard: Calculating dependencies… done!
xnguard: dev-util/cmake-2.4.8 pulled in by:
xnguard: dev-cpp/gccxml-0.7.0_pre20060311
xnguard: games-action/openastromenace-1.2.0
xnguard: sci-astronomy/stellarium-0.9.1
eboettcher: agd5f: that works, I was just wondering if there was an overiding reason
agd5f: eboettcher: nope
adamk: Mesa from git on r500 identifies the GL_VERSION as Mesa 7.1 rc1 and the GL_VENDOR as the R300 project, correct?
MostAwesomeDude: adamk: Should.
adamk: Woohoo… neverball on my x1650 with the open source drivers.
Nyle: haha
Nyle: MostAwesomeDude, what a great nickname
GerbilSoft: mipmapping’s broken right now 🙁
MostAwesomeDude: Nyle: Had it for quite a while.
GerbilSoft: which means no fancy 3D animations in OpenOffice Impress
Nyle: is otherwise known as dudeman
MostAwesomeDude: Off to class. Will fix LIT tonight.
adamk: Unfortunately, compiz locks up my machine… latest xserver, drm, mesa, and ati driver from git on both my x850 and x1650 🙁
adamk: onestone, Till I can get this working
adamk: Sorry…. I’ll roll back to the r300 drivers in fedora and test those items for you 🙂
dudeman: is there any news or info on when this driver could possibly provide 3d accel?
dudeman: couple months, couple years?
agd5f: dudeman: 3D already works on r5xx and below
dudeman: really?
dudeman: no way
agd5f: r6xx support will be starting soon
dudeman: I have x1900xt
dudeman: 256mbram
dudeman: so if i want i could get compiz confusion with alongside of radeon free driver in x1900xt card?
dudeman: right now?
agd5f: dudeman: already supported. however, you’ll need the latest git versions of mesa/xserver/drm/ati to use it
dudeman: agd5f, any idea if they could be already in debian experimetal if not sid
dudeman: ?
adamk: agd5f, Is it possible to get verbose debugging from the kernel module to find out what’s causing these system locksup? With the x850, I only get a kernel machine exception on the serial console and with the x1650, I don’t get anything on the console.
dudeman: which distribtion do you use
agd5f: dudeman: not sure. I think ubuntu has some test packages that should work
agd5f: adamk: yeah, but if it’s a GPU lock, I doubt you’ll get anything
adamk: Heh… Anything I can do to help resolve it?
agd5f: heh… that’s the $64,000 question
agd5f: 🙂
adamk: Short of sending you my system, of course 🙂
agd5f: if it used to work, perhaps try and find what versions last worked
dudeman: why 64?
adamk: Yeah, I guess it’s time to start bisecting…
dudeman: agd5f, so how about runing 3d games on this driver?
agd5f: dudeman: sure
dudeman: is it good perf?
dudeman: decent enough?
mikkoc: i just tried ut2004, it kinda works
agd5f: yup
adamk: dudeman, I just ran neverball on it.. Not the hardest hitting game in the work, but it worked 🙂
dudeman: I only play some nexiuz type fps games
adamk: s/workd/world/
dudeman: and classic doom in open gl
dudeman: doomsday engine + packs
dudeman: also can i have 1680×1050 native res on my 22″ lcd
adamk: agd5f, I’ll bisect with the x850, since that should be easier, and let you know what I come up with. Still interested in a gdb backtrace from when I tried the AGP x1300 at work?
GerbilSoft: i tried out mupen64plus – there’s some minor issues, but it works 🙂
GerbilSoft: notably the border has garbage left over from VRAM – not sure if that’s an emulator bug or a mesa bug
agd5f: adamk: no, that’s ok
adamk: k
dudeman: whats the best joystick/pad for n64 games?
dudeman: do you know?
dudeman: i have gravis gamepad ultra pro for like snes sega etc.
dudeman: mame works good too, GerbilSoft
GerbilSoft: i use a gamecube controller and super joybox 13
dudeman: ahh
dudeman: superjoybox
dudeman: hm
onestone: agd5f: I’ve found a bug in radeonCopyBuffer (mesa) where the number of submitted cliprects was to high. here is the patch http://dev.compiz-fusion.org/~onestone/0002-R2-3-4-5xx-fixed-calculation-of-cliprects-in-CopyBu.patch
Saist: dudeman : you can get usb adapters for the N64 controller
agd5f: onestone: nice! I’ll take a look
spstarr_work: agd5f: do you know when the r3xx specs will be liberated?
spstarr_work: so then the final bits of that driver can be completed?
adamk: agd5f, Does this tell you anything: [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
agd5f: spstarr_work: we already released r3xx 3D docs
spstarr_work: oh!
adamk: agd5f, I reset my compiz settings, started up compiz, and everything was fine till I started rapidly moving a window around… At which time dmesg was flooded with those radeon_cp_start errors.
onestone: agd5f: I’ve uploaded an updated version of the patch
stefan1: OK, switching to latest git’s… BRB
agd5f: adamk: sounds like a locking issue with fallbacks
dudeman: so I use debian sid
dudeman: so do i need to build the git stuff of xorg and everything for 3d?
surfer: yay!
surfer: compiz
dudeman: surfer, cool1
dudeman: !
mcgreg: dudeman: I’ll recomend to build full X from git and mesa
dudeman: surfer, my also is the goal same
agd5f: adamk: echo 1 > /sys/module/drm/parameters/debug then run compiz
surfer: having trouble dude?
dudeman: mcgreg, ok
agd5f: adamk: path might not be correct
dudeman: mcgreg, so build X from git then
dudeman: how?
dudeman: and how long can it take on 2gb ram of 3.0ghz core 2
adamk: agd5f, I’m sure I can find it. It did, eventually, lock up on me after a few seconds of those errors.
surfer: dude? which linux dist?
dudeman: debian sid
mcgreg: dudeman: compiling the stuff is rather quick
agd5f: dudeman: either that or see if your distro provides test packages
dudeman: I can always listen to niel young while I compile
dudeman: no big deal
dudeman: agd5f, i will check experimetnal archives
dudeman: ubuntu sems new should i try that with ubuntu, this driver
surfer: i can’t believe how good the shit is working
mcgreg: surfer: indeed 🙂
surfer: i have had a couple crashes though
surfer: hard lock ups
dudeman: ouch
dudeman: thats not food for yoru fs
dudeman: good
mcgreg: yeah happens here too 🙂
surfer: enable MAGIC_SYSRQ key if u care about ur data:)
dudeman: what is that?
surfer: a kernel option
dudeman: obviously
surfer: even after u locked up
dudeman: but what does it do?
surfer: u can still sync
surfer: remount all filesystems /ro
surfer: and reboot
dudeman: so how does that help me?
dudeman: would i not need to replay the journal in any case?
dudeman: given its a journed fs
xnguard: It provides some Ctrl+Alt+PrtSc key combinations. S to sync, U to remount filesystems read-only, B to reboot. There are a few others.
surfer: if u sync and remount ro
surfer: when u reboot ur filesystems are clean
surfer: no check needed
xnguard: Unfortunately, depending on how badly you screw X, the key input may not make it to the kernel.
dudeman: but if you replay the journal and write/wipe the inodes, you don’t need to check
surfer: so far, the lockups have been in a way i can always use it
eboettcher: sshd + second box helps 😛
xnguard: eboettcher: That also depends on how badly X is screwed.
eboettcher: true
surfer: what FPS u guys get from ur gears?
surfer: BTW… anybody know why I can only use 256MB of my 512MB card?
surfer: it’s a pcie card says “generation 2” but i had to set it to 8x
surfer: to use the other slot
surfer: says something about pci bar is 256MB
xnguard: dudeman: It’s possible to trash a journalling filesystem, so if you can get to the SysRq key combinations, you’re only improving your filesystem(s)’ chance of survival. 🙂
eboettcher: xnguard: I had that experience last week! :/
dudeman: i see
xnguard: dudeman: It helps if you remember that NTFS is and always has been a journalling fs. 😉
xnguard: eboettcher: Oh, dear. I hope you had backups.
stefanb: Damn, latest -ati git segfaults the server
eboettcher: xnguard: nope — I actualy went in with a combonation of grep, dd, and ext3grep to get stuff saved
xnguard: eboettcher: Whatever works, so long as it works.
stefanb: agd5f: (II) RADEON(0): RADEONScreenInit d8000000 0 0
stefanb: Backtrace:
stefanb: 0: X(xf86SigHandler+0x79) [0x80d3869]
stefanb: 1: [0x110400]
stefanb: 2: /usr/lib/xorg/modules/drivers//radeon_drv.so [0x22edd6]
stefanb: 3: /usr/lib/xorg/modules/drivers//radeon_drv.so [0x20faef]
stefanb: 4: /usr/lib/xorg/modules/drivers//radeon_drv.so(RADEONBlank+0xa1) [0x20b881]
stefanb: 5: /usr/lib/xorg/modules/drivers//radeon_drv.so(RADEONScreenInit+0x45c) [0x1f2bbc]
xnguard: eboettcher: Back in 03, I had everything important on a soft RAID5 array. Then a disk failed. Then I accidentally removed a non-failed disk from the array.
adamk: agd5f, You can the right file under /sys but it’s still not printing anything new to the serial console… I’ll fight with it some more and let you know how I make out.
xnguard: eboettcher: Now I use rsync and online disk backup to keep important stuff around.
PSYCHO___: i usually get this after hibernation/resume:
PSYCHO___: Backtrace:
PSYCHO___: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80bd624]
PSYCHO___: Fatal server error:
PSYCHO___: Caught signal 11. Server aborting
PSYCHO___: when i try gl or xv overlay
stefanb: No, this is at fresh X server start
agd5f: stefanb: looks like the same thing adamk hit. for some reason the driver was not able to access the bios
adamk: Yay, I’m not alone!
agd5f: the segfault should be fixed in git however, but the server won’t start unless it can get access to the bios
stefanb: adamk: 🙂
stefanb: Let me try the latest git
stefanb: BRB
gustaf1: when I start powermanga in fullscreen mode, both my monitors show the same thing (they are in dual-head usually). I think powermanga uses SDL. Anyway, is this the desired action? Personally I think one of the monitors should still show X as before.
stefanb: agd5f: Yep, X startup now fails
gustaf1: anyway, the worst thing is, when exiting powermanga, i’m in clone mode.
stefanb: –) RADEON(0): Chipset: “ATI Mobility Radeon X1300” (ChipID = 0x7149)
stefanb: (WW) RADEON(0): R500 support is under development. Please report any issues to [email protected]
stefanb: (–) RADEON(0): Linear framebuffer at 0x00000000d8000000
stefanb: (II) RADEON(0): PCIE card detected
stefanb: (II) RADEON(0): Attempting to read un-POSTed bios
stefanb: (WW) RADEON(0): Unrecognized BIOS signature, BIOS data will not be used
stefanb: (II) RADEON(0): RADEONFreeScreen
stefanb: agd5f: Any idea why the BIOS can’t be read? SELinux?
adamk: Nah, SELinux is disabled here, and it had the same issue on my machine.
adamk: Undoubtedly just some bug the developers need to work out.
mattst88: stefanb, you’re on an x86[-64] box?
stefanb: mattst88: 32bit Fedora 9
mattst88: strange, the log says the card is unposted
onestone: agd5f: the driver thinks that my lcd connected to VGA supports 1400×1050, but it only supports 1280×1024. http://dev.compiz-fusion.org/~onestone/Xorg.0.log
mattst88: normally see this on ppc/alpha boxes
agd5f: stefanb: try this patch: http://www.botchco.com/alex/xorg/stefanb.diff
agd5f: stefanb: are you using a libpciaccess enabled xserver or not?
stefanb: agd5f: Fedora 9 has 1.4.99 so I guess yes
stefanb: agd5f: $ fgrep PCI tmp/git-sources/xf86-video-ati/config.h
stefanb: /* #undef HAVE_PCI_DEVICE_ENABLE */
stefanb: oops sorry, wrong flag I guess 🙂
stefanb: $ fgrep PCI tmp/git-sources/xf86-video-ati/make.log
stefanb: checking whether XSERVER_LIBPCIACCESS is declared… yes
stefanb: checking for PCIACCESS… yes
agd5f: onestone: output of xrandr?
onestone: agd5f: sec
stefanb: BRB
adamk: agd5f, Is that worth me testing on the AGP x1300, too? 🙂
agd5f: adamk: sure
onestone: agd5f: hardlock after fullscreening mplayer (without compiz). vblank drm issue?
agd5f: onestone: not sure. is mplayer using Xv?
onestone: yes
surfer: what card?
GerbilSoft: onestone: possibly the same thing i’ve encountered
GerbilSoft: dragging a window over a fullscren mplayer/Xv causes a lock
GerbilSoft: *fullscreen
onestone: agd5f: it hardlocks mith mplayer fullscreen on kwin or in compiz with unredirect fullscreen windows
agd5f: onestone: what about when a comp manager isn’t running?
onestone: kwin is without comp mgr
agd5f: ok
onestone: compiz fullscreen works only without compmgr or compiz with unredirect fullscreen windows hardlocks
stefanb: agd5f: That patch helped
surfer: if i run glxgears on top of a terminal… then i move it off the terminal… the still shot of the gears stays painted on the terminal
surfer: until i move the terminal so it redraws
onestone: agd5f: http://dev.compiz-fusion.org/~onestone/xrandr.out
surfer: with compiz running
stefanb: surfer: Known “problem”
surfer: ok
surfer: just trying to be helpful
agd5f: onestone: do you have a Preferredmode option in your xorg config?
onestone: no
onestone: it has only a normal screen section with the “1400×1050” “1280×1024” …
agd5f: onestone: removes that line modes “1400×1050” “1280×1024” etc
onestone: ok will try
agd5f: I think the xserver is adding those as preferred modes
surfer: BTW, getting random hardlocks when dragging windows in compiz
surfer: everything built from repo 30 minutes ago
dudeman: hey guys
dudeman: is it hard to drive a device?
onestone: agd5f: http://dev.compiz-fusion.org/~onestone/xrandr.out2 now it also ahows a 1600×1024 mode and still selects 1400×1050 on startup. xrandr –output VGA-0 –off and then –auto again selects then 1280×1024
agd5f: onestone: ok, that looks better. the xserver is adding some weird modes. I’m guessing it adds 1400×1050 so that it can try and clone the LVDS panel and it’s withing the sync ranges of the monitor as reported by the edid
agd5f: ideally I guess we should just try and not make xrandr smart and just liit it to the modes in the edid
agd5f: s/liit/limit
onestone: agd5f: is the lcd native resolution stored in the edid?
agd5f: onestone: yes. botht eh lVDS panel and the VGA monitor have a edid with their supported modes
agd5f: the edid also lists sync ranges
stefanb: agd5f: About the BIOS problem & pci_device_enable. I guess I need to install libpciaccess 0.10.1?
agd5f: on CRT monitors you could support almost any mode as long as it was withing the sync ranges, however, this is not the case on LCDs
agd5f: stefanb: try that
agd5f: I’ll probably have to enable a workaround as well
onestone: agd5f: we definetly shouldn’t support to big modes. I’ve now removed also the monitor section and now get a 1792×1344 mode that is definitely not supported
agd5f: stefanb: although I can’t reproduce the problems here ufortunately.
agd5f: onestone: weird. I don’t know where the xserver is getting these modes
onestone: the modes don’t even appear in the Xorg.0.log
agd5f: onestone: are you running a vendor xserver or xserver from git?
onestone: git
onestone: git before MPX merge
agd5f: I wonder if ajax’s latest xrandr mode tweaking is to blame. I guess i need to update my xserver and test it out
stefanb: agd5f: OK, now got driver without your patch but compiled against libpciaccess with pci_device_enable()
stefanb: BRB
stefanb: agd5f: pci_device_enable() does not help
agd5f: weird
stefanb: OK, got to go now… my systems are shutting down 🙂
agd5f: stefanb: thanks for testing
adamk: agd5f, With that patch, X no longer crashes for me… But my load average is at 5, with Xorg using 103.2% of my CPUs 🙂
agd5f: adamk: does X start ok?
adamk: agd5f, I’m not in front of the machine 🙂 After killing the Xorg process, though, I looked in the Xorg log file and didn’t see anything odd.
adamk: Till I kill the Xorg, though, the system is essentially unusable 🙂
dudeman: hm
dudeman: so hey guys this driver is safe/stable yet?
dudeman: i hear you guys having lots of freeze/crash/lockup
adamk: bbl
adamk: dudeman, Depends largely on the card and what you use it for, I imagine 🙂
dudeman: x1900 for me and compiz confusion + games
agd5f: MrCooper: like to get you sign off on onestone’s patch: http://dev.compiz-fusion.org/~onestone/0002-R2-3-4-5xx-fixed-calculation-of-cliprects-in-CopyBu.patch
onox: is work on r300 still going on in the radeon driver?
rx__: yes
onox: when i am playing a video and move the cube in compiz, the video doesn’t move
onox: it’s like it gets rendered in a layer beneath my desktop environment
leio: you mean the overlay?
leio: to have that work good, you need to use textured video
leio: it’s the non-default xvideo ports
onox: is that something to be configured in xorg.conf?
leio: no, see xvinfo
leio: does it show textured video ports
onox: in “attributes” or “operations supported”?
leio: see http://www.phoronix.com/forums/showthread.php?t=7993
leio: especially posts by agd5f
leio: not sure if there’s a better place with a good summary and instructions.
onox: ok, i’ll check
agd5f: onox: yeah if your video app has an option to select which Xv port to use you’ll need to specify the textured video ports
onox: hmm, totem is probably not going to have tihs
onox: *this
onox: ah
onox: gstreamer-properties
onox: cool
onox: “X Window System (No Xv)” seems to do the trick
airlied: onox: you should be able to use Xv + textured video
agd5f: onox: what version of the driver are you using? 6.8.0 and before didn’t supported textured video
onox: using 6.8.0
onox: X Window System (No Xv) works, X Window System (X11/XShm/Xv) not
agd5f: onox: ok, then all you have is overlay
agd5f: onox: righ overlay doesn’t work with compositing managers
onox: ??
onox: I’m using compiz
agd5f: onox: Xv implemented as textures will work, but you need a newer version of the driver
agd5f: onox: compiz is a compositing manager
agd5f: onox: so either upgrade to latest git version of the driver, or use X11 if you want it to work with compiz
onox: why? both gstreamer plugins allow me to watch video’s and the non-Xv plugins also works great with compiz
leio: (X11 instead of Xv being usually considerably slower)
leio: what doesn’t work is overlay based Xv
leio: due to the nature of how it works in the GPU
onox: slow? I don’t notice any lag
leio: it works quick, it just doesn’t work the way you’d hope in a composited env
leio: Xv with overlays works quick I mean
leio: X11 usually takes multiple times more CPU to play. If you have powerful gear, then you might not notice other than in CPU resource graphs
leio: but for my 4 years old machine X11 with 720p video is too slow ;p
leio: overlay Xv works fine with CPU at 80%. TexturedVideo is a bit more resource demanding than overlays, at least on a r200 family ancient radeon card
leio: overlay* (there’s only one in most cards)
leio: on that note, time to stress that overlay a bit now.
leio: btw, I still have various glyph corruptions with git of everything 3 days old
onox: hmm, “No-Xv” eats 70% cpu for a 640 xvid video, “X11/XShm/Xv” about 20%
agd5f: onox: right. Xv does the rendering on the GPU so it frees up the CPU, but overlays don’t work with composite
agd5f: hence the textured video option. best of both worlds 🙂
onox: but I need trunk to get that? :p
leio: onox: now try that with a 1080p video ;p
onox: hmm, sorry, 640 video eat 45% :p
agd5f: onox: yeah you’ll need the ati driver from git
leio: onox: gentoo x11 overlay has an ebuild for that
leio: (how about a release soonish? 🙂
leio: (for some sweet 1.5 katamari love)
onox: rofl :p
onox: how is EXA doing on r300?
agd5f: onox: quite well
leio: text scrolling is a serious loss on r200
leio: should check how XAA fares in that regards these days
leio: basically if I compile something that spams a lot with keeping that terminal tab the active one, most of the CPU goes to that instead of compiling ;p
dmb: does fglrx use xaa or the other?
surfer: openarena runs well for me
surfer: but with compiz running there are crashes
spstarr: is using EXA now as default and i haven’t looked back at XAA
dmb: well, which one is the one that is the future?
dmb: or is it like an alliance/competitive thing
spstarr: XAA is old
GerbilSoft: hm – compiz isn’t working
GerbilSoft: it complains that GLX_EXT_texture_from_pixmap is missing
airlied: GerbilSoft: LIBGL_ALWAYS_INDIRECT=1 before running compiz
GerbilSoft: oh hey it works
GerbilSoft: thanks
|GerbilS|: bah x crashed
|GerbilS|: going to downgrade back to xserver 1.4, git xserver is a little too unstable
|GerbilS|: oh bah, forgot – latest mesa won’t compile properly with X. oh well, i’ll stay with git xserver. just won’t run compiz for a bit
|GerbilS|: *X 1.4
damentz_: hmm, should i get the git of mesa?
dmb: yes
eboettcher: agd5f: is the atombios stuff that remains for windows targets necessary anymore? 😛
eboettcher: I can’t think of a reason…
dmb: eboettcher, windows targets?
eboettcher: there’s some stuff for building on the M$ DDK
dmb: how can you run a X driver on windows though?
dmb: whats the point?
bridgman: dmb: the Windows stuff is there simply because the atombios code we released is used for
bridgman: multiple operating systems; it’s running on 5 or 6 different OSes today
bridgman: eboettcher; we’re trying to keep the atombios parser code relatively stock so that
dmb: ah, so its like a lib
bridgman: we can push new versions of the interpreter out without breaking anything
bridgman: top of the list is big-endian fixes; we found them, now we just have to push ’em
dmb: bridgman, how did you know what i was writing, logfile?
eboettcher: bridgman: ah, I see
bridgman: dmb: right; we put a cut-down version of the interpreter in the bios ROMs, and put the
bridgman: full version in the driver
dmb: oh
bridgman: yep, logfile. I don’t really have an alarm, just a nasty habit of showing up when
bridgman: there’s a question I actually know how to answer 😉
bridgman: usually agd5f beats me to it, but he must be slacking tonight
eboettcher: so I’ve spent the last few hours reading atombios stuffs
bridgman: it’s not pretty and it’s not well documented right now, but (a) we can fix the
bridgman: documentation and (b) it works pretty well so we haven’t really needed to fix it
bridgman: Worst thing a developer can do is have their code work first time; it gets shipped 😉
bridgman: eboettcher: we can get the current (not pretty) documentation out to you if that helps
eboettcher: that may
bridgman: ok; any particular areas where you have questions ? What we have right now is the
eboettcher: right now my only documentation is the code 😛
bridgman: design docs from about 5 years ago; we wrote it, it worked, we shipped it 😉
eboettcher: is the endianness of the bioses the same in all cards and only the host endianness different?
bridgman: (scratches head) yeah, I guess so — we use the same card in different systems with
bridgman: different CPUs so I think the endian-ness in the tables would always be the same
bridgman: I know we had to make some fixes to get the interpreter running on powerPC, finally
eboettcher: I’m guessing based on the fact that it works in my system, it’s all little-endian 😛
bridgman: found them…
eboettcher: what’s the point of regsdef.h?
bridgman: yeah, when Apple started using Intel CPUs the importance of big-endian support
bridgman: took a nosedive
bridgman: geez, that was a lot of disconnects; did an ISP just get nuked ?
eboettcher: like the stability of this network in the past year
eboettcher: netsplit
dmb: bridgman, nope, just a normal freenode netsplit
eboettcher: err crap
bridgman: what is a netsplit ?
eboettcher: considering the fact that I’m on simmons, how am I still talking to you guys?
eboettcher: bridgman: there isn’t a central IRC server
eboettcher: our clients connect to several different IRC servers that connect to eachother
eboettcher: netsplit is literally a split in the network
bridgman: ahh, OK. Works surprisingly well all things considered. Thanks
eboettcher: but I’m very disturbed by this split
bridgman: how come ?
eboettcher: because when I connected, I connected to simmons
dmb: it hasn’t rejoined
eboettcher: 22:54 -!- Netsplit simmons.freenode.net <-> irc.freenode.net quits: tilman, dudeman, bobbens, jkt|, kranga, Honk, grazzy
eboettcher: you are connected to irc.freenode.net
eboettcher: so it wasn’t a real netsplit or we wouldn’t be talking
dmb: hubslit maybe
dmb: split*
bridgman: I didn’t know what “connect to any server” would do so I hardcoded the only
bridgman: server name I knew 😉
bridgman: Probably in Elbonia or somewhere
eboettcher: well AFAIK irc.freenode.net is a roundrobin
dmb: eboettcher, also, for security purposes, they are probably hiding the actual server that split
bridgman: so I have no idea where I am. OK, I can live with that 😉
dmb: being irc.freenode.net
dmb: as a mask
eboettcher: that could be
dmb: poor bridgman and his dialup 🙁
bridgman: does it show ?
eboettcher: bridgman: watching the fosdem videos helped with certain things
dmb: bridgman, your hostname
eboettcher: a lot of the discussion I had seen in writing, but sometimes it’s nice to put a face to the name
surfer: dialup? do u live in montana or something
surfer: just had another crash with openarena
surfer: damn hard locks!
bridgman: worse – 40 miles outside Toronto, in the sticks, 18 miles from central office
dmblah: -dmwaters- {global notice} Good day all, one of our European hubs had a major routing problem but things look to be alright now, thank you for your patience, and thank you for using freenode!
bridgman: and surrounded by 60 foot trees so no satellite
dmblah: bridgman, no chance of broadband at all?
bridgman: This summer I’m going to be cutting down a heap of trees and putting a shed in;
airlied: bridgman: you need to at least get ISDN 🙂
eboettcher: bridgman: you may be closer to me than Alex…
dmblah: isn’t isdn dead?
bridgman: kills at least three birds with one stone – firewood, shed, and line of sight
airlied: dmblah: not if you can’t get ADSL
bridgman: to one of the satellites
bridgman: never thought of ISDN; anything is better than 21.4 Kbps
eboettcher: bridgman: I wouldn’t count on that satelite ‘net when percipitation falls
dmb: probably better then dialup though
eboettcher: and I don’t know about you in Ontario, but we sure do get a lot here in Michigan next to the great lakes
airlied: you should be able to get 128k on ISDN 🙂
bridgman: eboettcher; the trick seems to be getting a bigger dish than the installer says
bridgman: you need; kicks the s/n ratio up and cuts through the precip a bit better
eboettcher: bridgman: I think down here the FCC has some sort of law saying you can’t have a dish bigger than their director’s head.
bridgman: airlied: worth a try; that’s 6x what I have now. Heck, I could probably game online
bridgman: up here the rule is “don’t fry the satellite”
eboettcher: modern V.92 compression on dial-up lines allows for up to around 300KiB/s 🙂
bridgman: yeah, that’s what they tell me. Try getting that kind of compression on x86 binaries
airlied: has trouble with 1.5M ADSL, I really need to get back to ADSL2.
eboettcher: but that won’t help you get your frags in playing openarena
eboettcher: bridgman: that begs the question: Is it faster to send the source and compile it?
bridgman: interesting question; I have seen all kinds of non-intuitive things since I started
bridgman: this project; like 250K lines of sample code to help devs modify 1500 lines in a 20K line driver 😉
bridgman: I don’t really get much compression on the dial-up link, maybe 20-30% even when
dmb: eboettcher, since when does V.92 on dial-up lines allow that?
bridgman: downloading mostly text; usually I just VPN into work and run everything there
eboettcher: s/B/b/ 🙂
bridgman: even so 😉
eboettcher: bridgman: so, what’s the point of regsdef.h? 🙂
bridgman: We have different build environments for BIOS and driver; looks like there is a dependency
bridgman: on this file in the bios build environment and it needs an ifdef to remove the dependency
bridgman: when building in the driver; without the ifdef, there has to be a dummy file included
bridgman: to stop the driver builds from blowing chunks;
bridgman: seems like something we could fix
bridgman: … and even that answer doesn’t totally make sense because in theory we have a differet
bridgman: (cut down) interpreter for bios… so v2 answer is “idunno, will find out” 😉
bridgman: probably 50/50 chance the driver would build without it; that’s something we try in year 2 😉
eboettcher: year 2?
eboettcher: what is year 0?
bridgman: yeah, first year the focus is getting all the GPUs supported
bridgman: year 2 we clean up
bridgman: there was no year 0, except for lots and lots of meetings
bridgman: year 1 is now
bridgman: kinda July-ish to July-ish
eboettcher: err this is where I wish I had setup NAS
eboettcher: headphones are plugged into the laptop — desktop speakers are a pain in the ass to unplug
bridgman: so your life doesn’t end when your PC locks up ?
eboettcher: indeed it does not
eboettcher: 23:22:23 up 54 days, 4:11, 9 users, load average: 1.09, 1.05, 1.02
eboettcher: this is my laptop
bridgman: nice 😉
eboettcher: which has a load average of 1 while next to nothing is running? O.O
bridgman: That’s OK; when flying to Brussels for FOSDEM I discovered that my Vista laptop
bridgman: swapped constantly when nothing was running, battery life ~ 25 minutes
bridgman: I was planning to do final review of the 5xx acceleration document on the plane
bridgman: not a chance
eboettcher: I will say that I want a very simple mobile device
eboettcher: nothing but a small ROM, touchscreen, say a SSD, controllers for said stuff and a simple 1W cpu
bridgman: Yeah; 30 years ago I was reading about monochrome displays which could maintain an
eboettcher: all I want to do with it is read docs, code, take notes
bridgman: image without consuming power; only needed power on a redraw. They were the future…
eboettcher: what would it look like? Nothing but screen — the size of an A piece of paper
bridgman: … and 30 years later I’m still reading the same articles ;(
eboettcher: bridgman: how does that work?
bridgman: Yep, IMO tablets will take over the world when the technology is ready, but it’s not there
dmb: monochromes were awsom
eboettcher: I can’t think of many things that emit light and not use power.
eboettcher: perhaps reflect light
bridgman: IIRC it was a modified liquid crystal that had the ability to “freeze” the image
bridgman: then again if you look at OLPC the display is pretty awesome; as long as you have
eboettcher: bridgman: so we’re ignoring the backlight here
bridgman: decently bright light you can run with no power
bridgman: yes, definitely ignoring backlight. the thinking was that if you are going to read
eboettcher: reflecting ambient light?
bridgman: you should have a light on, just like with a book 😉
bridgman: Yep, reflecting ambient light. It’s been a long time since I played with diplays but
bridgman: my recollection is that you can either put a backlight or a reflector behind
eboettcher: so how does that work if the light must pass through the crystal twice?
eboettcher: the intensity would be cut to nothing!
bridgman: LCDs – the hard part is doing both, so if you have a backlight you lose ambient performance
bridgman: Going through twice is not a big deal if you adjust the contrast accordingly
bridgman: you just need the display to be REALLY transparent for “white” and half as opaque
bridgman: for “black”
dmb: hmm, i wonder if they still sell monochromes…
bridgman: Haven’t seen many monochromes recently; then again laptops are not really selling
bridgman: into the $100 market enough yet
eboettcher: bridgman: my focus would be the $100 tablet 😛
eboettcher: the screen would of course be the most expensive element
bridgman: Yep. Might just be because I’m the wrong generation, but I would take a really high
eboettcher: both in power and money
bridgman: res monochrome display over colour any day
dmb: http://images.google.com/imgres?imgurl=http://upload.wikimedia.org/wikipedia/en/thumb/1/1d/Amber_Screen_003.JPG/300px-Amber_Screen_003.JPG&imgrefurl=http://en.wikipedia.org/wiki/Monochrome_monitor&h=225&w=300&sz=13&hl=en&start=4&um=1&tbnid=_NtxqklVUhGXNM:&tbnh=87&tbnw=116&prev=/images%3Fq%3Dmonochrome%2Bmonitor%26um%3D1%26hl%3Den%26safe%3Doff%26client%3Dfirefox-a%26rls%3Dcom.ubuntu:en-US:unofficial%26sa%3DN
dmb: thats pretty cool
bridgman: then again nobody reads much these days
dmb: it almost looks like there is actual color
eboettcher: what does AMD offer these days in terms of low-power x86 embeded cpus?
eboettcher: dmb: bad request
airlied: eboettcher: OLPCs.. geodes
dmb: eboettcher, http://upload.wikimedia.org/wikipedia/en/1/1d/Amber_Screen_003.JPG
eboettcher: airlied: are any of those < 1W?
bridgman: Yep, Geode on one side and very low power athlons on the other; not really targetting
bridgman: the UMPC business yet
bridgman: We’re also targetting much lower power (microwatt kinda stuff) in the consumer BUs
bridgman: not sure what they’re using for CPU these days
eboettcher: well I think the best way to conserve power on say that tablet is not to use fancy C++ code compiled for an x86 cpu 😛
eboettcher: rather more power aware code
eboettcher: (perhaps someday we can say tell GCC to optimise for power :P)
dmb: eboettcher, you mean code it all from scratch in asm :D?
bridgman: Or at least C — the portable asm
eboettcher: indeed 🙂
bridgman: The OLPC does some real interesting things to save power; even an outboard
eboettcher: I just get sick of seing people when codeing for emebeded systems having encapsulation for their encapsualting classes that are abstracting the encapsualted interfaces.
eboettcher: -e(
eboettcher: *
bridgman: chip that grabs the video stream then lets the CPU shut down while this chip
bridgman: keeps the LCD refreshed
bridgman: eboettcher: I don’t think that problem is unique to embedded systems 😉
dmb: interesting
eboettcher: no, but it shows best there where the law of Java does not apply
eboettcher: “if it doesn’t run fast enough, get a faster CPU” 😛
bridgman: Yep; not everyone seems to grasp that productivity and efficiency are usually
bridgman: things you trade off against each other, not something you just “buy”
eboettcher: perhaps in the future object files may be bigger but can contain metadata about what’s really going on
eboettcher: so a dynamic linker may become a dynamic optimizing linker
bridgman: Would you want that for embedded; or would you just do the optimizing before
bridgman: burning the ROMs / images ?
eboettcher: oh no, not for embeded
eboettcher: we don’t want batteries dying before the thing boots 😛
bridgman: ? Isn’t that why you would want to only run pre-optimized code on the embedded device ?
bridgman: Or are you talking about the metadata as something that is used before you make
bridgman: the final image/rom for the embedded device; if so I agree
eboettcher: I mean in very general terms, but that does make me think of something else.
eboettcher: Compliers show us time after time that they can improve code within a module.
eboettcher: But what work do they do between modules?
bridgman: I’m a bit out of date on compiler technology but I think there is some ability
eboettcher: the developer’s decisions on how to split up the program may impede decisions the compiler would make if more modules were in the same sourcefile
bridgman: to optimize across modules today; the problem is that it’s just too hard for the
bridgman: compiler to understand what the heck the dev(s) were trying to accomplish
bridgman: in the first place 😉
eboettcher: bridgman: with some of the stuff we’re doing with relational databases these days, I’m sure we could improve compilers in that regard 😛
bridgman: BTW it looks like Geodes go down to 0.9W; I think that is “most of a system” but
bridgman: as you all know I’m on dialup so the page is still loading 😉
eboettcher: bridgman: does Geode have an MMU?
bridgman: eboettcher: no question, but then again RDBMS is a bit like graphics programming
bridgman: same small amount of work performed on an insanely large number of independent records
bridgman: so potentially different from a big monolithic application written over
bridgman: 20 years, 5 developers and 3 countries 😉
eboettcher: reading geode product breif page
eboettcher: .09W on a 150nm?
bridgman: http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Geode_LX_industi_temp_product_brief_FINAL_5.25.pdf
bridgman: Yep. Looks like everything except the southbridge; I assume that’s what the “companion
bridgman: part” is…
bridgman: xorg/drivers/xf86-video-amd 😉
eboettcher: O.O
eboettcher: I could probably play back xvid with that thing in a tablet!
bridgman: No 3D, but I think we could fix that pretty easily 😉
eboettcher: is that security block just a random number generator, or is there hardware AES support?
bridgman: Looks like HW AES but not sure; I can find out pretty easily (but would prefer
bridgman: not to do it through dial-up)
eboettcher: just curious here 🙂
eboettcher: when I go off to WMU I need to make a senior project of some sort
eboettcher: that’s two years down the line
bridgman: Pretty sure it would have AES HW because chips like this tend to get used
bridgman: on the far end of an insecure connection
bridgman: I’m sure we could add 3D in 2 years 😉
eboettcher: I bet tablets would catch on if a decent one didn’t cost as much as a desktop.
bridgman: Here’s a couple of links for “interesting” display technologies; first is a “sticky”
bridgman: monochrome display with a solar panel behind the display to power the device
bridgman: http://www.kentdisplays.com/tech/papers/2003/00-03%20SID%20Digest-Ultra%20low%20Power%20B%20&%20W%20Cholesteric%20Dsiplay%20with%20COG%20and%20Solar%20Array.pdf
bridgman: Yep; problem is that everyone is afraid to buy something that doesn’t have
bridgman: all the features of a laptop, so cost >> desktop
bridgman: e-books are supposed to be the answer but only old people read 😉
bridgman: Also here, look at the zero-power section :
bridgman: http://en.wikipedia.org/wiki/Liquid_crystal_display
bridgman: Better run; still work to do before sleep and it’s getting late
bridgman: g’night

Radeon IRC Logs For 2008-5-28

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-11-24

RadeonHD.org | Radeon IRC Logs For 2008-12-09

RadeonHD.org | Radeon IRC Logs For 2008-3-15