spstarr_desk: i wonder if i have libdrm debuginfo
airlied: doesn't help really. its just stuck in a swap ioctl
spstarr_desk: do we know that cause?
airlied: have alook at echo t > /proc/sysrq-trigger
airlied: gpu lockup
spstarr_desk: so garden variety
spstarr_desk: X shows.. no drm/radeon symbols
spstarr_desk: in t
airlied: spstarr: pastebin the X bits from sysrq-trigger
spstarr_desk: i killed X
spstarr_desk: apparently, if that was a wedge i would not be able to kill X?
airlied: did it restart?
spstarr: the corrupted VTs dont have a colour test pattern interestingly (no loony tunes rings)
spstarr: after I killed X with -9
spstarr: it was pegged in CPU
airlied: I should had you look at the /proc/dri/0/radeon*
spstarr: oh i can reproduce that one omment rebooting
spstarr: on VT Switch.. will crash...
spstarr_desk: getting proc
spstarr_desk: X is pegged
spstarr_desk: Interrupt enable: 02000200
spstarr_desk: Interrupts received: 2199
spstarr_desk: Current sequence: 205 205
spstarr_desk: Counter sequence: 205
spstarr_desk: CS: 0
spstarr_desk: RADEON_CP_RB_WPTR 00012b10
spstarr_desk: RADEON_CP_RB_RPTR 00012b10
airlied: wierd, must be something going wrong on vt switch.
spstarr_desk: er.. Write pointer and read pointers the same?
airlied: this is without kms?
airlied: ah maybe I'm not disabling some irq when I need to
spstarr_desk: with composite mode on note
airlied: could be the vbl irqs.
spstarr_desk: w/o it never locks
spstarr_desk: vbl == vblank?
spstarr_desk: wikipedia has better info
spstarr_desk: if you have ideas i'll look in /scroll during morning at work
spstarr_desk: syncs rawhide on this box and goes to sleep
spstarr_desk: hmm kernel -92
spstarr_desk: comments are always good :)
orkid: dri2? :)
csimpson: Gentlemen. :3
csimpson: A few things.
csimpson: First, I'm MostAwesomeDude. In case you didn't know. :3
csimpson: Second, pretty_print was driving me crazy, so I came up with http://pastebin.ca/1250164. I'm pretty sure it's bugging out on vertex and FP uploads, but whatever.
csimpson: Third. AFAIK there's no special upload system fglrx uses for HW TCL fogcoords. It's all VAP dark magic. If there's anybody out there with an RS690 that wants to make a revenge dump, it'd be appreciated.
orkid: my internetz still be down. so much for cheep access to t00bz
csimpson: Oh, right. That python code up above would like r300_reg.h or similar. Try "gen_parser.py r300_reg.h > parser.py".
csimpson: Fourth, fglrx uses a kernel call of some sort to do occlusion queries. Nothing in userspace AFAICT.
csimpson: Fifth, my laptop's given up the ghost. Pretty much for good. I've gotten an Eee for class, but I'm stuck with my workstation for radeon stuff. Still trying to migrate everything.
csimpson: Sixth, I'm out of items on this list. I think.
airlied: needs to put fglrx + revenge on live usb disk :)
csimpson: airlied: Two things. How do I see what's in the vertex data in revenge, and how could I dump what *we* do in order to find difference bugs?
airlied: csimpson: the vertex data should be just inline in the IB packets.
csimpson: airlied: Ah. It's just that, well, the fog coordinates aren't with the rest of the data. :3
airlied: or it may be in a separate vertex buffer.
airlied: I'm not sure.
csimpson: There's somethin' funky goin' on.
airlied: it depends on the packet3 used.
csimpson: I haven't slept this weekend. I forgot packet3 parsing.
zhasha_: phoronix just bore news of a dri2 enabled radeon driver
orkid: yes :)
TobiasIsACommie: ok, after reading phoronix today
TobiasIsACommie: what IS the legal trouble with the r600+ specs?
TobiasIsACommie: i just realized i didn't know why it had taken this long
glisse: TobiasIsACommie: just legal trouble
TobiasIsACommie: yeah, but with whoom, i mean, did amd have this trouble with the r500 series?
glisse: it's big compagny and this hw have drm (digital right management) stuff in it, i guess they are bound with others big corporation with that
glisse: i don't think r5xx really support drm
TobiasIsACommie: but doesn't r500 have that as well?
glisse: well i don't think there is any product with hdmi for bluray enabled
glisse: but i might be wrong
TobiasIsACommie: in the r500 series
TobiasIsACommie: hm, ok, i guess that explains it then :) i thought the hardware and drm issues would be about the same.. shows what i know
agd5f: TobiasIsACommie: the's not really legal holding things up, it's that we need sign off from lots of various hw/sw architects. it's more of a back and forth: " will releasing X compromise Y?" "no and here's why" or "yes, but here's an alternative" etc. legal will pretty much sign off on stuff as long as all the appropriate people sign off on it
agd5f: Also, we plan several generations of GPUs ahead based on a new design. the basic r3xx designed carried from r3xx -> r5xx
marcheu: so why don't the people just sign and move on then :)
agd5f: marcheu: easier said than done :)
marcheu: you should give threatening a try
marcheu: really we are at the point where OSS drivers lose credibility now...
marcheu: bah, I am now a sad panda
adamk: I wouldn't say that it's OSS drivers that are losing credibility, but AMD.
adamk: How many people per day come on here (and #radeonhd) asking about support for their r600/r700 GPUs only to find out that AMD hasn't released the necessary information yet?
marcheu: then they move on to fglrx...
marcheu: and then OSS driver loses, and AMD sees no change
adamk: Maybe no change to their bottom line, but they do to their reputation, and that will, eventually, impact the bottom line.
libv: adamk: yeah, sadly AMD is not looking well anymore... AMD wants proper free software drivers while ATI at the same time is very actively pushing fglrx
marcheu: adamk: no, the message is "OSS drivers suck, move on with the closed source program". what can we do ?
adamk: Yeah, frankly if I had to upgrade, and my choice was between an r700 GPU with closed source drivers or an nvidia card with closed source drivers... I'd probably go with nvidia right now, even knowing that OSS support for r700 is on its way. It's been on its way for too long for many people to take it seriously.
adamk: marcheu, I disagree. The message is more "AMD sucks. They promised to release specs and we're still waiting... " :-)
marcheu: adamk: actually, you just said you'd get nvidia and use binary drivers. what other proof do I need ?
adamk: marcheu, But I would't blame OSS for my decision. I'd blame AMD. Remember my comment was that AMD is losing credibility...
marcheu: to me the result is the same, "OSS drivers loses"
TobiasIsACommie: agd5f: thanks for the information :)
adamk: Oh, there's no doubt that OSS is hurting because of this, but no more than they were before AMD said they'd release the specs, IMHO :-)
TobiasIsACommie: right now i'm just waiting for amd to release the specs for r600-700, then i'll upgrade to, whatever beast is first supported in the oss driver
libv: adamk: amd is a big company, shrinking, but still a big company with many departments
adamk: libv, I do not doubt that. And I certainly understand the reason for the delay. But it still impacts their reputation :-)
libv: adamk: sadly, yes
libv: adamk: i read 90% share loss here on irc, maybe another channel, since buying ATI
libv: shareprice even
libv: adamk: so it's not only the open source world
adamk: Very true.
spstarr_work: csimpson: no longer MAD? :)
spstarr_work: dri2 ? :)
csimpson: spstarr_work: Not from this stupid web portal, no. :3
csimpson: agd5f: Is there some diagram somewhere of the various bits of the Radeon pipeline?
z3ro: csimpson: I asked about that a while ago. iirc there is only internal ones, which couldn't be released because they give too much detail on the hardware design.
z3ro: eg it's something for the ASIC engineers, not the programmers.
z3ro: though I'm sure a simplified one could be made.
rx__: someone trying to making a competing product? ;)
spstarr_work: csimpson: hehehe
spstarr_work: looks at the dri2 article
z3ro: csimpson: actually thinking about it, there are sometimes simple diagrams in the reviews for cards (eg when they talk about architecture)
z3ro: but I'm not sure how useful they would be.
agd5f: csimpson: yeah. that was the problem. I could probably make a cleaned up one at some point
spstarr_work: glisse: can i test your stuff?
spstarr_work: yes :)
glisse: as you wwish but it will be damm slow one frame per minute everythings X included
spstarr_work: glisse: will airlied's modesetting bits in be equivalent to what modesetting-gem has?
spstarr_work: glisse: i wanna see if I can trigger race condition slow or not
glisse: now you need bits in modesetting-gem which are not in drmrawhide
z3ro: I'm going to go see if some food place is open at 5am...
spstarr_work: ok so just replace the drm the kernel provides with those drm bits
glisse: spstarr_work: i mean you won't be able to do anythings
glisse: read one minute btw a click and the first things getting draw
spstarr_work: that fresh
spstarr_work: those Phoronix kids
csimpson: agd5f, z3ro: I just feel like I'm not properly visualizing the card parts, or I'm not understanding ATI's terminology.
csimpson: W is the depth value, used to determine how deep the fragment is drawn, whether it occludes other stuff, and that's the SC's fog value. So what's Z?
glisse: csimpson: w=1/z
glisse: it's about homogeneous coordinates
fat_chris: i'm having some trouble compiling latest libdrm from git (modesetting-gem branch)
fat_chris: anyone got any ideas how to fix? maybe something else needs updating too?
glisse: fat_chris: it's broken
glisse: due to me
glisse: i need to push fix
fat_chris: glisse, oh ok, i thought i might have broken something my end, thanks
csimpson: glisse: So Z is the depth value used for fog? Or is it W? Which corresponds to the actual fog coordinate?
agd5f: csimpson: W is for perspective divide. like glisse said, normalized coordinates
glisse: csimpson: well you could use w for fog, the hw can do 1/w which is z :)
glisse: this why you bit to either route z or w
glisse: ie ask to sc or fp unit to do w=1/z
csimpson: glisse: Yeah, I guess I need to take another look at those registers.
csimpson: Out of curiosity, have I just been spinning idly, or is this problem really as hard as I seem to think it is?
glisse: csimpson: which problem ? :)
csimpson: glisse: Fog coords. :3
rmh3093: airlied, i havent noticed a 3 sec hang yet
agd5f: csimpson: you can use anything for fog coordinates. they are usually calculated based on Z and the "scene" itself
agd5f: csimpson: this stuff may be useful: http://developer.amd.com/gpu/radeon/RadeonSampleCode/UsingFogCoordinatesonRadeon/Pages/default.aspx
glisse: csimpson: fogcoord ext iirc is about using somethings else than z as fogcoord :)
glisse: so it's about routing this additional value through the place which will use it
csimpson: ...FRAG_BIT_FOGC is 1/FRAG_BIT_WPOS with swizzle?
csimpson: If that's the case, I'm gonna facepalm.
fat_chris: rmh3093, just wondering if you've updated the drm in zen?
rmh3093: fat_chris, just the ati code
rmh3093: i will get to intel soon
fat_chris: i have ati anyway
zhasha: Did any of you have a hand in the DRI2 radeon driver?
spstarr_work: poor csimpson, fog fog fog
zhasha: It's hard living up to the nick MostAwesomeDude :P
spstarr_work: zhasha: glisse would ;)
zhasha: glisse would what?
zhasha: Did you see the announcement? Windows 7 will have no builtin SLI/CrossFire support (as in they wont officially support that type of hardware setup) because it's "too unstable and results in a poor experience"
fat_chris: zhasha, i thought microsoft are just recommending system builders to not use it, not necessarily to not support it
zhasha: fat_chris, I don't think they support it now. I think it's just a hacked together interface from the driver developers. By support I mean devise an interface that makes it easy to implement multi-gpu solutions
xnguard: SLI and whatnot happen entirely in the drivers anyway, so far as I know. I can't think of a reason the OS would need to "support" it.
xnguard: I'm more amused that Microsoft are advising system builders not to build in multi-vendor-GPU support, and saying they won't support it. As in switching between an Intel GMCH and an NVIDA 9600 in a laptop.
glisse: well apple will support multi-gpu
xnguard: And us, too, maybe? :)
xnguard: Although I'd point out that Apple's multi-vendor-GPU support is thus far limited to selecting the one you want and rebooting the system, so far as I know.
xnguard: To be honest, I'm not completely clear on why you need multiple GPUs, anyway, unless your big-fat-3D-card-vendor's power saving really isn't all that.
zhasha: xnguard, it isn't all that ;)
xnguard: I'm going to guess that AMD and NVIDIA need to take a few pointers from Intel or PA Semi (Apple) on how to really design your number-cruncher for power savings.
zhasha: ATi and NVidia need to fully embrace free software and just release their specs and driver sources so we can make it better
zhasha: I fail to see what they have to lose
xnguard: zhasha: Face. :)
xnguard: "OMG! Why would anyone do *that* to a poor, defenseless register bank!?"
csimpson: Hmm. Adventure time. Will investigate W/Z fun later.
spstarr_work: zhasha: nvidia need do nothing, Nouveau will steamroll over them anyway
spstarr_work: zhasha: I don't think anyone in NVidia is happy seeing Nouveau succeed :)
tlp: why do you say that?
spstarr_work: because they have been non-supportive at all
zhasha: why do you think nv will succeed?
spstarr_work: because nouveau is already succeeding
spstarr_work: is in Nouveau for this 7300 GS
zhasha: AFAIK they're still stuck in 2D land
spstarr_work: EXA 2D though no mesa stuff
zhasha: To my knowledge, radeon(hd) is doing a LOT better than nv
zhasha: and to be honest, I'm not thoroughly impressed by radeon(hd)
tlp: Perhaps they haven't been supportive, but I don't know if they actively dislike the project
zhasha: While it would be tits if nouveau killed NVidias own driver once and for all, I have doubts it'll happen
spstarr_work: don't doubt it
zhasha: do you have some juicy inside information?
tlp: dunno, I don't care to speculate on these things. It's all up to the developers.
airlied: michaellarabel: we mostly are concentrating on adding feature not performance to the driver at this point.
airlied: In fact I suspect perf may go backwards a bit more with a memory manager until we do a lot more optimisation.
rmh3093: airlied, ping
airlied: rmh3093: pong
rmh3093: idk if you saw my message, but i havent experienced any 3-sec hangs yet
rmh3093: all day
rmh3093: and i used to get it all the time
rmh3093: so i think you fixed it
airlied: rmh3093: cool... thanks for testing, now just need to figure out what is wrong with the other people :)
spstarr_work: airlied: any new stuff, going home will check spstarr_desk
MostAwesomeDude: Okay, so the secret method is to use the GEN_W stuff in RS to make W, then use 1/W for fragment.fogcoord. Am I rightish? Does that sound remotely sane?
spstarr_desk: nope :) back to laptop
spstarr: airlied: I get corrupt pixmaps still on minimize/maximize of xchat, with composite on or off
airlied: spstarr: kms?
spstarr: should I try kms today with your ring fixes?
airlied: can't hurt :)
spstarr: with composite off, maximize/minimize is different
spstarr: the text areas are blank (you see the root window wallpaper)
spstarr: while it redraws it
spstarr: with composite on you get corrupt pixmap area instead
rmh3093: airlied, ping
airlied: rmh3093: pong
rmh3093: so now that you fixed my big prob i feel like its time to mention another issue
rmh3093: probably already aware of
rmh3093: but text randomly disappears
spstarr: heh, aways another :-)
rmh3093: then reappears
rmh3093: mosly in firefox
spstarr: airlied: any stuff on vbl interrupts?
rmh3093: but also in gnome-terminal w/compositing
airlied: rmh3093: yup thats the one thats pissing me off :)
terracon: wow look at those performance gains!
airlied: I thought I'd fixed it but I just went from corrupt text to blank areas :)
spstarr: terracon: this is expected though with the changes going on
spstarr: grabs new kernel and tests kms
spstarr: looks for new DDX
orkid: ati devs are really chuggin along!
orkid: just looked at the article... and now notes sarcasm :P
spstarr: airlied: im in KDE with kms, no composite
spstarr: a interesting effect is happening
spstarr: lemme capture for you
spstarr: airlied: the root background goes corrupt with 'snow'
spstarr: but not always, this happens randomly when i minimize/maximise apps
spstarr: trying to capture it
spstarr: and now it wont do it at all
spstarr: turns on composite...
spstarr: VT switches
spstarr_desk: airlied: my laptop just rebooted on its own
spstarr_desk: thats not good.. i need serial console
spstarr_desk: we're rebooting on panics now(?)
airlied: spstarr_desk: stop cross posting shit
airlied: no we don't reboot on panic
spstarr_desk: im asking in there incase any kernel people are awake or know
spstarr_desk: ok so then what would trigger a reboot like that instantly?
spstarr_desk: im not touching any sysctl keys
airlied: I'm a kernel person, and I'd know.
airlied: spstarr_desk: the GPU caused it
airlied: someone reported it yesterady
spstarr_desk: oh, not just me
spstarr_desk: will serial console help find out why?
spstarr_desk: ok then why would the GPU cause the system to soft reset in kms and not non-kms?
airlied: because I do something bad in kms driver
spstarr_desk: oh :)
spstarr_desk: I didn't know the GPU could cause a reboot of a machine directly, other than just wedging the machine
luke-jr: try pulling the card out of a running system
spstarr_desk: unless a watchdog was enabled which might cause the machine to reset
spstarr_desk: luke-jr: thats not a good idea to do.. with power going though it
luke-jr: pretty sure it'll trigger a reboot for you