osiris_: airlied: have you looked at the bt?
airlied: osiris_: probably not :)
Vash63: Hmm. So I'm trying out the git release and when I have "ForceLowPowerMode", Xorg crashes.
ickle: airlied, in which tree do you keep your for-review/testing patches?
mikkoc: i thought last commit in xf86-video-ati was supposed to fix: radeon_dri2.c:171: error: 'struct
airlied: ickle: normally unpublished so I can freely rebase
airlied: at the moment though I've just been a bit under the weather so I'm just being lazy
ickle: airlied, yeah I'm still learning the constraint not to rebase trees I've pushed :(
airlied: everytime I publish a tree and someone quotes a commit id that disappears Linus smashes me
Vash63: Eh, submitted a bug report. The list of open bugs is pretty huge with some that haven't been updated in years... is it still actively maintained?
airlied: Vash63: mostly
Vash63: Hmm. Ok. I don't know much about driver dev but I have a feeling my problem is related to my somewhat-rare setup, with the PLX chip and all.
Vash63: Anyone know if ForceLowPowerMode has been tested on an R700?
airlied: Vash63: X doesn't crash in that log
Vash63: Yeah, it just hits 25% CPU usage and locks and stays there.
Vash63: And refuses to close.
Vash63: (quad core)
Vash63: I can SSH in with my phone to look at it.
airlied: ah so it hasn't crashed as much as hung the GPU
Vash63: Something like that.
airlied: so its likely the low power mode hasn't been tested on that gpu
Vash63: The fan slows down, which is awesome.
airlied: you could try Option "DRI" "false"
airlied: to see if its DRI related
airlied: generally slowing down the gpu clocks can have side effects
Vash63: R700's pretty much just two RV770's tied together with a PLX chip right?
Vash63: So the only thing that would go wrong is if the PLX chip is messing something up?
airlied: ah the old X21
airlied: X2 even
airlied: we should only use one chip though
airlied: its more likely the down clocking code is screwing up things
airlied: than the bridge chip
Vash63: DynamicPM works.
Vash63: Or DynamicClock or whatever.
Vash63: DynamicPM and ClockGating.
Vash63: Both work.
airlied: glisse: http://people.freedesktop.org/~airlied/tile.txt
airlied: is macrotiling
airlied: now I have to translate that to some sort of sw algorithm
glisse: airlied: shouldn't we do set/get properties rather than tiling so we can latter add compression stuff (if hw ever grow automatic buffer compression)
glisse: or other surface properties that might pop up in the futre
airlied: glisse: well it depends on what info those properties need
airlied: making it generic is pointless if we don't have any idea what they looks like
airlied: say it needs cpp or width or height, we'll need a new ioctl
airlied: but yeah tiling mightn't be a great name for it
airlied: but properties seems too generic
glisse: yup well it's just that i am traumatized with having too much ioctl ;)
airlied: better having new ioctls than making crappy apis with the old ones
airlied: thats the point of them
yokto: is someone fixing the DRI2BufferPtr DRI2Buffer2Ptr issue - in case not i have a suggestion http://pastebin.com/m27498f66
glisse: yokto: i think we will switch to new interface and forget the old one
cbmuser: airlied: have you investigated into the mtrr-bug already?
cbmuser: tell me, when you want me to test :)
zoyd: anyone knowwhat's wrong? i've also pasted in #ati
fat_chris: fglrx doesnt support 2.9.30 officially, there are patches... also #ati is the channel for fglrx not here
zoyd: thanks anyway.
nanonyme: agd5f: Btw, just a note: radeon_cs.c and especially radeon_state.c seem to be way too big for my code reading speed for me to figure out how to combine it properly with 2.6.31 in time. ^^
glisse: nanonyme: you don't want to combine radeon_state.c with anythings
glisse: once we are able to delete radeon_state.c car will fly and world will at peace
nanonyme: Oh, right. ;)
nanonyme: glisse: Iirc agd5f said the r6xx-r7xx-3D changes were in those files.
nanonyme: 00:39 < agd5f> nanonyme: cool. actually all you really need to port the code to any kernel is radeon_cs.c and the new ioctl definition in radeon_state.c
nanonyme: Oh, it was just one ioctl definition? Duh.
nanonyme: glisse: Where's that ioctl stuff ending up then?
glisse: nanonyme: at very bottom of radeon_state.c
glisse: it should be one line
nanonyme: I mean, if you end up deleting radeon_state.c. ;)
glisse: same stuff is in radeon_kms.c
nanonyme: Oh, so that's how ioctl's work. :o Neat.
agd5f: nanonyme: you should be able to just copy over radeon_cs.c and add it to the makefile and copy the ioctl line from radeon_state.c
agd5f: or call it r600_cs.c
nanonyme: (I say that a lot)
nanonyme: agd5f: Sounds good, was mostly wondering how much effort it is to put that together with the rest of the new kernel stuff.
eschat: is the problem with radeon and freebsd solved?
nanonyme: Which problem?
eschat: system hangs on startx
nanonyme: Is there a bug filed on it?
eschat: i dont know
nanonyme: Who did you talk to about it then? ;P
eschat: i talked about it in these chat. the problem was well known a few month ago
nanonyme: *shrug* No idea then.
nanonyme: bridgman: Came to monitor or have a comment? ;)
bridgman: I was trying to play "FreeCell and picked the wrong item" ;)
bridgman: only commment was re: forcelowpowermode on the x2 board; since there are now two different pcie buses involved (one going to the card and another between bridge and GPU) the lane reduction code probably needs changes
bridgman: and in the meantime the user might want to tweak that code to bypass the lane restriction on an x2
nanonyme: Can there be combinations of lane reduction/increase combinations (as in, the order) between the two buses?
nanonyme: Erm, complications even.
ryann: I'm running ubuntu karmic, kde4 w/compiz. I have an onboard ATI 200M card, and have not had much success with fglrx. I have X configured to use the open ATI drivers. Every so often, upon unloading X (to shutdown or reboot), the display turns to a white/black gradient and the entire system locks up. The only way out is a hard shutdown.
bridgman: ryann, this channel is for the open source drivers, try #ati
ryann: What can I do to troubleshoot this, and get the best compatibility between OS and VGA?
bridgman: never mind ;)
chithead: ryann: current fglrx does not support your chipset any more
ryann: Either my card is too old, or the fglrx just hated my chipset
ryann: I've had great results with the openati driver
ryann: video playback has been great, compiz effects as well..
glisse: ryann: have you tested git version of xf86-video-ati ?
glisse: along with recent kernel
ryann: glisse: this is the first I've looked into this further.. so no.
ryann: I am on the most recent kernel in the devel repository
Curan: ryann: probably dumb question: why don't you use the fancy effects from KWin instead of Compiz (I'd say the most often used Compiz stuff should be in KWin too; check the systemsettings out)
ryann: (note that this problem has been ongoing-- not since recent kernel)
ryann: I'm more comfortable with compiz. I have tried KWin and I found compiz to be more configurable.
glisse: ryann: yup than test with git version of xf86-video-ati and if you have issue open bug with xorg.log, kernel log and description of the problem, like usage pattern
ryann: kernel 2.6.31-2 generic
ryann: i wonder what version of the driver i have now
glisse: kernel is not the only component which matter, xf86-video-ati and mesa both have part of the driver too
ryann: 6.12.2 is the most recent on xorg
adamk: nanonyme: FYI, you may want to refer FreeBSD user questions to rnoland or the freebsd-x11 mailing list if you come across any others. Or even me, if I'm around.
nanonyme: adamk: Sure.
ryann: Am I reading this correctly? I am already running version 6.12.99 of the driver? http://pastebin.com/d664df8a
bridgman: AFAIK that's what you get if you build from git source... 6.12.99 is a placeholder for whatever the next release is going to be
ryann: should i proceed w/building xf86-video-ati-6.12.2?
glisse: ryann: use git version
glisse: git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
ryann: should i do the same for mesa, to be safe?
glisse: lot of fixes want in mesa in last few weeks
ryann: i'm exicited to try it out
ryann: so git://anongit.freedesktop.org/git/mesa/mesa and xorg/driver/xf86-video-ati
ryann: cool, ty.
ryann: wish this T1 weren't a T1.. blargh.
ryann: Curan: you asked before about KWin.. are there benefits (like less stress on the system) to use KWin as opposed to compiz?
erjc: xf86-video-ati-6.12.2_1 , rv350, 9550, pcdsd 7.1.1rc2 (freebsd7.2), X seems to loop between detection/config and 'rm xorg.conf' and failing both
erjc: pcbsd maintainer suggested disabling drm/glx
Curan: ryann: well: for me it's just »it's installed anyway« so I can use some of the effects I like/want, I have no comparison which uses less resources
Curan: ryann: but I assume it is better integrated into KDE as a part of that
Curan: ryann: so my question was essentially: might the problem be caused, because it's not a part of KDE, can it be fixed by using KDE's wm?
Curan: ryann: and it seems to be a real alternative nowadays, as it supports a wide variety of effects
ryann: i'll check it out again once i get this driver updated
ryann: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'
ryann: seem to be haivng problems compiling
nanonyme: Could check if you have xinerama-related development packages in your distro.
ajax: that means you need the X buildsystem macros installed.
ajax: xorg-x11-util-macros in fedora, some other package name elsewhere
ajax: util/macros in git
ryann: ah, thanks.
nanonyme: Probably want to prefer that package, right?
ryann: i've built and installed util/macros, same issue
agd5f: ryann: they end up in /usr/local unless you add a prefix
agd5f: so you're probably not picking them up
agd5f: ryann: right, but that path is probably not in your pkgconfig path
ryann: same damned error. i tried following the instructions on www.x.org/wiki/radeon
ryann: but same problem with xinerama
boris64_: Hi folks, i can't compile the master branch of xf86-video-ati for 3(?) days now. Could somebody check my output and give me a hint? Thank you -> http://pastebin.com/d2c2eea16
nesciens: boris64_: I think it's related to this: http://lists.x.org/archives/xorg-devel/2009-July/001324.html
boris64_: nesciens: Yes, i guess you're right. Looks like we got to wait for a proper fix?
nesciens: boris64: I guess so? Maybe nanonyme knows?
agd5f: MrCooper: the non-KMS build it pretty broken after your last set of commits
MrCooper: whoops :)
MrCooper: can you fix it, or should I take a look?
nanonyme: Me? Know something? That'd be a surprise. :p
nanonyme: (and yeah, I don't know anything of ati and compatibility atm anyway, haven't needed to keep up-to-date with master)
agd5f: MrCooper: fixed
nanonyme: radeon_dri2.c:171: error: 'struct
nanonyme: And yeah, nesciens is right, it's related to that post.
GuentherB: ryann: I think you need to tell aclocal where the macro is
agd5f: ryann: ACLOCAL="aclocal -I /path/to/macros"
nanonyme: boris64: Iirc airlied mentioned several days ago that you need to be using new version of the API which would perhaps imply something similar to DRI2Buffer2Ptr instead of DRI2BufferPtr but not sure since I haven't tried and the person airlied adviced didn't say anything on the channel after that.
nanonyme: boris64: So you could try changing line 123 "DRI2BufferPtr buffers;" to "DRI2Buffer2Ptr buffers;"
nanonyme: Might be enough, dunno.
yokto: http://pastebin.com/m573649c3 some one try it
nanonyme: Hmm, apparently various functions return DRI2BufferPtr's too.
nanonyme: (make that, replace all)
nanonyme: Assuming there's other code that relies on Dri2BufferPtr having format...
nanonyme: Yeah, clear now. :)
yokto: some one said earlyer they would drop the earlier version and the newer version has format so
nanonyme: agd5f: Do we have a pending patch for the DRI2BufferPtr->DRI2Buffer2Ptr issue or should one be written?
yokto: in case ther is non http://pastebin.com/m573649c3
phoenix64: hm, what is actually executed in a gallium driver (and the stack behind it) when the user calls SwapBuffers?
nanonyme: yokto: Well, the problem is that temporarily DRI2BufferPtr got the format member but due to ABI compliancy issues this change was rejected from X server 1.6.2. (it's not in 1.6.0 or 1.6.1 either) However, xf86-video-ati still relies on the fact that it has format.
nanonyme: The fix shouldn't be complex, mostly making xf86-video-ati use the right structs.
nanonyme: I just hate doing work someone else might have done already. ;)
agd5f: nanonyme: I haven't looked at it yet
nanonyme: Right, taking a deeper look into it then.
MostAwesomeDude: MrCooper: Don't wanna be annoying, but did you push that endian fix for r300g?
MrCooper: no, its status hasn't changed
MrCooper: but as I said, it's just the byte swapping bit in VAP_CNTL_STATUS
MostAwesomeDude: 'k. Is it fixed in classic r300, can I just steal it from there?
nanonyme: Hmm, seems I need to put several components much newer than F11 before checking out teh bug. :)
MrCooper: MostAwesomeDude: yeah, been fixed there pretty much forever
MostAwesomeDude: 'k, I'll fix it, and let random people test. :3
nanonyme: drools after Gallium3D
nanonyme: Arch. :/
nanonyme: I mean argh, Freudian.
masa-: any ideas why i get 0.5-1 second skipping forward with xv output on mplayer, about 1 or 2 times per minute?
masa-: using xf86-video-ati-6.12.2
masa-: didn't have that on fglrx, but it hard locked the whole pc a couple of times per episode..
masa-: i hate computers :<
nanonyme: Which card, what kind of videos?
masa-: HD4350, XviD and x264 encoded videos
masa-: i'm currently compiling vlc to try it out..
nanonyme: What's the CPU usage and have you tried it by setting audio out to no device?
masa-: have to wait a little for the cpu usage, it's 100% now because of the vlc compilation :p
masa-: but i think its around 10-20% max with the XviD
nanonyme: Right, can't be an issue with CPU not being fast enough for decoding then at least.
MostAwesomeDude: masa-: Do you get "your computer is TOO SLOW to play this!"
MostAwesomeDude: Do you have PulseAudio enabled?
masa-: yep, and this is a new bug/problem, they have worked perfectly before
MostAwesomeDude: Have you tried using -cache 16384 to make sure it's not just a lame video?
masa-: MostAwesomeDude: no pulseaudio shit on this pc :p
masa-: i have a WD GP hdd on my other PC and it causes 0.5-1 second _lag_ about once every 30 seconds or so (randomly..), propably because of the GP series head unload/load
masa-: so this is kinda reverse problem, i get 0.5-1 second skip ahead
masa-: why can't everything/anything just_work :/
nanonyme: Oh, I thought with r6xx/r7xx things are only *closing* the point where everything just works. ;)
masa-: well i would hope so.. :D
masa-: that things will get better some time in the near future
phoenix64: hm, enabling antialiasing on r500 automatically enables tiling, right?
phoenix64: (just playing around with the card a bit atm)
agd5f: masa-: if it was working before, bisect it and see if you can find what broke it
MostAwesomeDude: phoenix64: Hm, not sure.
phoenix64: at least that would explain what I am seeing right now
masa-: agd5f: well "before" also means different hardware/software..
nanonyme: Was the older hardware still r6xx/r7xx though?
agd5f: phoenix64: there are lots of ways to do anti-aliasing. what exactly are you asking about?
masa-: i'm not 100% sure, but i think it worked on some point with the current card and os installation and open drivers..
phoenix64: r300g, with one change, and that is R300_GB_AA_CONFIG set to 0x1 :D
masa-: at least it worked without the skipping with fglrx, but i get a lot of hard locks with them for some reason..
masa-: more so on the new pc and HD4550 or X600 cards, maybe some ACPI issues or something?
masa-: so i'm back on the old PC with currently has HD4350 on it
phoenix64: (http://imagebin.ca/view/3Or0cmY6.html, to me that looks like tiling used internally whereas the image then was read out to the screen linearly? I mean, the stripes get more yellow-ish towards the bottom, that would be tiles more on the right side?)
phoenix64: that is supposed to be trivial-tri btw
MrCooper: agd5f: I pushed some more fixes / cleanups
MostAwesomeDude: What happened to the deco?!
agd5f: phoenix64: there's more to it than just enabling that bit
phoenix64: well, didn't reset the setting, so AA was used for everything, with messed up tiling?
phoenix64: I don't know
phoenix64: hm, okay
phoenix64: is there anything in the docs about it?
agd5f: MrCooper: much better than my fix :)
nanonyme: Something very fishy is going on in here. :P
MrCooper: agd5f: let's hope it'll actually work, too :)
nanonyme: Oh, right. Completely forgot Fedora probably *was* using a patched X server 1.6 for DRI2 on Fedora 11...
masa-: hmmm, seems to work with -ao sdl
masa-: so another confirmation that alsa sucks?
nanonyme: Guess I'll have to compile the X server too then.
nanonyme: would assume SDL uses ALSA
boris64: nanonyme: Thx, the change from DRI2BufferPtr to DRI2Buffer2Ptr make the driver compile, i'll have to test if it still works as expected.
nanonyme: Hmm, compiling a stock X server 1.6.2. Let's see if I manage to get it to break already...
nanonyme: (little hard to fix an issue you're not getting)
nanonyme: boris64: Well... Might in the end make sense to have all code inside xf86-video-ati to pass DRI2Buffer2Ptr's around rather than DRI2BufferPtr's but I haven't gotten that far. Need to get the bug first. ;)
nanonyme: Still no bugs. o.O
masa-: horrible! ;)
nanonyme: Well, it is if you're expecting one and can't get it to appear.
boris64: nanonyme: I'll reload x *crossed fingers*
nanonyme: It'll probably be safe, I guess.
boris64: nanonyme: Well, looks fine 'til now. Thx for your help ;)
nanonyme: After all, it's in reality all the time DRI2Buffer2Ptr with the relevant memory area allocated even though it's called somewhere in the code as DRI2BufferPtr, me thinks...
nanonyme: boris64: Which X server version is this with?
boris64: nanonyme: shiny and new xorg-server-1.6.2
nanonyme: Oh, right. Should be there.
ryann: good news is mesa is finally compiling.. bad news is it's taking it's sweet time!
ryann: this is a relatively fresh install, so i was missing a ton of developmental headers and stuff
ryann: i may still have that xinerama issue but will cross that bridge if/when i come to it
nanonyme: Now it should break.
nanonyme: Yeah, it did.
nanonyme: Also thus far seems no fixes outside radeon_dri2.c are required.
ryann: now i face this lovely error when compiling the driver module
nanonyme: agd5f: Assuming it's as simple as I thought, this changes all the occurrences to the new version. http://koti.kapsi.fi/nanonyme/public/DRI2BufferPtr-to-Dri2Buffer2Ptr.patch
agd5f: ryann: pull the latest commits
agd5f: nanonyme: yeah, that will probably do it
ryann: agd5f: done. trying to build again
ryann: ok, great ;)
ryann: strange there was no driver "ati" already in xorg.conf..
nanonyme: You don't need it, X server defaults to ati, I think.
nanonyme: (technically I've heard it does some race condition between radeon and radeonhd but whatever :P)
ryann: i'll leave it without, since the X logs show it having loaded ati
ryann: ok, just cleaning up before i reboot.. *crosses fingers*
ryann: back up in kde, though compiz failed to start citing no whitelisted driver.. i'll check into that
nanonyme: Hmm, seems glxinfo now says "Mesa DRI R600 (unknown 9501) 20090101 TCL". Any idea what I might have done to break the chip detection there? ;)
MostAwesomeDude: phoenix64: Give me a second; fixing up r300g for those last security registers.
phoenix64: any simple task to be done on r300g?
MostAwesomeDude: Fix mipmap demos. Fix surface
MostAwesomeDude: Ag. Fix surface_copy; find out why it sometimes doesn't quite work.
MostAwesomeDude: If you're feeling adventurous, hook up the Python bindings.
ryann: crap, ati is listed
phoenix64: hm, I know nothing about python. Well, I don't know anything about the rest either, so let's see whether I am able to do anything from that *g*
phoenix64: ah, now I know, why I only tried with tri, everything else does not work for me atm :D
phoenix64: hm, why does tri fail for some window sizes? drm says that not enough data was allocated, sec
phoenix64: that is, with rawhide from yesterday, nothing else changed in my distro.
ryann: I've just updated my ati driver to the latest open driver from xorg, and upon restarting X, Compiz says there is no whitelisted driver found, though X should be loading the ati driver (and ati is listed as whitelist in /usr/bin/compiz)
phoenix64: (window size 200x200 e.g. works, that is 192x192)
MostAwesomeDude: ryann: A better question is why it's getting blacklisted. Compiz should be completely okay with radeon.
nanonyme: r6xx-rewrite getting very very close to working right with redbook hello, nice job ;)
ryann: i suppose so
ryann: hey, that's why i'm here
ryann: from all i can gather, the driver installed properly and is working
MostAwesomeDude: Unless you have a Mobility 200M, or another of the rare cards that get auto-blacklisted, it should work OOTB.
phoenix64: well, where would that error be created probably? would gallium crash if it wouldn't get any valid fb? (it does not and shows up when I resize the window)
ryann: i do have a 200M
MostAwesomeDude: ryann: Ah, that would be it. You'll have to edit the blacklist too.
MostAwesomeDude: phoenix64: Lemme see if I get one like that.
ryann: MostAwesomeDude: a compiz blacklist?
MostAwesomeDude: ryann: Yeah, compiz has a blacklist *and* whitelist. Really stupid IMO.
MostAwesomeDude: phoenix64: Nope, no dmesg problems.
ryann: i didn't touch the compiz config though.. all i've done is update the ati driver.. i just don't see how this could have happened
phoenix64: well, most programs from trivial don't render anything either, so something really is broken with this setup.
MostAwesomeDude: phoenix64: A fair amount of my trivial progs render fine. Some only work with SW TCL (that's a bug), some only with HW TCL (that's a bug too.)
phoenix64: yeah, used to work before, sure
ryann: and nothing jumps out on the blacklist line.. ugh
phoenix64: not with this distro/setup though, what are you using?
ryann: i've pasted my Xorg log file here http://pastebin.com/d5ee32ee1
MostAwesomeDude: phoenix64: Alright, pushed. You shouldn't have any more dmesg problems.
ryann: and my xorg.conf file is here.. http://pastebin.com/d6749a3f3
ryann: if anyone has any ideas while i google and play
nanonyme: hopes he gets KMS and rootless X server soon, annoying to notice the only reason your changes don't work is you forgot the setuid root bit from Xorg binary ;)
agd5f: ryann: remove the gartsize option
nanonyme: Isn't it commented out anyway?
agd5f: in the log: (**) RADEON(0): Option "GARTSize" "64"
ryann: it is commented out
nanonyme: Ah, you're right.
nanonyme: It's obviously not in the log.
ryann: is it possible the driver isn't fully loaded or something to that effect?
ryann: glxinfo shows direct rendering is working
agd5f: ryann: what's the problem?
agd5f: log looks fine
ryann: when i try to launch compiz, it reports no whitelisted driver was found.. though all i have done was update the ati driver. no other config has changed.
agd5f: ryann: sounds like a compiz issue
ryann: probably is.. though i am skeptical with this ati card.. it's been such an uphill battle
ryann: which reminds me, let me make sure video playback is working
ryann: a-ok there
MostAwesomeDude: I'd suggest that you try #compiz, but it looks like you're already there. :3
ryann: hm.. it works if i do SKIP_CHECKS=yes
ryann: though i don't see how anything meets the blacklist criteria
ryann: ::shrug:: thanks all for the help & ears
masa-: will KMS, TTM and rootless X help to avoid those nasty hard lockups due to whatever graphics driver bugs etc?
ryann: anyway, i'll reboot a few times to see if the ultimate problem has been resolved..
ajax: no, it'll just make them kernel bugs.
ryann: which was the driver bug (or whatever) causing the machine to lock up when X unloaded
ryann: haha.. nope.. just happend. ugh
masa-: ajax: i would hope that the kernel is of higher quality and those bugs are more rare..
agd5f: masa-: it makes them easier to debug however since we can dump a lot more hw state
ajax: masa-: i would hope that too.
ajax: however, i've worked on software before, so i know better.
ryann: wow.. the rendering in kwin is terrible compared to compiz
fireun: chalks one more fubar up to jaunty ... broke support for a usb camera as well as everything else
rah: have there been any regressions in xf86-video-ati for r7xx with the recent KMS changes?
agd5f: rah: not that I'm aware of
rah: ok, thanks
nanonyme: rah: Not related to the channel, just funny coincidence with the latest r6xx-r7xx-3d commit.
nanonyme: (well, mostly related to I failing anyway)
nanonyme: Just recalled from the latest r6xx-rewrite commit that agd5f talked of DRM needing ioctl for buffer aging but didn't notice he had already put a temporary solution in the DRM. :)
nanonyme: Hmm, I guess I gould take a look now to whether or not r6xx-r7xx-3d will compile on 2.6.31.
nanonyme: (not that anyone probably cares :p)
Kano: hi, is the r600+ mesa 3d code public yet?
nanonyme: Kano: It's been public for quite some time.
nbz: Kano: http://cgit.freedesktop.org/mesa/mesa/log/?h=r6xx-rewrite
Kano: live images with that code too?
nanonyme: Afaik mostly the "not public" parts are the ones that developers are working on locally.
nanonyme: Kano: Well, it's in an experimental state...
Kano: is glxgears working?
Kano: so what app works?
nanonyme: There's reports on redbook hello working on some setups.
Kano: what is that
nanonyme: I guess you'd have to ask the devs for what exactly they've tested.
nanonyme: Redbook hello is a simple OpenGL application that draws a white rectangle on black background.
Kano: how exiting
fireun: whats red about that? (:
chithead: if you read the r6xx-rewrite commit messages, you will occasionally find names of demos that have been made work with that particular commit
nanonyme: fireun: The book that it's from had red covers afaik.
nanonyme: Some programming guide, I guess.
nbz: Kano: http://jbridgman.livejournal.com/945.html
Kano: you need 2.6.28?
nanonyme: It's recommended.
nanonyme: It compiles on 2.6.29 and I've a patch to get it to compile on 2.6.30 but it behaves better on 2.6.28.
nanonyme: (r did on my setup anyway.
nanonyme: Most of the devs are using older kernels, not much testing on the newer ones.
Kano: different to intel it seems
nanonyme: Kano: Got spare time and proper hardware for testing it out? :3
Kano: well the compile fix for fglrx + 2.6.31 i found seems to be only working by accident
nanonyme: fglrx is probably going to break pretty bad with 2.6.32, btw.
Kano: so i am waiting for a better fix. do you have got live images to try? dont like to compile the whole day
nanonyme: Not me anyway.
Kano: the fglrx support is really bad... for nv all i need is a patch for 185.18.14 which can be found in nvnews.net - legacy drivers work out of the box
nanonyme: guesses closed drivers are going to break pretty badly again with 2.6.32
Kano: what is so special with .32?
nbz: nanonyme: why?
nanonyme: They're dropping direct DMA access then, you have to have ported your display drivers to use DMA API instead.
Kano: is that for all drivers?
nanonyme: The old memory access is still in 2.6.31 for compatibility, needs to be enabled specifically.
nanonyme: But I'd assume open drivers won't have much issues with porting.
nanonyme: Probably more of an issue to notice such stuff beforehand than to actually change it.
Kano: hmm, usually that will only be a hard time for fglrx users then...
Kano: the devs work slower than a turtle
nanonyme: I doubt they're actually working that slow, rather that it's a huge area of bugs to squish and they're working on a different area.
Kano: still no supported kernel newer than .28 in 9-6 - and with offical patches you collect error messages in syslog
Kano: unofficial i mean, as there are no official ones...
nanonyme: *shrug* Haven't used fglrx myself for ages.
Kano: the driver is crap, was crap and will ever be
chithead: people who want to use the very latest kernels are declaredly not in fglrx target group
Kano: why do you think i use the oss driver for watching movies?
nanonyme: I noticed it's much less of an effort to keep Linux clean and do a multiboot than jump constantly back and forth between fglrx and opensource drivers.
Kano: as fglrx has problems with unloading you often need a reboot when you disable it
Kano: but the uninstall is straight forward
chithead: nanonyme: switching between open source and proprietary drivers is something your distro can make easy or hard
nanonyme: chithead: Plus Catalyst actually works on one (1) platform. ;) Don't have to guess which one it is.
Kano: i dont get what so hard for fglrx devs to write a tearfree xv
Kano: you could use opengl output. for xine i made it to work with a 2nd override option, still not as good as oss xv
MostAwesomeDude: I have a feeling that most of their paying customers are decidedly not movie watchers. :3
Kano: but kaffeine does not use that override option and therefore can not use opengl output
nanonyme: MostAwesomeDude: I have a feeling that the movie watcher consumers use Windows. ;)
Kano: it gets even more funny when you read about xvba benchmarks
Kano: which you can not use, you dont know if that would be tearfree or not
MostAwesomeDude: It wouldn't, probably.
nanonyme: Windows ATi users would probably laugh their asses off if they knew about the XvBA situation on Linux. :p
MostAwesomeDude: And, again, that's for paying customers.
Kano: it just like ati did not get money for the cards they sold to linux users
agd5f: Kano: video decode is separate from rendering. Xv or GL can be used for rendering regardless of how the decode is done (sw, xvmc, etc.)
MostAwesomeDude: fglrx is for FireGL cards first, Radeons second; devs are focusing on the enterprise customers' problems first. Why are people always amazed by this?
Kano: agd5f: so that xvba would still use xv/gl?
Kano: nv uses a vdpau output path
MostAwesomeDude: nv has video accel? If it does, it's only Xv...
agd5f: Kano: vdpau can do the decode and then it could be rendered with Xv or GL, etc.
MostAwesomeDude: You mean nvidia, right?
nanonyme: MostAwesomeDude: :3
nanonyme: (shocker, shocker, on Windows all cards use the same video decoding API)
Kano: agd5f: for mplayer you need the -vo vdpau and not only the vdpau override codec
Kano: agd5f: just the -vo vdpau can be used for software codecs too
agd5f: Kano: maybe vdpau can handle rendering as well. I'm not that familiar with it
Kano: i guess so, as currently only 1 output is supported
MostAwesomeDude: vdpau is Video Decoding/Presentation API for Unix. Has decoding and also rendering.
agd5f: my point is that the video pipeline as several parts can be accelerated by various means
Kano: is va-api only decoding?
nanonyme: MostAwesomeDude: Btw, is the thing that's planned for Gallium3D supposed to be both for decoding and presentatin then too?
nanonyme: Presentation even. :)
MostAwesomeDude: nanonyme: Yeah, you could, or you could just decode only.
agd5f: you could do motion compensation with GL and an appropriate shader
Kano: it just has to be tearfree not something that looks like fglrx...
MostAwesomeDude: AFAICT you could totally do total MPEG decoding with GL. It'd be a bitch to do CAVLC/CABAC, but you could.
Kano: MostAwesomeDude: i dont think that mpeg 1/2 is a real problem
agd5f: Kano: you could do newer formats with GL as well
Kano: even with lowend cards?
MostAwesomeDude: But man, it is so much easier to do it with something nice and unified.
nanonyme: Hrm, just wondering: can you also encode? Maybe useful if you wanted to could recode from one codec to another with the GPU
MostAwesomeDude: Well, my proposal was to have two pieces to this.
MostAwesomeDude: First piece is formats for video frames. PIPE_FORMAT_THEORA, PIPE_FORMAT_H264, PIPE_FORMAT_XVID, etc.
MostAwesomeDude: And then you have an accelerated path, called a video pipeline, which gets stuffed with callbacks by the video decoding layer.
MostAwesomeDude: And the pipe driver can override any of those callbacks that it likes, in order to try to accelerate things.
Kano: this is a new idea or is it va-api?
agd5f: yeah you could encode or decode
MostAwesomeDude: So, the video decoding layer would create a pipeline for, say, THEORA to R8G8B8A8.
MostAwesomeDude: Then, the driver would get a chance to change things like, say, MC, to its own accelerated MC.
MostAwesomeDude: And then the pipeline would get executed.
MostAwesomeDude: Kind of like the Mesa render pipeline.
MostAwesomeDude: Kano: This is my take on how we should clean up and expand on the video decoding in Gallium.
MostAwesomeDude: But yeah, you could totally generate a pipeline for R8G8B8A8 to THEORA and have Gallium encode it. Dunno how much could get accelerated...
MostAwesomeDude: ...but the beauty is that *some* of it could get accelerated.
Kano: but isnt that something you would do in opencl?
MostAwesomeDude: You could.
MostAwesomeDude: But OpenCL is going to be on top of Gallium, too.
Kano: for decoding all should focus on one standard not create new ones
nanonyme: You mean like on Windows?
nanonyme: Linux is about choices, it seems. :)
MostAwesomeDude: Kano: Already done. We agree that VDPAU is the easiest to implement, so it'll probably be started first.
Kano: same accelleration possible as with nv cards?
nanonyme: Kano: Well, it's just an API.
MostAwesomeDude: We'll be doing this for *all* cards with Gallium pipes.
Kano: sure, but i guess then you offload more to the cpu or not
MostAwesomeDude: It depends on the card.
MostAwesomeDude: For newer cards with complete video decoding engines, we might be able to use all-GPU, but only if we know how to program it.
Kano: is that xvba part already known?
MostAwesomeDude: Nope. I'd need either the API headers, so I could do a black-box RE, or I could do some things that aren't legally permitted where I live.
nanonyme: XvBA is also just an API. (and likely completely ignored by the open drivers assuming UVD docco is complete enough)
Kano: i guess when this is available for all cards 30 € cpus will be fast enough to decode full hd too ;)
MostAwesomeDude: We'll see.
nanonyme: Kano: There's Quad HD coming in a few years. *shrug*
nanonyme: Assuming GPU's are still more efficient for this stuff than CPU's at that point, it'll still make sense to do decoding on GPU's.
Kano: only for mobile devices
Kano: currently you need to spend about 60-70 € for a cpu which can handle it fine
nanonyme: Handling it and handling it efficiently are two different things though.
Kano: thats correct. but from my experience with vdpau the gfx driver can crash when the input stream has too many errors
Kano: that of course does not happen with cpu decoding
nanonyme: would prefer to use the efficient solutions as long as he pays his own electricity bills
Kano: to get it stable took quite some time vor nv
nanonyme: Ah, kernel finally got done. Now off for r6xx-r7xx-3d on 2.6.31 testing. :o
Kano: CPU[Dual Intel Core2 Duo E8400 @ clocked at 2999.000 Mhz] Kernel[Linux 2.6.31-2-generic i686] Up[-2:02-] Mem[-590.0/1977.5MB-] HDD[-1000GB(10%used)-] Procs[-162-] Client[Konversation 1.1]
biotube: i wonder if OpenCL can accerlate compiling
nanonyme: I doubt it'd be useful for that unless you have a CPU on a card that you want to use over OpenCL...
biotube: with the complexity of some languages, highly parallel parsing might be in order
ajax: that's the funniest thing i've heard all evening
ajax: thank you
nanonyme: But probably makes more sense to just buy a multi-CPU motherboard or order a supercomputer from one of the bigger vendors. ;)
MostAwesomeDude: ajax: I guess you haven't read the Phoronix articles yet. They want to know where Xorg 7.5 is.
Kano: i want to see intel larrabee for this kind of accelleration too...
ajax: MostAwesomeDude: i believe my official response to any phoronix article is "fuck you" and "get off my internet"
Kano: they are targeting 2 tflops with first release
ajax: yeah, it'll be great, it'll be an x86 with a lower power budget than the motherboard it sits on
ajax: that should be blazing fast
ajax: oh. wait.
MostAwesomeDude: Yeah, my skepticism knows no bounds WRT Larrabee.
airlied: I'm expecting the first edition will need a new PSU :)
ajax: man i'm cranky tonight. i haven't even been drinking yet.
MostAwesomeDude: It's x86+SSE2 with a few "special GPU features" thrown in. I have no idea WTF it's gonna look like.
ajax: the special features are known
airlied: ajax: does drinking increase or decrease cranky?
airlied: ajax: and I blame MGA
ajax: it's just the AVX instruction set
ajax: everything beyond that is tuning the pipeline for avx
MostAwesomeDude: I bet it'll look like a Mac Mini board with a PCI-E connector.
ajax: which, sure, that could be nice.
airlied: wonders what the Linux driver will look like
ajax: airlied: increase, up to the point where i cease being able to talk
nanonyme: airlied: Oh, you're actually assuming they'll make one in a timely fashion? :)
Kano: well i guess it is just the first strike to write gfx drivers for more cpu like gpus
airlied: stops talking
chithead: maybe it will resemble the mesa cell driver
biotube: don't most GPUs have more than 16 floating-point registers
ajax: many, many more.
MostAwesomeDude: I really, really, really hope they decide to LLVM for it. Because, y'know, you could probably write the shader compiler as an extension of the x86 LLVM target. :3
Kano: did you see the crysis benchmark on i7 with emulated dx10? they are already at 5fps with standard cpus
nanonyme: Uh, oh.
Kano: nanonyme: btw the benchmarks was done by ms
biotube: I suppose they count as a neutral fourth party in this area
Kano: just the i7 as 8 core is misleading, there are 4 core with ht
nanonyme: is very disturbed by the fact that the exact same DRM code really seems to behave different on different kernels
nanonyme: r6xx-r7xx-3d does compile on 2.6.31 now though.
Kano: i guess you patched it, a pure variant does not compile
nanonyme: Yeah, patched it a few minutes ago.
Kano: because i have got a dkms script for that
Kano: which still fails
nanonyme: Needs this http://koti.kapsi.fi/nanonyme/public/r6xx-r7xx-3d-22.214.171.124-compat.patch and on top of it this http://koti.kapsi.fi/nanonyme/public/r6xx-r7xx-3d-2.6.31-rc2-compat.patch as far as I've been able to to figure out
Kano: ok, no problem to add some patches
nanonyme: Not for end users. :p
Kano: thats the most simple thing with dkms
nanonyme: Something's going wrong before you even need the patches though since 2.6.29 doesn't require patching but the DRM still behaves different on it than 2.6.28.
Kano: as they have got the kernel ver incl. you would not need to trigger it howeve
Kano: dkms can use regexp. to trigger patching
Kano: drm-r6xx-r7xx-3d, 2.4.3+git.e9aca37b, 2.6.31-2-generic, i686: installed (original_module exists)
Kano: i did not trigger it that way
Kano: as you have got already kernel ver checks
Kano: but you could add somthing like
Kano: well with " at the end ;)
nanonyme: I'm a bit unnerved by r6xx-r7xx-3d outputting so many warnings though on 2.6.31.
Kano: dpkg --purge drm-r6xx-r7xx-3d-dkms
Kano: you can remove it
Kano: thats what i like with dkms, you can cleanly remove it
nanonyme: Well, my approach is never to install the stuff in the first place.
nanonyme: Just boot in run level 3, then load modules, then start X.
Kano: well that way you can try it without problems, you can not destroy your system as you can always revert
nanonyme: You don't destroy your system either if the modules never leave your git tree.
Kano: dkms makes backups of the original files
nanonyme: I just insmod and be done with that.
Kano: there are many ways, some are just more easy to use
Kano: triggered on install/boot of new kernels
Kano: when you look at the script it is easy to create, dont you think so?
Kano: a few tricks to get a nice version
Kano: but rest is straigt forward
nanonyme: Your distro has all git commands as unix commands? o.O
nanonyme: if ! [ -x /usr/bin/git-clone ];
Kano: sure, you can use git-clone or git clone, thats the same
nanonyme: That'd always give false on Fedora. ;)
chithead: it is a compile-time option for git whether to create the individual commands
Kano: well apt-get wont work on fedora or dkms mkdeb, you would need to rewrite those lines a bit, you can use mkrpm
nanonyme: chithead: Yeaps, that's why I noted his distro has it.
Kano: i am sure you need less than 5 min to adopt the script for fedora
nanonyme: Safer to check for /usr/bin/git imo.
Kano: i could do, if that makes you happy ;)
nanonyme: Naw, I'm not going to use it anyway, don't bother. ;)
Kano: you can try dkms mkrpm
Kano: creating deb/rpm makes it more easy to remove
nanonyme: Seriously, I prefer it that I *never* end up accidentally booting X with experimental DRM modules.
Kano: so unstable?
nanonyme: Mostly a precaution. It shouldn't lockup unless you're running OpenGL, mind.
nanonyme: I still don't like the idea system falls down under me when I'm doing something interesting.
nanonyme: (or less interesting; anyway, something I want to do)
nanonyme: doesn't recall what was the big point of storing #if 0 stuff inside code
mjr: it's like a comment except it's not
biotube: it's for when you want to remove code but still want to keep it around
nanonyme: Was just looking at r6xx-r7xx-3d radeon_cs.c.
nanonyme: There's an intriguing nesting of macros inside one function. :)
nanonyme: #if 1 inside #if 0.
nanonyme: (Pre-processor instructions, whatever)
nanonyme: I don't suppose you're supposed to be calling that function then.
bridgman: nanonyme; #if 0 usually means "I know pretty much what this code should do, but I'm not sure exactly when it should run, and I don't have time to test it right now, but I'm pretty sure the code is right so..."
bridgman: the rest of the time I think it means "I wonder if this code is causing the problem ?"
biotube: either that or "this is faster than deleting it"
bridgman: btw these days drm gets used for a lot more than just opengl, even on pre-KMS systems. All the 2d and video acceleration goes through drm on 5xx and up as well...
bridgman: biotube; yep, or "my mouse isn't working well so selecting this big block of text is gonna be hard"
mekius: I use #if 0 as a block comment when /**/ is already in use :P
biotube: I've used mice before that made selecting hard
biotube: big block with a blue button to enable select mode
airlied: bridgman: it went through drm on r100 and up also :)
airlied: it just was optional
MostAwesomeDude: #if 0 is, for me, "this doesn't compile and I don't think I need it."
biotube: anybody else have a fancy editor that know #if 0 is a comment?
MostAwesomeDude: My vim does.
arggg: does MAD share his vim config?
kepstin: arggg, he doesn't have to, the default vim syntax highlighting does that
sgcb: gedit does as well ;)
MostAwesomeDude: arggg: My vim's kind of boring. Now, my bashrc might be more interesting, if it weren't just a mashup of Gentoo, Fedora, and Debian bashrc.
biotube: speaking of default vim highlighting, why does it use dark blue on a black background? hurts my eyes
mekius: so when can I play 3D games with full AA/AF using my 4850? :D
mekius: note that's a joke ;)
biotube: I'd love 9250 performance
kepstin: biotube, it uses different colours if it knows you have a dark background terminal, but it can't always tell :) try adding 'set background=dark' to your vimrc.
biotube: looks much better
biotube: think I'll stick with Kate, though
mekius: I use scite personally, but it doesn't recognize #if 0
sgcb: configure is telling me "kernel modesetting: yes" with my r630. Is this for real?
airlied: no its just mean the src code is configured to use it
airlied: ./configure isn't exactly probing the hw
MostAwesomeDude: That'd be interesting and probably fail.
sgcb: oh :(
mekius: probably wouldn't be impossible if there was a good id->chip mapping :)
airlied: mekius: how?
airlied: its configure
MostAwesomeDude: mekius: Would still require HW probe, which usually requires root. Additionally, soon, we'll be able to have KMS for everybody. And still some people might want KMS off.
airlied: maybe I should just have it print out: Pony: yes
MostAwesomeDude: If you do that, soon we'll have to add it to the other drivers too.
mekius: All the intel users will be jealous
MostAwesomeDude: And then marcheu will add "Ponies: 2" to nouveau...
MostAwesomeDude: And we'll never hear the end of it. :3
airlied: glisse: ouch, rs480 really wants MC_FB_LOCATION ! at 0
airlied: in fcat it really wants it at where TOM left it
airlied: TOP OF MEMORY
airlied: I put the VRAM down into memory, started a compile ,trashed my VT
airlied: chvt then trashed my compile
airlied: ass this time the cursor broke my compiler
airlied: hehe.. fsck time for me then
mekius: you lost me...
airlied: mekius: it helps if you don't tell the graphics card to write the console into random parts of main memory
airlied: when you do this, console drawing will corrupt running process
mekius: lol, I bet
mekius: well sure
airlied: hmm might be reinstalling that box
DanaG: Oh yeah, that reminds me... what constitutes "top" of memory, or Flash, or such? is "top" the lowest address, or the highest? Or is that an endianness thing?
MostAwesomeDude: Top is 0, or as close as you can get. Usually the first bits of memory are reserved.
MostAwesomeDude: On the GPU, VRAM starts at 0. On main memory, the BIOS reserves a bunch, then the kernel, then PCI maps IIRC.
mekius: airlied: ouch...
DanaG: Oh yeah, that reminds me...
DanaG: I have 4 gigs of RAM in my laptop, yet "free" shows 3826 megabytes, not 4096.
DanaG: 270 megs difference.
airlied: lots of chipsets like about being able to do 4GB
MostAwesomeDude: DanaG: That's just various mappings and reserved stuff taking up mapping space. You're on 32-bit?
DanaG: Nope, 64-bit.
DanaG: Montevina, specifically.
MostAwesomeDude: Ah, well, then what airlied said. 64-bit mappings (usually) don't displace RAM, but there's still reserved space too.
airlied: which chipset?
airlied: like in numbers
DanaG: lemme' lspci it.
airlied: guesses some 945
DanaG: "4 series"
airlied: ah GM45?
airlied: you might be able to see in dmseg what is doing bad things
DanaG: I have no idea how Intel numbers stuff. It makes very little sense sometimes.
mekius: I have 4GB here and seeing 3950
mekius: wait, integrated video?
DanaG: Like, this laptop's NIC is 82566, older one was 82765.
DanaG: or something like that.
DanaG: Nope, discrete video -- 256 meg RV635.
airlied: yeah most likely a gm45 of some sort
airlied: if its paired with an r600
DanaG: I wish AMD had a Serial-Over-LAN thing. That's really the only part of AMT I actually use.
spstarr: is now unemployed for 3 months and counting
airlied: has serial over serial
airlied: but also kvm over ip
DanaG: I'd have to buy a dock to get that.
DanaG: KVM over IP is nifty, though.
airlied: synergy is KM over IP not so much the V :)