Radeon IRC Logs For 2008-5-22

MostAwesomeDude: Huh, wow.
MostAwesomeDude: Okay, so ignore everything I said earlier about hardware trig, and also I can’t start X without AIGLX.
airlied: oh yeah you neeed a glcore installed..
airlied: and consider your trig ignored 🙂
MostAwesomeDude: airlied: And I have no idea how to build one.
airlied: MostAwesomeDude: make glcore in mesa
MostAwesomeDude: airlied: You probably know why kids like cinammon toast crunch, too.
MostAwesomeDude: :3
eboettcher: oh boy
MostAwesomeDude: eboettcher: ?
eboettcher: good way to kill boxen: start 16 mplayer processing each using a different textured video overlay
MostAwesomeDude: eboettcher: …I’ll take your word for it.
eboettcher: erm
eboettcher: I think the machine died
eboettcher: it needed a reboot anyways 😛
MostAwesomeDude: I’d make an extended joke about domestic CPU abuse (“Only you can prevent it! The more you know…”) but I’ve almost got LRP.
eboettcher: LRP?
MostAwesomeDude: eboettcher: Linear interpolation inst.
MostAwesomeDude: Whoohoo, got it. Lemme clean up and push.
eboettcher: well
eboettcher: when I don’t use 1080p streams that works just fine 🙂
eboettcher: all 16 textured xv overlays in use at once
eboettcher: (without a compositing window manager..)
MostAwesomeDude: eboettcher: Speaking of which, tried compiz yet?
eboettcher: yep
MostAwesomeDude: Pretty cool, am I right?
eboettcher: indeed
eboettcher: crap, one died
MostAwesomeDude: airlied: Pushed. You now have POW and LRP, whatever they were for.
airlied: MostAwesomeDude: oh nice will grab laptop.
eboettcher: so I have a crash with overlay
eboettcher: and a problem when more than one client asks for the same textured video port
MostAwesomeDude: eboettcher: When a client requests an XV port in use, shouldn’t XV reject its request, resulting in XV init failing?
eboettcher: well it’s not happening
MostAwesomeDude: airlied: I can’t remember what LRP was for. My kdm log doesn’t show compiz using it.
eboettcher: instead the other program is dying in the thread that swaps buffers
eboettcher: (the first one that had the port)
MostAwesomeDude: Hmm.
airlied: MostAwesomeDude: I’ve seen it for compiz 🙂
MostAwesomeDude: airlied: Alright. Well, I’ll test it and see. Maybe this fixes Alt-Tab glitchies?
eboettcher: started with 16, started compiz and down to 12 left running correctly
MostAwesomeDude: XD
MostAwesomeDude: Be right back, enabling Composite, etc.
MostAwesomeDude: airlied: My Alt-Tab works fine now.
airlied: MostAwesomeDude: cool.. googleearth fails.
airlied: I don’t think I have the wrong drm..
airlied: I’m getting a drm failure.
MostAwesomeDude: airlied: Hmm.
MostAwesomeDude: Well, there’s literally nothing in my recent changes that messes with DRM.
MostAwesomeDude: How’s your compiz?
airlied: didn’t try yet.
MostAwesomeDude: Fonts are a tiny bit on the blurry side; is that just because of the different rendering path?
MrCooper: possibly, if it ends up using some kind of filtering
MrCooper: I think I had that at some point if I enabled ‘best’ texture quality
MostAwesomeDude: MrCooper: I don’t know.
MostAwesomeDude: All I know for sure is that it’s awesome.
MostAwesomeDude: I can’t believe how much I missed the power of compiz.
mcgreg: haha you’re addicted to eyecandy 😉
eboettcher: is there a quick way to find out what pid owns say window 0x2200001?
airlied: hmm we appear to have some sort of failure in the fp submission..
airlied: I’m miscounting something somewhere.
MostAwesomeDude: airlied: For Google Earth?
airlied: MostAwesomeDude: yup..
airlied: the kernel rejects the command packet..
MostAwesomeDude: Well, it’s only for certain FPs, right? Perhaps I miscounted in POW?
airlied: I don’t think you can.
airlied: I think I wrote the submit code 🙂
MostAwesomeDude: airlied: Fair enough. I just checked, and POW’s not wrong, and neither is LRP.
airlied: hmm how many instructions can we take?
airlied: the progam appears to be 33 instructions long when it fails 🙂
airlied: ah I only resever 128 spots.
MostAwesomeDude: airlied: It’s 128 temps and 256 consts, IIRC.
airlied: okay not craashing.
airlied: just looks like ass still.
MostAwesomeDude: airlied: googleearth?
eboettcher: …
airlied: someone was giving out about wierd drm messages last night..
airlied: whoever that was it should be fixed now..
airlied: MostAwesomeDude: yup.
eboettcher: all the compiz stuff got corrupted with my little stunt :/
eboettcher: (from the powerdown I’m guessing)
eboettcher: erm.. alot more of my filesystem is gone than I thought
airlied: hmm I saw some brief corruption with compiz..
airlied: oops.. mplayer playing in the switcher is cool..
airlied: until it dies.
MostAwesomeDude: The window decorator from KDE, Crystal, uses faked transparency, and so it glitches a tiny bit, but that can’t be avoided.
MostAwesomeDude: That’s a KDE3 problem.
MostAwesomeDude: But everything else is cool. mplayer and youtube both work on the cube.
airlied: hmm it came back..
z3ro: airlied: the drm messages I pasted?
z3ro: or something else?
airlied: z3ro: yup those ones..
airlied: should be fixed now.
z3ro: airlied: ok, thanks. 🙂
airlied: wow movies on cube is cool… except for the 20-30 sec hangs I’m seeing
airlied: I wonder whats happening there.
z3ro: what was the problem? I just saw the commit and it looks like some size was specified too small?
MostAwesomeDude: airlied: Tex indirection, maybe?
airlied: yeah using r300 fp cmd sizes..
z3ro: so it would overwrite into the next command buffer?
airlied: MostAwesomeDude: 20-30 secs hang is very wierd..
MostAwesomeDude: airlied: Oh, 20-30, not 2-3.
airlied: z3ro: it just wouldn’t fir all the current buffer in.
MostAwesomeDude: Wow.
z3ro: airlied: ah I see
airlied: MostAwesomeDude: well probably more like 7-8 sec.
airlied: I’m bad at timing in my head 🙂
airlied: actually 40 secs.
airlied: wow..
MostAwesomeDude: airlied: Steps to reproduce?
airlied: MostAwesomeDude: run compiz, play move in mplayer xv go mess with cube.
airlied: hmm appears to be getting stuck in-kernel.
airlied: hmm vblank wait.
airlied: so its probably just my vbl code doing something like fail.
MostAwesomeDude: airlied: Can’t reproduce except by holding down Ctrl+Alt+Left/Right.
airlied: MostAwesomeDude: its definitely vbl related, turning on drm debugging its spins in the kernel 🙂
MrCooper: airlied: could be one of the vblank-rework quirks
airlied: MrCooper: true.. I may also have messed up vblank impl ..
airlied: MrCooper: I wonder is 40 secs how long it takes to wrap the frame count or something
eboettcher: >< this is an epic corruption, and I have no backup of /
airlied: hmm no. 2400 frames a sec
airlied: doh..
airlied: 2400 frames in 40 secs.
MrCooper: yeah, that would be a very low wraparound
airlied: it ghives back EINTR for the vbl interrupt.
airlied: doh vbl ioctl.
MostAwesomeDude: airlied: Where is it spinning? Spinlock, or starvation, or something else?
MrCooper: airlied: I get that sometimes, but then it never recovers on its own…
airlied: MostAwesomeDude: aiglx driver keeps calling the kernel and getting EINTR
airlied: MrCooper: I wonder do we have some wierd AIGLX interacton.
MrCooper: airlied: I have to attach gdb to it, finish the ioctl and return ret from its caller…
MrCooper: airlied: I have no idea what’s going on 🙁 it’s very weird
airlied: I suspect DRM_WAIT_ON related fail :
MostAwesomeDude: Dammit, gitweb is down. Wonder if git is down too.
MrCooper: airlied: I stared at that for a long time but couldn’t see anything wrong
glisse: MostAwesomeDude: for sin & cos and other trig you also might need to clamp to either 0,2pi or -pi,pi
glisse: MostAwesomeDude: this is due to the approximation used
glisse: this approximation give best result only if supplied angle is in thus range
glisse: iirc the sin/cos implementation in r300 use the best approximation i know of
airlied: MrCooper: I think it might be X server schedule signals causing the EINTR.
airlied: MrCooper: since the AIGLX is the same process.
airlied: I wonder could we end up a in a wierd sync state between the sched signal and vblank waits 🙂
MrCooper: hmm yeah, that could be if the X server always triggers a signal within 3 seconds
MostAwesomeDude: glisse: I see your point. I didn’t even consider that.
airlied: its gets a signal ever 20ms.
airlied: every 20ms for smart scheduler
MrCooper: that’s probably it then
glisse: MostAwesomeDude: well if you want reliable an solid sin/cos you need to do that clamp note that one of the trig opcode in arb fp are supposed to provide already clamped value
glisse: so you shouldn’t need to clamp
glisse: but i suspect other implementation to clamp even for this one as often programmer don’t pay much attention to this
MostAwesomeDude: glisse: Check out what currently happens with SIN/COS/SCS.
MrCooper: airlied: so I think the root problem is vblank-rework not handling disabled/restarted CRTCs properly yet; I have fixes for that almost ready
MostAwesomeDude: I can see how the clamp would help.
airlied: MrCooper: cool.. I’ll see if I can debug it later.. I’ve just got into the Doctor Who episode I was testing with 🙂
MrCooper: airlied: enjoy 🙂
glisse: MostAwesomeDude: git broken for me
glisse: MostAwesomeDude: could you pastebin sin opcode for instance
glisse: oh r500 has sin/cos instruction
MostAwesomeDude: glisse: http://rafb.net/p/Uglzf918.html
MostAwesomeDude: 886 is SIN.
MostAwesomeDude: We’re using their instruction, but it’s not working right. Would you like a screencap?
glisse: if you got one this might give a clue
MostAwesomeDude: glisse: http://home.aweenet.net/~simpson/snapshot54.png
MostAwesomeDude: That’s SIN. COS is similar.
MostAwesomeDude: SCS is the same kind of bars, but only in one direction and two channels.
glisse: MostAwesomeDude: ok so according to doc p87 you need to clamp before asking for sin or cos
glisse: my understanding is that hw clamp inf but return 1 or 0 if angle is outside -pi/pi
glisse: this would explain why its black for sin
MostAwesomeDude: glisse: That’s VP, not FP, but I see what you’re saying.
glisse: is it white for cos ?
glisse: or did you try to mul by 2PI ?
glisse: doc doesn’t give much information for alu
glisse: so my guess is that fp has same implementation as vp
MostAwesomeDude: glisse: Nope. http://home.aweenet.net/~simpson/snapshot55.png
MostAwesomeDude: glisse: The hardware is supposed to multiply by 2pi before performing the trig.
glisse: then my wild guess is that you need to do B = A % 2pi, then sin(B)
MostAwesomeDude: glisse: My thinking exactly. Take a look at what fglrx does for trig: http://rafb.net/p/7ViFGe78.html
MostAwesomeDude: I’m trying to think of a cheap way to do it.
glisse: there is no cheap way 🙂
glisse: well you can’t optimize this without some kind of a real compiler infrastructure
glisse: as for instance if program ask for a sin of a supplied constant you might want to precompute this outside of shader
MostAwesomeDude: glisse: Yeah.
MostAwesomeDude: Still, it’s gonna be cheaper than the parabolic approx. in r3xx.
glisse: yup
MostAwesomeDude: Well, as we move towards GLSL, I’m going to try to make this more and more robust.
MostAwesomeDude: I’m gonna meditate on the maths for a bit. A % 2pi seems like the cheapest, quickest way, but I’m not sure how to do modulus.
bobbens: \o/ GLSL
airlied: I would suspect fglrx optimise anything they can quite well 🙂
airlied: though llvm would be interesting .
MostAwesomeDude: airlied: It would be better to just go on a per-opcode basis and let the GLSL compiler do its thing.
MostAwesomeDude: And I’m still puzzled over “render targets” and why fglrx needs to write to all four of them.
glisse: MostAwesomeDude: ok i was wrong its not A % 2pi you just do sin(frc(A/2pi))
glisse: airlied: amd optimize because they have compiler
MostAwesomeDude: glisse: Yeah, that’s what the code says, but that makes sooo little sense.
glisse: airlied: i can’t see how you can optimize in any sensible manner without compiler
airlied: glisse: exactly..
glisse: the nvidia compiler is very clever too
MostAwesomeDude: Anyway, I’m going to go figure out a high-quality inv(2pi) to use.
airlied: glisse: we need to get one someday 🙂 hopefully llvm is it.
glisse: impressive as matter of fact
airlied: MostAwesomeDude: no idea why thye would write to all the render targets.
glisse: MostAwesomeDude: don’t inv(2pi) in code
glisse: MostAwesomeDude: supply 1/2pi as a constant
MostAwesomeDude: glisse: That’s what I’m thinking.
MostAwesomeDude: Sorry, it’s late. I’m not thinkin’ straight.
glisse: MostAwesomeDude: A % 2pi = 2pi * frc(A/2pi)
MostAwesomeDude: But I still don’t know what a “render target” is. It’s not mentioned anywhere else in the docs.
MostAwesomeDude: glisse: ( Oo) That’s some crazy maths.
airlied: MostAwesomeDude: they are just output targets..
airlied: MostAwesomeDude: like textures are inputs
glisse: MostAwesomeDude: you got 4 render buffer on this hw
glisse: we always use one
glisse: so render target is one of those 4
glisse: so as sin and cos premultiply by 2pi you don’t need to do that
glisse: so sin & cos actualy clamp the things with little help from our side 🙂
MostAwesomeDude: ‘k.
MostAwesomeDude: Implementing now.
MostAwesomeDude: Arg, nevermind. Will take a few; have to add const refcounting first.
airlied: there is mention about SCS input operand in the ARB_fp docs
glisse: airlied: i think multiple render target is used for special effect like motion blur
glisse: i can’t remember where i did see somethings about that
z3ro: airlied: hmm I noticed a possible bug with revenge on the dri r5xx driver. it seems to dump *way* too many ib’s
z3ro: and some of them are in fact exactly the same.
glisse: airlied: for scs the argument should already be clamped
z3ro: so I’ll have to look into that.
airlied: z3ro: we don’;t use ibs 🙂
glisse: anyway got to go bbl
airlied: so its dumping all the DDX ones.
z3ro: hmm yeah.
z3ro: I don’t know whether it’s possible to avoid that… I mean, revenge just looks at the ring pointers.
airlied: MRT might be useful for stereo or something.
z3ro: so if something else (ddx) puts data in there, there isn’t much I can do to filter it afaik…
airlied: z3ro: you could ignore IBs on open source DRI 🙂
airlied: z3ro: the only thing I can think off is to try and get the IB before the app submits it.
airlied: z3ro: find the fglrx ib submission ioctl
airlied: and trap on it since you are in the same process with revenge
z3ro: that could work… but I’m not sure I like the idea of making it (even more) dependant on fglrx version.
airlied: hmm MRT for render-to-vertex buffer stuf is all I can really se
z3ro: and there is the –disable-ib option which could be used for DRI.
airlied: hmm MRT deferred shaing, you can light the scene after rendering..
z3ro: brb trying r300_demo hacked for r5xx
z3ro: cool seems to work. 🙂
z3ro: btw which regs control where the hardware will start drawing in the FB? I think it’s just RB3D_COLOROFFSET[0-3] and COLORPITCH[0-3]
z3ro: (and the same for DEPTH)
z3ro: and why are there 4 color offset/pitch regs?
airlied: z3ro: yes.
airlied: z3ro: one for each render target
z3ro: ah right
z3ro: ok well it should be pretty easy to patch up a cmd buffer so it runs on a different display then. 🙂
MostAwesomeDude: Well, I have found something new.
rx__: what?
airlied: MrCooper: hmm I’m thinking some sort of SMP race here..
MrCooper: airlied: UP here
airlied: MrCooper: I’m seeing the vblank count jump in 0x1fffffe steps
airlied: which is my max vbl – 1
MrCooper: airlied: that happens when the hardware counter goes backwards
MrCooper: airlied: the driver independent code assumes it wrapped around
airlied: yeah I don’t think it is going backwards though..
airlied: I think you might have a race somewhere.
MrCooper: ah, yes indeed there is
MrCooper: the core needs to treat -1 as 0
MrCooper: because the method to make the driver counter increase at the beginning of the vblank period isn’t bullet-proof yet
airlied: cool I’ll havea look later.. dinner time 🙂
MostAwesomeDude: Okay, so SCS works.
MostAwesomeDude: COS doesn’t quite have the correct masks yet, although I’m almost there.
MostAwesomeDude: And SIN causes DRM to not like me, even though it’s nigh-identical to COS.
MostAwesomeDude: Ooh, nevermind.
MostAwesomeDude: DRM doesn’t care about SIN; it’s ticked at the constants.
MostAwesomeDude: There are a total of three constants to upload to the card, and I guess DRM doesn’t like that for tri-sin.
glisse: MostAwesomeDude: note that fglrx seem to do: A/2pi + 0.5
glisse: ok so they do A/2pi + 0.5 so that the result is in 0, 2pi range
MostAwesomeDude: glisse: The maths is fine; it’s just masking problems now.
MostAwesomeDude: SCS works.
stefan1: airlied: mplayer -vo gl now works with your latest -ati commit. Thanks
MostAwesomeDude: Whoo, compiz killed X.
stefan1: MostAwesomeDude: I’m just going to pull your latest mesa commits
MostAwesomeDude: stefan1: Go for it.
stefan1: MostAwesomeDude: Let’s see if kwin4 starts to work 🙂
glisse: MostAwesomeDude: if they add 0.5 is to always have positive value
glisse: this might be important
glisse: i don’t think they add 0.5 just for fun but for profit 🙂
MostAwesomeDude: glisse: That might be the case on r3xx, but on r5xx, FRC is guaranteed to return a positive number between 0 and 1.
glisse: frc will always return a positive number
glisse: it’s just the result of the math behind
stefan1: 0.5 sounds like rounding…
glisse: MostAwesomeDude: frc(A/2pi) != frc(A/2pi + 0.5)
MostAwesomeDude: glisse: frc(A/2pi) + pi == frc(A/2pi + 0.5)
glisse: MostAwesomeDude: no here 🙂
glisse: s/no/not
glisse: frc(2pi/2pi)+pi = pi frc(2pi/2pi +0.5) = 0.5
gustaf1: may I ask what FRC, CSC etc stands for?
gustaf1: SCS*
glisse: gustaf1: look at arb fp extension this are opcode doing basic math frc(A)=A-floor(A)
gustaf1: arb?
glisse: scs is sin & cos in a single operation
gustaf1: oh
glisse: http://www.opengl.org/registry/specs/ARB/fragment_program.txt
MostAwesomeDude: glisse: That 0.5 * 2pi == pi when it goes into COS.
gustaf1: glisse: thanks
glisse: MostAwesomeDude: frc(A/2pi + 0.5) * 2pi != (frc(A/2pi) + 0.5) * 2pi
stefan1: MostAwesomeDude: OK, POW error message gone from mplayer -vo gl2:yuv=3
glisse: MostAwesomeDude: frc(A/2pi+0.5)=frc((A+pi)/2pi) adding pi can make sense guiving the underlying approximation the hw use for sin & cos look at http://www.devmaster.net/forums/showthread.php?t=5784
glisse: for example of such approximation
stefan1: OK, restarting X with new mesa
stefan1: MostAwesomeDude: some progress with mplayer -vo gl2
stefan1: MostAwesomeDude: no error messages anymore, but playback can get “stuck”
MostAwesomeDude: stefan1: How so?
stefan1: when it is working yuv=2 & yuv=3 show correct graphics & colors, yuv=4 shows black & white
stefan1: MostAwesomeDude: stuck: shows the first image and then mplayer stops. But you can still press Q to quit
stefan1: MostAwesomeDude: according to the mplayer status line it stops at frame 11 in my example mpeg4 video
MostAwesomeDude: Hmm, very strange.
stefan1: MostAwesomeDude: yes, very. Could be some missing initialization -> junk left over from “previous” fragment program left on chip
MrCooper: stefan1: could be related to the vblank issue discussed with airlied before you joined
MrCooper: try running with vblank_mode=0 maybe
stefan1: MrCooper: OK. airlied fixed -vo gl with yesterdays commit though…
stefan1: MrCooper: OKIE
stefan1: MrCooper: Hmm, mplayer doesn’t know vblank_mode
MrCooper: it’s a driconf option / environment variable
stefan1: Ahhh pausing – unpausing video fixes the problem
stefan1: MrCooper: vblank_mode=0 mplayer …. always works
stefan1: Nope, still gets stuck sometimes…
airlied: MrCooper: yeah adding a -1 seems to help 🙂
MrCooper: airlied: that’s not what I meant though
airlied: MrCooper: well I just want to see what it would do..
airlied: do you know where the real race is?
MrCooper: if (cur_vblank == dev->last_vblank[crtc] – 1) { diff = 0; } else { } is what I’ve been testing
airlied: ah cool.
MrCooper: the race is due to the hardware frame counters and ‘in vertical blank’ bits apparently not flipping in sync
airlied: or at least changing in between the two reg reads..
MrCooper: I think the latter will sometimes still be up while the former has already incremented
MrCooper: so next time the result appears to have gone backwards
airlied: ah yes makes sense, so the inc happens but you get another one from the level.
stefan1: -vo gl2:yuv=4 looks funny. I guess only luminance (Y) from the YUV data is shown…
MrCooper: airlied: maybe a loop waiting for them to stabilize would help
MrCooper: airlied: or maybe they’re just out of sync
MrCooper: in which case I’m not sure what to do other than the core workaround :}
stefan1: MostAwesomeDude: Would a dump of the gl2:yuv=4 fragment program help to figure out what is still missing in r5xx mesa?
airlied: MrCooper: do we really care about the level.. i assume its more accurate.
MrCooper: airlied: yes, it’s the whole point of sync to *vblank* 🙂
MostAwesomeDude: stefan1: Sure, go ahead.
airlied: I’m still seeing compiz crap at a few places on statrup..
airlied: MrCooper: well you might be very close to the end of vbl 🙂
MrCooper: airlied: syncing to the start of scanout results in judder and tearing
MrCooper: airlied: more precisely, the counter needs to be aligned with the vblank interrupts
MrCooper: airlied: otherwise, sleep for interrupt -> wake up -> do stuff -> wait for next vblank -> hardware counter has already incremented -> fail
stefan1: MostAwesomeDude: no progress with kwin4 composition. black screen, crash or stuck.
MostAwesomeDude: stefan1: I have no idea what goes on in kwin4.
stefan1: MostAwesomeDude: Yeah, let’s see. F9 pushed KDE 4.0.4 yesterday. Maybe we get some improvements
stefan1: MostAwesomeDude: But I’m a little bit wary about compiz. My experiences with it on a Nvidia/closed source driver F8 have not been too good.
MostAwesomeDude: stefan1: We are neither closed source nor nVidia.
stefan1: MostAwesomeDude: I don’t know if the problem is compiz or the Nvidia driver, but noveau doesn’t support that card :-/
MostAwesomeDude: stefan1: When in doubt, assume that the app is bad.
MostAwesomeDude: Although compiz is surprisingly well-written.
stefan1: MostAwesomeDude: But with the 30″ Dell connected to that card you see the speed improvements from composition drastically
stefan1: MostAwesomeDude: So I now suffer from slow window management without compiz 🙁
MostAwesomeDude: stefan1: compiz is still slower than straight EXA on my laptop.
MostAwesomeDude: Although compiz is pretty fast.
santi: hi there!
MostAwesomeDude: santi: Yo.
stefan1: MostAwesomeDude: I doubt nvidia closed source driver doesn’t know what EXA is 🙂
MrCooper: it certainly doesn’t use it; it’s almost a complete X server of its own that happens to use Xorg as the loader 😉
MostAwesomeDude: stefan1: You never know. There is solid evidence that at one point the ATI devs didn’t know what GCC was or why it was used to build code on Unix.
MrCooper: well, complete DDX anyway
MostAwesomeDude: For lulz, try an strace or ltrace of fglrx and watch it try to open various Windows system paths.
santi: i have a nvidia fx5200 card… and i tired of closed source driver… so i want to change…. i have several pages on free3d.org to see best options…. i can buy a new ati 9600xt (25�) or a second hand 9200 (15-20�)… on radeon on page and x.ork wiki says that 3d is not well supported above 9200….
santi: i dont need huige performance…. just googleearth and ppracer….
santi: buy i want stability.
MostAwesomeDude: santi: Intel.
santi: i have a amd94 9393 socket
MostAwesomeDude: I would say that Intel drivers are the most stable.
MostAwesomeDude: But, that’s not really practical.
MostAwesomeDude: 3D is rapidly becoming better on more modern Radeons.
stefan1: Thanks to some MostAwesomeDudes 🙂
stefan1: BRB
santi: sorry… i had to go…..i cant use intel because i have a 939 board…
santi: http://www.x.org/wiki/radeon says… “3D for R300/R400 class chips support is quite stable, 2D stable.”
santi: but http://dri.freedesktop.org/wiki/ATIRadeon#head-2f5098616350345fc8b9d26888cb729d63303cf2 says # 9100 denotes a R200 based card
santi: # 9200 denotes a rv280 based card.
santi: *
santi: Cards below this point are not well supported for 3D, but do have accelerated 2D
santi: is 9600xt well supported (i mean stable)?
z3ro: well stable-ish
z3ro: most things work, but there are some lockup problems
santi: is 9200 3d support hard-rock?
z3ro: not sure about r200
santi: i thilk il go with the 9600.
santi: I think i’ll go with the 9600
arekm: can say only that r300 isn’t stable for 3d
glisse: arekm: it depends a lot on the card
santi: so i should believe http://dri.freedesktop.org/wiki/ATIRadeon#head-2f5098616350345fc8b9d26888cb729d63303cf2 and not http://www.x.org/wiki/radeon
glisse: for instance pcie tends to be safer
glisse: i do have here a x600 that i still never succeed to lockup
santi: brr!!. i have and AGP board.
santi: s/and/an/
z3ro: hmm oops. screwed something up while messing with the coloroffset. 😛
arekm: glisse: my card. x600 pcie in thinkpad. Recently one lockup cause has been fixed. Didn’t try any 3d apps in meantime so maybe that was the only one
PSYCHO___: with today sinced git i get lots of wierd artefacts: http://hlukotvor.no-ip.org/~scarab/stuffie.jpg (it happens everywhere, i can get rid of it when i change to other desktop and back)
PSYCHO___: so with complete redraw
PSYCHO___: i have r420
tormod: guys, fantastic r500 progress, thanks a lot! googleearth runs well on my X1300. All GL screensavers work.
tormod: unless I set vblank_mode to 0, I get “do_wait: drmWaitVBlank returned -1, IRQs don’t seem to be working correctly.” but that’s WIP.
tormod: btw, I guess there’s a typo: “Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.” LIBL -> LIBGL?
tormod: In ppracer I get small frames around all objects like fishes and trees.
stefan1: Hmm just tried compiz
stefan1: instead of kwin4
stefan1: only get an error message
stefan1: $ compiz –replace
stefan1: Warning, RV515 detected, 3D HAHAHAHAHA!!.
stefan1: compiz (core) – Fatal: GLX_EXT_texture_from_pixmap is missing
stefan1: After reading airlied’s blog I was assuming that compiz works now?
Saist: sorta
otaylor: stefan1: Try LIBGL_ALWAYS_INDIRECT=1
otaylor: stefan1: It was working for me pretty well with todays mesa. Went all corrupt on me at one point, but came back, and has been fine since
stefan1: Yep, that works somewhat
stefan1: kde-window-decorator doesn’t do anything thow
otaylor: stefan1: that’s more likely to be a compiz setup issue than a driver issue
MrCooper: yeah, probably the decoration plugin isn’t loaded
runman: hello
santi: hi there!
santi: I here again…. i wonder… is a 9200 with r200 open source driver enough to run googleearth smoothly?
santi: ciao
stefan1: Well, compiz works somewhat…
stefan1: at least better than kwin4 composition features 🙂
stefan1: MostAwesomeDude: current mesa git seems to be enough for basic compiz functionality
MostAwesomeDude: stefan1: Yes, it does.
MostAwesomeDude: “Basic”… have you found any compiz plugins that don’t work?
stefan1: MostAwesomeDude: window switchers, desktop cube/plane, scale “freeze” X for a while, maybe roughly 1 minute
stefan1: MostAwesomeDude: Strangely enough window minimizer effect (which also scales windows) works fine
MostAwesomeDude: stefan1: Hmm. I wonder about that.
MostAwesomeDude: Over here, all plugins work except video accel. which needs a different colorspace.
MostAwesomeDude: (And we don’t need compiz’ video accel. since we already have plenty of video speed from XV.)
stefan1: MostAwesomeDude: mplayer doesn’t have window decoration
stefan1: under compiz
MostAwesomeDude: stefan1: GNOME or KDE, and are you using a compiz decorator?
stefan1: MostAwesomeDude: KDE4, compiz with kde-window-decorator
MostAwesomeDude: Hmm.
MostAwesomeDude: Do you still have KDE3 installed, by any chance?
stefan1: MostAwesomeDude: Fedora 9 has only minimal KDE3
MostAwesomeDude: Well, I want to chalk it up to KDE4 being slower, but I could be wrong.
stefan1: MostAwesomeDude: Basically only the KDE3 libs for old apps and KDE3 apps that don’t exist/work on KDE4 yet
MostAwesomeDude: And the driver definitely isn’t mature.
stefan1: MostAwesomeDude: compiz replaces KDE4 window manager
MostAwesomeDude: Same with KDE3.
MostAwesomeDude: It’s just that I don’t know why it would be massively slow for you.
MostAwesomeDude: Are you sure that you’re accelerated?
stefan1: Yes, I have wobbly windows without problems 🙂
otaylor: stefan1: I assume (since it’s a r500) you have plenty of video ram?
stefan1: (–) RADEON(0): Mapped VideoRAM: 65536 kByte (64 bit DDR SDRAM)
otaylor: stefan1: Ouch, that may well me your problem
stefan1: otaylor: Not enough RAM for textures?
MostAwesomeDude: $ grep VideoRAM /usr/var/log/Xorg.0.log
MostAwesomeDude: (–) RADEON(0): Mapped VideoRAM: 262144 kByte (64 bit DDR SDRAM)
otaylor: stefan1: On a r300 with 64megs, I regularly run out of video ram for window pixmaps if I try to to use compiz
otaylor: stefan1: though that shouldn’treally cause an entire freeze, just extreme slowness
otaylor: stefan1: Adding something like:
otaylor: Option “FBTexPercent” “25”
otaylor: To the “Device” section in your xorg.conf will help a bit
otaylor: stefan1: That’s saying “use only 25% of my ram for textures, and the rest for other stuff … in particular window pixmaps”
otaylor: stefan1: To see if this is the problem, close all but a couple of small windows and see if things are better
stefan1: OK, restarting X… BBL
stefanb: otaylor: Didn’t help
otaylor: stefanb: Does the freeze occur even with a few small windows?
stefanb: otaylor: I think the problem is probably different. I don’t see slowness at all. I just have to wait ~30 seconds before e.g. scale starts
otaylor: stefanb: scale is the “expose” style thing?
stefanb: otaylor: Is closing windows required or is hiding enough?
stefanb: otaylor: yes, scale: move mouse to top right -> visible windows are scaled down
otaylor: stefanb: Not sure. I thinkhiding is enough, but I’m not sure under what circumstances the server dumps pixmaps for redirected windows
stefanb: Hmmm I’m wondering. Could this again be a problem with waiting for vblank?
otaylor: stefanb: You can configure whether compiz syncs to vblank right?
stefanb: Yes, just found the option… trying off now
stefanb: otaylor: hmm didn’t help.
stefanb: let me try closing all windows…
otaylor: stefanb: after that, the next thing to figure out is whether it’s freezing at 100% cpu or 0%cpu (you probably cna just tell by putting your hand next to your laptop’s vents…)
stefanb: otaylor: nope, “freeze” happens even with small console window as the only window on the desktop
otaylor: stefanb: OK, then it’s likely a driver bug specific to your card, though weird ..that’s not a normal sort of thing for driver bugs to cause
stefanb: otaylor: mesa driver, drm driver or X driver?
otaylor: stefanb: hard to say. can you ssh in and take a look at top when things are freezing and see who (if anybody) is eating cpu?
stefanb: otaylor: let’s see…
stefanb: otaylor: Nope, no CPU load.
stefanb: otaylor: So it looks like it’s waiting for something.
otaylor: stefanb: Next step would be to attach to compiz with a debugger from the ssh session (debuginfo-install compiz first) control-c it and see what it’s doing
stefanb: otaylor: ah found a side effect
stefanb: otaylor: scale and minimize plugin seem to block each other…
otaylor: stefanb: That might just be sequencing in compiz .. avoiding running two effects at once?
stefanb: otaylor: Well it only helped the first time
stefanb: otaylor: now scale is stuck again even when I switch off minimize & fade plugins
otaylor: stefanb: Well, the gdb results would be interesting…. in some sense, compiz is a poor test case to try and guess what it is doing just from looking at what triggers a problem
ghepeu: hello
ghepeu: so, I was experiencing random lockup on my radeon rv370, after a few weeks of tests I think that the problem was introduced between mesa 7.0.3rc2 and mesa 7.0.3
ghepeu: any idea on what commit could be responsible? I’d try bisecting but it could take weeks
airlied: the freeze are vblank,
stefanb: otaylor: Any particular place where I should put a breakpoint? I have to use “cont” in order to be able to use the machine
airlied: read the logs ppl.
airlied: when I bitch and d ebug something it might mean something 🙂
stefanb: [mi] EQ overflowing. The server is probably stuck in an infinite loop.
stefanb: [mi] mieqEnequeue: out-of-order valuator event; dropping.
stefanb: This?
airlied: we need a drm patch that MrCooper hasn’t checked in yet..
airlied: stefanb: that mieq stuff means you’re GPU might have crashed.
stefanb: Don’t see anything else in the log
stefanb: But I just tried, that message doesn’t appear with the “scale freeze”
stefanb: probably side effect of trying gdb on compiz…
stefanb: Would running compiz with vblank_mode=0 help?
airlied: stefanb: maybe, I think you can turn vblank off in compiz, but it didn’t appear to take notice for me .
ghepeu: airlied, “the freeze are vblank” were you talking to me?
airlied: I was talking to whoever saw a 30s to 1m freeze with compiz on r50
airlied: r500.
egore: hmm, interesting. I used software rendering until today on my r500. now I upgraded to xserver git and mesa git (r500 branch) and openarena is working great. what really makes me wonder is that blender is slower than before o.0
airlied: egore: blender probably needs disable_lowimpact_fallback=true
egore: but shouldn’t the fallback be as fast as software rendering?
egore: airlied, since to me it seems that it should run the same code
egore: airlied, or is the fallback slower because of the transfer between gpu->cpu and back?
airlied: egore: I think it’ll be rendering to surfaces in VRAM maybe or something like that..
stefanb: airlied: So is there a patch in drm/linux-core for vblank that I should try?
stefanb: or do I have to wait for MrCooper?
airlied: stefanb: he mentioned what he did earlier but he didn’t check it in yet.
stefanb: OK, then something for tomorrow when my head is not so sleepy anymore… nightie-night…
stefanb: strange…
stefanb: ouch
stefanb: after hibernate the screen looks like an expresionist oil painting 🙂
mattmatteh: anyone familiar with xvideo test? i was looking at bug http://bugs.freedesktop.org/show_bug.cgi?id=16001 and tried run the test in that and all i get is a small window
mattst88: does the radeon ddx driver support any kind of backlight controls?
mattst88: xbacklight reports “No outputs have backlight property” on my r480
airlied: mattst88: backlight may be done by the acpi bios..
eboettcher: erm
eboettcher: I’m going to re-install my OS tonight :/ I wish I could be messing with Xv instead.
eboettcher: I spent the day sleeping and doing data recovery :/
Nicky: hi all
eboettcher: hello
Nicky: eboettcher : Do Radeon X1X series have major problems with mandriva 2006 ?
eboettcher: Nicky: I don’t know anything about mandriva
eboettcher: but based on the date, I’d say yes
eboettcher: you need modern drivers
Nicky: eboettcher : Do games like torcs or vdrift need DRI from those radeon series ?
eboettcher: airlied: have you guys tried out any games besides openarena? 😛
eboettcher: Nicky: development of dri drivers on those cards is up-to-the minute — unless you want to use experiemental drivers, you may be forced to use fglrx
airlied: eboettcher: not really 🙂 I tried et but it hung the machine on level load.
MostAwesomeDude: eboettcher: I don’t have openarena. Not a big FPS fan.
airlied: tuxracer looks a bit messed up.
airlied: the textures looks to have sizing issuess.
spstarr: airlied: any r300 cycles on that bug?
MostAwesomeDude: UT2k4 hangs on load, prolly because it’s massive.
Nicky: eboettcher : SO XOrg drivers wont give me DRI.
airlied: spstarr: well if I can get r500 to run KDE it’ll have the same bug 🙂
spstarr: airlied: nice
spstarr: airlied: I like when code paths have same bug, even with newer hw
eboettcher: Nicky: well they will if you’re patient 🙂
spstarr: in the meantime, i wanna see what this GNU gold linker is like
eboettcher: spstarr: no luck for me
eboettcher: not until it supports all of those odd options the old linker supported
spstarr: im trying today’s cvs checkout with the fedora .spec file
spstarr: maybe i can build KDE with it now
spstarr: i just bootstrapped binutils with gold though
spstarr: heh
eboettcher: HAHA
eboettcher: good luck
eboettcher: kde with gold.. may the force be with you 😛
spstarr: it links
spstarr: !!!!!!!
spstarr: GNU gold (version 2.18.50-2 20080523) 1.6
spstarr: i just built ktorrent
spstarr: and it runs 🙂
MostAwesomeDude: Nice.
spstarr: indeed the future is golden 😉
eboettcher: nice 🙂
eboettcher: KDE4 stuffs?
spstarr: yes

Radeon IRC Logs For 2008-5-22

Rig Lab Hardware

You Might Also Like

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

RadeonHD.org | Radeon IRC Logs For 2008-10-30

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