dmb: are you sure, i thought 0 was no vblank
dmb: also, when running glxheads, i see some kind of glitch
dmb: if i move my terminal window all the way to the right of the screen
dmb: and keep the glxheads windows on the top left
dmb: i see garbage on the right side of the screen
dmb: like white lines moving up and down
MostAwesomeDude: Pushed better LIT.
dmb: MostAwesomeDude: is there any example of anything that uses LIT?
dmb: is it me, oris http://gitweb.freedesktop.org/ not responding?
simpson: dmb: Can't think of any good examples, no.
z3ro: the ami bios boot order setup is really stupid. =/
dmb: ami bios sucks:/
dmb: phoenix bios is where its at :P
z3ro: I'd like to get linuxbios running on this board... but I think it would be a lot of work.
z3ro: afaik the chipset is some nvidia thing thats pretty unknown.
MostAwesomeDude: ...Ubuntu is making me angry. It wouldn't like me when I'm angry.
MostAwesomeDude: I'm soo close to making revenge work.
dmb: MostAwesomeDude: whats wrong?
MostAwesomeDude: dmb: Wrong mem offsets.
MostAwesomeDude: revenge isn't correctly detecting regs and fb.
dmb: :/
MostAwesomeDude: I think I'm just going to hardcode them and see what happens.
z3ro: MostAwesomeDude: hard coding them will work fine, thats what I did before I added the detection code.
MostAwesomeDude: z3ro: 'k.
MostAwesomeDude: If/when I get it working, want a patch for anisotropy detect?
z3ro: and the detection code isn't foolproof... if lspci can't get the right data, then chances are revenge won't either.
MostAwesomeDude: z3ro: It's not matching lspci.
z3ro: sure, patches are always good. :)
z3ro: hmm thats a bit weird...
MostAwesomeDude: Just a bit...
z3ro: just comment out the detect_* (); calls, and hard code the values. that should get it going.
MostAwesomeDude: Huh.
MostAwesomeDude: Okay, so the LIT is not going to get any more accurate.
MostAwesomeDude: Changing it to do the justified math and then doing a CND is definitely not correct.
MostAwesomeDude: I think just leaving it slightly incorrect is the best we can do.
MostAwesomeDude: z3ro: The patch. http://rafb.net/p/wKF9g586.html
z3ro: MostAwesomeDude: cool, I'll commit it to my local tree and push it once I've updated my gpg key.
z3ro: at the moment I can't commit.
MostAwesomeDude: 'k.
MostAwesomeDude: No rush, no worries.
MostAwesomeDude: Now I just need to get the entire assembly working, and then start parsing input.
surfer: is it still necessary to use vblank_mode=0?
airlied: shouldn't be.
surfer: ok
surfer: before compiz wouldn't last very long without it
surfer: i'll turn it on and see what happens
surfer: is there a difference from vblank and vsync?
airlied: no.
surfer: i wish i could do more to help besides report bugs
rbrett: surfer: reporting bugs is underrated, and is of great help to developers (who do not own every machine)
surfer: i know c but i dont know enough about opengl or 3d hardware
surfer: to do anything useful
MostAwesomeDude: surfer: Read code, watch git.
revx: MostAwesomeDude: do you know of any gitk like tools that are aware of modern toolkits?
MostAwesomeDude: revx: Not really.
revx: the tcl/tk stuff in gitk is horrendus :
revx: (and broken)
tilman: revx: there's giggle
revx: just moved everything to here
revx: laptop going down
revx: 04:04:59 up 63 days, 8:54, 9 users, load average: 1.15, 1.05, 1.01
nh_: MostAwesomeDude: fyi, it looks like anisotropic filtering has no effect on r3xx - there's no breakage, it just doesn't change anything
revx: nh_: indeed
revx: silently ignored
nh_: yup
revx: is there any docs on that register I see in the guide?
nh_: we're setting some registers, but they're obviously not correct
nh_: the docs don't mention anisotropic filtering at all
nh_: as far as I can tell
revx: there's a register in the r3xx doc IIRC
nh_: which one?
MostAwesomeDude: nh_: Yeah, that's what I'm seeing too.
revx: let me look
MostAwesomeDude: I'm reading through the revenge dump, looking for diffs between AF on and AF off tex tris.
nh_: revx: we have some aniso-related #defines in r300_reg.h in the driver, but they're probably not correct (or we're missing something else)
nh_: MostAwesomeDude: very good
MostAwesomeDude: There's a couple different things. I'm hoping it's not weird VAP magic like the AA stuff.
nh_: I'm off to some hacking to figure out the precise cubemap memory layout
MostAwesomeDude: nh_: Good luck.
revx: nh_: it's not as described in the r5xx doc?
revx: (cubemap that is)
revx: sequential is what I read
nh_: revx: what page is that on?
revx: nh_: I don't have that up -- looking for the register right now
nh_: okay
nh_: well, I've got the basic layout right anyway, it's just the small miplevels where things are wrong
nh_: likely because we don't get alignment of rows right
MostAwesomeDude: Whoever was looking at stuffed tex stippling, check out the chroma key on TX_FILTER1; looks like you could use that to stipple in the tex filter before reaching the FP?
MostAwesomeDude: nh_: There's a VOL_FILTER in TX_FILTER0? Says it's for "filter used between levels of a volume"
nh_: MostAwesomeDude: I noticed that yesterday as well; my theory is that you still need a TEX instruction in the FP to trigger the texture unit, but we probably won't need an additional indirection or KIL
MostAwesomeDude: Could that have anything to do with cubemaps?
nh_: more likely it's related to 3D textures
revx: MostAwesomeDude: so then are the GB_AA_CONFIG docs way off as far as you can tell?
MostAwesomeDude: revx: Yeah. bridgman said as much a while ago, and I've experimented with them too.
MostAwesomeDude: GB_AA_CONFIG simply doesn't do anything.
MostAwesomeDude: Or it doesn't do anything unless we poke it in a place I didn't try.
Zajec: z3ro: ping
revx: MostAwesomeDude: do the multisample positions need to be set first?
MostAwesomeDude: Huh, think I found something. Can somebody suggest something simpler than compiz, that I could see a definite difference using anisotropic filters?
revx: MostAwesomeDude: the af redbook demo?
MostAwesomeDude: revx: In theory, you just flick on AA before drawing an AA primitive.
MostAwesomeDude: revx: Ooh. Lemme go grab my redbook and see what it looks like.
revx: MostAwesomeDude: not in the book as much as in mesa/progs/redbook :P
MostAwesomeDude: facepalms
revx: MostAwesomeDude: the r3xx reg doc says the multisample positions all default to 0
MostAwesomeDude: revx: I'm pretty sure I flicked on multisampling too.
MostAwesomeDude: I'll take a look in a sec.
revx: have you tried playing with GB_MSPOS* yet?
MostAwesomeDude: No.
glisse: dmb: did you tested ? and did it help ?
nh_: http://steinsoft.net/index.php?site=Programming/Projects/OpenGL/anisotropictest claims to be a nice test for aniso
MostAwesomeDude: nh_: Saw that.
MostAwesomeDude: There's also an ATI demo, but it's big.
revx: MostAwesomeDude: what are you looking for?
MostAwesomeDude: revx: Just a visible test of anisotropy.
revx: with the redbook one you can set the level and rotate a textured object
MostAwesomeDude: It's sort of a mild effect.
MostAwesomeDude: There's no redbook demos with i.t
MostAwesomeDude: *it.
revx: hm?
revx: I know one of the demos has it.. perhaps it wasn't a redbook one
revx: tests/textfilt.c?
MostAwesomeDude: tests/texfilt has it, but it's not really visible.
revx: -t* :P
MostAwesomeDude: The one nh posted is suitable.
MostAwesomeDude: Hmm, I'm closer, I think.
MostAwesomeDude: The demo now looks different.
MostAwesomeDude: Lot less blurry.
MostAwesomeDude: Looks like it's some undocumented stuff in the tex filter.
MostAwesomeDude: Hmm, how did we get the original AF stuff?
MostAwesomeDude: Meh, whatever.
MostAwesomeDude: I don't know how correct the filter level numbers are.
MostAwesomeDude: Changing the filter number written seems to turn it on, though.
MostAwesomeDude: revx, nh_, thanks for the ideas, I'm gonna look at AA again.
z3ro: Zajec: pong
z3ro: Zajec: I'm just grabbing the valgrind source now to rebase mmt.
z3ro: MostAwesomeDude: hmm let me know if you get AF working. this is a feature I'd really like to see.
z3ro: AA would be cool too, but I'm mostly interested in having the floor textures render in a non-crappy way in my engine. :)
z3ro: MostAwesomeDude: btw, I can tell you that AF does work on r3xx. I've seen this on fglrx.
z3ro: but it might have been a "r300 compatible" card, eg r4xx or so.
MostAwesomeDude: revx: Okay, touching GB_MSPOS is a bad idea.
onestone: MostAwesomeDude: you should really fix fragment.position
MostAwesomeDude: onestone: Yes, I should.
MostAwesomeDude: I'll look into it tomorrow.
MostAwesomeDude: Wow, compiz looks gobs better if AF is forced on. I'm gonna push; would r3xx people let me know if this causes anything bad to happen?
nh_: MostAwesomeDude: sure
nh_: I'm still trying to figure out wtf is wrong with cubemaps, but I'll have a look later
z3ro: nh_: yeah I meant to ask... how broken/fixed are they right now?
z3ro: eg does it mostly work?
nh_: z3ro: they seem pretty good actually, but the small miplevels are mixed up
z3ro: hmm ok. I might take another look at my skybox program then, and see if I can make it work this time.
nh_: good
z3ro: the last time I could never get it to work because the faces were all mixed up, but I think thats fixed now.
nh_: nonmipmapped cubemaps seem to work perfectly, and mipmapped cubemaps mostly work (with current git, I applied some fixes yesterday), it's just the small mipmaps that are somehow broken
z3ro: ok. it should work well enough for testing then.
z3ro: and I could just force non-mipmap if I need to.
MostAwesomeDude: ...Okay, sleep is now necessary. Be back in a while.
z3ro: ok, night
revx: MostAwesomeDude: err, sorry :/
z3ro: Zajec: ok, got a patch.
z3ro: Zajec: this *should* work, but I haven't tested it.
nh_: wow, this is very interesting
z3ro: Zajec: http://pastebin.ca/raw/1041115
nh_: miplevel calculation aren't uniform across a rectangle
z3ro: it's against valgrind 3.3.1
nh_: even though it looks like they should be
umtc: has there been any progress on adding a tv_vertical_size control?
Zajec: z3ro: woho :)
glisse: z3ro: btw did you tested free-lockup branch ?
z3ro: Zajec: sorry about taking a bit longer than I said it would... :)
z3ro: let me know if there are any problems with it.
Zajec: z3ro: no problem :) i was quite busy last few days so i didn't notice that until today :)
z3ro: glisse: not yet. I'll do it in the morning. I don't want to shutdown to change the gpu at the moment.
glisse: z3ro: okay just let me know result
z3ro: glisse: ok :)
nh_: okay: piglit's cubemap test draws a flat square with simple texcoords to get one face of a cube texture
nh_: and for some reason, r3xx doesn't select a uniform miplevel across that square
nh_: can you say suckage?
nh_: mmh... fglrx fails the cubemap test as well
nh_: but the miplevel miscalculation at the border of the squares is less pronounced
nh_: interesting
Zajec: z3ro: could you help me, please?
Zajec: The next patch would create the file Makefile.am,
Zajec: which already exists! Assume -R? [n]
z3ro: Zajec: did you do patch -p1 < file
z3ro: or even: git am < file
Zajec: yes, other files was patched fine
Zajec: only at this one file (Makefile.am) I get this question
Zajec: rest of files was just patched
Zajec: hm, weird... i used -p1 and it worked fine :)
Zajec: ok, sorry for noise... i configure valgrind with mmt patch now :)
mcgreg: google earth finally works correctly here
mcgreg: thx very very much :)
dli: mcgreg, is the fix in current git already?
mcgreg: I think so
Zajec: is radeon git supposed to work with KDE kwin effects? X700 Mobility (R4xx(
mcgreg: hmm I suppose it is. I'll recommend to try it ;)
nh_: z3ro: revenge fails with revenge_dump.c:199: dump_packets: Assertion '0' failed.
Zajec: doesn't for me
nh_: z3ro: do you have an idea what's wrong?
Zajec: display is corupcted somehow
nh_: (this happens on the very first test (gl_alpha_test))
z3ro: nh_: is this the latest code from git? line numbers don't seem to match up.
nh_: it's probably moved one line down, because I wanted to add a test for cubemaps
Zajec: all the windows are only black/grey rectangles
nh_: I can revert my changes though and try again
z3ro: well for line 199 of revenge_dump.c I get " packet_opcode = (mem_map[i] >> 8) & 0xff;
z3ro: I think it would be the assert in the default case of switch (packet_type)
nh_: yes
z3ro: in which case, check if packet_type == 1 (I didn't implement support for type 1 packets yet)
nh_: and I'm uptodate wrt the people.fdo/~z3ro/revenge repository
dli: glxgears stay foreground
z3ro: nh_: one sec, I'll write type-1 support.
nh_: z3ro: odd, the line number should be exactly the line number from the repository
z3ro: hmm I might have local changes
dli: googleearth almost works, but still with a flashing black box
arekm: MostAwesomeDude: https://bugs.freedesktop.org/show_bug.cgi?id=16253
z3ro: nh_: doh! had some local changes.
z3ro: one sec and I'll add type-1 support.
nh_: thx
Zajec: z3ro: i installed valgrind just fine! thanks for your work! now only waiting for sb (probably Alex) for howto of using it :)
z3ro: Zajec: there is some info online somewhere, one sec...
z3ro: Zajec: sudo valgrind --tool=mmt --offset=c1000000 /usr/bin/Xorg :0 -ac > x.log 2>&1
Zajec: z3ro: i'm afraid nobody wrote info for using valgrind against EDID reader of video driver :)
Zajec: wooh, looks magicly :)
z3ro: you could just replace the Xorg bit with whatever program you want to dump.
z3ro: and the offset, of course.
z3ro: look in lspci -v for the offset of the register memory for your card
z3ro: on radeon cards this is a 64K region
Zajec: should I look for "offset" work in lspci -v ?
Zajec: http://pastebin.com/m5351d7b2
z3ro: typically you'll have something like this:
z3ro: 02:00.0 VGA compatible controller: ATI Technologies Inc Radeon... Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at dfff0000 (64-bit, non-prefetchable) [size=64K]
z3ro: irssi ate the newlines...
z3ro: but you're loooking for the size=64K one.
z3ro: so I would use dfff0000 for my card.
mcgreg: and I believe vsync works now correctly too .. glxgears reports 60 fps (59,xxx)
Zajec: z3ro: i have two lines with "size="... it's for "prefetchable" and "non-prefetchable"
z3ro: Zajec: you would use c0100000
Zajec: ah, this one :) ok
z3ro: it's always the "(32-bit, non-prefetchable) [size=64K]" line.
Zajec: will line
Zajec: valgrind --tool=mmt --offset=c0100000 /usr/bin/Xorg :0 -ac > x.log 2>&1
Zajec: work fine for detecting EDID reader operations in driver?
z3ro: yeah, it's going to show you all MMIO access from the DDX (part of Xorg)
Zajec: sounds nice :) i'll try this, thanks a lot
z3ro: no problem :)
mcgreg: uhh I hope you can fix those annoying crashes though
mcgreg: had to reboot, X totally died
stefanb: ouch, mesa build system changed. Let's hope it still fits to Fedora 9 SRPM
z3ro: nh_: ok, I think this should work... http://pastebin.ca/raw/1041154
nh_: z3ro: okay, I'll give it a try
z3ro: it's a bit weird that you're seeing type-1 packets though. iirc they are considered obsolete
nh_: hmm.. maybe something else is wrong here
nh_: sudo ./revenge.sh --agp should do the trick, right?
nh_: now I'm getting: revenge_dump.c:232: dump_packets: Assertion `i - tail <= 1' failed.
nh_: perhaps revenge is picking the wrong memory region?
z3ro: nh_: yeah, thats possible... you could just comment out the calls to detect_* (); and hard code those values.
z3ro: iirc MostAwesomeDude was having problems with it not detecting addresses correctly, so maybe something changed in newer versions of libpci...
nh_: z3ro: sometimes, a number of the gl_alpha_test tests are run before the assertion happens
z3ro: nh_: hmm this might be the bug I could never track down. I think it could be a timing thing...
Zajec: z3ro: should i install some "mmt" program additionaly?
z3ro: eg the part of the RB that revenge is trying to read gets overwritten before it can read it back.
Zajec: cat x.log
Zajec: valgrind: failed to start tool 'mmt' for platform 'x86-linux': No such file or directory
z3ro: nh_: try the --fast option, or a longer delay in revenge_test.c:test_quiescent
z3ro: Zajec: hmm it should be installed automatically
Zajec: find /opt/valgrind -name "*mmt*"
Zajec: gives me nothing :(
z3ro: if you just did: ./configure && make && make install, then it wouldn't install to /opt
Zajec: ./configure --prefix=/opt/valgrind/
nh_: z3ro: no combination helped, the machine just died
nh_: I'll give it one more try, and if that doesn't work I'll just give up for now
z3ro: nh_: which driver are you running it on anyway?
nh_: fglrx
z3ro: version?
nh_: hold on... have to wait until the system has booted again ;)
z3ro: hehe :P
z3ro: Zajec: hmm ok. not sure why it didn't install then.
nh_: essentially it's the one installed by ubuntu
z3ro: maybe I messed up the makefile or something... one sec
nh_: OpenGL version string: 2.1.7412 Release
Zajec: z3ro: oki
osiris_: nh_: I was hitting the Assertion `i - tail <= 1' problem too. To solve it, I just run revenge under clean X (no programs, even no WM), so that ddx mess around as less as possible
z3ro: nh_: can you check the version from the fglrx installer? like fglrx-8...something or whatever the new catalyst thing is called.
Zajec: grep -c "mmt" ./Makefile
Zajec: 0
stefanb: Hmm, can't get latest mesa git to compile anymore
z3ro: Zajec: doh! I probably forgot autoreconf.
z3ro: I'll fix it, one sec.
Zajec: z3ro: :) could you prepare new patch?
Zajec: ok :)
nh_: z3ro: any idea how to figure that version out from a distro-provided package?
z3ro: nh_: not really, but I was just going to compare that to what I've used previously. in fact, osiris' idea might be worth trying.
z3ro: I usually run a very minimal setup when working with revenge.
z3ro: in fact I use ratpoison all the time anyway, so... ;P
nh_: yeah, I just tried that, but so far without success
z3ro: check to make sure there isn't anything fancy enabled (aiglx, compositing, etc)
z3ro: I don't know whether that will help, but the DDX can get in the way sometimes.
nh_: well; I'M now basically doing the following:
nh_: sudo X&; export DISPLAY=:0.0; xterm &; sudo src/revenge; via ssh
osiris_: nh_: what card do you have?
z3ro: nh_: that should work
nh_: ATI Technologies Inc R420 JI [Radeon X800PRO]
nh_: hmm, got a different error message for a change:
nh_: revenge: revenge_dump.c:190: dump_packets: Assertion `mem_map[i]' failed.
nh_: though it's probably just a different symptom of the same problem
osiris_: nh_: maybe revenge doesn't detect fb & agp addresses correctly
z3ro: nh_: another hard to debug problem. there should never be 0x0 dwords in the ring buffer (except possibly in the packet payload)
nh_: osiris_: I think it does:
z3ro: usually it means revenge dumped garbage in the ring.
nh_: detect_reg_aperture: reg_addr = 0xe8020000 reg_len = 0x00010000
nh_: detect_fb_aperture: fb_addr = 0xd0000000 fb_len = 0x10000000
nh_: detect_agp_aperture: agp_addr = 0xd0000000 agp_len = 0x08000000
nh_: compare to:
nh_:
nh_: Memory at d8000000 (32-bit, prefetchable) [size=128M]
nh_: I/O ports at c000 [size=256]
nh_: Memory at e8020000 (32-bit, non-prefetchable) [size=64K]
nh_: no wait
osiris_: nh_: see what Xorg log says
osiris_: fb_addr are different
nh_: yes, I was blind
z3ro: nh_: try disable detect_fb_aperture, and manually setup fb_addr and fb_len.
z3ro: revenge_detect.c
nh_: aha, now it works
nh_: you've been right all along, sorry
z3ro: I'll have to look into why the detect code fails.
osiris_: z3ro: for r500 family you should use mcind regs to get fb & agp addresses
z3ro: osiris_: yeah, I'll fix that sometime.
z3ro: I should get some sleep soon, though.
stefanb: Wow, finally I got the right makefile fixes for latest mesa...
stefanb: OK, trying to install new mesa RPMs
nh_: packet3 NOP {1337f00d 0000005d 00000000}
nh_: heh
nh_: "leet food"
z3ro: haha
z3ro: btw I wrote a replacement for pretty_print_cmd_stream thats included in expose. (similar to r300_demo) I haven't released it yet as it still needs some work...
nh_: cool
z3ro: I'm waiting to see exactly what tcore includes once it's released.
z3ro: I'd like to have something that can run independently of drm/x/dri and be enough to bring up the hardware, and do some small demos.
z3ro: for now though it goes through the drm.
z3ro: so something like tcore+tgl
nh_: screw this cubemap business
nh_: I wonder if I can get away with some simply LOD bias
z3ro: or ask bridgman about the memory layout when he's here.
z3ro: he can probably find out
Zajec: z3ro: i was away, if you will get patch working please ping me
z3ro: Zajec: yeah, I'll look at it again in the morning. just going to get some sleep now.
Zajec: ok, will catch you later :)
Zajec: you live in crazy timezone ;-)
nh_: z3ro: actually, after running some tests I'm fairly certain that I've gotten the memory layout right. The problem is more that the chip calculates an unexpected miplevel close to the corners
nh_: z3ro: one can observe this by enabling MIP_LINEAR filtering
nh_: the border pixels of the quad obviously have a lambda value that is different from interior pixels
nh_: by what seems like a non-continuous function
osiris_: I've been trying to make stuffed textures work for 2 days without a luck. whole primitive (line in my case) is covered with last texture pixel. it's like both line vertexes gets tex coords=1.0 instead of first getting 0.0 and second 1.0
osiris_: I'm out of ideas
osiris_: here's current code: http://rafb.net/p/0AK8m246.html
osiris_: glisse, nh_ ?
nh_: osiris_: have you tried outputting the texture coordinate as the fragment.color?
nh_: to double check whether the correct coordinates arrive at the pixel shader?
nh_: basically, don't do any texturing at all, just write the texture coordinate into the output color register
osiris_: nh_: how do I do that? remove TEX inst from frag prog?
nh_: osiris_: write a fragment program that only contains a single instruction: MOV result.color, vertex.texcoord[i];
nh_: where vertex.texcoord[i]; is the texture coordinate where the line texcoord is expected
nh_: if texcoord goes from 0.0 to 1.0, you should see some kind of gradient from black to red or from black to grey or something
xAFFE: Hi folks, I'm trying to get the radeon driver up und running with DRI, but I fail miserable. When X starts I have the following in my Xorg.0.log: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
xAFFE: [dri] radeon.o kernel module version is 8.49.7 but version 1.17.0 or newer is needed.
nh_: xAFFE: and... ?
xAFFE: I dont know where this version 8.49.7 comes from (maybe the binary driver) and how to not compile it against this version of libdri
xAFFE: [dri] radeon.o kernel module version is 8.49.7 but version 1.17.0 or newer is needed. <<--- did this message hit the channel?
nh_: interesting
nh_: lsmod should show a module radeon, no module fglrx, and dmesg should contain a line like "[drm] Initialized radeon
nh_: if that's not the case, you need to update your drm (i.e. the kernel module)
xAFFE: aah, ok, thats a good pointer, didnt knew that
bridgman: yeah, that definitely looks like a leftover fglrx kernel module
osiris_: nh_: vertex.texcoord is by default 1 at pixel stack?
glisse: osiris_: we talk about vector
glisse: osiris_: another easy way to test if kil work is to feed a constant to frag prog
osiris_: glisse: so can I put texture coords on pixel stack?
nh_: okay... where did bridgman come from?
glisse: R300_ALU_DSTC_OUTPUT_Z this appear bogus
nh_: and how did he know about what xAFFE wrote?
glisse: nh_: they secretly monitoring channel ;)
glisse: osiris_: yes you can put text cord on pixel stack but its easier to sned a constant
nh_: glisse: the point is to test whether the texcoord stuffing is working correctly
osiris_: how do I do that?
glisse: nh_: i think we don't even know if texture is working so i would test texture first :)
osiris_: glisse: texture is working, because I get color of last texture pixel
glisse: oh didn't notice
nh_: one important question that I didn't think of before: does the texcoord stuffing happen before or after vertex program?
glisse: osiris_: also i think you don't program properly gb_enabl
glisse: nh_: i think it's after
nh_: if it happens before vertex program, then the vertex program needs to contain ALU operations that forward the texcoord
nh_: okay
osiris_: nh_: I have rs690 chip (no vertex shaders)
glisse: nh_: it says top of raster pipe
nh_: glisse: yes, I think you're right
glisse: osiris_: you need to set bit 16 of gb enable
glisse: otherwise texture coordinate is not stuffed
glisse: also you only need one temp in your program
TobiasTheCommie: just wondering, are there any of the current ati cards that have the avivo and drm in seperate chips(so avivo can be implemented)?
glisse: temp=pixelstack
glisse: TobiasTheCommie: it seems there is a missunderstading their
glisse: drm is a software
TobiasTheCommie: glisse: i meant the digital right manegement implemented on, for instance, the rv530 card
glisse: avivo is a marketing name of a silicum part of ati
osiris_: glisse: now I get red line. and I think it should be black->red gradient
glisse: TobiasTheCommie: oh
glisse: osiris_: what kind of texture you set ?
TobiasTheCommie: glisse: and that drm is in the same chip as avivo, which means ati can't release the specs for that avivo chips(haven't got the rights to release the drm bits iirc)
glisse: TobiasTheCommie: drm is in the chip
TobiasTheCommie: wtf "that avivo chips", ok sorry bout that.
glisse: no other way to do drm
nh_: osiris_: so now we know that the problem is with the texcoord stuffing and not with the texture itself, right?
osiris_: nh_: yeap
nh_: osiris_: did you make the gb enable changes glisse suggested?
osiris_: glisse: texture is set to black -> white gradient
osiris_: nh_: yeap
glisse: nh_: well it depend of the texture, stipple texture should be simple
TobiasTheCommie: glisse: but i'm fairly certain that some of ati's newer cards(not sure if they have reached production yet) would have the avivo and drm seperated, so the specs for avivo could be released.. which would give linux hardware h.264 decryption support
TobiasTheCommie: and mpeg 4
glisse: TobiasTheCommie: it still be on same silicium but i guess the drm register are well separated from other func
TobiasTheCommie: that is how i understand it... i just don't know if there are any current boards out where the avivo specs has been(or will be) released
glisse: osiris_: okay i see your texture
glisse: osiris_: the problem might texture coordinate scaling
nh_: MostAwesomeDude: anisotropic filtering has an effect on r3xx :)
nh_: of course, I don't really know whether it's exactly the way it's supposed to be, but it looks better than without it
osiris_: ga_line_stipple_config.stipple_scale value has effect on output fragment color (so possibly on texture coords)
dmb: glisse: so far, no lock ups
glisse: dmb: even with the lockup prone screensaver ?
dmb: yup, but i don't know if that was 100% reproducable
dmb: i'll try google earth
dmb: google earth has hard locked me a couple times
osiris_: oh, my bad. it has now effect
nh_: oh ffs
nh_: there's a race somewhere
dmb: glisse: so far so good
nh_: glean/texCube fails in reflection mode, but it doesn't fail if I add a sleep(1); into the rendering loop
osiris_: if I debug using fprint to stderr is it possible that debug messages will be in messed up order?
glisse: osiris_: they shouldn't
osiris_: glisse: so mesa is invoking some functions in parallel
osiris_: or something else weard is happening for me
osiris_: *weird
xAFFE: hi guys, loading the radeonmodule made everything work, now xv and composite works verynicely :)
xAFFE: thank you very much :)
dmb: glisse: i say merge it :D
dmb: didn't cause any side effects that I am awware of
glisse: dmb: well it's does fix all lockup on r300
dmb: i haven't noticed any lockups yet
glisse: if one happen it will be a hard one
glisse: this patch fix softlockup
dmb: oh
dmb: what exactly is softlockup?
dmb: is that when maybe the mouse works, but i can't use keyboard, crtl-alt-backspace etc?
glisse: when gpu is busy doing something and the kernel wait in loop for the gpu to end
glisse: yup when mouse mose
glisse: when you can move mouse
osiris_: bridgman: can you find out how stuffed textures works?
glisse: osiris_: well we have information we are just bad at using it :)
glisse: osiris_: did you draw a long enough line ?
osiris_: glisse: yeah, I think so. gradient in demo with same line length and texture size is visible
glisse: osiris_: did you corrected point i stressed ?
glisse: gb_enable ....
glisse: if can you upload lastest patch i will look over it more carfully
glisse: funny i filled my hd with r300 log
glisse: 18Go of log
osiris_: glisse: yea, I did
osiris_: glisse: without it, nothing shows up on MOV result.color, tex.coord frag prog
glisse: osiris_: so it help to actualy route something :)
osiris_: yeah, but it looks like it sets 1.0 texcoord for both line vertices
glisse: osiris_: okay maybe we need to ask for proper routing
glisse: can you try to set a vertex program in your gl line test and write 0.5, 0.5... to first texture coordinate output ?
glisse: write somethings to color too
glisse: like 0.25
osiris_: glisse: or maybe it's just my card (rs690) that doesn't support stuffed textures
glisse: osiris_: no it should same 3d engine
osiris_: rs690 is nontcl chip, so I can't
glisse: gpu hate me i found hardlockup reason....
glisse: well at leat no hardlockup in a lot longer period then i ever reach
agd5f: TobiasTheCommie: we should be able to open up the video stuff on r1xx-r6xx. it's just the UVD block that may have issues with drm hw. we may be able to release that too, but haven't had a chance to review it yet
TobiasTheCommie: ah, oki.
TobiasTheCommie: actually, i meant the UVD block, thought the UVD block was avivo
TobiasTheCommie: thanks :)
bridgman: nh_: no secret monitoring, I just try to check the logs every so often to see
bridgman: if there's anything going on we can either help with or I should learn from ;)
bridgman: I'm on dialup so most of my IRC time is "drive-by"; connect, skim logs,
glisse: z3ro: for lockup free remove r300_pacify on top of my branch and your card should not lockup anymore
bridgman: onto IRC, hangup
bridgman: then go do something else
glisse: bridgman: hey, i allmost beat to death lockup
bridgman: congratulations; that sounds really good
glisse: at least i can't trigger them here with my lockup prone card :)
bridgman: that will make for many happy developers (and users)
bridgman: maybe I can find you a more lockup-prone card ;)
bridgman: seriously, we have tried to dig up this info but it's not like anyone
glisse: bridgman: i am sure you can ask your engi to remove some key part so that it easly lockup and then send it to me ;)
bridgman: knows "do this to stop lockups", it's just years of accumulated experience
bridgman: scattered through the driver source
bridgman: glisse; I'll ask ;()
bridgman: s/()/)/
glisse: bridgman: well i need some more info on why fglrx purge cache every now and then
glisse: i need to remove this on top of my patch to avoid hard lockup
glisse: otherwise i hardlockup once in while
bridgman: ok, shoot me some specifics (card, frequency, how the purge is done) amd O
bridgman: fingers in wrong place on keyboard, trying again
bridgman: shoot me some specifics (card, frequency, details of purge) and I'll find out
glisse: bridgman: well we purge each time we get command from userspace
bridgman: is it easy to see which component is running when the purge happens ?
glisse: bridgman: like only red color ?
bridgman: oh... (scratches head) really ?
bridgman: glisse: yeah;)
bridgman: failing that, whether ogl or 2d acceleration or...
glisse: bridgman: well now when there is the purge the lockup happen a bit after purge i think
glisse: s/now/no
glisse: but i can be sure as hardlockup give you no way to debug them
bridgman: ok, that is interesting; so you're seeing lockups during operation on fglrx ?
glisse: no on radeon
glisse: but we added the purge rb3d & zcache
glisse: because we were seing them done by fglrx
bridgman: ahh, trying to duplicate same as fglrx purge ?
bridgman: got it
glisse: it just seems that we don't do them at the same time fglrx does
bridgman: or you're not waiting as long as fglrx for the purge to finish ?
glisse: so i wanted to know in which state we should do them
glisse: oh you have to wait after purge ?
glisse: :)
bridgman: patience, grasshopper
glisse: we are not waiting at all :)
bridgman: honestly, I don't know -- I just got the sense that waiting was required from
bridgman: reading through the docs
bridgman: but I think I have enough to ask questions now
glisse: bridgman: well i htink the question is what to wait or when to do purge and do we need to wait after a purge :)
bridgman: yep, that shoudl be sufficiently specific for me to get answers
bridgman: gotta ring off now, drive into city to pick up my car from service
bridgman: bbl
glisse: agd5f, z3ro: pushed my local free on fdo just grab radeon-lockup-free and test
glisse: the patch is ugly a lot of debugging every where as well as many udelay scattered around so that i can see printk :)
agd5f: glisse: still need to remove r300_pacify?
ghepeu: glisse, I tested your branch with the only lockup I can reliably trigger on my rv370
ghepeu: and now the machine lock for 2-3 seconds, then reboots
glisse: ghepeu: nice to know :)
glisse: ghepeu: with lastest commit ?
ghepeu: let me check
glisse: agd5f: no i pushed this change
glisse: ghepeu: commit from 10min ago
ghepeu: no
ghepeu: my pc was rebooting 10 minutes ago
glisse: ghepeu: this new commit might make the difference:)
ghepeu: ok, let me test it
ghepeu: oh, in the last week I'm always reverting an old commit by z3ro that could cause problems but nobody was sure of it
ghepeu: *weeks
ghepeu: could it be important?
glisse: ghepeu: maybe, maybe not
glisse: if you got commit id i can take a look
ghepeu: yeah, looking for it in git log
ghepeu: 31815730732a5d2a446aa316a5b4d837766762e6
ghepeu: r300: Added the CP maximum fetch size and ring rptr update variables.
nh_: is it possible to invalidate caches in userspace?
glisse: nh_: cpu cache you mean ?
nh_: yes
glisse: not on amd cpu
nh_: bleh
nh_: okay, I'll try something else then :)
glisse: and on intel i think there is things but you should not rely on them
glisse: well uncached memory seems to be the only solution
glisse: ghepeu: well try with & without Oliver patch but i think his patch is good
ghepeu: the lockup happens with and without that commit so I'll keep it for now
glisse: ok just keep me posted if my branch help or not
glisse: i might be lucky and only have fixed it for my card
glisse: ghepeu: note that things my become slow as hell but you should still be able to quit the faulty program
davi: Is already there a radeon 3D free software driver?
glisse: in lockup case my patch keep reseting the gpu and reseting gpu hundre times per second make things go slowly :)
glisse: davi: yup
glisse: up to r5xx
davi: URI?
glisse: cgit.freedesktop.org mesa
davi: thanks glisse
glisse: www.mesa3d.org
davi: What license is it using?
glisse: a modified bsd license
davi: cool
glisse: but there is a lot of linux|bsd specific code
davi: I could say _too much_ cool
ghepeu: ok, module in place. now I need to wait for a download to end
davi: GPL version 3 could be better. Anyway, as it is BSD like anyone can relicense it
nh_: okay, I'm 99% certain that the bug I'm seeing is because the CPU has cache entries for the framebuffer that are outdated
nh_: I want to clear those cache entries from radeonSpanRenderStart
nh_: glisse: do you know what the best approach would be? I guess some kind of cache flush in kernel territory, but it's been a long time since I've looked there
ghepeu: ok, restarting X...
glisse: nh_: iirc the instruction on intel is called cliflush
davi: What hardware do you advice to buy?
glisse: for cache line flush
glisse: davi: well depend on your usage but r5xx are pretty cheap nowaday (r5xx is x1300 to x1950
nh_: isn't there some kind of Linux kernel define I can use?
davi: thanks glisse
glisse: see wikipedia for commercial to product name link
davi: thanks
glisse: nh_: it's clflush
glisse: i don't think there is any kernel things
glisse: nh_: but this sounds strange as if you access fb it should be mapped as wc
glisse: so you should not see cache issue
nh_: hmm
nh_: maybe you have an alternate explanation
nh_: this test program basically does
glisse: a look at your mtrr and at the fb address should tell it you for sure
nh_: loop(...) { render_something(); glReadPixels(...); }
nh_: and without some kind of sleep, the readpixels returns incorrect data on subsequent iterations *unless* I modify the code such that the code does not always overwrite and read from the same area of the framebuffer
glisse: nh_: well as present day i would not rely on any kind of synchronisation btw gpu and cpu
nh_: cat /proc/mtrr says write-combining
glisse: it's like that gpu keep writting new stuff while cpu read things
nh_: but doesn't this mean that the CPU keeps copies of what it read as cache?
nh_: glisse: well, radeon_span.c is supposed to ensure the GPU is idle and flushed its caches
glisse: no, wc means that whenever there is writte cpu buffer few writte and do the write in batch
glisse: nh_: i have very little trust in that aspect of the code :)
nh_: yes, my point is: a wc mapping still has a cache
glisse: but it's long time i have take a look at this part
nh_: glisse: me neither; that's why I want to fix it ;)
nh_: and this CPU cache contains stale entries; and once I know that the GPU has become idle, I want to free those stale entries
nh_: so it's not so much a flush as an invalidate of the cache that I'm looking for
glisse: in your look you not only read pixel from cpu you also write to it ?
glisse: s/look/loop
glisse: i am tired
nh_: the CPU reads pixels via ReadPixels, but it does not write directly via WritePixels, it just renders via the normal 3d operations
glisse: it render pixel by pixel ?
nh_: it renders quads
nh_: it's the glean/texCube test, to be precise
nh_: anyway, I'm just going to dive into kernel stuff, and see if I can somehow convince it to invalidate the CPU cache
glisse: nh_: try starting from clflush but i don't think there is much stuff on that
glisse: it looks like cpu aremoving toward a scheme where you can't ask for explicit flush of a cache line
nh_: shame
ghepeu: glisse, no luck. Reboot even with your latest commit
glisse: ghepeu: is it agp ?
ghepeu: also, I had a lockup also when I launched glxgears while running compiz
ghepeu: no, PCIe
ghepeu: rv370, X550
glisse: ghepeu: strange i am doing this test on a x550 too
glisse: ghepeu: cpu/motherboard ?
ghepeu: what I did:
ghepeu: close X, rmmod drm radeon, modprobe drm radeon, restart X, launch compiz, glxgears, lockup
ghepeu: then when I rebooted glxgears worked
ghepeu: so I tested celestia but it locked and the machine rebooted
ghepeu: athlon64 3500+, abit kn9 (nvidia nforce 4)
ghepeu: I was checking the logs
ghepeu: for the first lockup (the one with glxgears) I see only
ghepeu: Jun 7 17:48:25 KazeNoTani [drm] FIFO wait *************************************
ghepeu: Jun 7 17:48:25 KazeNoTani [drm] FIFO wait end ---------------------------------
ghepeu: Jun 7 17:48:25 KazeNoTani [drm] IDLE wait *************************************
ghepeu: Jun 7 17:48:25 KazeNoTani [drm] IDLE wait end ---------------------------------
ghepeu: Jun 7 17:48:25 KazeNoTani [drm] 529 wait for idle success 0
ghepeu: repeated
glisse: well this means no usefull log :)
ghepeu: the same for the second lockup
glisse: ghepeu: glxgears work here but i am able to lockup with celestia and compiz if i resize celestia window quickly
ghepeu: I can reliably trigger a lockup by choosing "Go to object ..." in the "Navigation menu"
ghepeu: when the dialog appears, the machine locks (and reboots, with your tree, or stays locked with kernel drm)
glisse: ghepeu: having use case help a lot to fjx these kind of issues
ghepeu: I agree
ghepeu: I experienced random lockups with compiz last months, and all I can say it's that maybe (a huge maybe) they're due to something between mesa 7.0.3 rc2 and mesa 7.0.3
ghepeu: maybe
osiris_: glisse: I just run glean test and it soft locked. will try your lockfree branch and see if it helps
ghepeu: glisse, by the way, your branch fixed another lockup I could trigger with git drm, at least until may 15
nh_: glisse: adding a wbinvd() to radeon_cp_idle() fixes the bug I'm seeing...
nh_: of course, if I understand wbinvd() correctly, it's like fighting a cockroach infestation with nuclear weapons
nh_: (maybe not the best picture, since cockroaches are supposed to survive nuclear winter, but oh well)
ghepeu: nh_, I doubt that they could survive a direct hit by a nuclear bomb
nh_: true :)
nh_: the fact remains, one wbinvd() per radeon_cp_idle is complete overkill
glisse: ghepeu: how do you trigger nav menu ?
ghepeu: the navigation menu is on the top of the window.
ghepeu: i can trigger the bug just by clicking on the "Go to object..." entry
MostAwesomeDude: Morning.
MostAwesomeDude: nh_: Yeah, I was thinking something along those lines for the aniso powers.
glisse: ghepeu: i pushed another kind of approach
glisse: ghepeu: keep me posted once you got time to test it :)
glisse: ghepeu: note that this ine seems to slow rendering quite a bit
nh_: glisse: / MostAwesomeDude: does glean/texCube pass for you w/ latest git?
glisse: nh_: i got to run will test it tomorrow
nh_: glisse: thanks
MostAwesomeDude: nh_: glean/texCube fails.
xAFFE: hi folks, I have a new problem, I cant control the backlight anymore, xbacklight doesnt seems to work and the hardware switches also dont work, I'm have a thinkpad z61m with a x1400, anyone an idea what could fail this one?
MostAwesomeDude: xAFFE: I'm not too sure on the subject. Does radeontool help?
nh_: MostAwesomeDude: which part? The REFLECTION_MAP part?
MostAwesomeDude: nh_: Not sure; lemme look at the results.
MostAwesomeDude: Still not very familiar with piglit yet.
xAFFE: MostAwesomeDude, nope, doesnt do the job, besides it doesent work, as it apears to me, you can only switch it off and on with radeontool and not the brightness as I want it.
MostAwesomeDude: xAFFE: Oh, you want brightness.
MostAwesomeDude: Um, do you have the ACPI modules for Thinkpads?
MostAwesomeDude: There should also be a generic control in /proc/acpi/video/*/brightness, I think.
MostAwesomeDude: Or something along those lines.
MostAwesomeDude: Whoohoo, that was fun.
MostAwesomeDude: Note to self: Anisotropy should not be forced to 16.0 if running Compiz.
nh_: MostAwesomeDude: why?
nh_: MostAwesomeDude: the texCube failure mode is the same as on my system; I wrote an email to dri-devel about it, I really don't understand the problem we're getting there
MostAwesomeDude: nh_: Anisotropy requires massive amounts of RAM; each increase in level requires a doubled amount of RAM IIRC.
MostAwesomeDude: And I was just testing some more code.
MostAwesomeDude: Unbroke the driconf for forcing anisotropy.
MostAwesomeDude: That is, if the app doesn't specify.
MostAwesomeDude: So now compiz is truly pretty.
nh_: MostAwesomeDude: that's odd; as far as the driver is concerned, AF textures should have the exact same memory layout as other textures
MostAwesomeDude: Of course, it would be nice if they would reapply the beryl patches to the cube.
MostAwesomeDude: nh_: It's not a driver-side thing, I think it's just asking the GPU to do too much.
MostAwesomeDude: ...I suppose I should debug this?
nh_: oh, you mean it's something in Compiz
nh_: btw, I committed a number of changes to depth/stencil handling to fix a number of bugs exposed by piglit
nh_: they're all in parts that should work equally well for r3xx and r5xx, but I can only test on r3xx
nh_: MostAwesomeDude: I don't understand your latest commit
glisse: nh_: so your fb is mapped wc ?
glisse: nh_: isn't there any aliasing on mapping policy somewhere on your configuration ?
glisse: oups
glisse: netsplit :(
glisse: nh_: isn't there any aliasing on mapping policy somewhere on your configuration ?
glisse: nh_: and what is your kernel version btw ? iirc i saw a bug about mapping policy that was solved recently
glisse: cache is a nightmare :)
nh_: glisse: kernel is ubuntu's 2.6.24; and how would I find such an aliasing?
nh_: btw, MostAwesomeDude has the same failure mode in glean/texCube
MostAwesomeDude: nh_: You can anisotropically filter a texture that has no mipmaps, although I don't know exactly how effective it is. Also we want to force the aniso on if it's set in driconf, and I couldn't think of a more correct way.
nh_: MostAwesomeDude: okay.
MostAwesomeDude: I might just change driconf instead so we have an option "Force anisotropy" like the Windows nv/ati drivers do.
nh_: though maybe we shouldn't set MIP_LINEAR in this case
nh_: and I still don't understand where your patch interacts with driconf
nh_: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=21f50818b09c1ab3b5b1dc797b34c23b9b1634dc
nh_: I just don't get what this has to do with driconf
MostAwesomeDude: nh_: MaxAnisotropy is set from the driconf value, but it won't be respected if it's set before the texture filters.
MostAwesomeDude: I'll just rewrite it so we have another driconf value, I guess.
glisse: nh_: might be worse trying with 2.6.26-rc5
glisse: nh_: i think airlied fixed somethings recently
glisse: but i can't find back what it was
glisse: airlied: btw i was wondering if for the vblank stuff we could use dma write to register
glisse: i believe no one in the opensource ever tested this path
glisse: maybe it can properly coexist with cp
surfer: i have a weird bug with my desktop icons
surfer: sometimes my blue icons turn half black half blue
GerbilSoft: gah, now that OOo transitions are working, i have to make a choice
GerbilSoft: - stick with openoffice-bin, which doesn't have 3D transitions, but has other nice stuff
GerbilSoft: - downgrade to openoffice-2.4.0, which has 3D transitions but lacks the extra nice stuff :(
GerbilSoft: - or wait for openoffice-3.0.0
PSYCHO___: GerbilSoft: i was talking bout servers
GerbilSoft: i knowwww
PSYCHO___: okok
GerbilSoft: ...wtf how'd that w repeat itself
PSYCHO___: GerbilSoft: i write stuff in tex and use gnuplot. but on win machine i have beta of ooo and it works quite reasonable
GerbilSoft: ok
GerbilSoft: what i was talking about was the 3D slide transitions in impress - right now you can only get it by compiling from source
GerbilSoft: gentoo doesn't have an openoffice 3.0-beta1 source ebuild yet
PSYCHO___: openoffice is crazy stuff
PSYCHO___: wait while i;ll look on ebuild
GerbilSoft: beta2 should be released july 1, and final eptember 2
GerbilSoft: *september 2
PSYCHO___: it is really crazy stuff too much java and gtk on my opinion :]
PSYCHO___: and on forum there is way to instal rpm
GerbilSoft: that's the binary version
PSYCHO___: yep
GerbilSoft: they haven't enabled 3D transitions in the binary version for some reason
PSYCHO___: oh
PSYCHO___: on ooo i hate that i cannot access its inner functions from comand line, specialy doc->pdf function
airlied: damn no nh..
airlied: I'm sure hes just seeing GPU cache flush effects.
airlied: the wbinvd is only delaying things on the CPU side longer
glisse: airlied: did you ever tested dma for writting to register ?
glisse: airlied: i think we could implement vblank blit using that
airlied: glisse: oh sounds bad as well :), doing anything when the CP is rnuning == bad.
airlied: as they both could git the same regs
glisse: airlied: in dma you can ask cp to hold until dma is done
glisse: so dma can preempt cp
airlied: glisse: but what happens if CP was in the middle of a lbit?
airlied: we hand program the blit with packet0s now.
glisse: airlied: of course in this scheme we need to make everyblit go through dma :)
airlied: so it could be 2 packet0s in and then DMA..
glisse: when vblank happen you suspend unvblank blit and fire vblank blit
glisse: airlied: no need to touch cp to launch dma
glisse: you can directly launch it through mmio (one reg to write)
airlied: glisse: true that might be workable..
glisse: i think writting one reg should be safe
glisse: as long as we forbid it in the cp stream
airlied: we still don't know if DMA goes via GART, or if we need a new special page.
glisse: from my reading dma use the card virtual memory address space
glisse: so if there is a gart it will go through gart
airlied: glisse: I wonder did benh dma code do any of thart.
glisse: can't remembe
glisse: can't remember
airlied: http://gate.crashing.org/~benh/radeon-sgdma-xorg.diff
airlied: http://gate.crashing.org/~benh/radeon-sgdma-drm.diff
glisse: according to benh patch dma use phys page address
airlied: glisse: well outside the gart is padd through.
airlied: pass through.
glisse: well a quick hack would tell us
glisse: i should stop talking about quicj hack as i never experience any hack which was done in short period of time ;)
glisse: anyway this is just another possible path for vblank that might be worht trying
glisse: btw i looked at r600 shader and the beast is becoming like a cpu :)
mcgreg: btw I got wow+google earth working quite finer here.. just a questionb.. is that still normal that X crashes after a while I use 3d? it totally dies and I have to reboot (by pressing hardware-reset)
glisse: mcgreg: i have a branch named radeon-lockup-free which you might want to try
glisse: i am testing several solution in it
mcgreg: well, I just wanted to know if that "normal" or perhaps some hardware-related problem
glisse: mcgreg: well it's not normal it's boggus
glisse: mcgreg: and having people testing solution is a good way toward fixing this
glisse: i am advertizing my branch ;)
mcgreg: well.. I mena, does it happen for other ppl too? sometimes I believe my hardware is somehow broken, as I get strange errors from kernel sometimes :/
glisse: it happens to other people too
airlied: glisse: if it doesn't make thnigs worse you should merge it :)
glisse: and when such things happen your hw enter a dimension where logic as no sense :)
glisse: airlied: well i think my lastest version should fix them all at the cost of a hard slow down of the whole performance
glisse: airlied: according to John we should wait after we purge cache
glisse: adding this wait seems to have fixed the lockup ghepeu was pointing too, at least it seems i can't reproduce it anymore with this patch
airlied: glisse: seems like nh's problem..
glisse: might be related
glisse: funny how things meet :)
mcgreg: maxbe you could have a short look if you have seen anything like this before .. I totally have no idea whats wrong and where to look about it : http://rafb.net/p/QRNmTC17.html
glisse: anyway if a wait after a purge is the solution then we need to be more clever about purge and not do such things to often
airlied: glisse: hopefully brigdeman can find out what fglrx does.
glisse: mcgreg: yoour ahci is having trouble for some reason
glisse: maybe your hard drive is dying
glisse: airlied: yup hopefully they can dig out when purge should happen :)
airlied: glisse: you know what a PM4 redirect packet is?
airlied: "Any DMA from CP to system memory while 2D engine is busy can cause a hang"
glisse: airlied: well we should do dma only the other way around :)
glisse: ie dma from memory to register
glisse: then 2d is activated and do the blit
airlied: bridgeman: whats a PM4 redirect packet...
airlied: glisse: you know what a PM4 redirect packet is?Some asics (such as R520) require the ISYNC_CNTL be programmed through the pm4 stream
airlied: oops..
glisse: airlied: where is there a reference to this ?
airlied: glisse: I'm reading tcore :)
airlied: the problem is the code it has is commented out :)
airlied: so obviously doesn't work either.e
glisse: airlied: well starting from r5xx you can program isync and few other reg only through pm4 packet
glisse: ie through cp
glisse: given that my patcheds seemed to solve a lockup for one r5xx user i would say that normal packet should work
glisse: there is likely left over of initial hw design in tcore
airlied: glisse: I wonder do we need to use DC_FINISH
airlied: glisse: and block the CP waiting for it
glisse: well using dc finish should permit to avoid using wait_until 3didleclean
airlied: glisse: well the tcore code has two paths :)
glisse: not sure this would be any better from performance point of view
airlied: wait until path, and dc finish path, the dc finish path is commented out.
airlied: with some mention of rv410..
glisse: so dcfinish likely doesn't work that reliably :)
airlied: glisse: what does fglrx do?
glisse: airlied: from memory fglrx didn't explicitly wait right after the flush but stuffed some more register write and likely then waited
glisse: but i don't have dump of this anymore
glisse: nouveau is so more well organize then radeon :)
airlied: glisse: surely a revenge dump would have it in the ib/rb
glisse: yup but here i don't have a r300, well i do but its a ppc and i am working on my thesis so i would rather not enable dri :)
airlied: with some mention of rv410..
airlied: damn mouse
airlied: http://people.freedesktop.org/~z3ro/revenge/
airlied: I think 5b63 is r300
glisse: oh didn't know about this archive :)
glisse: airlied: seems that fglrx wait for idle
glisse: but not for idleclean
airlied: glisse: what do they set ISYNC_CNTL to?
glisse: they don't use isync :)
glisse: they don't submit broken cmd stream neither ;)
glisse: and they don't purge the cache
glisse: just flush it
airlied: hmm they also do some host flushing in tcore.
airlied: something I don't kknow we ever do.
airlied: that might be nh's problem either.
glisse: airlied: also fglrx use dcfinish
mcgreg: good luck guys, off to bed :)
glisse: airlied: okay when they purge they do wiat3didleclean
glisse: when they flush they do wait3didle
glisse: but it seems they don't purge often
glisse: i see a lot of flush but not many purge i had to browse few dump before finding one
glisse: z3ro: nice work with revenge :)
glisse: also when they purge cache they purge all cache, z, 3d, texture
airlied: glisse: so where do they use dcfinish?
glisse: in all flush case
glisse: when they flush they use dcfinish
glisse: when they purge they use wait_until
airlied: so I see in tcore they have WAIT_HOST_IDLECLEAN
airlied: to flush cached host writes to VRAM.
glisse: airlied: also they don't always use dcfinish
airlied: how does sending a singal to the CP work?
airlied: do you hve to tell the CP ot wait for it?
glisse: i don't see WAIT_HOST_IDLECLEAN in dump
airlied: glisse: maybe fglrx don't use it.. just tcore..
glisse: hhhmm i don't see how dcfinish work...
glisse: airlied: ok it's section 4.9
glisse: they use dcfinish when they want to advertize somethings is done
glisse: they are using that as a sync checkpoint
glisse: so cp is not stall
glisse: it's just the CP_RESYNC things that gets unstalled
airlied: glisse: they write to scratch regs.
glisse: i see writte to those one in dump
airlied: it might be the driver does something..
glisse: airlied: yup it's likely what we will use as fence mecanism
glisse: at least it sounds like what we should use :)
glisse: airlied: when 2.6.26 release is planned ?
glisse: end of month ?
glisse: sooner ?
airlied: glisse: planned hehe :), probably end of month or so.
glisse: is trying to stick to its own timetable... ;)
glisse: airlied: i will cleanup my patch and push to master to have more tester then i think if it bring good feedback it should be pushed into 26 as bugfix :)
airlied: glisse: yeah it might be a good idea :)
airlied: I'll see if I can get it into Fedora first..
glisse: well don't take my branch there is lot of useless code in it of unsuccessfull attempt
glisse: just take the isync protection of waituntil and also the waituntil idleclean after purge
glisse: but i think we should transform purge into flush and see if it gives any bad outcome
glisse: anyway bed time :)
glisse: zzzZZZzz if i got time to clean it up tomorrow you should see a merge to master
dmb: heya
dmb: morfic, hey, what is anistropic filtering?
revx: dmb: a way to sharpen textures rendered at angles
dmb: oops, forget that i said morfic, accidental tab completion
dmb: oh
dmb: glisse, any more improvments?
dmb: whats the wait for idle after flush?
z3ro: airlied: did tcore get released? or you just got an early preview?
z3ro: I didn't see it online anywhere.
dmb: z3ro, probably a NDS release
dmb: i know some radeonhd developers got to see it with a NDA
sima: HI How do i repair my package base? I get error: subprocess post-removal script returned error exit status 2 (i am trying to remove xorg-driver-fglrx)
dli: sima, /j #ati
sima: ok, i am on it
surfer: how do i turn on aniso filtering?
surfer: is it a drirc option?
Nyle: hi
surfer: nevermind, figured ito ut
agd5f: surfer: It's a GL extension
GerbilSoft: bah i've decided to downgrade to ooo 2.4
GerbilSoft: since the 3D transitions have been fixed
GerbilSoft: taking forever to compile :(
surfer: i installed 'driconf' and figured it out, but thanx
surfer: [18603.244323] X[26185]: segfault at 8d ip a6d8c30d sp bfe1dd90 error 4 in r300_dri.so[a6ccb000+220000]
surfer: that's never good
agd5f: airlied: before you push the r5xx drm bits upstream, we may want to check and make sure we add ranges for the heirz stuff if it's not already there
umtc: has there been any progress on implementing the tv_vertical_size adjustment?
umtc: is there a homepage for the driver?
dmb: airlied, theres more r5xx stuff coming?