Zajec: in radeon-rewrite there are r100, r200, r300 rewriten Mesa drivers
Zajec: does r300 Mesa driver support also r4xx/r5xx?
Toksyuryel: that's just the name mesa calls it
Zajec: ok, thanks
Toksyuryel: it doesn't seem to have anything to do with ati's numbering scheme
airlied: it supported r300 first
airlied: calling the driver r34500 and changing the name each time hardly seema practical
Zajec: airlied: do you still have many issues with radeon-rewrite? can you predict finishing time?
airlied: Zajec: one fix left, for r200 depth buffer reading I think
airlied: I'm just fixing up kms paths now mostly
Zajec: wow, didn't expect that :)
Zajec: sounds really nice
mjt: is there a way to make a screenshot together with mouse cursor?
mjt: (i mean, not using a photo camera etc ;)
mjt: i see quite an interesting mouse cursor corruption
yangman: mjt: not with hardware cursor
yangman: mjt: it's composited onto the output by the hardware
mjt: ..and it suddenly started working again... doh.
yangman: yeah, the cursor issues are weird
mjt: the cursor was like large (~100 pixels high) zigzaggy red-n-black line
yangman: dual screen?
mjt: sometimes becoming a 100x100 square flickering with all colors
mjt: i've seen that bugreport ;)
yangman: right. yeah, not the same
Yankeeboy: is radeonHD still being developed, or has the recent decisions by ATI killed it off ?
nanonyme: Recent which decisions?
adamk: It's still developed.
adamk: One radeonhd developer at Novell was laid off.
adamk: And, as I understand it, the other two had their hours cut back. But the documentation is available, and the code is available, so there's very little chance that the development would stop even if all the developers at Novell were laid off.
AStorm: at worst one driver will disappear
nanonyme: adamk_: Not all specs though, right? I was under the impression power management docs need to go through screening process still.
AStorm: pity Catalyst has no-rev-eng clause
nanonyme: AStorm: Probably for the same reason as why stuff coming officially out from AMD need to go through IP screening. :P
adamk_: nanonyme: That I'm not sure about. All 3D specs are available, though, as I understand it.
AStorm: actually, we could go the nouveau way
nanonyme: adamk_: Yeah, that's true.
AStorm: have IO traced
AStorm: and see what happens when Powerplay is activated
adamk_: Well, and avivo was completely reverse engineered from fglrx, wasn't it?
AStorm: I don't think so
nanonyme: adamk_: Desktop users can be full support with current specs. It's afaik just the laptop users who suffer the most until power management (read: dynamic clocking) gets there.
AStorm: it's not just dynamic clocking - unless by dynamic you mean 0 HZ
nanonyme: Dynamic as in changeable here.
AStorm: (yes, there can be other freqs too)
AStorm: no, radeon had dynamic clocking (for all), and it didn't save enough
AStorm: you have to disable subunits or sth
AStorm: to get adequate power saving
AStorm: probably it also supports voltage regulation
Yankeeboy: I thought there was an issue with fan control as well
AStorm: yeah, fan control would be useful too, it's some W
Yankeeboy: I guess that would be model specific, I have an Mobility Radeon HD 3600
AStorm: but that should work well even automatically
Yankeeboy: which I guess is an RV635
mjt: ohh... I wish i can just turn the whole thing off... ;) The on-mobo graphics thing, 100% of it....
Yankeeboy: So, with the RV635, what's the curent driver ?
AStorm: you can use either radeonhd or radeon
Yankeeboy: presumably HD is the one I want ?
Yankeeboy: Mine is an HD chip (I think)
AStorm: not much difference
AStorm: these drivers are very similar on r6xx and r7xx
AStorm: one does better in one place, another in other
AStorm: radeonhd supports hdmi audio
Yankeeboy: Ah, I always wondered what the difference was
AStorm: and has optional non-atombios setup code
AStorm: in my practice, (HD 3850), radeon driver is faster, but doesn't add so many modes as radeonhd
AStorm: but now it does support aspect-correct scaling :)
AStorm: (talking latest master, with EXA 2D acceleration)
nanonyme: AStorm: In my practice radeonhd has been faster (HD 3870) so that might be very situation-dependent. :)
AStorm: see, I get slowness all around in radeonhd (latest)
AStorm: with EXA
AStorm: and XComposite
AStorm: while with radeon, I don't get that
AStorm: it is a regression
nanonyme: XComposite as in using a composite manager?
AStorm: yeah, to be exact, xfwm4
AStorm: xfwm4 4.6-svn
nanonyme: Where does the sluggishness show?
nanonyme: Just enabled xcompmgr -a, seeing if I can duplicate.
AStorm: xcompmgr -a is ok
AStorm: xfwm4 is not (or KDE 4)
Yankeeboy: Thanks for the advice
AStorm: fun part is that on radeon driver, all work fast
AStorm: and it uses the same code (or does it?)
nanonyme: Unsure. The same code in DRM but possibly the code in ddx might not be 1:1.
AStorm: similar enough...
AStorm: still, aspect-correct scaling is major win
AStorm: and a very minor change
AStorm: I'd rather the drivers merged :>
nanonyme: Not going to happen very soon, I think.
nanonyme: Aww, seems some upgrade broke swrast. :) I suppose I won't be doing any 3D rendering for now then.
nanonyme: (Not that essential anyway)
AStorm: my glxgears has transparent background
AStorm: is it using composite by chance? ;P
AStorm: slow though (software rendering)
AStorm: 1209 frames in 5.0 seconds = 241.607 FPS
nanonyme: Sounds normal.
AStorm: unknown chip id 0x9504, can't guess. - I guess radeon should also add the ID
nanonyme: Iirc I only got that on radeon but not radeonhd.
nanonyme: Might want to test. As I said, currently glxgears doesn't run for me.
AStorm: because it uses chip id to determine if hardware 3D accelleration is supported
nanonyme: AStorm: Lol. Swrast seems to have developed quite a bit. :)
nanonyme: I'm now getting 560 FPS with swrast from Debian experimental. ^^
nanonyme: (Used to get less than half of that with olde versions)
nanonyme: But yeah, apparently you can't have both swrast and glx at the same time installed on Debian. :(
AStorm: I'm getting so few only because of XComposite slowdown
AStorm: and my CPU isn't stellar either
nanonyme: Well, I have an Athlon AMD64 3500+ so it's not that new either.
nanonyme: And the swrast fps's literally more than doubled on the same CPU.
AStorm: 2041 frames in 5.0 seconds = 408.102 FPS
AStorm: w/o compositor
AStorm: cpu[2 x AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-82 (AuthenticAMD) @ 2,19GHz w/ 1024 KB L2 Cache]
nanonyme: I have the same results as before with xcompmgr -a.
nanonyme: I think our CPU's are quite on if it can only use a single core yours.
nanonyme: Quite on par even.
nanonyme: Mine is single core.
AStorm: -a is different
AStorm: it disables special effects
nanonyme: Well, why would you want special effects with compositing? ;)
nanonyme: I just use it because compositing improves speed in some cases.
AStorm: because they look nice? ;>
AStorm: especially the shadows
nanonyme: I don't need the system to look any nicer than it is. :)
AStorm: shadows give a measure of... depth to the desktop
nanonyme: I'm still a bit puzzled though why scrolling a web page quickly up and down easily takes 100% CPU.
AStorm: here it doesn't (radeon driver)
AStorm: it does with radeonhd
AStorm: this is caused by some EXA accel missing
nanonyme: I was already suspecting mouse device to be the guilty party.
AStorm: it does eat 54% of a core
AStorm: up to 65% actually
AStorm: this is with smooth scrolling enabled
AStorm: so some operation is still not that optimal
AStorm: w/ xcompmgr -a
nanonyme: For Well, I'm not sure how much it actually takes but it results in my CPU to up its frequency to maximum.
nanonyme: I assume this shouldn't happen.
nanonyme: I think I'll actually try xf86-video-ati now again next.
AStorm: scrolling back-forth is most intensive
AStorm: scrolling in one direction is fast
nanonyme: Just wondering why scrolling back-forth is so intensive and where could it be fixed?
AStorm: so, Firefox is abusing some unaccelerated or poorly accelerated EXA part
AStorm: because it sends 1px updates
AStorm: many of them
AStorm: smooth scrolling sends less updates when scrolling larger distances
AStorm: so, I suspect it taxes EXA copy operation
AStorm: some that isn't fast
nanonyme: AStorm: So... It'd be a problem in Firefox rendering design on *nix?
nanonyme: Yeah, doesn't seem to happen at all on Konqueror.
AStorm: that's because firefox sends 1px updates at first
AStorm: and exponentially increases scroll distance
AStorm: (up to some value)
AStorm: while konqueror has no smooth scrolling?
nanonyme: AStorm: Smooth scrolling is by default disabled in FF3 and I was getting the same issue still.
nanonyme: I think you're right though.
nanonyme: That is, of what the cause is.
AStorm: I get 18% of a core used w/o smooth scrolling, so definitely much faster
AStorm: still, some copy operation is definitely unaccelerated
AStorm: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090303 Gentoo Firefox/3.2a1pre
nanonyme: AStorm: general.smoothScroll?
nanonyme: Or where'd you turn it off?
AStorm: in PReferences
AStorm: there's a checkbox Use smooth scrolling
nanonyme: It's unchecked by default.
AStorm: it is
nanonyme: That is, behaviour for me: first slow scrolling, the rendering lags behind maybe several rounds of the scrolling, then scrolling suddendly jumps very fast and CPU usage peaks.
AStorm: this is radeonhd bug
AStorm: I've seen that too with compositing, sometimes
AStorm: it means the driver runs out of ring buffer space
nanonyme: I'm getting the same on radeon. ;)
AStorm: (the default is 2 MB)
AStorm: try Option "RingSize" "6"
AStorm: (at least on radeon, not sure what the name is on radeonhd)
nanonyme: AStorm: No change.
AStorm: I'm not getting that problem - do you have latest master? (and latest x11-drm)
AStorm: I did have it before, but it's been fixed
nanonyme: I do have the latest ddx of both drivers, yes.
nanonyme: And using the latest of drm-next.
AStorm: no, you need the branch
nanonyme: I shouldn't.
AStorm: you do
nanonyme: agd5f said I don't.
AStorm: let me check
nanonyme: I understood drm-next is the stuff with EXA and Xv that is getting to kernel 2.6.30.
AStorm: where's that drm-next?
AStorm: on git.kernel.org?
nanonyme: Yeah iirc.
AStorm: can't find it on fd.o
nanonyme: airlied's tree if I remember correctly.
nanonyme: Erm, his branch even.
AStorm: no, it has old EXA code
AStorm: at least from looking at the shortlog
nanonyme: Funny. It runs Xv fine.
nanonyme: On rv670.
nanonyme: (Or at least detects. Mplayer broke for me a day ago, hard to test)
AStorm: it will
AStorm: but the code is old still
AStorm: do pull the branch
nanonyme: AStorm: Iirc when I asked agd5f told drm-next was preferred to the drm r6xx-r7xx-support branch. Probably a bug if it's missing stuff.
AStorm: compare code, I recommend diff :)
mjt: what IS drm-next, anyway?
mjt: i always used r6xx-r7xx-support branch so far
nanonyme: mjt: The actual code that'll get into main kernel tree.
mjt: and where it is? :)
nanonyme: It's a branch on git.kernel.org as AStorm said.
AStorm: unless... unless the code is CPU and not git pull
mjt: looks at scrollback...
AStorm: which he shouldn't have done
AStorm: I'll check it out
mjt: hmm.. can't find it
mjt: it's only a few lines back, i searched whole scrollback - almost a week of it...
agd5f: drm-next is a branch in airlied'd tree: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
agd5f: it's the upstream drm tree
AStorm: does it have *everything* r6xx-r7xx-support has?
agd5f: AStorm: yeah
agd5f: pretty much the same code, just adjusted to work with the other upstream changes
AStorm: pity it can't be built as easily
AStorm: I'd have to pull it into my kernel tree
nanonyme: AStorm: Hmm, this is odd. Getting the think&jump window move bug only on radeonhd, not radeon. o.O
AStorm: yes, me too
AStorm: Xv is also subject there to the bug
bridgman: nanonyme; power management documeents have to be WRITTEN first, *then* they need to go through the screening process ;)
bridgman: we actually try to do the two in parallel where possible; figure out what is safe to release at the same time we're writing the docs
bridgman: more or less
bridgman: the bigger issue is that power management needs to be in drm, and right now there are so many different things going on in drm that adding power management to the mix is probably a bit daunting
bridgman: for the very short term it probably would be good to have some code to run the engine clocks more slowly; playing with memory clocks is tricky because you can end up starving the display when there's lots of drawing going on, and that's where having PM in the kernel really helps
bridgman: "whoa, look at all them 3D packets, better crank up the memory clocks"
bridgman: slowing the engine down is a lot easier since the main conseqence is slowness
AStorm: btw, I suspect this is NDAized, but does it have 0HZ operation support for subunits or undervolting?
nanonyme: bridgman: Right, sorry for spreading partial disinformation. ^^
bridgman: we're still learning about the voltage side; voltage control is not built into the chips AFAIK but (where supported) is handled by an external regulator
bridgman: no prob
nanonyme: bridgman: Btw, read that stuff about the read&jump issue we talked earlier? Iirc you talked of something about blits involved in it earlier. Could it still be the issue if the issue only exists on one ddx but not the other?
bridgman: there is some clock gating capability; some is automated, some needs to be driver controlled
bridgman: the chips are so complex these days that driver control is becoming impractical; most of the independent blocks are gone and the rest are heavily inter-dependent
nanonyme: Hrm, that is, me and AStorm talked of it some minutes ago, you commented on I talking about it a day or two ago.
bridgman: huh ?
nanonyme: Move a window around rapidly: the system sometimes stops for thinking for less than a second, then the window jumps to the new location.
nanonyme: This happens on radeonhd but not on radeon.
nanonyme: And disappears from radeonhd with compositor.
AStorm: well, I'll check myself
nanonyme: Just wondered what it was exactly you said back before. Something about blits and memory handling.
bridgman: ah yes; my recollection was that the "temp buffer" change only went into radeonhd but I haven't checked the commit logs
bridgman: please hold
bridgman: my guess was that every so often it took a while for the memory manager to cough up a big temp buffer
agd5f: no, they both use temp buffers
agd5f: code is pretty much the same
AStorm: it's doing fine here
AStorm: I'll check Xv again
AStorm: I had problems with Xv + xfwm4 compositor earlier
AStorm: it's fine now
AStorm: wait, no
AStorm: moving window around blocks Xv
AStorm: doesn't happen with radeon!
AStorm: actually, any window update
AStorm: this is some major Xv bug
AStorm: radeon has no such problem, but I'll better check ring buffer size radeonhd allocated
nanonyme: AStorm: Does composited/non-composited affect it for you in any way on radeonhd?
AStorm: yes, works faster not composited, but the effect is still there
AStorm: how do I increase ring buffer size on radeonhd?
agd5f: AStorm: you have to edit the code
AStorm: but I think radeon doesn't have the problem even with default ring buffer size
AStorm: (in a few seconds, have to finish scanning some tracks for replaygain/RVA)
agd5f: although I don't really think there's any need for a ring larger than 1 MB though since most commands are in IBs
bridgman: ok, another beautiful theory destroyed by an ugly fact
AStorm: the Xv blocking doesn't happen w/o composite
AStorm: bridgman, hmmh? :>
AStorm: seems it's some bug in radeonhd handling of composite
AStorm: vs Xv
AStorm: note: I used mplayer for playback
AStorm: I'll test with xcompmgr now
AStorm: xcompmgr -c also causes this
AStorm: actually, any composite
AStorm: and not just Xv
AStorm: other window moves can cause it too
AStorm: now checking if it's the shadows
AStorm: ok, it's not the shadows
AStorm: client side compositing is broken with radeonhd
AStorm: might be some operation not accelerated properly - window moves cause this
AStorm: actually, seems like all composite copy operations are unaccelerated
agd5f: AStorm: try removing the call to wait_vline_range() in R600DisplayTexturedVideo() in r600_texturedvideofuncs.c
AStorm: agd5f, but that won't fix any other composite
AStorm: it's related to composite and not Xv
agd5f: AStorm: sure it will
AStorm: moving composite windows can trigger this too
agd5f: it's not checking if the surface it's rendering to offscreen or not, so it always inserts the wait
AStorm: w/o any Xv
agd5f: ah, ok
yangman: ugh. damn video standards
yangman: I'm gonna have to try and find a book on this stuff...
oyvind: Hello folks .. Just a simple question: is it possible to get tear free XVideo playback with latest radeonhd git snapshot on ATI X1400 hardware ?
agd5f: oyvind: no, you'll need radeon
oyvind: k, thanks
nanonyme: Now, that was an odd issue. Switched to VT and back with DRI and EXA on, mouse worked, numlock worked, screen didn't fully update graphics and nothing else worked.
nanonyme: (Also the soft shutdown sequence using power button didn't work)
Samushka: i installed radeonHD on my ATI HD4850, when i try to run compiz, i get a white screen with a mouse cursor... anyone know as to maybe why? ... glxinfo | grep direct = direct rendering: Yes
Samushka: also have ... Option "AccelMethod" "exa" ... and ... Option "DRI" "on"
kepstin: Samushka, with recent xorg versions, "glxinfo | grep renderer" is a little more relevent. I didn't think there was a working opensource 3d driver for a radeon 4850? not sure about that.
Samushka: is compiz considered 3d rendering ?
kepstin: compiz uses 3d rendering, yes.
Samushka: ah okay
Samushka: whats teh progress on 3d rendering fo RV770 ?
kepstin: not a clue, althoug i hear it is being worked on :)
Samushka: i also heard there was a seperate branch for rv6xx and rv7xx now
yangman: Samushka: DRI support is non-existant at the moment. AMD is adding mesa support in-house, but no ETA
Samushka: dammit... catalyst isn't working w/ xorg 1.6
Samushka: and arch abandoned catalyst for radeonHD
kepstin: yeah, i don't see anything for rv6xx or rv7xx in the public mesa branches from a quick peek.
AStorm: Samushka, there's no 3D for r6xx and r7xx yet
AStorm: (not until someone writes a gallium pipeline)
kepstin: the xorg ati and radeonhd drivers had a seperate r6xx/r7xx branch for a while, but it's been merged into master for both now.
AStorm: yeah, but still no 3D obviously :)
kepstin: well, yeah, those aren't 3d drivers :)
AStorm: 2D accel is mostly fine (with radeon driver - I'll test radeonhd now again)
kepstin: doesn't use 3d much, but is quite happy with the nicely working xv on his 4670 :)
kepstin: anyways, Samushka - regarding the direct rendering thing - modern versions of mesa support direct rendering with the software renderer, so 'direct rendering' does not mean hardware accellerated :)
AStorm: yeah, and it's faster than indirect
AStorm: heck, latest glxgears even uses xcomposite as its background
AStorm: cogs on transparent background look funny
AStorm: Composite still uses indirect rendering
AStorm: (because there's no other way)
kepstin: well, you can use compositing with direct rendering, it just breaks in interesting ways :)
AStorm: not really, you can't
AStorm: I mean, you can, but can't mix it with other windows
AStorm: major breakage will occur then ;P
kepstin: well, it'll just render the 3d over the other windows
kepstin: xv in overlay mode is fun like that, too :)
airlied: I can on my cards
airlied: has been playing with gears inside compiz for a few weeks now
kepstin: hmm. isn't dri2 supposed to be fixing that, actually?
airlied: thats what DRI2 is mainly for
AStorm: ok, found the problem apparently
AStorm: seems like some Composite copy is not accelerated
AStorm: so client-side composing is slow
AStorm: (from time to time - probably related to ring buffer fill?)
AStorm: doesn't happen with radeon driver
AStorm: at least much slower than on radeon
AStorm: drat guys, you really should merge
AStorm: I suspect the next step after doing HDMI is futzing with the unprotected output... bleh