csimpson: Okay, so.
csimpson: R300_RS_COUNT. WTF is up with W_ADDR? Is "relative rasterizer packet location of w" just the offset where the fogcoord is? What's w_count, is that the same as R300_RS_INST.W_CN?
agd5f: csimpson: w_count id bit 11 of RS_COUNT
agd5f: seems to have disappeared on r5xx
csimpson: agd5f: Ah. I see. Any rules about where it gets written?
agd5f: w_addr is the addr of the w coordinate in the input stream
agd5f: rs input stream
csimpson: Right, I figured that.
csimpson: But, I mean, where does RS write it?
csimpson: Hm, there's another bit on here too missing in r5xx docs. W_EN.
csimpson: Anyway. Tried the fog texcoord stuffing. Does *not* work.
csimpson: Or perhaps I just suck.
agd5f: those bits don't seem to exist on r5xx unless they are undocumented. I suspect the behavior changed slightly
csimpson: That's not what I was hoping to hear.
airlied: csimpson: US_W_FMT is how you get W into sader
csimpson: Revenge is not really very helpful for this. I feel like fglrx is just kinda magically optimizing away the need for some of the onboard fog handling.
airlied: set W_SRC to get W from the rasteriser
csimpson: But then how do I get the W from RS->US?
agd5f: csimpson: you don't
csimpson: W goes from RS->FG?
csimpson: So that'll work for using the fog HW. Hm.
agd5f: depending on the setting of US_W_FMT
agd5f: if you want to compute fog int eh shader you need to pass it in as a color
csimpson: Oh, I see. W can *either* come from the RS or the US, and it always ends up ready for FG.
csimpson: Okay, first things first. Need to get fogc from SW TCL to RS to US. That'll fix the currently broken default Mesa path.
csimpson: Or, get W from RS to US.
csimpson: But if I'm understanding right, can't transport W from RS->US unless it's a color. So, gotta make RS think that the fogc/W is a color?
glisse: csimpson: yup you have to route z or w as a color, also fglrx is likely doing fog directly in the shader not using dedicated hw
hifi: Radeon X1250 is (integrated, yes) R(V)5xx chipset?
airlied: nope its an rs690, based on part r500 display controller and rv380 3D engine
airlied: and if its with an Intel CPU it has some r600 bits in the memory controller
hifi: 3d accelerated RS690 support is a long way I suppose if R500 is just barely spinning glxgears?
airlied: hifi: rs690 is working fine, rs600 not so much.
airlied: it mainly depends on which CPU the chipset is joined to
airlied: so in that case not so good, as we need some of the r600 code.
airlied: the amd variant runs fine.
hifi: http://www.verkkokauppa.com/popups/prodinfo.php?id=11455 I thought buying that mobo for my next desktop
csimpson: glisse: Yeah, Mesa attempts to put the fog into the shader, and if it doesn't, we ask it to, if FogOptions are set, so the fog HW is usually not used in this new system.
hifi: it'd be great for my quake experience
airlied: hifi: yup rs600 but not so rocking with open source due to missing bits.
airlied: I suspect when we get the r600 docs it'll be fairly quick to support
airlied: as the 3D engine is the same as the rv380 but has no vertex shader
hifi: are r600 docs already scheduled to be released?
airlied: yes but they are taking their time :)
hifi: and I'd be happy to do some testing with my work desktop when the new xorg drops from debian experimental to unstable:
hifi: 01:00.0 VGA compatible controller: ATI Technologies Inc RV515 [Radeon X1300]
hifi: as adviced for 2D, I bought it :)
csimpson: How do I get vertices from revenge? I found something finally.
glisse: csimpson: doesn't dump vertices, just cmdbuffer :)
csimpson: As soon as z3ro's finished with his GLX-ification work, I want a re-dump of this. There's strange things in here.
csimpson: Too bad we can't get an ATI guy to just come in and say, "Oh, yeah, gotta do this-an-this to get it to work."
csimpson: Clearly, fog > me.
csimpson: Arg. Screw it.
csimpson: I've got no chance to get this.
csimpson: Does 0x2180 or 0x2184 (VAP input ctrls) need to know about per-vertex fog?
airlied: csimpson: I still think you are trying too hard :)
csimpson: airlied: Probably, yes. But I've tried all kinds of various things, and each time, I get massive failure.
airlied: csimpson: are you trying to get all fog working at once?
glisse: csimpson: you should first try to get z to fragprog working
glisse: there is simple demo in mesa to test that
glisse: once you know that z is properly routed
glisse: you know that it all boils down to the shader mesa provide
csimpson: glisse: Which demo is that?
glisse: you can dump the shader (r300 binary & string) to see if it does somethings stupid then
csimpson: glisse: Those all work fine.
glisse: run then with mesa software to see what it should looks like
csimpson: frag.pos.xyzw... z and w correspond to Z and W?
csimpson: Single facepalm is not enough. I'm going to need a two-handed facepalm for this.
csimpson: ( ><)
MrCooper: I'm with airlied, I think the initial focus should be on fixing the immediate r300 regression only, then worry about other fog functionality
csimpson: The general idea, I think. progs/demos/fogcoord looks like an LSD trip, but it doesn't crash.
csimpson: Sleep now, get flamed in morning. :3
glisse: MrCooper: there are know regressions lately ? i should follow bug :)
MrCooper: glisse: yes, fog has been busted for a while, try e.g. the teapot demo
adamk: Does KMS support different resolutions on different outputs on a single video card?
zhasha: csim = corbin?
glisse: zhasha: don't think so
zhasha: Hey glisse. Are you working on a gallium driver? :)
glisse: or he is been flying over the atlantique in some flying saucer
glisse: i am finishing dri2 before going back to gallium
sannes: From what I have gathered (by lurking on mailing lists) there will be some kind of common memory/synchronization handling in the Linux 2.6.28 kernel for the graphics drivers to use .. and I was wondering how soon the git master branch (at git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati) will make use of it?
sannes: or if it is delayed until kernel mode setting is merged into it?
glisse: there is nothings in 2.6.28 for radeon
glisse: only intel bits
glisse: and plan is to have memory management only with kms to make transition easier and kernel bits cleaner
agd5f: adamk: yes
adamk: agd5f, I thought as much. Thanks for the confirmation. I'll have to give it a try with Fedora 10 when it's out.
agd5f: adamk: np
adamk: Hmmm... One more question. One of my monitors is attached via a KVM, and I have to use a 1280x1024 Modeline in my xorg.conf file, and use the PreferredMode option. I expect kms will have the same issue? Is there a similar option?
agd5f: adamk: should work the same. only difference is that the modesetting bits live in the kernel rather than the ddx
sannes: glisse: thanks :)
adamk: agd5f, Gotcha. Thanks again.
mcgreg: most probably I'll get my radeon 4670 tomorrow :) lookign forward to it ;)
sannes: does the linux kernel module radeon.ko not support Xpress 1200 (0x1002 and 0x7941) ?
csimpson: is MostAwesomeDude
csimpson: I've been banned at home for reasons I don't understand yet.
fat_chris: airlied, im having some issues with kms when switching to vts from x, at first it freezes then i get "no signal" from my monitor and im forced to reboot sysrq style, any ideas?
airlied: fat_chris: wierd. considering it should't do a mode switch.
airlied: got xorg log file?
airlied: fat_chris: so it boots fine?
fat_chris: yes, pretty much my only issues are with vt switching, including when ending X/rebooting from X
MostAwesomeDude: Whoo, that was fun.
spstarr_work: caught in fog? ;)
MostAwesomeDude: Long story short, I'm on the Tor service now.
spstarr_work: your popularity is getting you in trouble? ;-)
MostAwesomeDude: We have an SW TCL bug with WPOS.
MostAwesomeDude: Try "R300_NO_TCL=1 progs/fp/tri-depth", but make sure you save all your work first, 'cause it'll softlock.
spstarr_work: looks at koji
spstarr_work: airlied: anything in upstream drm that might fix the VT issue?
airlied: spstarr_work: not that I know off.
MostAwesomeDude: airlied: Any ideas on how to get WPOS through SW TCL?
rmh3093: MostAwesomeDude, hows fog coming?
MostAwesomeDude: 'Cause it'd be really nice (read: easy) if SW TCL could provide either W or FOGC in the WPOS vector. That way, RS wouldn't have to change.
MostAwesomeDude: rmh3093: glisse pointed something out last night, and I facepalmed pretty hard.
MostAwesomeDude: But it's going.
rmh3093: seems like you've been working on this forever....
rmh3093: not that im saying it isnt hard or that i could do it faster
MostAwesomeDude: I think it's a combination.
MostAwesomeDude: 1) I'm really new to graphics cards still and I'm constantly not understanding things.
MostAwesomeDude: 2) Fog's a bitch.
airlied: MostAwesomeDude: don't we pass WPOS in a texture or somethinhg?
MostAwesomeDude: 3) Nobody else really knows either AFAIK.
airlied: I didn't think there was a WPOS vector going from VP->FP
MostAwesomeDude: airlied: In RS, yes, but not in SWTCL. "R300_NO_TCL=1 progs/fp/tri-depth" will softlock.
airlied: well we need to pass the WPOS to a texture in swtcl as well.
agd5f: as a tex or color would work too IIRC
MostAwesomeDude: Right. I'm just asking if you have any idea on how to do that, 'cause I'm terrible with swtcl.
airlied: I think the intel driver does some fancy foot work with wpos.
MostAwesomeDude: Research must be done. For science!
MostAwesomeDude: Okay. So XYZW is always in HPOS, the first post-TCL vertex value.
MostAwesomeDude: RS uses that to do its thing, and hands Z and W to GA and then FG.
MostAwesomeDude: We don't want to mess with the "real" Z and W. What we want is to have a stuffed texcoord with WPOS, which is basically 00zw and gets forwarded to US.
MostAwesomeDude: So TCL should produce XYZW in HPOS, and also 00ZW or 000W in the first available texcoord.
MostAwesomeDude: And then the existing setup should correctly get RS to do the stuffing, and then US can do what my posted patch does.
MostAwesomeDude: Hm. Looks like the correct-ish solution is just to get swtcl to emit HPOS twice at two different spots. This might be a job for Mesa core. :c
MostAwesomeDude: Anybody have any idea why http://pastebin.ca/1253891 causes technicolor?
MostAwesomeDude: It's almost there, just not quite.
dmb: MostAwesomeDude, what is it that actually causes a lockup when it comes to graphics?
RTFM_FTW: trashing a kernel side data structure (of whatever sort) is a common example
RTFM_FTW: dereferencing a NULLed / invalid pointer in kernel space :D
airlied: programming the graphics card wrong usually
RTFM_FTW: that too
MostAwesomeDude: dmb: Programming certain blocks on the graphics card wrong causes stalls.
MostAwesomeDude: In my case, usually RS.
RTFM_FTW: I've hit upon points (1) and (2) above quite a few times when fooling around with the VRAM manager :D
RTFM_FTW: although ASIC hangs in a user-space component are exceedingly rare anymore (thankfully) :D
dmb: is there usually a way to determine how it crashes?
dmb: it seems to be whenever i use the mesa stack
z3ro: dmb: for a lockup, assuming you can still use the box, usually some combination of guessing and looking at status regs.
dmb: z3ro, usually i can't
dmb: i'll using ssh next time it happens
z3ro: but that isn't really so helpful... usually it's just something like "whatever block is busy"
dmb: i can imagine i'm not the only one having problems
z3ro: I mean, at least it gives you some idea where to look.
dmb: i know nothing about gpu stuff
z3ro: then just check any regs related to that block very carefully.
dmb: z3ro, is there a program to grab the registers in the video card?
z3ro: unless you want to start messing around with it yourself, I'd just start with filing a bug report.
z3ro: but lockups are usually very hard to debug, so don't expect too much.
z3ro: the more info you can provide increases the chances of it getting fixed.
dmb: z3ro, it usually isn't reproducible, it happens at random times
z3ro: yeah, another reason why they are so hard to debug.
dmb: but if i'm using compiz, it will happen like less then an hour of use
dmb: the windows driver has that VPU recover thing, is there nothing like that for us?
z3ro: yeah, compiz will be using the 3d engine.
z3ro: there is a soft reset register for r5xx. but I couldn't really get it working right when I was debugging a lockup a while ago.
spstarr: dmb: we can't reset things yet
z3ro: next time the lockup happens, see if you can ssh in... if you can, dumping a few regs like rbbm_status might provide some basic info.
dmb: that be cool if someday that gets implemented :D
z3ro: I think the better solution is just to not lockup. :P
dmb: wish it were that easy :D
dmb: i'll switch back to the oss driver now, and see try sshing in
z3ro: well, yeah, the tricky thing is finding out exactly why we lockup, then fixing it.
dmb: its usually the same symptoms before every lockup
dmb: the mouse gets real jumpy
dmb: then usually just stops
z3ro: thats a bit strange. usually the lockups I've seen are pretty instant.
MostAwesomeDude: Okay, so I've unbroken non-fogcoord fog.,
z3ro: cool :)
rx__: noway :P
MostAwesomeDude: I'm gonna hack the VPS so WPOS is populated with the fogcoord when it's present.
MostAwesomeDude: Should I use Z or W?
z3ro: hmm won't that (further) break fragment.pos?
MostAwesomeDude: z3ro: fragment.position is only broken on swtcl.
dmb: is there any glsl code in the mesa driver itself?
z3ro: MostAwesomeDude: ok, I mean, broken for me and my shader. :P
MostAwesomeDude: dmb: Yeah, Mesa'
MostAwesomeDude: Mesa's got a fully-compliant GLSL compiler.
z3ro: although it's not really a big deal (only used for mirror/portal surfaces) but I should take another look at it sometime.
MostAwesomeDude: z3ro: Well, are you using frag.pos.zw ?
MostAwesomeDude: Those two are iffy.
dmb: MostAwesomeDude, you know the best way to learn glsl???
z3ro: MostAwesomeDude: nope, just .xy
dmb: like, in 2 days :(
MostAwesomeDude: dmb: Book?
MostAwesomeDude: z3ro: frag.pos.xy have been unbroken for a while. nha unbroke them.
dmb: might have to get an ebook
dmb: have to present a program that uses glsl by thursday :(
z3ro: I'm reasonablyl sure I tested those patches, and they fixed a lot, but not this shader for some reason.
z3ro: but I might be wrong... I'll have to retest at some point.
MostAwesomeDude: Anybody who wants to test it out... http://pastebin.ca/1253919
MostAwesomeDude: This *does not unbreak RS690*.
z3ro: I would, but at the moment this box has an r6xx card. =/
MostAwesomeDude: Hm. Time to go test some games!
MostAwesomeDude: Okay. Looks like there's some very strange banding. Not sure what's up with that.
MostAwesomeDude: Yes, yes, I know, I'm a Touhou-loving weeaboo.
MostAwesomeDude: But really, that banding in the BG shouldn't be there.
rx__: i don't think there's any japanese in here to judge you ;)
soreau: MostAwesomeDude: Hey.. should this fix stuff like playing n64 emulator? I noticed it had serious fog related issues (or I assume they're related to fog)
z3ro: damn, gcc isn't generating any SSE code... maybe I'm missing some options.
z3ro: I really don't want to rewrite this manually in SSE.
RTFM_FTW: mmm what fun things are you doing with SSE?
z3ro: calculating the tangent spaces for bump mapping. it's the last major CPU bottleneck. :)
z3ro: hmm actually it's not too bad with more aggressive optimizations. let's profile this...
z3ro: damn still really high and no noticeable fps increase. guess I'm manually rewriting it after all.
MostAwesomeDude: soreau: It might. Try and see.
soreau: MostAwesomeDude: Sorry, but what will I need for this?
soreau: I'm assuming it's mesa your working or ..
MostAwesomeDude: soreau: http://pastebin.ca/1253919
MostAwesomeDude: Apply that, cross your fingers. :3
soreau: To radeon dri driver?
MostAwesomeDude: Yeah. Apply to Mesa.
soreau: MostAwesomeDude: What's the git link to mesa?
soreau: Thanks :)
soreau: MostAwesomeDude: I should report back before too long
rx__: can i run tf2 yet? ;)
dmb: can it display the meaning of life yet?
soreau: MostAwesomeDude: I already have xf86-video-ati from git, is there anything else I should grab the latest and greatest of?
MostAwesomeDude: soreau: Don't think so, no.
MostAwesomeDude: rx__: Prolly not, since we're still missing lots of GLSL stuff.
soreau: nice :p
MostAwesomeDude: dmb: Sure, go grab forty-two.c and compile. Should work.
rx__: forgot my sarcasm tags
soreau: MostAwesomeDude: Am I doing it wrong already? http://pastebin.ca/1254004
soreau: I am the worst with patches :P
MostAwesomeDude: soreau: "git am
soreau: MostAwesomeDude: http://pastebin.ca/1254005
MostAwesomeDude: soreau: Do as it says? :3
soreau: That wasn't so bad I guess :P
soreau: MostAwesomeDude: Looks like I need dri2proto >= 1.99.1
spstarr: diving into dri2 eh :)
soreau: It says I have DRI2Proto 1.1
MostAwesomeDude: soreau: Oh, icky. Sorry.
MostAwesomeDude: Good luck.
soreau: This is just a default Intrepid install
soreau: good luck?
soreau: MostAwesomeDude: Come on man, just tell me where to get the dri2proto source pleas if you can?
MostAwesomeDude: soreau: Those kinds of upgrades can be annoyingly painful sometimes.
soreau: Do you not use this?
MostAwesomeDude: git://anongit.freedesktop.org/git/xorg/dri2proto IIRC.
MostAwesomeDude: I'm on Debian, so I just grabbed everything from the experimental repo.
soreau: Ok, well if I don't really need it, it says I can work around it
soreau: MostAwesomeDude: Can you point me to the experimental repo then?
MostAwesomeDude: soreau: http://packages.debian.org/experimental IIRC.
soreau: Alright, thanks
soreau: ugh, that's for debian, duh
soreau: MostAwesomeDude: That git link for dri2proto isn't right :/
soreau: I found it, np
benh: agd5f: dude, I found a funny one here
benh: agd5f: so I have this x86emu based thingy that POSTs cards
soreau: Yea, that was it. Google is stupendous sometimes :p
benh: agd5f: including this X1650 I have here
benh: agd5f: well .. it's fun
benh: agd5f: the BIOS seems to try to access IO 3b4/3b5 (monochrome MDA CRT registers)
benh: agd5f: which the card doesn't seem to implement
benh: agd5f: it aborts on the PCI bus, which on this machine causes a machine check !
benh: agd5f: any way you can poke internally with the BIOS folks what's up and if that's somewhat going to remain or is a known bug to be fixed ?
soreau: MostAwesomeDude: Ok, now it can't seem to find intel_bufmgr.h (and I can't either)
MostAwesomeDude: soreau: I thought you were on a Radeon?
soreau: I am
MostAwesomeDude: Add --with-driver=dri --with-dri-driver=r300,swrast to your configure.
soreau: Curious, Why swrast?
MostAwesomeDude: Fallback. Just in case. :3
soreau: ah yes
soreau: But.. I use the radeon driver
soreau: still use r300?
MostAwesomeDude: Well, which Radeon?
soreau: It's 9600
MostAwesomeDude: Yep, r300 is the right Mesa driver.
soreau: In the config output, it says OSMesa no. Is this a problem?
soreau: Also for DRI drivers it lists like every single driver for all cards
soreau: Is --without-dri-driver
tlp: MostAwesomeDude: Are you familiar with the DRI end of the FOSS intel driver?
MostAwesomeDude: soreau: Maybe it's --with-dri-drivers.
MostAwesomeDude: tlp: Not as much as I'm going to be in the next few months, no. :3
tlp: I wonder because my Dell Mini uses an Intel chip, and it runs WarCraft 3 under Wine smoothly, whereas the radeon driver does not.
tlp: I'm wondering if there's an obvious reason
airlied: tlp: FBos
airlied: most likely.
soreau: MostAwesomeDude: yup, it is :)
MostAwesomeDude: tlp: We're a bit behind the Intel folk in speed and features. :C
MostAwesomeDude: Okay, so my analysis.
MostAwesomeDude: Currently, vertex programs suck ass.
MostAwesomeDude: Solution: Write vertex program dumper, and then fix parts of Mesa that generate the VPS fail.
soreau: Thanks MAD|nap that did it
soreau: (at least it compiled, now to test)
soreau: Well, it didn't fix exactly what I wanted it to, but at least it didn't fail horribly either ;)