ssieb: someone mentioned a firebox demo and that it was packaged for Fedora, but I can't find it. anyone know?
airlied: fbo_firecube
airlied: yum install /usr/bin/fbo_firecube
airlied: works out tiling by hand :(
ssieb: airlied: thank you, I have no idea why I didn't see it before...
ssieb: airlied: what do I need to get framebuffer objects?
airlied: in theory if kms is running ytou should have them
airlied: but I think some fixes in the latsest mesa might be needed
ssieb: I wondered if that was the problem :-/
ssieb: isn't using kms
airlied: ssieb: no FBOs with memory manager
soreau: agd5f: I found a Hardy live session I can get fglrx working without direct rendering but enables tvout 1024x768. So I try ./radeondump -d ~/mnt/to/local/partition as root and it does not write to file. Just freezes the box. I tried the same scenario with an 'installed' session and it does the same thing. Does not write to any file
soreau: -~
soreau: In short, I cannot get radeondump to 'work'
soreau: asks glisse, too
soreau: and by 'installed session', I mean here on Jaunty with latest xf86-video-ati drivers working with 3D
terracon: airlied: agpmode 4 helps. close to speedwise with nodmodeset
agd5f: soreau: does it work if you don't specify a path for the prefix?
soreau: agd5f: Have not tried that yet actually
soreau: No -d, just run radeondump?
agd5f: soreau: radeondump -d test or whatever
soreau: um.. no
soreau: tests
soreau: agd5f: Nope, not dumping to any file just locking hard
glisse: airlied: cool, i think we should give a way to let userspace to decide if front got surface or not
glisse: i guess we won't use tiling for pixmap
glisse: i might look into pixman a little more in timeoff
soreau: glisse: Can you please tell me how to use radeondump correctly? It seems pretty straightforward but is failing for me
glisse: radeondump -d toto
soreau: It seems to lockup before it has a chance to write to file
glisse: but the one on fdo is likely broken
glisse: which card
soreau: 9600 RV350
glisse: yeah likely broken on that
glisse: i need to build valid reg table
soreau: glisse: Would you please? I am specifically trying to capture the reg pll's needed for timing correctness of tvout 1024x768
glisse: soreau: you better use the other dump tools available
glisse: won't touch radeondump before a while
soreau: glisse: I used radeontool to regmatch '*' but agd5f says info is insufficient
soreau: What other tools might be useful?
airlied: glisse: I'm adding a flag to set tiling
airlied: glisse: call surface :)
airlied: I'm having some trouble getting mesa span code working
glisse: you don't set surface for mesa right ?
glisse: i tried mesa span code few weeks ago and it was working
soreau: patiently waits
glisse: soreau: you can hack the other radeontool to print pll reg
airlied: glisse: wierd it isn't going for me now, at least with macrotiling only
glisse: look at reg which are used in the ddx
airlied: I'm just testing with trivial/readpixels
agd5f: soreau: you can add new options to radeontool or print out arbitrary regs
airlied: glisse: yes no surface in mesa
glisse: airlied: so the surface flag is in what ioctl ?
airlied: set tiling
airlied: it gets reported in get tiling
soreau: agd5f: glisse: The problem is, I do not know how to do that or which regs are interesting for what I am trying to accomplish
glisse: airlied: i would rather put it in modeset ioctl where we set a buffer as an fb
glisse: soreau: look in the ddx in the tv functions, i am sure interesting reg are their
airlied: glisse: no mixing scanout and tiling.
glisse: then it's only a matter cut/paste in radeontool
airlied: glisse: its just a really bad idea
glisse: airlied: still don't see why it's bad
soreau: glisse: Thank you for your input. I will try some more
glisse: airlied: i am not saying tiling but surface
airlied: surfaces are only on the HDP they have nothing to do with scanout
soreau: agd5f: I would like to know more specifically what I need to hack. Like hex code requests
airlied: so associating them is a bad design
glisse: i don't want userspace to believe it can have surface for other thing than fb
agd5f: soreau: in radeondump.c remove lines 143-173
airlied: glisse: we write userspace
soreau: agd5f: Ok
airlied: glisse: other people can do what they like :)
agd5f: then it will just dump the the plls
glisse: airlied: i am always assuming someone dumb might use the api we do now at latter point
soreau: agd5f: I will give it a shot
airlied: glisse: they might, but I don't really care to screw up the API to help them
airlied: wierd MESA_NO_ASM=1 gives a different answer on readpixels
airlied: still broken though
airlied: glisse: did you test macro/micro or just macro?
glisse: can't remember
airlied: hmm scaling readpixels down to a 64x64 window segfaults in the driver span code
glisse: airlied: i guess then we get report surface back with get only when bo is an fb
airlied: glisse: so far I'm just setting the surface flags in the DDX when X allocates a buffer for use as front or rotate
airlied: probaly don't need it on rotate actually
airlied: I don't think we map that ever
airlied: for dri2 buffers I just set MACRO flag no surface flag
airlied: and mesa reads the flags and sets the rb bits
glisse: airlied: my thinking was that get report the actual status for instance if bo a framebuffer with interlaced mode we need to force microtile off iirc so kernel can change tiling of framebuffer and also set the surface flag only on fb
airlied: what happens if the CPU tries to access a buffer that used to be the scanout
airlied: but isn't currently scanning out?
glisse: up to userspace to query getile to know
glisse: a framebuffer will keeps its surface even if it's not scaned out
glisse: it loose it once it's not anymore a framebuffer
glisse: memory might get tight on 32M vram with fbcon + 2 Xserver
soreau: agd5f: Still doesn't write to file. I am spent for the night however. Better fortune next try I guess
agd5f: glisse: for interlaced you need to force all tiling off iirc
airlied: glisse: thats fine with the API I have then, you can say a buffer needs a surface at setup, and only do it for frontbuffer
agd5f: also, the biggested advantage for tiling is for textures and render buffers, scanout buffers actually prefer linear or micro tiles since in the crtc linebuffer is scanline based
airlied: glisse: btw I'd also like to stop doing munmap on last unmap
airlied: at least in the DDX its a quite large CPU overhead
airlied: for F11 we had to do it to make things usefully fast
airlied: x11perf -all would take for ever without it
glisse: airlied: i guess setdomain should be enough
glisse: and we can keep mapping around
airlied: glisse: so GET_PTR doesn't erally work so well on tiled buffers
airlied: since the SSE code assume linear memroy layou
airlied: we could probably do SSE fetches up to the tile size
airlied: the microtile size I supose
airlied: hmm using GET/PUT_VALUE at least makes it more consistent
MrCooper: airlied: your renderbuffer dimension fixes did the trick for FBOs here :)
MrCooper: airlied: having a span problem?
MrCooper: airlied: note that we're missing a bo_wait before software fallbacks
kyku: hello, what to do if I get "Not Optimum Mode" on my monitor ?
chithead: kyku: switch to the optimum mode
kyku: chainsawbike, doesn't seem to work
kyku: i added serweral modelines and when I activate them I always end up using 1600x1200@30hz
kyku: (according to osd)
chithead: interlaced?
suokko: Moving from kms-support to master (video-ati) make X crash when pidgin starts :(
mikkoc: suokko: your dmesg is full of errors too?
suokko: nothing
suokko: and nothing on Xorg.log
mikkoc: ah ok
suokko: hmm. How can I copy from console? Is screen only solution?
airlied: MrCooper: well issue 1 was using GET_PTR on a tiled buffer, it might be not waiting causing the second one, or the span code is messed up still :(
airlied: one for next week
suokko: http://pastebin.com/pastebin.php?dl=mad3d8c6
suokko: some warnings when compiling video-ati from master
fireun: got a 200M here, just upgraded to Jaunty but the xserver-xorg-video-radeon driver gives appalling performance - any pointers to setting it up the right way, or should I go back to the fglrx driver if I want good video playback and game speed?
fireun: any advise appreciated in advance
suokko1: yes. MAster is crashing but kms-support branch is not
suokko1: But the peculiar part is that there is no backtrace in Xorg.log
suokko1: So is something calling exit?
suokko: I hate that stupid screen is flashing when using tab completion :(
suokko: fireun: free driver can't yet compete in 3D performance with fglrx
chithead: fireun: fglrx in jaunty does not support the 200m
fireun: er
fireun: thats disappointing?
chithead: sometimes, 3d performance can be improved by disabling low impact fallback in driconf
fireun: suokko: how about mucking with agpspeed and fastwrites?
fireun: chithead: 2fps leaves a lot of room for improvement
suokko: fireun: But if you wantto try it you could try kms-radeon from launchpad packages that might give better performance for some applications
suokko: fireun: It depends on what you are trying to play
suokko: It might be that free driver doesn't yet support many openglfeatures that would give the best performance
fireun: well, urbanterror is the usual suspect, the great push to jaunty today was for OpenOrion - but really, I noticed a huge quality and cpu overhead jump in video playback when switching to the fglrx module
fireun: suokko: yea, well openorion wants opengl 1.5? support.
suokko: fireun: 1.3/1.4 is only supported by free drivers unless using the kms driver
suokko: You could test kms with live-cd from https://launchpad.net/~xorg-edgers/+archive/radeon-kms
suokko: But read the instruction from that page about using the packages that can be found from there
fireun: yeah, I've added launchpad projects before (yay chromium)
fireun: and my dvd drive has been broken since my manufacturer's warranty expired
fireun: (:
fireun: xorg-edgers is the group to follow? (:
suokko1: fireun: xorg-edgers are providing the latest updates from graphics drivers
fireun: thanks
fireun: ah crap, the jaunty upgrade blew away my sources.list
suokko1: But there is a lot of stuff that is still in development so might include bugs
suokko1: There is backups ;)
DanaG: has R600... no 3D worth bothering with.
suokko: It wasn't video-ati calling exit :(
suokko: So where is exit called then?
suokko: Is there some way to replace all calls to exit with abort?
fireun: suokko: hey, I'll try it at least once before crowbaring fglrx back in
fireun: oh, AND upgrading the kernel
fireun: sheesh, it is kinda late to be doing all that
nanonyme: suokko: Talking of a text file?
nanonyme: Sed should do there.
nanonyme: DanaG: Yeah and not only that but also either needs quite a bit of debugging to work with newer kernels. :/
fireun: thanks for the insight guys
suokko: nanonyme: Only problem is that xserver is modular
suokko: And I did use sed to replace all calls to exit in mesa/dri/r200 and in video-ati
suokko: But still only silent exit
nanonyme: Blah.
DanaG: heh, gotta' love this DMI data:
DanaG: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346505
DanaG: =þ
scarabeus: hm
scarabeus: when i run glxgears i get this in the konsole
scarabeus: rrb is 0x8c01f48 0 300x300
scarabeus: it is flooding the list
scarabeus: 2.6.30, git head for mesa and driver
scarabeus: and libdrm
MrCooper: scarabeus: fixed in mesa Git
scarabeus: thx
airlied: suokko: I don't think exit is getting called
airlied: glibc is crashing in a realloc
suokko: and that wouldn't give backtrace then ...
airlied: well it seems to crash in the backtrace handler, or reenter or something
suokko: (If I just had 2nd machine for remote debugging everything would be easier)
airlied: the realloc is broken somehow in libdrm_radeon
DanaG: grr, danged kernel developers keep preferably breaking fglrx by removing """unused""" symbols.
DanaG: Example: commit 17f98dcf6010a1cfd25d179fd0ce77d3dc2685c3
DanaG: Same thing happened in the past with the "unused" pci_num_buses.
DanaG: s/preferably/preferentially/
DanaG: anyway, I go boot 2.6.30.
nanonyme: DanaG: Rather fglrx doesn't exist in their world. ;)
scarabeus: it soon wont exist in mine world
nanonyme: They just ignore everything that's not in the kernel tree.
scarabeus: mine ultimate goal is get rid of it in gentoo
DanaG: To be honest, since I got the new laptop, I haven't followed the nvidia.
DanaG: They may be facing the same issues.
DanaG: But this "unused" seems a bit arrogant to me.
DanaG: Anyway, I go reboot now.
DanaG: Oh, and for some reason, i915 keeps loading on 2.6.30.
nanonyme: Well, afaik the idea is that unless the code gets migrated to main kernel tree, it doesn't have to be taken into account when doing kernel development decisions...
DanaG: er. 31.
DanaG: I just wish they'd poll some of the major vendors, to say, "hey, we plan to get rid of this; make sure your next release won't need it".
DanaG: ... rather than having to wait two releases.
airlied: glisse: your realloc math is wrong
DanaG: Anyway, the ideal would be open-source all the way, but that's a work-in-progress.
nanonyme: And not just any open-source but one that can be merged into Linus' tree. ;)
airlied: glisse: I'm pushing a fix to libdrm_radeon please make sure I'm right :)
DanaG: The other issue is the i915 randomly loading.
DanaG: Now, why would it do that?
DanaG: Unloading it gives a null pointer dereference when it also unloads the acpi video module.
airlied: okay in theory the realloc fail is fixed
DanaG: anyway, reboot now.
airlied: though I suspect I need to flush more often
DanaG: Weird... evbug is also loading, despite being blacklisted.
nanonyme: Nothing depends on it?
DanaG: I can directly unload it, and it doesn't argue -- no "is used by".
DanaG: Anyway, that's a karmic thing, not a radeon thing. Likely related to the i915 thing, too.
airlied: hmm still some flushing bug I think, but ah well at least it isn't dying on its ass now
suokko: [ 320.629506] Unpin not necessary for d9151f00
suokko: Seems like some logic bug in drm
glisse: airlied: the num stuff is still buggy will comit a fix
glisse: i can't remember why i did such a complex code
nanonyme: IRC-protokolla määrittelee topicin muistaakseni tyyliin "TOPIC
nanonyme: Ja jos sen tahtoo tyhjentää, niin pistää pelkän kaksoispisteen.
nanonyme: Oops, wrong channel. Sorry.
nanonyme: God, that was embarassing.
mroconnor: :)
nanonyme: (mostly explaining to a friend how topic removal on IRC works and why the message "topic unset" in irssi is a bit misleading)
mroconnor: agreed
_moep_: lolita:/home/moep/buildtree/xf86-video-ati# git pull
_moep_: Already up-to-date.
_moep_: crap :)
spstarr: http://www.phoronix.com/scan.php?page=news_item&px=NzM2Mw
spstarr: oh?
spstarr: its time for me to begin testing
nanonyme: spstarr: Have a 2.6.28 to test it on?
spstarr: 2.6.29.4-167.fc11.x86_64 :/
nanonyme: You seriously don't want to be using that for testing.
spstarr: I can wait
nanonyme: While the r6xx-r7xx-3d doesn't give errors or warnings if you load it into that, behaviour isn't the same as on 2.6.28.
spstarr: remains in his intel GPU mode for now ;/
nanonyme: Some silent errors, I guess.
nanonyme: Last I tried, it already drew the rectangle pretty much fine on 2.6.28. Just the background didn't get blanked properly. Been one or two commits after that though.
nanonyme: (As in, in redbook hello)
nanonyme: spstarr: Well, if you don't want to go that far into testing, I suspect you might as well wait for/help with r6xx/r7xx mm... :)
spstarr: im patient :)
spstarr: having a dual GPU laptop gives me options
AndrewR: while testing latest ddx (git master) code in KMS mode i found new bug: start tvtime -> freeze. Probably some xvideo problem. also gears for some reason renders only few frames, and then window just blacks out, somethimes with small part of rotating red gear in top-left corner.
AndrewR: on rv280 with pci mode.
suokko: nanonyme: make clear && make CFLAGS="-Wall -pedantic -Werror"?
suokko: -Wextra might help too but I would predict a lot of "bogus" warnings
nanonyme: Yeah, those and the -ansi MrCooper mentioned XF86 to have had might've been nice too. (but seriously starts getting in the area where you might have to rewrite large sections of code)
nanonyme: (most of GNU userland is written with pretty loose rules and a lot of guessing from GNU libc anyway)
jcristau: using -ansi today doesn't make much sense imo
nanonyme: Probably not.
nanonyme: Demanding only posix might be relatively sane though.
nanonyme: (would suspect that -Werror fixes most of stupid stuff though)
suokko: nanonyme: You also have to enable all the warnings ;)
suokko: A lot of usefull warnigs aren't enabled by default
nanonyme: Hmm, yeah.
nanonyme: The scary thing is that a lot of the userspace emit tons of warnings even with default settings. :3
nanonyme: s/space/land/
biker_rat: http://pastebin.com/m714c4e24
biker_rat: Thisis an Xlog for a x1900GT with th Radeon driver.
biker_rat: No 2D accel. No 3D accel. Horrible problems rendering widows.
biker_rat: This is the best open source support for this card in a modern distro I could find..
biker_rat: Can you fix open source support for this card. With catalyst it is a honey, but catalyst 9.3 is the final edition and will soon be obsolete.
biker_rat: Distro is sidux livecd pre1 2009-02.
biker_rat: Ssytem is amd64.
biker_rat: Anyone in today?
biker_rat: MostAwesomeDude did you look at my pastebin?
MostAwesomeDude: biker_rat: I just woke up, give me a second.
biker_rat: Everything loads (dri xxa) and then shuts down.
MostAwesomeDude: biker_rat: Pastebin your xorg.conf. I think you have DRI disabled and XAA enabled for some reason.
biker_rat: xorg.conf is by sidux. basically it just says "radeon".
MostAwesomeDude: EXA is default in 6.12.x; I have a distinct feeling that "AccelMethod" "XAA" is in there, and I'd like to see what other goodies are in there.
MostAwesomeDude: Also it looks like there's either a kernel bug or something similar preventing DRI from being used...
MostAwesomeDude: And I have no idea why there would be rendering problems with XAA, but we really really want people to move to EXA.
biker_rat: It's like 3 lines Section radeon endsection that's it
MostAwesomeDude: Finally, without a pastebin of "LIBGL_DEBUG=verbose glxinfo" I can't diagnose 3D.
suokko: biker_rat: Logsayes that XAA is not supported with card ...
biker_rat: I have to install sidux to hard drive then. I will do so tomrrow. I installed 20 distros yesterday before I settled on slamd64 + catalyst 8.12. I am going to swap in a new hard drive. I don't want to screw up this install now that it works and I used 4 primary partitions so I am not screwing around with trying to wedge sidux into this hd.
suokko: biker_rat: You should be able to edit configfail in live session and restart X server
nanonyme: Configfail. <3
biker_rat: I tried. Iput in radeonhd into xorg conf, but radeon was still there when I restarted x.
suokko: fail!
biker_rat: What's configfail.
nanonyme: I'd assume a Freudian slip.
nanonyme: Probably meant config file.
biker_rat: By the way frame rates are monstrous with this card when it works. Alienarena 30-40 at max settings.
biker_rat: Glxgears is not a benchmark, but 10000.
nanonyme: Errr... 30-40 *is* damn high framerate in a game...
biker_rat: I'll pastbin everything in the morning, I have to go out and seize the day now.
nanonyme: Keep in mind your eyes start noticing it if momentary framerate drops under 25.
biker_rat: With every option switched on at maximum resolution , it is.
nanonyme: Yups.
biker_rat: At more moderate setting its 90-100
nanonyme: I wish r6xx/r7xx framerates get there too some day. <3
nanonyme: (then again, it's not like my display could do higher than 1280x1024 anyway)
nanonyme: MostAwesomeDude: His log seemed pretty odd, don't you think? Just "Closed DRM Master.\Direct rendering disabled", no errors. o.O
nanonyme: *shrug*
suokko: nanonyme: AIGLX also calims no dri1/dri2 capable screen
nanonyme: suokko: Yeah but DRM shouldn't have been shutting down in the first place.
nanonyme: Pretty obvious you don't get DRI1/DRI2 if that happens.
suokko: yes
scarabeus: nanonyme: btw statement 40fps is enought is not correct, when you use hight precision mouse and have really fancy display and play counterstrike :]
nanonyme: scarabeus: Note that I said *momentary* framerate.
nanonyme: If momentary framerate is always over 25, should be fine. If it's average framerate that's going roughly at 30-40 and might fall down to 10 at a bad time, you'll be in trouble. :)
nanonyme: scarabeus: The 25fps is not related to how good the display is, it's related to how much human eyes suck. :P
scarabeus: i know
scarabeus: we suck in being human
dmb: is the radeon hd 2600 a r6xx?
nanonyme: Should be.
nanonyme: bridgman: What was the tip for DRM you suggested, btw?
bridgman: biker_rat, did you try anything boring like Ubuntu 9.04 ? I *know* that has a good set of open source drivers for X1xxx
nanonyme: Commenting out some line.
bridgman: ahh, no longer required
nanonyme: He sadly left, I think. :/
bridgman: bring up the 6xx-rewrite commit log, OK ?
bridgman: Cooper found the original problem and his initial patch deleted a line
bridgman: Alex suggested a more generic patch which was :
bridgman: http://cgit.freedesktop.org/mesa/mesa/commit/?h=r6xx-rewrite&id=65cdf9c561c518a7e2c6b6584382fb2fb902ea40
Zajec: bridgman: you were talking about some double offsets counting in Mesa and drm... was that fixed?
bridgman: then Richard suggested an even more generic patch :
bridgman: http://cgit.freedesktop.org/mesa/mesa/commit/?h=r6xx-rewrite&id=bb429803e08231f5ee5fab25383be62b1952bd45
bridgman: Zajec, yes it was the "Fix color data can't be fetched" commit
Zajec: ah, thanks
Zajec: heh, quite simple, probably much harder to find :)
nanonyme: Right.
nanonyme: bridgman: Btw, does the net of changes seem a bit funny to you? :)
nanonyme: If you look at the situation before the first commit and after the second commit, it's very close to the same thing, just in a bit different order. ;)
nanonyme: As in, from "ui = ui ? unNumOfReg : ui;" to "ui = ui ? ui : unNumOfReg;"
bridgman: yep, but funny with a purpose
bridgman: Richard had the terms reversed, which caused a bunch of other subtle problems
nanonyme: Oh, right.
bridgman: which were fixed in a couple of different ways
bridgman: Richard happened to be on vacation the day of the changes (Canada Day, y'know); once he got back he realized what the real problem was, so the final fix was simpler than the interim fixes
bridgman: it would be easier if everyone's brain was wired together but we can't do that under Ontario labour law
nanonyme: Btw, I just tried it on 2.6.28 and seems the clear code (if it's due to that) doesn't work properly for me still. It draws the white rectangle if the GL window isn't on top of any other window (with a wrong colour background).
nanonyme: And if the GL window is on another window, lots of garbage.
nanonyme: This is regarding the redbook hello.
bridgman: good to know
bridgman: it seems to work on at least a few systems in house but hasn't been broadly tested at all
bridgman: what is your GPU again ? 38xx ?
nanonyme: 3870, yeah.
nanonyme: The colour in the background in the first case was consistent, btw. Iirc it was some shade of grey.
fcami: bridgman: (re: fusing brains) I'm not sure working for ATI/AMD is safe. you guys sure have weird ideas.
nanonyme: :p
fcami: on the other hand, I'm the one listening to The Locomotion in a loop on Friday night.
nanonyme: Then when the employee one day forgets to turn off the link when watching porn, everyone's gonna have a good time. :p (would this constitute work harassment?)
nanonyme: Perhaps it's a blessing humans aren't telepaths. :)
bridgman: probably; any time people tell me what they're thinking I usually end up wishing they hadn't...
fcami: nanonyme: I'm not sure John thought having user-severable links was a useful feature anyway
nanonyme: ponders on OpenCL on human brains
bridgman: I guess it depends on the bandwidth; ideal would be a "sync" button so you wouldn't have to be connected all the time
mpyne: airlied: I saw that a fix was committed for the realloc() bug, and it even works. :)
mpyne: It's still broken overall for me as the desktop doesn't update after the time when I used to have it crash, but it's progress.
fcami: bridgman: with ICAP support so that you don't sync all your life to your co-workers.
nanonyme: Then again, might be the other way around too as in co-workers simply don't want to know as much as you'd want to share. ^^
fcami: we're closing on an excellent product idea...
bridgman: yep, cue the marketing department and the powerpoint slides
bridgman: then venture capital, media interviews, and somewhere along the way we should probably do some R&D
nanonyme: Ewwww, marketing. :(
bridgman: you need marketing to do an IPO - without marketing you actually have to make the product work, which is usually really hard and boring
nanonyme: (Fun on smaller scale, I'm glad there's usually other people than me doing it on the larger scale)
marvin24: hi
fcami: we do without marketing. it's useless anyway.
marvin24: does http://cgit.freedesktop.org/mesa/mesa/commit/?id=65cdf9c561c518a7e2c6b6584382fb2fb902ea40 means, that redbook/hello is suposed to work on rs780?
marvin24: I'm asking, because it crashes my machine here :-(
bridgman: marvin24; the developers are working with discrete cards right now, don't think there has been much testing on 780 yet, so there may still be issues there
bridgman: once we get the remaining major issues out of the way we'll start looking at a wider range of hardware
bridgman: right now it's really a couple of developers each working with whatever GPU is in their system
nanonyme: Iirc currently it locks up my 2.6.29.3 too. :) Should probably set up remote gdb or something.
nanonyme: (If this is an r6xx/r7xx)
bridgman: probably safest to assume the drm won't work on anything newer than 2.6.28
bridgman: marvin24, which kernel and distro are you using ?
nanonyme: bridgman: Yeah, I more thought that eventually should probably try to find out *why* it doesn't seem to work on newer than 2.6.28. :)
nanonyme: Not highly energetic currently though, still having a flu.
nanonyme: So maybe I'll give it a pass. :p
bridgman: nah, it's good to have something to stare at when you have the flu; please carry on ;)
bridgman: you're not feeling at all swinish, I hope
nanonyme: Oink.
nanonyme: Well, probably not. I'd have a higher fever then anyway.
bridgman: do you have swine flu parties there ? apparently they're all the rage now; if one kid gets a mild case of swine flu then other parents bring their children over to visit, in the hope that they will build up immunity from a potentially more virulent form of the virus that might come in the future
bridgman: based on the old "pox parties" apparently
bridgman: seems like a bad idea
mcgreg: nanonyme: you would be doing a good thing if you could fix that problem with drm not building on >.28 kernels :)
mcgreg: you have my blessing ;)
bridgman: it builds for nanonyme, just doesn't *work*
mcgreg: oh
mcgreg: sry then, I misunderstood
nanonyme: mcgreg: Builts and loads with no problems.
nanonyme: Builds even.
nanonyme: It's just that there's oddities on runtime.
bridgman: mcgreg; of course it wouldn't hurt for you to tell nanonyme what build problems you are having
nanonyme: And nothing in dmesg so it'd take some debugging.
nanonyme: Sure.
bridgman: since he might end up staring dully at the code anyways
bridgman: drinking chicken soup
bridgman: or do you have some kind of "grandmothers fish soup" cure there ?
nanonyme: I guess I'm more of a new-age guy: I just take an overdose of vitamin C after eating and hope it helps.
mcgreg: bridgman: still the same ones I had all the time with drm-6xx-7xx-3d and 2.6.30 . I'll check it again
nanonyme: Well, 2.6.30 does have compiling problems.
nanonyme: I do know the cure to the first one and the second might be solvable by combining stuff from kernel DRM with the r6xx-r7xx-3d (agd5f said the part shouldn't matter for r6xx/r7xx 3D so might be safe to copy the file over and see if stuff starts working)
nanonyme: Meh, maybe I'll just boot to the other side of dual-boot. It's not like I've anything better to do...
nanonyme: bridgman: Yes, I decided not to even try for backwards compat initially, most to try if it works.
bridgman: the good news is that once the code gets into the kernel then everyone can kinda stop worrying about backwards compatibility for a while
bridgman: "wassa behind me, it donna' matter"
nanonyme: I know. ;)
suokko: There is always someone who wants to backport the driver ;)
bridgman: and we all support them and heave a great sigh of relief that we don't have to do it ;)
nanonyme: Well, backporting shouldn't be as bad as backwards compatibility anyway.
nanonyme: Considering even with backporting you only have to support one version of the kernel API.
bridgman: it's a tough call; with backwards compatibility you just have to "keep it working", but with backporting you have to "make it work" ;)
nanonyme: Hmm, true.
nanonyme: And I suppose the new idea of putting backwards compat stuff outside drm_compat.(c|h) reduces the work required considerably.
nanonyme: (Dunno how new it is)
nanonyme: compiles a 2.6.30.1 himself too so he'll see how well it works immediately
mcgreg: hmm I dont know if that cocerns the gfx driver, but I''ll just ask. when I play a video .. (the vuideo runs in a window behind the current one, so I cant see it, just hear the sound) and I scroll (with opera) the sounds stutters/get corrupted. is that a drm/gfx driver propblem?
mcgreg: or maxbe a video player problem?
bridgman: probably not directly a graphics driver problem, but maybe CPU load is too high so other bits can't keep up ?
bridgman: not sure how process prioritization & CPU allocation work if the window is partially obscured
mcgreg: bridgman: cpu is impossible . amd x2 5600. the video is quite small and probbaly wont even cause 5% cpu time.
bridgman: never hurts to check; there's still a lot of single-threadedness going on which makes it hard to use the full CPU power
mcgreg: hmm I just cheked with "top"
bridgman: but I agree a small video shouldn't make for much load
mcgreg: it is xorg that uses 100% of the cpu when scrolling
mcgreg: is that normal for a 1680x1050x32 screen using a radeon 4670 withg exa?
masa-: do i have to select something in the kernel config to enable KMS support? does tjhat option under staging just enable it by default, without any parameters needed?
bridgman: depends on the app; not all apps use accelerated operations when scrolling
nanonyme: Firefox scrolling was iirc pretty awful. :)
mcgreg: oh .. I thought the gfx cares cares about such stuff generally. (but then I have no idea about such stuff at all)
mcgreg: *-cares
marvin24: bridgman: sorry, needed to get some food ... - using ubuntu 9.04 with 6xx-rewrite/ati/drm and kernel from master
mcgreg: *+card
bridgman: marvin24; did drm come from ~agd5f/drm r6xx-r7xx-3d branch ?
marvin24: its from master (only the lib), modules are from kernel
nanonyme: Needs to be r6xx-r7xx-3d branch from agd5f's drm module git tree.
bridgman: yep, that's the only branch with the new 6xx/7xx cs ioctls for 3d support
marvin24: ah
bridgman: ubuntu 9.04 ships with 6xx/7xx drm support for the x server's acceleration but not for mesa
marvin24: ok - will try - does it compile on 2.6.31-rc1?
nanonyme: Probably not.
marvin24: ;-)
bridgman: nope, stay with 2.6.28 if you want some confidence it'll work
nanonyme: Haven't tried though.
bridgman: but it doesn't seem to work on 2.6.29 and doesn't seem to compile on 2.6.30, so it's highly unlikely everything will magically work on 2.6.31
spstarr: /join #fedora-devel
bridgman: I believe "low probability of success" is the correct term
nanonyme: Yeah, API changes seldom magically go away just because you wish hard they do. ;)
marvin24: will try to get it compile here
bridgman: just remember that compile != work ;)
nanonyme: (the r6xx-r7xx-3d is a bit ironically currently in a similar situation atm as Catalyst is regarding the Linux kernel; since it's not part of Linus' tree, API changes might happen without the breakages caused by the changes getting fixed)
masa-: why don't they just make the API perfect the first time around ;)
nanonyme: Because they don't have (or didn't have in the beginning) a clear vision of how it should be and they keep constantly moving stuff around? ;)
masa-: yeah, well, they should have had it ;)
nanonyme: (sure, it's always nice if you are free to make your API look more clean by changing it)
masa-: yeah, clear visions of how everything should be from the first moment are quite rare for myself also :D
masa-: always breaking everything
nanonyme: recalls his programming project last Fall where he ended up scrapping his entire API just before the demo because he found it terrible
nanonyme: Can do funny stuff when you're not responsible to anyone. :)
nanonyme: (If it was a group project, I'd probably have been strangled at that point)
bridgman: the problem is that there are only two ways to get the API right the first time
bridgman: one is going through and doing a full detailed review of all the potential use cases, essentially simulating the design along with any major alternatives
bridgman: the other is luck
bridgman: it's often less work to prototype a proposed API than to fully simulate/evaluate it on paper
bridgman: it's just that people sometimes forget they are prototyping ;)
bridgman: if you just assume that the first implementation is going to get tossed that's pretty close
bridgman: it's one of the reasons we're doing classic mesa first for 6xx/7xx 3d; hopefully we'll learn enough to get the Gallium3D implementation right first time
bridgman: and we won't have to throw anything away ;)
nanonyme: And you probably want to have KMS+mm to test it with so you don't just have to blindly guess whether it'll work or not. ;)
bridgman: wouldn't hurt...
nanonyme: (on that thought, probably nice if KMS+mm bugs could be tested against r6xx-rewrite, then Gallium3D could be written against mostly working kernel modules)
marvin24: got something compiled ...
marvin24: redbook hello works !
bridgman: congratulations
nanonyme: Nice. ^^
nanonyme: Sounds like better than it worked here then. ;) (I'm slowly starting to ponder if it's a local problem unless anyone else still has background probs with hello)
marvin24: not so fast ...
marvin24: moving the window causes some hang
marvin24: but better than nothing
nanonyme: Resizing probably does too.
bridgman: there's some kind of problem with repeated draws, probably the same thing that's taking out glxgears
bridgman: Richard's looking into it
marvin24: yeah - I'm really happy, that there is some good progress!
marvin24: keep on going
nanonyme: :)
mcgreg: nanonyme: hmm upgrading to 2.6.31-rc1, so you dont need to fix the drm problem for .30 anymore :)
mcgreg: ;)
bridgman: ooh, thanks ;)
mcgreg: ok, time to test the new kernel :)
bridgman: looks away from the screen just in case
nanonyme: wants r6xx KMS so he'll have a bigger screen for DRM code diffs :P
mcgreg: btw, I saw phenom x4 cpu 3,2Ghz for about 160 euro in a online-shop. really, when it#s down to 150, I'll buy it. thats so cool. such a great cpu for a really fair price
fireun: and I'm back.
bridgman: yeah, it's finally worth upgrading PCs again; seemed like there was a 3-4 year period where it just wasn't worth it
fireun: so the kms_radeon stuff requires kernel 2.6.31, yes? and If I've just upgraded to Jaunty, that means I still have to wait for Kosmic, or risk an alpha install (yikes)
bridgman: AFAIK yes
fireun: hmph.
bridgman: you can swipe stuff from Fedora 11 but that's probably even higher risk
fireun: linux is >difficult< (:
bridgman: F11 is the "one stop shop" source right now
fireun: yeah, I like the bleeding edge of sanity
fireun: I dont like to step over that line
mcgreg: bridgman: well, I will need a new mainboard and ram. the rest should be fine. and I will have a great 4-cpu, 4gb-ram machine :)
fireun: then I end up booting up my circa 2001 macbook and wondering why I ever ran linux (;
suokko: fireun: you can try it using the livecd
fireun: cdrom doesnt work
fireun: I need to find or buy a big usb drive
mcgreg: and from what I read in tests, the cpu has really good performance
fireun: I thought I had a 1 or two gig usb keyfob
fireun: mcgreg: you all still run big beige box PCs?
fireun: dont they make a lot of noise? (:
mcgreg: no. my box is gray ;)
mcgreg: grey
fireun: graey
masa-: now i got confused again..
masa-: is mesa/drm same as libdrm?
fireun: mcgreg: but it is generally a square like metal box?
mcgreg: not really a square.. but generally yes?
mpyne: masa-: libdrm is part of mesa/drm. but mesa/drm also has the kernel modules
masa-: hmm, ok..
masa-: just trying to build stuff to test out KMS
masa-: already compiled the .31-rc1-git10 kernel
mpyne: airlied's blog entry from about a week ago has what you need to know for what to compile
mpyne: with the exception that I *think* the kms-support branch for xf86-driver-ati got merged into master
masa-: i was just wondering about that
mpyne: masa-: what card do you have?
masa-: X600 plugged in atm, HD 4350 and HD 4550 also
masa-: but i'll have to wait a little bit longer for them..
mpyne: OK. I have r600 available but I've been using a r500 card I bought since it was (in theory) so well supported.
mpyne: Joke's on me I guess.
masa-: :)
fireun: I went with radeon because nvidia seemed to not have great linux support
fireun: what a joke
mpyne: If I enable DRI with latest drivers I get no screen updates even though the desktop is there as I can click on things
masa-: my friends are playing CS 1.5 atm, i can't cause i get immense flickering with the open drivers and lockups with the fglrx
mpyne: Ironically disabling DRI has made this card about a million times faster, except for OpenGL :-/
mpyne: anyways, I have DRM debugging dumps so I'm about to open up a bug on fd.o, hopefully the logs from root and non-root will help troubleshoot the cause
bridgman: mpyne; latest drivers from git are still development code; you're better off with stable drivers probably
mpyne: not if I want Composite support, which I do.
fireun: I could handle slow 2d performance if I could get fast video and 3d opengl
mpyne: mind you, a month or so ago enabling Composite with git drivers would simply crash the kernel hard
mpyne: so there's definite progress being made, even with the bump in the road I'm at now
bridgman: Cat 9.3 might be your best bet; that has initial composite code and works on 5xx
mpyne: bridgman: My kernel is way too high a version for that IIRC :-/
mpyne: I suppose I could see if 2.6.27 is supported since it's a kernel version with more long-term security support, but I don't like running unsupported kernels
fireun: I have cat 8.593, which I thought was the last to support the 200M
bridgman: yep, 8.593 is Catalyst 9.3 (ie the March 2009 Catalyst release)
bridgman: bbl
fireun: thats not confusing to me at all (:
nanonyme: Right. Got r6xx-r7xx-3d to compile on 2.6.30.1, now off to the interesting parts. :p
fireun: wishes laptop video cards could be upgraded
mpyne: me too
mpyne: on the other hand laptop video cards are often intel, which works nicely (except for newer intel)
mpyne: for instance my crappy Dell laptop has magnificent Composite support, my KDE 4.2 desktop is much more performant on my laptop than on this machine, which is a beast by comparison
fireun: I'd happily lose my dvd drive bay in favor of a video card module
nanonyme: Hmm, lol.
mpyne: well honestly I don't do intensive enough gaming on the laptop to make a big deal about it as long as it works
nanonyme: Apparently it works.
fireun: mpyne: full screen video playback goes hand in hand with gaming performance IMO
suokko: mpyne, masa-: video-ati master is unstable for me so better be reasy to switch to kms-support
mpyne: Even that doesn't take a monster 3D card though
nanonyme: agd5f: In case you care of r6xx-r7xx-3d working on 2.6.30 at this point in the slightest, it's apparently semi-trivial.
fireun: mpyne: I've got a 200M, its not a monster by any means (:
mpyne: suokko: Yeah, I can try that too I suppose, it looks to me like kms-support isn't being worked on which is why I switched back to master :)
fireun: are there weird dependancies for kms? or can I just handroll a 2.6.31 kernel for my jaunty box?
mpyne: fireun: A 2.6.31 kernel is enough as far as kernel deps go. You need to update libdrm per airlied's instructions, as well as updating your xf86-video-ati driver
mpyne: I don't know how recent Mesa needs to be but it has the DRI2 driver so you should probably be using Mesa git master as well
mpyne: airlied blogged about what to compile a couple of weeks ago
fireun: mpyne: hmm, is there a wiki checklist for this posted somewhere handy?
fireun: ah, will look for it then.
fireun: mpyne: my july 4 project I guess (:
nha: mpyne: note that what to compile has changed
nha: pretty much everything's in master now
nanonyme: Except KMS stuff gets disabled by default in libdrm. ;)
stikonas: and KMS stuff is disabled by default in kernel
nanonyme: True that, too.
mpyne: nha: I have master built for xf86-video-ati instead of kms-support. Actually I'm on master for pretty much everything at this point
mpyne: My KMS support is enabled in the kernel and in libdrm (at least if --enable-radeon-experimental-api is all I need)
Sarvatt: is it possible the overlay commit in xf86-video-ati master could fix this problem? http://paste.ubuntu.com/209284/
Sarvatt: wishes he had the hardware to test what he's packaging himself.
Sarvatt: got a few people getting that problem with the packages here - https://edge.launchpad.net/~xorg-edgers/+archive/ppa but the ddx didnt include the latest overlay commit when they tested it and they arent around to get them to try again :D
agd5f: fireun: there was a regression in newer versions of mesa for IGP chips like yours
agd5f: it's fixed in mesa master
mpyne: well my issue is now fd.o bug 22608
suokko: Sarvatt: btw, xf86-vieo-ati master is unstable with rv280 card for me
fireun: agd5f: hmm, still not seeing the big picture as to what is the right collection of bits to put together.
fireun: mpyne: said airlied's blog was a good list, but then nha said it was outdated already... (:
mpyne: well one thing was changed, not everything. ;)
agd5f: fireun: just dropping in a newer mesa should fix 3d performance
mpyne: If when you read "use kms-support branch" you instead say to yourself "use master branch" you'll be fine
fireun: mpyne: hah, ok.
fireun: agd5f: newer mesa with kms branch, or ...
Sarvatt: in KMS or in both cases suokko? it works fine with radeon.modeset=0 for these people
suokko: Sarvatt: in KMS
agd5f: fireun: you don't need kms for your issue
fireun: agd5f: ah well thats nice to hear.
fireun: digs into finding the newest mesa then
agd5f: fireun: besides all the kms mesa stuff is integrated into mesa master anyway. no special branches
Sarvatt: suokko: are you able to start x at all with it, or is it just flaky after the fact? these people cant even start x
fireun: agd5f: so it looks like mesa 7.4.4 is latest?
agd5f: fireun: you'll need a 7.6 snapshot
fireun: got it
suokko: Sarvatt: It's not the same problem. I have crash when I try to start pidgin
Sarvatt: ah good to know it starts up at least for you, thats what im worried about :D thanks for the info
suokko: And I would guess I'm using different code path for my card than others
suokko: I'm running now kms-support which is more or less stable
suokko: i have also patched kernel with some fixes from dri mailing list which prevents some hard locks when having high disk ussage
Sarvatt: oh ok, this problem is just on master and kms-support works fine for them. if the overlay thing wasnt the problem i guess i'll move edgers to the kms-support ddx for a bit longer :D
nanonyme: agd5f: In that tiniest amount of interest, those should make the branch compile with http://koti.kapsi.fi/nanonyme/public/r6xx-r7xx-3d-2.6.30.1-compat.patch current kernel release. ;)
AndrewR: suokko, does xvideo works for you in kms mode?
suokko: AndrewR: yes. But it is slow because of pci mode.
suokko: agpmode is now broken but when it still worked I had better xv performance with agp mode
AndrewR: suokko, for me it just hangs (one moment, i just realized i tested it with compositor active)
suokko: worse problem is that stupid alsa->pulse wrapper makes video hang if I forget to tell mplayer to use pulse
suokko: and more stupid think is that it is hard to get rid of pulse
suokko: "include/drm/drm.h:858: error: ISO C forbids forward references to ‘enum’ types"
nanonyme: Hmm?
suokko: I try to compile video-ati master with -std=c99 -pedantic -Wall -Werror
nanonyme: What's the line?
nanonyme: That is, what does it say? ;)
nanonyme: (probably different in different versions of libdrm)
suokko: typedef enum drm_bo_type drm_bo_type_t;
nanonyme: Egh.
fireun: brb (hopefully)
suokko: nanonyme: Problem is that drm_bo_type enue is defined in some other header
AndrewR: suokko, sorry, it was tvitime, not xvideo in general. mplayer works, tvtime works too without compositor.
suokko: I think drm_bo_type doesn't exists at all
suokko: So is it something left from old code?
nanonyme: I'd just comment the line out, see if it breaks more or less stuff. ;P
suokko: grep doesn't find any hits from mesa, kernel or ddx
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: Neat.
fireun: ok, well 3d fps is more than doubled, but the bad news is that 8fps is still unusable (:
nanonyme: Will write that bit of information down, will take a look into it a bit later.
fireun: however, full screen video playback is reasonable, even in low cpu speed mode
fireun: still isnt where he wants to be, however
nanonyme: agd5f: That is, with that patch it compiles, loads and functions as best as I've gotten any other kernel version to behave. I'd seriously need to bump some random user who has 2.6.30 to have him test whether my problems are local. :)
suokko: nanonyme: You could try this: make CFLAGS="-std=c99 -g -O2 -Wall -Werror -pedantic"
suokko: I tried that with libdrm now. a lot of errors ;)
nanonyme: :D
fireun: goes back to catalyst for the time being, will check back in in a couple months to see where things are at - or wait for karmic, whichever comes first
fireun: thanks for the help guys
nanonyme: Months sounds good. ^^
nanonyme: Not that things would be finished in that time but they're at least bound to progress. :)
suokko: fireun: I would suspect that something like Karmic beta might be good time to try
fireun: nods in agreement
soreau: I need help getting radeondump to dump. When I run './radeondump -d /path' it locks the machine and doesn't even create a file
fireun: waves
nanonyme: suokko: I don't really want to try. :) Besides, I think I only know how to type C89, not C99.
AndrewR: suokko, and monitor just go to sleep in the middle of internet activity (planet.freedesktop.org -> kernel.org). In KMS mode ...
soreau: I looked at the code and the only thing I can figure is the hard lock occurs before it opens the file for write
suokko: pci id can't be negative, right?
soreau: just wants to see svideo / tvout at the full 1024x768 the card is capable of outputing
soreau: suokko: I would assume not..
nanonyme: suokko: Why?
suokko: nanonyme: error: format ‘%04x’ expects type ‘unsigned int *’, but argument 3 has type ‘int *’
AndrewR: http://pastebin.ca/1483411 - full log of errors
nanonyme: would expect a coding error
suokko: because in code there is mixed sign/unsigned for pci id.
nanonyme: Yeah.
suokko: In practice that doesn't matter but strict compilation warns
suokko: It would only matter if we would be in >2^31 area
nanonyme: Hrm.
nanonyme: Probably would be good future-proofing to fix those all to unsigned if it's supposed to be non-negative...
AndrewR: http://pastebin.ca/1483415 - sorry, just want to show some period of normal activity between "Console: switching to colour frame buffer device 128x48" and error flood
suokko: Not nice headers: /usr/include/features.h:197:36: error: token "=" is not valid in preprocessor expressions
nanonyme: :P
nanonyme: Obviously different line in my headers.
suokko: chown return values aren't checked
suokko: That might be security problem (reason for warning about it)
suokko: may fail: "The chown() function was interrupted by a signal which was caught."
nanonyme: makes a note to code himself a digital parrot to listen to him while he's coding and playing interest since apparently he tends to make too much of a fuss of things and better to pour it all on a simple AI...
ikus060: Hi All, I'm having trouble with my video setting. I guess the problem is related to the video driver that doesn't detect the monitor spec properly .. For some reason, resolution of my external display connected to my dock station are not detected properly. So I'm looking for a way to debug this problem, is there a way to activate a debug logs or a verbose logs ??
bridgman: startx -logverbose N
bridgman: default is N=3, devs usually ask for 7 IIRC
bridgman: so startx -logverbose 7
ikus060: bridgman: So I need to first kill the current X .. is there a way to set this verbose logs during the startup ??
ikus060: I guess it's in /init.d ..
ikus060: /etc/init.d
suokko: blaah. I should learn to use git send-email :( It is easy generate a lot of spam
bridgman: ikus060; sounds reasonable
bridgman: at the limit of my knowledge things drop off quite sharply ;)
suokko: ikus060: if you using gdm you can set it in /etc/gdm/gdm.conf
ikus060: suokko: actually, I'm using gdm ! :)
suokko: ikus060: search for "[server-Standard]
suokko: and there is command option where you can edit the parameter
ikus060: suokko : command=/usr/X11R6/bin/X -br -audit 0 ??
suokko: yes. There you can add -logverbose 7
ikus060: Thanks
ikus060: I gonna try it
DanaG: goes off to time a reboot.
DanaG: eh, not right now, rather.
Sarvatt: is radeon KMS working on powerpc? spent the past 8 hours compiling everything to test it out and it just dawned on me to ask right as the final step (mesa) is almost done :D