MostAwesomeDude: airlied: Okay, I'm tired of waiting. I'm getting bored. What's the easiest way to downgrade Fedora 9 to Fedora 8?
airlied: MostAwesomeDude: tired of waiting for what?
MostAwesomeDude: airlied: fglrx for Fedora 9.
airlied: wonders if I said I'd fix something and forgot :)
airlied: ah fglrx, you can probably try and downgrade kernel and/or X packages.
MostAwesomeDude: airlied: No, not your fault at all. I just REALLY want to get the FSAA/FSAF stuff working.
airlied: http://www.fedoraforum.org/forum/showthread.php?t=189227
airlied: MostAwesomeDude: maybe try that.
MostAwesomeDude: I'm going to need to go all the way to F8, I think... Lemme check out that forum post.
airlied: FSAA will need a memory manager.
airlied: so not much you can do there.
airlied: you need to allocate a large back buffer..
MostAwesomeDude: airlied: Supposedly, FSAA, FSAF, and per-poly AA are all HW accelerated, we just aren't doing it right.
airlied: if its just normal point/line/poly-aa then you should be okay.
airlied: MostAwesomeDude: FSAA is vastly different to per-polyAA
MostAwesomeDude: Hm, FSAA would be done by back-buffering the entire screen, then applying the AA, then sending to screen?
airlied: and we need a memory manager to do it nicely.
MostAwesomeDude: I see.
airlied: MostAwesomeDude: you need to have a backbuffer thats like 4x the size
MostAwesomeDude: airlied: Okay. Well, what about AF?
airlied: MostAwesomeDude: not sure, since its full screen it may be similiar but I'm not sure about it.
MostAwesomeDude: Since most modern cards are supposed to be able to do that on HW...
airlied: I just know I looked at FSAA enough to know we needed better mm.
MostAwesomeDude: We ALWAYS need better MM. :3
hifi: has anyone built libdrm 2.3.1 debian packages?
airlied: hifi: there isn't a libdrm 2.3.1 release yet
hifi: ~git snapshot
MostAwesomeDude: airlied: Well, got fglrx installed, but it doesn't like Composite, AIGLX, or KDE4.
MostAwesomeDude: I feel like I've been warped into the past.
Zajec: pff, what did you expect from fglrx... use radeon! ;)
Zajec: seriosuly: do you try to RE sth?
MostAwesomeDude: Zajec: Yep, I'm trying to figure out how to do per-poly AA. :#
MostAwesomeDude: WB.
MostAwesomeDude: Yeah, those instructions hosed my GUI for good, and I can't get wireless working from the command line. I'm just going straight to F8.
MostAwesomeDude: Not going to waste time on a dev box.
glisse: airlied: well thinking it over maybe we can forget about tearing in non composited mode
glisse: ie we just blit and don't care about vblank
glisse: while for composited case we use pageflip
airlied: glisse: I've no major problems doing that...
airlied: full-screen apps can pageflip..
glisse: That sounds like the easiet way :)
airlied: I think we can do vbl swaps just not guarantee they are on the irq if needs be
glisse: and anyway composited use should become default
ghepeu: hello, there's (probably) a typo in the recent -ati commit "RADEON: update RADEONGetVRAMType() for newer chips"
ghepeu: patch: http://pastebin.com/m1ab1de44
airlied: ghepeu: I think its fixed already.
airlied: oops it snot .. I'm blind
airlied: ghepeu: fixed thanks.
ghepeu: you're welcome ;)
algol: sorry to ask again the same question, but if I set RenderAccel off, does it make any difference which AccelMethod I select?
airlied: algol: yes.. XAA and EXA work different even without renderaccel
onestone: airlied: ping
onestone: I've found the reg that is cousing the performance drop after suspend. It's RADEON_GEN_INT_CNTL. It's set to 0x02000000 before suspend and to 0x0 after. If i set it back to 0x020000000, then everything goes to normal speed again.
glisse: onestone: then you can come up with a patch to fix this in resume function of drm :)
glisse: sounds like a pretty easy patch
onestone: glisse: I will look at it
glisse: onestone: hey we are always trying to get people writing code, this ain't that hard :)
glisse: you have done the hardest part found the trouble
osiris_: alpha = 0 means full opacity or full transparency?
glisse: osiris_: well it's a convention so it depends
glisse: generaly 0 mean transparent
ilm: thought 1 did
onestone: it was simple, but boring, because avivotool hardlocks quite often. Create 10 dumps before suspend and 10 dumps after and write a tool that finds the differences in both groups of dumps.
glisse: onestone: radeondump is a tool which does this kind of stuff already
glisse: onestone: i guess we lack advertising on tools we have
onestone: glisse: I can't find the suspend/resume code in drm. Any hint?
glisse: onestone: in radeon_cp.c
glisse: there is a resume function in it
onestone: glisse: it seams to be more complicated. The reg is part of the irq/vblank system the bit is RADEON_SW_INT_ENABLE. Someone that know the code should fix it at the right place
MrCooper: onestone: ah, so it's no longer generating software interrupts, so the waits for those time out
MrCooper: onestone: try calling radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1); from the resume function
osiris_: which r300 tex inst is the arb fp TEX inst? LD or TXP?
onestone: MrCooper: http://dev.compiz-fusion.org/~onestone/0001-Restore-software-interrupt-on-resume.patch fixes my suspend problem
MrCooper: onestone: looks good
onestone: g2g. thx for the help
osiris_: glisse: what is the src addr for in tex instruction? isn't texture id enough?
glisse: osiris_: texture is enough but i am not sure i understand what you mean by src addr
osiris_: r300_us_tex_inst takes src_addr, dst_addr, tex_id and tex_inst
osiris_: or should I just ignore src_addr for TEX inst?
glisse: osiris_: src addr is the addr of the coordinate
glisse: dst addr is the addr of where to put the result
glisse: and tex id is is the texture id
osiris_: glisse: hmm, I don't get it. TEX instr puts tex color vector to coordinate vector, so what is this src_addr for?
glisse: osiris_: for stiplle here is what you want R300_US_TEX_INST_0, (R300_TEX_SRC_ADDR(0) | R300_TEX_DST_ADDR(0) | R300_TEX_ID(0) | R300_TEX_INST(R300_TEX_INST_TEXKIL)
glisse: osiris_: dst_addr = texture[tex_id][src_addr]
glisse: osiris_: did you get the first step working ?
glisse: ie upload a constant program shader
osiris_: glisse: yeap, I manage to do MOV result.color, [1, 0, 0, 0] using r300 mad inst
glisse: osiris_: then second step is to bind the stipple texture
glisse: the frag prog is then :
glisse: osiris_: for stiplle here is what you want R300_US_TEX_INST_0, (R300_TEX_SRC_ADDR(0) | R300_TEX_DST_ADDR(0) | R300_TEX_ID(0) | R300_TEX_INST(R300_TEX_INST_TEXKIL)
glisse: new node
glisse: MOV result.color, input.color
glisse: z3ro_: there is a radeon-lockup-free branch in my drm repo would nice if you could give it a try on some usecase that lockup
glisse: i got a fairly stable card here so i don't know if my patch help or not
osiris_: glisse: ok, will try. I just don't understand few things in r300 frag shaders. what are these nodes for? are src_addr and dst_addr numbers of temporary regs?
glisse: yup dst_addr and src_addr are the temporary reg number
glisse: osiris_: new node is for texture indirection see opengl arb_fragment_program extension
glisse: btw anybody having lockup with r300/r400/r500 might want to give my branch a try
orki: airlied: If you are around, thanks for your F9 with R500 imporvement post. It works very well with X1650Pro (RV535).
glisse: airlied, z3ro_: i tested my lockup-free branch and theory is good but there is one more step to actualy make it usefull, in ga_reset we should reset the cp and clear the ring ie we should reset cp, stop, it, and start from new empty ring
glisse: i have been able to resume lockup but sometimes it resume cp in middle of cmd stream so cp hang again and i can enter in a loop btw cp redoing the same half broken stream
glisse: so i think we should reset cp and drop actual ring, this means some frame loose but keeping us in business sounds lot more interesting than avoiding frame loose
glisse: otherwise it seems that this way we should be able to recover lockup even with WAIT_UNTIL :)
glisse: that's a pretty big step forward stability
osiris_: glisse: to send instructions to new node one just need to set appropriate offsets in R300_US_CODE_ADDR_n?
glisse: osiris_: you write all instruction one after the other
glisse: then in its a matter of properly setting US_CODE_ADDR, US_CODE_OFFSET, US_CONFIG
osiris_: glisse: there should be at least one tex op in every except first node. so which tex op should I put if I don't need tex in the node? nop inst?
glisse: osiris_: no i think there could be no tex op in a node
glisse: let me check
osiris_: glisse: line 1595 in r300_reg.h
otaylor: osiris_: If you don't have any tex ops, you don't need the node, right?
osiris_: otaylor: glisse said that MOV result.color, input.color (see ^^^) should be in new node, but maybe I just misunderstood him.
otaylor: osiris_: glisse certainly knows this stuff better than I do, I'm working from memory of reading the docs. And I'm not completely sure that by "node" you guys mean what I am thinking of
^^MAg^^: system rashes after couple of minutes playing openarena, how to debug this?
otaylor: osiris_: My memory is that the r300 fragmnet shaders are divided into four parts (what I thinki of as node) by texture indirections
otaylor: osiris_: If you have no indirections ... texture lookups depending on the results of other texture lookups, you only need one of them
otaylor: osiris_: Hmm, actually maye that's *any* instructions depending on the result of texture lookups
otaylor: osiris_: So that would correspond with what glisse said. Wild guess: maybe you are thinking of them numbered backwards from how the docs you are reading number them?
osiris_: otaylor: nope, I'm not, but I think I know why glisse said that. glisse: writing R300_TEX_INST_TEXKIL, you meant TEX and then KIL?
glisse: otaylor: sorry i got heavy connection problem
glisse: otaylor: you could need to emit new node even when there is no texture in them
otaylor: glisse: No problem, I'm just guessing wildly in your absence to see if I can confuse osiris_ ;-)
glisse: in the stipple case you need to put the mov result in another node so that if texture lookup kill frag you don't have written anyresult
glisse: osiris_: for texkil this is a texture instruction
glisse: r300 hw implement the kill function in texture lookup
glisse: so as this is a texture instruction you put it in first node and if fragment is not killed then second node is executed
glisse: and color is written
mileeee: hi
mileeee: module ABI major version (4) doesn't match the server's version (2)
mileeee: followed this guide http://www.phoronix.com/forums/showthread.php?t=9951
mileeee: wrong version of xorg?
mileeee: and I compiled latest radeon drivers from git and some patches for powerplay from here http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=agd-powerplay
z3ro_: glisse: hmm that sound interesting... is the branch online?
glisse: z3ro_: yup but it's not functionnal
glisse: i am working on finishing few details
z3ro_: ok. I'm just looking at the code now.
z3ro_: but then I just woke up, so. :P
glisse: z3ro_: well theory work
glisse: but for someunknown reason the fifo get stuck
glisse: well not unknown
glisse: the retry fifo get triggered and fill the fifo which brings down the machine
glisse: but still i am able to reset the GA part of the engine :)
z3ro_: :)
glisse: oh i might know why they resetting 16times
z3ro_: so the fifo gets reset even in retry mode?
glisse: yup likely to exhaust the retry fifo
glisse: i am waiting for fsck to end to test if this is the case
z3ro_: ok
glisse: gladly i found an app which trigger lockup :)
airlied: glisse: you'll fix the lockup then :)
glisse: airlied: well i am frustrated i am able to recover the ga but now somethings is filling the fifo in my back, it's just like the card want me to suffer ;)
airlied: glisse: I blame engine reset code :)
glisse: damm i am so near it
glisse: i recovered 64lockup in a row
glisse: then fifo fill
glisse: stupid fifo
glisse: i can even see new frame draw btw lockup recover :)
z3ro_: glisse: iirc there is a rbbm_reset bit for fifo? maybe that would help?
rx__: you recovered from 64 lockups? ......
glisse: z3ro_: trust me i am trying many bits :)
z3ro_: ok. let me know if you get something that works. :)
z3ro_: btw, when the lockup recover code gets called, we should dump the cmd buffers if possible.
z3ro_: for debugging.
z3ro_: I guess you thought of that already though. :)
glisse: well i am not interested in debugging cmd stream as likely many lockup are due to bandwidth badluck
glisse: but that could be helpfull
glisse: rx__: yup 64 lockup in row recovered and application was drawing again btw lockup
glisse: airlied: airlied, z3ro_: pushed my working version
glisse: oups too much completion :)
glisse: well it does work several time
glisse: you will see flicker when a lockup happen
glisse: it seems that there is a path i don't catch as there is still one lockup i don't recover from but i don't get anyoutput when this happen
z3ro_: ok. I'll try it out soon
glisse: z3ro_: well keep me posted if it works for you too
glisse: if it doesn't work ie fail to recover some lockup i am interested in rbbm_status which should appear in your syslog
z3ro_: glisse: ok, I'll try it with my engine, but it doesn't lockup as much on r5xx pci-e as it did on r3xx agp, so hopefully I can still trigger a lokcup.
z3ro_: *lockup
glisse: z3ro_: please try on r3xx or r4xx
glisse: its not tested on r5xx
glisse: even though it should work
z3ro_: ok. I'll have to swap the card out later then.
glisse: well you can test r5xx
glisse: but if it doesn't work at all i wouldn't be surprise :)
z3ro_: ok
MostAwesomeDude: z3ro_: Revenge can't map the FB on Ubuntu.
z3ro_: MostAwesomeDude: run it with --debug and tell me what that says.
MostAwesomeDude: detect_reg_aperture: reg_addr = 0xfeff0000 reg_len = 0x00010000
airlied: they might have some /dev/mem "security" patches.
MostAwesomeDude: detect_fb_aperture: fb_addr = 0xc1005000 fb_len = 0xff4fb000
z3ro_: MostAwesomeDude: so thats all it gets to?
z3ro_: ah that doesn't look right.
MostAwesomeDude: And then revenge_main.c:180: Cannot allocate memory
MostAwesomeDude: Well, Ubuntu's the only distro that has working fglrx for me.
MostAwesomeDude: F8 got it installed, but refuses to start an X server, bombing out with a cryptic symbol error.
MostAwesomeDude: F9 won't install it, and neither will my Gentoo.
z3ro_: MostAwesomeDude: yeah it could be some security patch for /dev/mem.
z3ro_: mmap would try to map a region of memory 0xff4fb000 bytes long which is *way* too big.
MostAwesomeDude: Yeah.
MostAwesomeDude: Hm. I'll keep looking.
z3ro_: does fb_addr match the address from lspci -v?
z3ro_: maybe revenge is just detecting the length wrong.
MostAwesomeDude: I suppose if I could find some unsuspecting victim, that I could always just write the test into revenge and have somebody else run it.
MostAwesomeDude: And yeah, lspci -v doesn't even have it.
MostAwesomeDude: Stupid patched Ubuntu.
z3ro_: just installing your own kernel should fix it.
z3ro_: brb
MostAwesomeDude: This isn't an install, just a LiveCD. I'm just gonna sit back and wait for Catalyst to release 2.6.25/2.6.26 compat.
z3ro_: ok
MostAwesomeDude: In the meantime, lemme bang out the test for GL_LINE_SMOOTH.
MostAwesomeDude: ...Wait a sec. There's already a working test.
MostAwesomeDude: facepalms
MostAwesomeDude: Does anybody have a revenge tarball I can look at?
rx__: hmm..
rx__: on my notebook
rx__: you mean the dump?
MostAwesomeDude: rx__: Yeah, I think I'll only need one dump.
MostAwesomeDude: I remember something about an FTP full of revenge dumps.
rx__: uh.. i'm not near my notebook though :)
MostAwesomeDude: Poxies.
rx__: pm me your email and i'll get it to you some time tonight?
rx__: :D
MostAwesomeDude: rx__: MostAwesomeDude@gmail.com
MostAwesomeDude: Hardly a private email, XD.
rx__: haha okay
MostAwesomeDude: No rush, but really there's not a lot left for me to do.
MostAwesomeDude: Except stuff like this.
MostAwesomeDude: And whatever my imaginary, non-existent employer wants me to work on. :3
rx__: oh
rx__: i found one
rx__: http://people.freedesktop.org/~airlied/revenge-1.0-5460-7ce7.tar.bz2
rx__: i'm sure airlied has more recent ones around
airlied: http://people.freedesktop.org/~z3ro/revenge/
rx__: or that..
airlied: I have some r500 ones but I think they are on my other laptop
MostAwesomeDude: One sec, dissecting. Mm, yummy.
MostAwesomeDude: Agh, need to update pretty_print code.
z3ro_: I wrote some new code that replaces pretty_print_cmd_stream btw.
MostAwesomeDude: z3ro_: That could be useful.
z3ro_: although it can't print names for the registers.
z3ro_: it's part of my new demo tool, expose. so it can convert packets into expose function calls.
MostAwesomeDude: 0x46BC is being written 0x1, but it's not documented. Also all the other dumps are writing to it...
MostAwesomeDude: Man, it would be nice if AMD could just tell us what we need to set.
MostAwesomeDude: I doubt there's any patents on polygon antialiasing.
z3ro_: I guess they would still have to get legal clearance though.
MostAwesomeDude: Yeah.
airlied: waves hand, 0x46bc is not the register you are looking fir :)
airlied: for .
MostAwesomeDude: Quite the hand wave there.
airlied: jedi mind trick ftw.
MostAwesomeDude: airlied: Any ideas on what I should be looking for? There's no plain tri dump, so I'm sorta just checking regs that we don't have any info on and seeing how suspicious they are.
z3ro_: MostAwesomeDude: there should be a single tri dump...
airlied: MostAwesomeDude: decode the frag prog, and have a look at the documented GA_ regs
z3ro_: gl_clear does glClear && tri();
syntropy: bloody hell i hate git
syntropy: it's so frustrating trying to keep everything updated
bridgman: ooh, reverse engineering, I'll just look the other way ;)
z3ro_: hehe I bet he's still reading the logs though. ;)
z3ro_: yes, we see you! ;)
MostAwesomeDude: bridgman: You aren't allowed to giggle at our misguided efforts to RE stuff?
bridgman: Why not ?
bridgman: Seriously, trying to get this but just not enough hours in the day recently
bridgman: should improve soon
bridgman: trying to get 6xx stuff out to distract you so we have time to find this
MostAwesomeDude: XD
z3ro_: I'm looking forward to those r6xx docs and tcore... :)
bridgman: *&^*(& aa poly stuff
MostAwesomeDude: As am I.
MostAwesomeDude: bridgman: I'll figure it out eventually.
MostAwesomeDude: I just complain a lot 'cause I'm poor at RE. :3
bridgman: nobody is looking forward to it being released more than me ;)
z3ro_: hehe
bridgman: whereas glisse RE's a lot because he's not very good at complaining ?
airlied: sometimes RE is just faster :)
z3ro_: btw is there an ETA for tcore and r6xx?
bridgman: yeah, that surprised me at first
z3ro_: I was kind of hoping this weekend.
bridgman: z3ro: last week ;(
bridgman: working on it now but all the reg's are starting to blur together ;(
bridgman: probably time for a break
bridgman: maybe go stand in the rain or something
bridgman: bbl
z3ro_: glisse: hmm I think I've seen fglrx dumps write ISYNC_CNTL, so maybe amd use this trick to avoid lockups, too.
z3ro_: I just remember 1724 from somewhere...
z3ro_: brb
MostAwesomeDude: Argh. The only differences that actually matter at all are the vertices being uploaded.
MostAwesomeDude: What's the deal with each of the ib files? Are they just arbitrarily divided up?
z3ro_: MostAwesomeDude: on the dri drivers, we don't use IB's for 3d... they are from the DDX and can be ignored.
z3ro_: MostAwesomeDude: fglrx uses the ring mostly as a "dispatch and sync" system. so "execute ib, sync, ..."
z3ro_: eg on fglrx the good stuff is in the IB's and on DRI it's in the RB (ring buffer)
MostAwesomeDude: z3ro_: Right. So there's no real way to tell order of regs?
MostAwesomeDude: I mean, across all IBs?
z3ro_: MostAwesomeDude: yeah, you look at the RB and look for the ib_addr/ib_size regs.
z3ro_: the first one is ib_001.txt, second one _002.txt, etc.
MostAwesomeDude: Oh joy.
MostAwesomeDude: Alright, I'll put more time into this later.
airlied: z3ro_: I do wonder if you could scan the rb before and adfter the test
airlied: and see if you can narrow down the ibs involved in the test
z3ro_: airlied: well revenge only looks at a section of the rb. it checks the rptr just before running the test, and again after the test has finished.
z3ro_: so in theory the only thing between those two pointers should be commands generated by that test.
z3ro_: the "extra" ib's when running on DRI come from the DDX just randomly stuffing things into the RB, I guess.
z3ro_: which btw doesn't sound like the best thing to do...
z3ro_: running with --disable-ib on DRI should fix it, though.
MostAwesomeDude: BRB, commute time.