rnoland_: text corruption issue is much better, but not fixed
virtuald: is there power management with kms yet? if not when do you think it will be implemented or ported?
amarks: gmake: *** No rule to make target `compiler/libr300compiler.a', needed by `r300_dri.so'. Stop.
amarks: llok like mesa master is broken
stikonas: amarks: run make distclean and ./configure. mesa works for me
amarks: stikonas: i'm on gentoo, so i'm basically starting a mesa build from scratch when i emerge, and it also updates from git, looks like a recent build failure, was working a few days ago
nha: MostAwesomeDude: you might want to use git pull --rebase in the future to avoid spurious merge conflicts when you're not actually working on a branch
zeier: I succeeded in building mesa, drm, and xf86-video-ati, but still get "[dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.". I was following http://xorg.freedesktop.org/wiki/radeonBuildHowTo. Does anybody have an idea?
osiris: nha: here's my API proposal for RS setup in gallium http://pastebin.com/me2d90ea
chithead: zeier: this means you don't use kms capable ddx
osiris: can you review it?
osiris: MostAwesomeDude: you should be interested in it too ^^^
zeier: chithead: I read that already in the howto. I shall compile xf86-video-ati against new drm with --enable-radeon-experimental-api. I compiled drm with that option, installed it, and afterwards compiled xf86-video-ati again. Did I do something wrong? Is there another thing I should do?
adamk_: zeier, drm is different from libdrm. Did you compile libdrm with that --enable-radeon-experimental-api option?
zeier: I compiled git://anongit.freedesktop.org/git/mesa/drm with that option.
zeier: so I have to compile libdrm also?
zeier: didn't know there was a difference
adamk_: No, that would be libdrm.
adamk_: So that's fine.
adamk_: Anyway, re-run configure in the xf86-video-ati directory and check to see if it says that kernel modesetting is enabled at the end of the configure process.
zeier: so, where could be the problem? Does make&make install drm, and afterwards compiling xf86-video-ati mean "compiling xf86-video ati against new libdrm" as stated in the howrto?
zeier: okay, I'll check that
adamk_: It is possible that xf86-video-ati isn't seeing the new version of libdrm you compiled.
zeier: What am I exactly searching for? Cannot find sth like that...
adamk_: Kernel modesetting: yes
adamk_: Should be displayed if it picks up the new libdrm.
zeier: Isn't stated
adamk_: xf86-video-ati is from git?
zeier: it's from-... wait
adamk_: When you ./configured libdrm, did you set a --prefix option?
PsyMan: hmm... looks like i still fail at manipulating monitor capabilities :\
zeier: otherwise it would be copied into /usr/local I think
PsyMan: wish there was more info about the aradeon bios on the net
adamk_: zeier, What does 'echo $PKG_CONFIG_PATH' show?
zeier: it's empty
adamk_: zeier, Do both /usr/lib/pkgconfig/libdrm.pc and /usr/lib/pkgconfig/libdrm_radeon.pc exist?
adamk_: Alright, so I'm running out of ideas then.
zeier: Should I follow the chapter "Bleeding Edge Code from development branch" in the howto? there seems to be handled such things as PKG_CONFIG_PATH and so on
adamk_: libdrm appears to be compiled properly and installed properly. I have no idea why it would xf86-video-ati wouldn't pick it up.
adamk_: Well, except that libdrm seems to be installed to /usr, so setting PKG_CONFIG_PATH should not be necessary.
nha: osiris: I don't know... ideally we would have RS code that doesn't require recompiling VS and FS for RS-related changes
adamk_: zeier, Can you pastebin the config.log from xf86-video-ati and libdrm ?
nha: osiris: in other words: compile VS, fix the order of output registers only based on VS; compile FS, fix the order of input registers on the pixstack only based on FS
nha: osiris: then compute the RS based on the compilation result of VS and FS, without having to recompile VS/FS
nha: osiris: this would imply that rs_request_attrib's out_nr would actually be an input parameter
zeier: adamk: I will do that
osiris: nha: I don't think it is possible
mjt: is the 32/64bit issue with console fonts when kms is enabled a known one?
nha: osiris: ultimately I believe that would be a better approach because it would save us from some recompilations, but there may be some limitations
nha: osiris: I think it's possible unless you want to use some tex stuffing tricks
zeier: drm: http://pastebin.com/f669e754b
zeier: ddx: http://pastebin.com/f14c41515
nha: so I just suspect that a nice interface may not be really possible, but I think it would be better if we avoid recompiling of VS/FS as much as possible
nha: after all, switching the RS setup is a lot cheaper than switching shaders
nha: just in terms of number of dwords in the command stream and so on
osiris: nha: yeah, tex stuffing is blocking it.
osiris: hmm, I don't think that perf hit of changing VS only would be different than changing VS and FS
adamk_: zeier, It does not look like that xf86-video-ati is the latest from git.
adamk_: zeier, It says: "xf86-video-ati configure 6.12.4"
adamk_: zeier, That should be "xf86-video-ati configure 6.12.99"
nha: it should be possible to make a VS-only or FS-only switch faster
nha: but of course, hard to tell without actual benchmarks and profiling
zeier: adamk: yes, you are right. That comes from using stable branch (as described in the howto). I'll revert to bleeding edge.
zeier: Do you think that's my problem?
adamk_: Yeah, you need the latest xf86-video-ati from git.
zeier: how can I tell git to use latest instead of the selected branch=?
osiris: nha: even if the swiching VS only or FS only will be faster, there are other bottlenecks, that will probably negate the gain
adamk_: zeier, Just 'git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati' should do it.
nha: osiris: depends on the application, I suppose
zeier: adamk: even if I used that directory for my branch?
zeier: WIll the branch get overwritten automatically?
zeier: okay, just deleted the old
osiris: nha: also to get best of the switching, we should implement vs/fs manager that would modify the code start/end regs, and upload new shaders only if necessary
nha: osiris: correct
nha: that requires tracking the shader switches at runtime at selecting a "resident set" of shaders that are kept uploaded
nha: keeping in mind that we have to assume all shaders are wiped at the beginning of a command stream
osiris: nha: here's the API adopted to the idea of seperate VS/FS changes http://pastebin.com/m4136b702
osiris: nha: as you can see, there's only one change in "boolean rs_request_attrib(rc_attr attr, int out_nr);" the out_nr param is given by fs now
osiris: nha: and actually with this api there should be no problem with texture stuffing (for r300 you need to do most of the job by modifying the fp/vp)
osiris: rs would just output the same attribute twice to different locations on pixel stack
osiris: and the swizzles would do the rest
osiris: (fp swizzles)
osiris: summons bridgman
osiris: MostAwesomeDude: you need to separate the fs/vs shader emit and constant buffer emit functions (these can change separately)
osiris: MostAwesomeDude: actually nevermind, I'm already working on it
dileX: I am tracking down a problem w/ binutils-gold and linux-kernel <=2.6.31-rc1 and using git-bisect
dileX: so I have a log
dileX: the shown stat-commit is OK
dileX: so what are the next steps?
dileX: thats my manual bisect-protocol
dileX: (hmm, overread good and bad commit will do reset hard on the bad commit and compile)
vilda: hi, anybody can help me set up radeon x600 with ubuntu 9.10?
vilda: I am having heavy trouble setting up any 3d acceleration
stikonas: what's the problem?
stikonas: it should work out of box
vilda: and it even caused that my computer started hanging with 3d apps, even with ubuntu 8.10, which is my stable environment
vilda: stikonas: compiz works, but not 3d
vilda: should glxinfo report something usefull about this? since it seems that it my computer uses mesa
stikonas: pastebin it
soreau: vilda: If compiz works, 3D is working
vilda: soreau: that's strange, not my case...
vilda: but I didn't try 3d compiz effects
soreau: Unless you're using compiz-0.9 and don't have opengl plugin loaded, which is not likely the case ;)
soreau: vilda: What does 'glxinfo|grep renderer' show?
vilda: this is glxinfo
vilda: OpenGL renderer string: Mesa DRI R300 (RV380 3150) 20090101 x86/MMX/SSE2 TCL
nha: vilda: that looks like everything's working correctly
vilda: that is weird
stikonas: 3d apps will not fully work with compiz unless you use DRI2
vilda: I have smooth browser and everything
vilda: stikonas: I don't want both, I'd be satisfied with 3d without compiz
vilda: so I should somehow enable dri2?
nha: vilda: so what's the problem in the end? you get lockups with 3d? or what?
nha: vilda: you need an appropriate kernel and xf86-video-ati and boot with radeon.modeset=1
vilda: there is obviously no 3d acceleration
nha: vilda: glxinfo tells you that 3d acceleration is used; what more evidence do you need?
vilda: well compiz works, but blender is terribly slow, other gl softwares dont start
nha: maybe you should be more precise about what is failing and how
vilda: and after some seconds to minutes, I get a complete hang of the system when using anything 3d
nha: blender being slow might be a regression; or it's falling back to software because it uses unusual rendering paths
vilda: i got it even with glxgears :(
nha: somehow your report is horribly confused
nha: because you clearly shouldn't get a complete system hang if software rendering is used
vilda: I should see if I'll be able to get something '3d' with compiz working, like the cube or something
logari81: vilda: is it a clean install of 9.10 or a distribution update? I ve recently tried 9.10 from the liveCD and without kms/dri2 my X700 works better than ever. I had problems (bad 2D,3D performance) only with kms/dri2 enabled
vilda: hmm cube rotates nicely
vilda: it is clean instal on a special partitition
vilda: hmm but I obviously haven't dri2?
stikonas: no, you need to enable kms
stikonas: which I think can be enabled from grub
vilda: kms? can I set it up with startup manager?
nha: vilda: I don't know about startup manager, but you can edit the kernel command line in grub and append "radeon.modeset=1"
nha: that should do the trick if your kernel has KMS-support builtin
vilda: should be current kernel in 9.10 beta
vilda: should be somewhere ind /etc/grub.d/ ?
stikonas: vilda: if you use grub2, you can add it to /etc/default/grub
vilda: GRUB_CMDLINE_LINUX="" this one?
nha: vilda: no idea to be honest, but you can edit the command line during boot I think
nha: (of course, those edits aren't permanent, but it's useful for testing)
vilda: ok, will try to reboot and try this one. thanks a lot, will be back in 10 minutes maybe :)
vilda: thanks a lot everyone, I tried on forums with no luck, so you are first ones to give me some hints
osiris: nha: so would do you think about it?
amarsh04: thought he was in #grub rather than #radeon
vilda: hmm back with no succes...
nha: osiris: I think the interface like that seems pretty fine; it doesn't really belong into the compiler, but maybe in a r300_rs.c file in the driver
vilda: compiz runs flawlessly, anything else doesn't work...
osiris: nha: yeah, I wasn't going to put it into the rc_compiler stuff
vilda: glxgear doez over 2000 fps...
nha: but I think it's a nice way to abstract all the RS mess, and put a cleaner structure into that handling
nha: vilda: please make up your mind; either things work or they don't; I doubt glxgears can get 2000 fps with software rendering
MostAwesomeDude: I do agree that some stuff needs to change. I've got a local branch with about half of the HWTCL fast-path written.
MostAwesomeDude: Lemme explain why I did the keys for r300_state_derived.
osiris: MostAwesomeDude: great
MostAwesomeDude: So the st binds shaders a *lot*. It binds shaders it's never going to use.
nha: awesome, I just got a package update message: "Disable DST switch for Argentina tomorrow, as the Argentina government decided yesterday."
nha: not that it matters for me...
vilda: agh, hard crash this time with glxgears
MostAwesomeDude: r300_update_derived_state doesn't get called until right before a draw command. At that point, we look up the vformat and rs associated with the current vp/fp pair, and use those. (Or create them if they don't exist.)
MostAwesomeDude: This effectively turns vformat and rs into CSO.
mjt: hm. 2000 for glxgears is quite alot, no?
mjt: here it shows ~950fps
vilda: well it reported 8000 per 5s
stikonas: vilda: have you got KMS working?
vilda: mjt what card?
vilda: stikonas - not sure, how can I know?
stikonas: switch to tty consoles
mjt: it's amd780g
stikonas: Ctrl+Alt+F1, if it has native resolution and switches instantly
stikonas: then you are usint KMS, otherwise no
vilda: I wasn't sure which line is the 'kernel line', but tried twice with both last lines which had kernel version somehow in them
stikonas: also glxinfo should repost DRI2 in renderer string
vilda: ctrl alt f1 gets me to text mode
nha: vilda: easier way to check is to look at the output of dmesg, glxinfo, and the Xorg.0.log
stikonas: vilda have you ran update-grub after editing /etc/default/grub
vilda: stikonas - I just edited commands on startup
mjt: nha: cat /proc/cmdline
vilda: since in that file I didn't see anything where I could put that setting
mjt: nha: (hint: not whole world is grub ;)
mjt: (and debian for that matter)
MostAwesomeDude: We should then be able to change rs and psc and vformate as much as we like.
nha: mjt: which of dmesg, glxinfo, Xorg.0.log is not universal at least across Linux distributions?
MostAwesomeDude: Goddammit Comcast.
vilda: mjt: I should edit this one? the radeon.modeset should be with a - before it?
mjt: nha: ughm, i was referring to stikonas's comment :)
nha: ah, okay
mjt: -ETOOMANYNICKS :)
MostAwesomeDude: So, for example, in osiris' model, during RS setup you have to query the shader. That's lame. Why not just directly look at the currently bound shader instead of having this big complex API?
vilda: hmm still confused
MostAwesomeDude: As for advertising, Gallium *should* be doing things like requesting WPOS in vp if it needs it in fp.
vilda: trying again, will be back...
osiris: MostAwesomeDude: the API ain't big and complex at all. it's just 3 functions to make RS setup sane and clean
nha: MostAwesomeDude: I think osiris' API is a good idea to abstract the bit-twiddling for RS behind a sane API; however, it might be changed to make it fit better into an RS-setup-caching structure
vilda: hi guys, I am back
vilda: the radeon.modeset=1 was a good idea, and for the first time I've seen accelerated 3d on my computer, but just for a minute
vilda: besides many drawing errors, it hang again
vilda: what is strange that it reports the radeon.modeset as unknown option, ignoring
vilda: but it actually changes things
vilda: i meant for the first time with opensource driver
vilda: please where can I edit the commands for these changes to get permanent?
chithead: vilda: if radeon is built as module, /etc/modprobe.d and if it is compiled in, grub menu.lst
MostAwesomeDude: osiris, nha : If you guys want to fiddle with that stuff, be my guest.
MostAwesomeDude: I'm just as happy letting you guys figure out why gears started flickering.
vilda: hmm in modprobe are just some blacklists..
vilda: and in boot/grub where menu.lst used to be isn't anything like that
vilda: in /etc/grub.d there are some files but no menu.lst too
vilda: it's 9.10 default grub, which is grub 2 or 1.9something
vilda: it has different structure...
vilda: you know, I am just a casual user, but currently quite confused...
vilda: ok will try to reboot again and fiddle more... last try for today
osiris: MostAwesomeDude: when did it start flickering?
MostAwesomeDude: osiris: Right after I introduced the vp/fp hashing. :3
zeier: adamk: thanks for your help, 3D running here, now ;)
dileX: mjt: did you recently pushed kbuild-fixes?
mjt: no, what's it? :)
dileX: than it is another "mjt" :_)
mjt: i'm THE mjt here on freenode and on oftc.
mjt: and i'd definitely interested to know about "another" mjts :)
mjt: it's me indeed
mjt: what's up with that?
dileX: having troubles with gold and compiling recent linus-tree (2.6.29-rc8 and 2.6.30 is OK)
mjt: well, that change has nothing to do with the linker
mjt: and this is not #kernel :)
mjt: (or what channel it is, i dunno really)
mjt: i'm not familiar with kbuild. I just fixed a small bug.
dileX: mjt: small fixes sometimes can cause big changes (in both directions) :-)
mjt: this one isn't one of them
mjt: it's a no-op if your /bin/echo is from util-linux or coreutils
dileX: mjt: if you are interested
mjt: heck. and what it has to do with the patch?
mjt: it's 2.6.31. the patch is not even part of linus tree as of 2.6.32-rc4
mjt: that place i changed kicks in after the vmlinux link
mjt: to build bzImage out of vmlinux
mjt: but the whole bug is umm.. excellent. Not!
mjt: it lacks information on both sides
dileX: mjt: hehe, yupp it was not that precise as my bug-report to LKML
MostAwesomeDude: nha: Two things.
osiris: MostAwesomeDude: can you push your HWTCL fastpath?
MostAwesomeDude: First, can we use fs->info->writes_z from the tgsi_shader_info instead of our own depthwrite test, or is it not correct?
MostAwesomeDude: osiris: It's not working yet.
MostAwesomeDude: nha: Second, could you take a look at r300_shader_key_hash and fix it if it sucks? I'm not good at maths. :3
MostAwesomeDude: osiris: Lemme see if I can get enough of it working to be pushable.
osiris: MostAwesomeDude: ok
osiris: nha: you should be ok using the fs->info->writes_z. the problems are only with input stuff (like reads fogc) because of shader deadcode elimination
osiris: MostAwesomeDude: ^^^
MostAwesomeDude: tgsi_shader_info also has uses_fogcoord and uses_frontfacing. :3
MostAwesomeDude: And I have permission to add other things, if we need them.
osiris: yes, and you cannot use these
osiris: MostAwesomeDude: there are few problems with current usage of draw module.
osiris: we emit these attributes which are outputted by vertex shaders, while the VS could have such line: MAD fogc.x, tex1.x, tex2.x, -1.0
osiris: i.e. we don't emit the attributes we need in some cases
MostAwesomeDude: osiris: I know; that's part of the fastpath work.
osiris: MostAwesomeDude: and I have no idea how to fix it, because I don't know how to get attributes that are going to be read
MostAwesomeDude: Well, the frag shader knows what it's going to read.
MostAwesomeDude: And the vert shader knows what it's going to write.
MostAwesomeDude: We just have to rework the code in the middle.
osiris: MostAwesomeDude: I'm talking about the input for vertex shader
osiris: I can't find a way to get input attributes for vertex shader
MostAwesomeDude: Vert elements.
MostAwesomeDude: We're not storing them yet, just passing them to Draw and then asking Draw for them later.
osiris: where do we pass them to the draw?
MostAwesomeDude: Check out pipe_vertex_element and r300_set_vertex_elements in r300_state.
gustavderdrache: I'm trying to find out which driver a card falls under -- specifically, the Radeon x1250. I can't tell if I'd need the radeon or the radeonhd drivers for it.
adamk_: THough, personally, I prefer radeon.
biotube: both work for r6xx and r7xx
gustavderdrache: Is there a performance/OpenGL version/whatever difference?
adamk_: both work for r5xx, r6xx and r7xx.
biotube: radeonhd is just a ddx
biotube: as is radoen
biotube: they use the same OGL driver
gustavderdrache: that's where Mesa comes in, is it?
gustavderdrache: *isn't it
biotube: Mesa is OpenGL
biotube: DRM is hardware access
biotube: DDX is 2d-drawing
yangman: gustavderdrache: http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/
gustavderdrache: yangman: checking that out
yangman: btw, if anyone finds a mistake in there, do let me know :3
gustavderdrache: yangman: now it all makes sense
gustavderdrache: i'm a fairly habitual Nvidia user, so this is fairly new
biotube: radeonhd had something to do with atombios
MostAwesomeDude: radeonhd originally didn't use atombios.
gustavderdrache: is that the big difference between the two drivers?
biotube: not any more
MostAwesomeDude: I'd say the biggest difference between them is that radeonhd isn't shipped as part of Xorg.
dileX: yangman: excellent explanations
MostAwesomeDude: yangman: More or less. Didn't see anything really wrong in there.
adamk_: MostAwesomeDude, Does radeon now have the support for HDMI audio?
gustavderdrache: Anyway, thanks guys. This clears up a lot more confusion than I thought it would
MostAwesomeDude: adamk_: Christian (the guy that did it for radeonhd) posted patches to KMS a week ago, and things appear to work.
adamk_: Ahhh, cool.
dileX: yangman: a diagram showing the correlations between the software components would be fine
yangman: dileX: yeah, seems like something people want from some of the early comments I've received
biotube: what about this? http://dri.sourceforge.net/doc/dri_data_flow.html
dileX: biotube: thats sexy
dileX: hmm, thats gone
jcristau: well that was on /home
dileX: yeah, gone with the crash
dileX: hmm, the diagram is missing
zhasha: I must have caused the crash. It happened right after I uploaded my first repo
dileX: (looking through his bookmarks)
subchee: is here anyone who uses x200m ati vga & Linux? :)
zhasha: maybe. what's the problem?
adamk_: subchee, Is that really what you came to IRC to find out?
subchee: with enabled DRI the suspend/resume doesn't work for me
subchee: adamk_ : why is it a problem?
biotube: subchee: methinks he meant "get to the point"
dileX: biotube: wow
MostAwesomeDude: Looks abour right.
MostAwesomeDude: *about, even.
subchee: okay, so the point is that I'd like to know if there's a workaround for my problem or a new patch or anything
adamk_: I have not had that problem myself. I don't have an x200 with current drivers installed, but I did a while back and suspend/resume worked fine.
adamk_: subchee, What happens when you try?
subchee: my laptop goes to sleep, at least it seems okay, but after that when I'm trying to resume, it hangs.. there's only a black screen and operating system is frozen
subchee: I can restart the system with hard-reset only :(
subchee: without DRI the suspend/resume works fine
adamk_: If you switch to a VT before suspending, does it resume fine then? Do you have KMS enabled?
subchee: no, if I use a VT it does the same, just hangs on resume.
subchee: KMS.. how can I check it?
fly_: that is one LONG kernel title
adamk_: subchee, What's the output of 'cat /proc/fb' ?
subchee: it's an empty output
subchee: I googled for that and now I assuse KMS = kernel based mode setting
tormod: subchee, is this an RC410 chip?
subchee: yes, it is
tormod: it is a known bug that those have resume problems
subchee: is there any workaround for the bug?
MostAwesomeDude: Icky RC4xx.
MostAwesomeDude: Sure; don't suspend.
MostAwesomeDude: I'm serious. That's the workaround.
subchee: it's not too fast, because I have to boot up my Linux when I want to use it
fly_: still thinks thats either a power save problem or a kernel problem.. i dont have those sisues
fly_: maybe its my card
tormod: subchee, you must be from that Ubuntu report. do what I suggest there
subchee: a boot process takes 100-120 seconds for me
subchee: tormod, yes, it's me :)
fly_: @_@ thats long
subchee: I tried the most current kernel (2.6.32-rc5) but the problem is still exists
tormod: subchee, do the debugging steps I told you and add the info to the bug report. that's how bugs get fixed
subchee: and that kernel is unstable for me, so I downgraded to 2.6.31-14
fly_: look around on google theres a coupla good rc guides that will help you trim that down a bunch (ive got a bunch of services disabled that i dont need)
fly_: er the rc-5 was also stable for me
fly_: you are probably missing something in its configuration
mjt: i wonder why install and disable unneded services, instead of not installing them in the first place...
fly_: mjt, because this is fedora.. they automatically install them
mjt: so remove them
fly_: i did
subchee: well, I'm using a default Karmic Koala, so I didn't configured the xorg
MostAwesomeDude: fly_: Fedora can be installed bare-bones, y'know.
fly_: yeah most
fly_: but i am finding and reporting bugs for rawhide
mjt: damn, it has been several years when i last used rpm :)
subchee: I'll take the time to prepare a bug report
tormod: subchee, karmic does not really boot fast on rotating HD's I can tell you
fly_: ive got 4 under my belt already :)\
tormod: subchee, good
mjt: about 20 sec here with debian
mjt: from boot to gdm login
mjt: from power-on, even
subchee: tormod, the main problem is my notebook (and the bios of it), because it boots very slow... after the GRUB comes up, the Ubuntu boots quickly
fly_: yeah it takes me ~1min to issue a reboot command and be back in irc
fly_: and im in KDE now :o
franjva: hi. does anyone know what causes corruption in things like youtube or virtualbox?
franjva: i'm using r600 + kms + mesa git + driver git
mjt: franjva: like what?
franjva: the youtube videos are garbled
franjva: let me take a screen capture
subchee: I've got to sleep, good night people and thanks for your support :)
mjt: franjva: https://bugs.freedesktop.org/show_bug.cgi?id=24601 does it describe your situation?
mjt: franjva: note the second screenshot in that bugreport (the kvm screen, windows in virtual machine)
franjva: yep, that's exactly what I see
franjva: in my case, in virtualbox
mjt: here we go :)
mjt: (it's my bugreport, i submitted it a few hours ago
franjva: but I also see it in other apps. mainly youtube and image viewers like comix
mjt: sure - see other screenshot ;)
franjva: mmm... you also use 2.6.32-rc4
franjva: I thing I started seeing them when I updated to rc4
franjva: have you tried downgrading?
mjt: it's my first try at kms
fly_: rc 5 is out :p
franjva: rc5 doesn't solve it
mjt: before i used 2.6.30 without any radeon stuff
fly_: ew driverless
mjt: previous radeon (non-kms one) worked just fine
mjt: but not for 3d and not for two X sessions in parallel.
franjva: I remember seeing corruption like this before, but it was usually solved with some git update after 1 or 2 days
franjva: this has been like this for some time
mjt: if it gets noticed
mjt: so i filed the bug ;)
agd5f: franjva: use drm-next
agd5f: linus doesn't have the fix yet IIRC
mjt: is there a fix? :)
mjt: i asked about this some 10..12 times here :)
mjt: tries that...
franjva: drm-next is still based on 31-rc9, right?
mjt: agd5f: maybe you also have the fix for font issues in console? :)
mjt: the 32/64 bit issue and international fonts
agd5f: mjt: with compiz and dri1? use mesa 7.6 branch
mjt: no, on console
franjva: i've compiled 32-rc3, brb
fly_: munches pumpkin seeds
dileX: franjva mjt: missing drm-next for linus-tree
franjva: yep, 32-rc3 works. meh, i was waiting for a fix in radeon git when it was the kernel :(
franjva: dileX: that's for latest 32-rc?
dileX: franjva: 32-rc5-git1 works with it
franjva: great, thanks
mjt: oh shit ;)
fly_: so im out of the loop here maybe but nobody has explained what drm-next is to me
dileX: franjva: as a single patch
mjt: fly_: it's the patches queued for the next kernel merge
fly_: would they most likely be included in my fedora kernel?
mjt: most likely not
fly_: 2.6.32-0.24.rc4.git0.Combaticus.fc12.x86_64 #1 SMP PREEMPT
fly_: and what benefit would i see from said patches
fly_: i mean would it improve my performance with the gallium driver (which i need to reinstall)
fly_: im building the dependency list for my fedora mesa git guide so i hosed all my video again
dileX: mjt: didnt see a pull request from dave
Uncle_CM: Hi there, i tried enabling s-video on mobility 9600 (M10) for months, but i just get a scrambled picture on tv (lvds works fine). Is there a known bug for M10?
dileX: mjt: last one was this
fly_: sorry thats cross-compile mesa git guide
franjva: yep, the big patch applies almost cleanly over 32-rc5 (just an offset in one file) and fixes the bug, thanks
dileX: franjva: fine
mjt: agd5f: just rebooted with that patch, and all my corruption is now gone
mjt: ditto ;)
franjva: I thought just taking the patches from drm-next was not enough, because they might be someone else touching those files in linus kernel
mjt: and i see there's another bug like this one, already dup'ed by agd5f ;)
mjt: dileX: I wonder.. who do you think I am? :)
mjt: dileX: just to clarify: i'm just a user of the damn thing, i'm not a kernel or radeon driver developer or somesuch... ;)
dileX: mjt: hoped someone who can help to fix my gold-linker problem (but I am already in talk with one of the binutils dev)
mjt: "your" ?
dileX: mjt: seen from another side it could be a kernel-problem
mjt: agd5f: thank you!
mjt: dileX: but why do you say it's your problem? Are you gold (binutils) developer or kernel developer? ;)
dileX: mjt: sorry. its a problem I discovered (seems I was the first), but "ignored" on LKML. and the guys always want from you testing and feedback.
dileX: wow, the webmaster of kernel.org answered (took a while). hahaha
franjva: is the assertion "migrate_image_to_miptree: Assertion `srclvl->size == dstlvl->size'" a known problem?
franjva: I only see it in some old logs (from april)
franjva: but I get it in darwinia and doom3
franjva: backtrace: http://pastebin.com/m787b6541
dileX: franjva: btw, which xorg-server version?
nha: dileX: franjva: that message should be from mesa, so the mesa version and possibly kms yes/no matters
panfist: whats the difference between here and #radeonhd
Uncle_CM: Is there a howto to finetune the s-video? http://wiki.x.org/wiki/radeonTV doesnt work for me ...
MostAwesomeDude: panfist: This channel is for radeon, that one is for radeonhd.
MostAwesomeDude: But most of us are in both channels.
UnNamed: hi, is it normal that some things are slower with EXA than with XAA (in r300, and yes, i saw the warning about no render ext accel)?
panfist: ok let me rephrase the question: what's the difference between radeon and radeonhd?
MostAwesomeDude: panfist: radeonhd doesn't support KMS.
agd5f: UnNamed: depends on the system
MostAwesomeDude: UnNamed: Only for very specific things. Drawing lots of stipples? :3
agd5f: generally EXA is faster with more recent X server (like 1.5 or newer)
panfist: what's KMS?
zhasha: Kernel-based Mode Setting
UnNamed: MostAwesomeDude: no, gimp image, and it really sucks in EXA, to the point of being useless (i am not masochist)
panfist: i have an integrated hd3200, which I guess isn't well supported in the radeon driver yet. i got the radeonhd packges for my distro but i dont think they were enabled since i rebooted...it's not listed in lsmod
zhasha: panfist: radeonhd is just a DDX, it won't be listed as a kernel module
UnNamed: MostAwesomeDude: what is more, the full gtk interface take a lot more when changing workspace (scrollbars, status bar, etc... in the same image window)
agd5f: UnNamed: how much vram do you have and do you have the dri enabled
zhasha: radeonhd also has nothing to do with 3D if that's what you're after, it's ONLY a 2D driver
UnNamed: agd5f: 256M, dri on (3d works)
agd5f: if youhave limited vram or don't have the dri enabled, exa will perform poorly
zhasha: for 3D, both radeon and radeonhd use the mesa driver (r600 in your case)
panfist: i'm getting awful 2d support too
agd5f: panfist: you need a recent kernel (2.6.30 or newer) for accel on r6xx+
zhasha: do you plan on using HDMI audio? if not, you might want to try just using the radeon driver (xf86-video-ati)
panfist: no hdmi audio
UnNamed: agd5f: agp working at 8x, gart size configured to 128M (dmesg | grep "AGP aperture")... anything else i could check?
_MaggoT_: can someone help me i got hd4770 but cannot load my gpu at slackware 13
panfist: ok...i have that package for my distro...how do i choose to use that driver?
zeier: I know that glxgears is not an benchmark, but is ~2000fps normal atm? (R600 hw accel)
agd5f: UnNamed: profile the gimp and see what slow path it's hitting
zhasha: panfist: assuming you have an xorg.conf, change the Driver option to "ati"
MostAwesomeDude: zeier: Sure.
zhasha: if not, it'll work automagically
UnNamed: agd5f: with sysprof?
agd5f: UnNamed: sure
UnNamed: will have to compile module, etc then
panfist: zhasha no conf file, but something is wrong because my performance is -awful- it takes like 2 seconds to redraw a terminal if i page up/page down
zeier: Is it possible, that with kwin4 composing effects enabled, glxgear's framerate drops to ~300 from ~2000?
agd5f: panfist: is the dri enabled? it's required for accel on r6xx+ chips
zhasha: panfist: uninstall radeonhd, install xf86-video-ati, restart X, look.
zhasha: also, what kernel are you using?
panfist: zhasha i'll try that, thanks.
panfist: agd5f how do check that
zhasha: and are your vts in native resolution?
agd5f: panfist: check dmesg and your xorg log
panfist: dmesg|grep DRI has nothing. cat /var/log/Xorg.0.log|grep DRI has some stuff, "Screen 0 is not DRI enabled"
panfist: going to try to restart x
zhasha: it might be your kernel
panfist: how do i fix that :(
panfist: i'm using ubuntu 9.04 sever,
zhasha: what kernel is that running on? uname -r to find out
ossman: agd5f, is http://www.x.org/wiki/RadeonFeature up to date for r600? No GLSL support yet?
zhasha: I believe you need 2.6.30 for r600 drm
agd5f: ossman: yep
ossman: agd5f, bummer. I was hoping to run some XBMC on my R600 :/
agd5f: ossman: it's ~GL 1.4ish
UnNamed: ossman: why server?
ossman: agd5f, Unfortunately I'm not intimate with the OpenGL version numbers :)
ossman: UnNamed, I think you meant "panfist" ;)
agd5f: richard's working on some flow control improvements for the shader compiler, but it'll probaly require gallium before it's supported
UnNamed: ossman: ooops, sorry, yes, panfist
ossman: agd5f, I see. And the GalliumStatus page doesn't even mention R600, so I guess I shouldn't be hoping for anything next week :)
agd5f: ossman: fortunately, flow control is much easier than a previous asics, still, it's non-trivial
agd5f: ossman: yeah, no gallium driver for r600 yet
MostAwesomeDude: It won't happen overnight though.
ossman: agd5f, what is this flow control issue? memory bandwidth management?
zeier: what should I take, mesa 7.6 or 7.7 exp?
agd5f: ossman: writing a compiler that supports flow control
agd5f: a shader compiler
panfist: do i need 2.6.30 for any version of the radeon driver or just the current version? because it doesnt make much sense for my distro to package the driver with an incompatible kernel
panfist: i just tried to install xf86-video=-ati and it says it's built from the radeon driver
agd5f: ossman: compiler that compiles mesa ir into card specific shader asm
ossman: agd5f, I still don't see the term "flow control" coming naturally into that context :)
agd5f: ossman: well shaders with loops, if/else, etc,
panfist: ossman i'm using server because this machine is primarily a ssh, file, web server
zhasha: panfist: the driver works but has no direct rendering
ossman: agd5f, ah, handling control flow ops then :)
Kano: what the problem here
agd5f: ossman: yeah
ossman: I was thinking flow control as in resources management
ossman: like bandwidth
zhasha: the problem is that there has to be drm kernel module for DRI, which you don't have
agd5f: Kano: probably new stuff that's not supported on older xservers
Kano: then maybe test it on older xservers
agd5f: Kano: should be easy to patch
Kano: would be nice when it would compile
panfist: i have the exact same hardware at my office and from a vanilla install of debian i am getting acceptable 2d performance; i'm 99% certain that kernel is not as new as 2.6.30. i just want basic 2d performance like being able to scroll a terminal smoothly at least
Kano: i revert only one patch
panfist: i uninstalled anything matching ati or radeon from my system and now my cursors, window decorations, etc are all rendering in acid mode and i still have terrible 2d
panfist: then i went to try to install xf86-video-ati and it says it's based on the radeon driver which apparently isn't supported in my kernel, so im very confused
bobbens: [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
bobbens: ^ interesting...
chithead: bobbens: your ddx is not kms capable, you need git master
chithead: or the radeon devs need to tag a kms capable (pre-)release
bobbens: well this is with arch linux binaries
chithead: bobbens: then no kms for you
bobbens: well I noticed it did activate the framebuffer while loading
chithead: bobbens: yes, kms gives you framebuffer console
bobbens: so basically kms is kicking in and the module is crapping out
bobbens: what I don't understand is why it gives that error message if 2.0.0 > 1.17.0?
chithead: yeah, the message could be improved
bobbens: well they recommend disabling kms (arch guys)
panfist: if i were using the radeonhd driver, would the pattern 'radeonhd' appear in dmesg or Xorg.0.log ?
chithead: panfist: in Xorg.0.log
panfist: it's not appearing there, when i believe it should...
panfist: if i type in glxinfo, i get "unable to open display"
Kano: panfist: exit
ossman: ok, I have an entirely different issue. tv-out seems to hang my r300, even before X
ossman: who's the tv-out expert? :)
agd5f: ossman: hang?
ossman: completely locked up machine
ossman: and no decent signal out on the svideo port
panfist: the command 'glxinfo | grep renderer" returns "Software rasterizer" ... that's not what i want.. :(
chithead: panfist: run glxinfo as the user logged into X, also make sure you have permission to access /dev/dri
agd5f: ossman: and it works ok when it's disconnected?
agd5f: ossman: using kms?
ossman: I just switched from an external tv convert to directly connected
ossman: figuring the driver was mature enough to run tv-out :)
ossman: yeah, kms
ossman: I'm about to try without kms
panfist: chithead glxinfo was run as the user logged into X, not sure how to check for permissions of /dev/dri
agd5f: ossman: what kernel?
ossman: it's fedora rawhide, so it should be fairly up to date stuff
panfist: http://pastebin.com/m3ddd214a <-- my Xorg.0.log
chithead: panfist: "ls -l /dev/dri"
panfist: ls /dev|grep dri #returns nothing
agd5f: ossman: file a bug
chithead: panfist: you are using the vesa driver. install xf86-video--ati
agd5f: ossman: you might try airlied's drm-next branch first
ossman: agd5f, this machine is sloooooow. compiling kernels is not an appealing thought :)
ossman: agd5f, ok, starting without KMS avoids the hang
ossman: but there is no signal out once X has started
agd5f: ossman: doe it work ok if you enabled tv-out after starting X? for both kms and non-kms?
ossman: let me check
ossman: hmm... odd... now it says that S-video is disconnected
ossman: but it decided to select a 1024x768 mode on it
agd5f: ossman: is the tv the only monitor connected?
ossman: yes, it was
agd5f: tv-out load detection is kind of unreliable on older chips
ossman: now I have both TV and a monitor hooked up
ossman: and behold! tv-out works
agd5f: so it's likely not detecting anything and failing
ossman: that wouldn't really explain the hang
ossman: so it is doing something
agd5f: in non-kms, you can force tv-out with options in your config
ossman: this is a HTPC. I can't very well have a monitor sitting next to it just to make the driver happy :)
agd5f: well, the drm may be dying somehow when no outputs are connected
ossman: that theory is easily tested. I can just yank everything
ossman: agd5f, no hang with nothing connected
ossman: so it is doing something stupid with only s-video attached
fredrik_: Hello All. I'm on a DEll Latitude d610 and I'm fiddeling with the S-video output and just got it working following this guide. http://www.x.org/wiki/radeonTV. The only problem is that the picture is "cut off" to the right and at the bottom. I can se as far as the klock and my login name att the ubuntu top bar... Can this be fixed?
panfist: i installed those xf86-video-ati drivers and i'm finally back in x, which is rendering in totally psychedelic colros
panfist: ls /dev|grep dri is still returning nothing
ossman: panfist, how about "lsmod | grep radeon" ?
panfist: someone here told me earlier that "radeon is just a ddx so it wouldn't show in lsmod"
panfist: returns nothing
biotube: panfist: the drm module is also named "radeon"
UnNamed: panfist: and by psycocolours, do you mean they change when you change application?
fredrik_: no one that have info on the s-video out feature?
ossman: fredrik_, I think it is possible to shift it around
ossman: but I'm afraid I don't know how
airlied: fredrik_: there are some randr properties I think
airlied: xrandr --props
airlied: not sure how mch you can move it with those
ossman: airlied, ever heard of system lockups when using s-video?
ossman: (only with kms9
airlied: ossman: not specific to using s-video no
ossman: if I have _only_ s-video attached, then it completely kills the machine
ossman: having s-video and VGA works fine though
panfist: unnamed no they don't change, theyre just not what theyre supposed to be. the black of my font, the part thats supposed to be #000000 is black, i think, but all the fancy anti-aliased parts around it are seemingly random. my background, supposed to be the orange/brown of ubuntu, is a weird rainbow. like the colors are remapped
airlied: ossman: kills it or display nothing? can you sh?
UnNamed: panfist: uh... maybe you ended with a 256 colour mode
ossman: airlied, completely hosed machine. it only responds to a 4 second power button push
fredrik_: ossmand xrandr i have tried to use --output S-video --set tv_horizontal_size xxx with different values and shure, it shifts the screen around but it is still cut to the right. If i move the screen to the left I get a black part to the right. Is there more options I can use to move the screen?
ossman: airlied, without kms, the lockup is avoided but X doesn't init the s-video properly
ossman: so there seems to be something the current code doesn't like about my card
panfist: UnNamed i'm seeing more than 256 colors, theyre just not the colors i'm supposed to see
panfist: ossman did you try alt-sysreq-REISUB
panfist: instead of power button
ossman: airlied, if I turn KMS off, then it no longer detects the S-video connection. Not sure if it's related..
soreau: ossman: Curious, which chip does that happen on?
ossman: soreau, a r300 (9700 specifically)
dileX: biotube: thx for the hint with restarting gpm in init-3 (after unload/reload radeon k-m)
laska: airlied: i got a "[TTM] Erroneous page count. Leaking pages" on linux-2.6.32-rc5 with some patches from drm-next, details: https://bugs.freedesktop.org/show_bug.cgi?id=24536
ossman: hmm... load detection is off by default in non-KMS. I would have thought that the driver would assume something is connected in that case
ossman: I don't see how it could be useful otherwise?
soreau: ossman: Hmm.. I should try here on my rv350 (AGP 9600)
ossman: soreau, please do
soreau: ossman: How to reproduce specifically? And which kernel are you using there?
ossman: soreau, just boot with KMS and only s-video connected. it will lock up as KMS inits
fredrik_: airlied: Se you are a bit occupied. But if you have some clue on witch randr properties. I would appreciate it. I have no clue
ossman: it is a airlied patched 220.127.116.11. (fedora rawhide)
airlied: fredrik_: I'm not near a radeon to look
soreau: ossman: drm-next?
ossman: fredrik_, you max out horiontal size and position before you get something decent?
soreau: wonders what is patched about it
soreau: ossman: Alright, testing now
ossman: soreau, should be somewhat close at least. you'll have to ask airlied about exactly what he's put in the fedora kernels
soreau: Damn, I just realized I'm in the middle of a lengthy update
soreau: ossman: I will test as soon as I get the chance
fredrik_: ossman. How do you mean? I get a pretty good picture just by turn it on. But the picture is to wide to the right and to the bottom
ossman: fredrik_, you have these three properties:
ossman: tv_vertical_position: 0 (0x00000000) range: (-5,5)
ossman: tv_horizontal_position: 0 (0x00000000) range: (-5,5)
ossman: tv_horizontal_size: 0 (0x00000000) range: (-5,5)
ossman: they give you some control over the tv output
soreau: fredrik_: Which card do you have?
fredrik_: I tried to change tv_horizontal_size but it shifted the screen to the left, leving a black screen to the right. The picture is still cut off though
ossman: sounds odd
soreau: fredrik_: Tv-out is hard coded to 800x600 at least for r3xx cards. If you use a larger resolution than that on the main monitor, it will only show the upper left 800x600 of the main output on S-video
ossman: are you sure you don't have a larger framebuffer than what is sent out to the tv though?
ossman: hmm... setting xorg.conf options isn't so easy these days when there is no conf file :/
fredrik_: soreau: MOBILITYTM RADEON® X300 with 64MB DDR video
panfist: well...after about 4 unsuccessful reboots and having no idea what i just did, my psychedelic colors are gone but performance is still bad
panfist: still using software rasterization
fredrik_: soreau: can it be as simple as that... testing..
fredrik_: soreau: Yeh! It worked!!!! So sweet... Now, I'm gonna sitt back and think this threw
soreau: panfist: Care to post your X log somewhere?
panfist: one moment
soreau: fredrik_: The thing that sucks is the hardware is capable of 1024x768, but apparently we need a hardware engineer to reveal the pll code we would need to get the timing right for it :<
airlied: someone could just reverse engineer fglrx
soreau: (If I knew exactly which registers were needed, I probably could dump them while using fglrx)
panfist: and xorg.conf: http://pastebin.com/m6e8f3c41
airlied: radeon_tv.c contains the name of most of them
soreau: panfist: Your kernel is too old
soreau: You will need at least 2.6.30 or later (I recommend later)
soreau: airlied: Most isn't good enough :/
panfist: soreau i'm using the packages that are provided with my distro which, unless the world has gone completely mad, should be compatible with my kernel
airlied: soreau: oh you dumped those already?
soreau: I would love to know how to reverse engineer fglrx.
soreau: airlied: Yes, remember last time we went through this?
panfist: soreau what distro is using such a new kerneL
soreau: airlied: You said that there were some regs that couldn't be accessed or something like that
airlied: sorta, I like to blank tv-out stuff out of my brain
soreau: panfist: Fedora
soreau: airlied :)
airlied: soreau: ah probably some of the PLL regs
soreau: Those are the ones that are needed for the timing
panfist: soreau shouldnt the older versions of the drivers work with the older kernel i have?
soreau: I can already get 1024x768 tv-out working, just the timing is all screwed up because of the wrong pll codes
soreau: panfist: No
soreau: panfist: For your card, 3D is very new in the open drivers
ossman: hmm... annoying. TVDACLoadDetect doesn't seem to be working
ossman: fortunately ForceTVOut still does
soreau: My favorite thing so far is being able to first modes with kernel parameters ;)
panfist: soreau i dont even want 3d. all i want to be able to do is scroll a terminal smoothly. that would make me very happy
amarks: airlied: will you have some time this week to look at the cmap issue
soreau: panfist: Well that X log shows you're using the vesa driver there
airlied: amarks: not sure, not near any hw
panfist: soreau ok, so how do i not use the vesa driver there
airlied: I'm unfortuantely strapped in Tokyo, which is a real bummer .. NOT!!
soreau: panfist: In xorg.conf, use Driver "radeon" in the Device section
amarks: airlied: should i open a defect to document it?
soreau: airlied: Konichiwa ;)
airlied: amarks: nah we know abot it, and Linus knows now due my mentioning it too loudly at dinner
airlied: so I gotta fix it this week proably
jcristau: make linus fix it
airlied: well I gave out about how nearly fbdev drivers does it different and wrong
airlied: almost like nobody actually knew what they were diong when they designed it
soreau: airlied: You don't mean dinner in a literal sense, do you? (as in you got to dine with Linus?)
airlied: soreau: well I was late so they'd finished eating :-)
soreau: is so jealous
soreau: airlied: That is awesome.. your first time meeting him?
airlied: soreau: nah I meet him fairly regularly
amarks: airlied: well it's not like brissy is a distracting place to live ;) no excuses
airlied: amarks: exactly hence why I'm in Tokyo for a few days ;-)
amarks: airlied: live it up mate
airlied: gose for sushi breakfast
soreau: fredrik_: Glad you got it working :)
fredrik_: soreau: me2 Been working on this on and off all weekend. Should have turnes to IRC hours ago :-)
fredrik_: now, time for bed!
panfist: ok...enabling the "radeon" driver in xorg.conf did bad things. had to revert to vesa. "radeonhd" got me into X at the correct resolution and colors...but performance is off. still getting "glxinfo|grep renderer" returns "software rasterizer"
T-Hawk: hey ppl, on a laptop with a Radeon RV250, Mobility FireGL 9000 card, anybody know why i would get a completely blank screen when starting X?
mjt: see logs
soreau: panfist: As I already told you, you're not going to be able to get 3D working with that card with the open driver and that old kernel.
soreau: That's basically what swrast means is that you do not have 3d
T-Hawk: mjt, if it's me, there's no warnings or errors in the logs
soreau: T-Hawk: Can you pastebin your X log from the failed session?
mjt: T-Hawk: that can't be - it always has warnings
mjt: xorg.log that is
panfist: i'm sorry if i dont get this right away. i'm just frustrated that i can't get this box to work like another identical-hardware box i have in my office. it has a vanilla debian install and 2d performance is great. i would ssh into the box but my key was changed on friday and i forgot to bring it home.
mjt: which card it is btw?
panfist: integrated hd3200
mjt: you need 2.6.32-rc for that
panfist: part of my problem is i dont even know which driver i want...i just want basic 2d support
panfist: i dont know if i want radeon or radeonhd or something else
panfist: not fglrx...that was giving me screen tearing issues
chithead: for 2d it should be enough to use kernel 2.6.31 and xf86-video-ati-6.12.4
mjt: and for basic 2d, use 2.6.30 kernel and radeon driver
chithead: 2.6.30 does not have r600 drm
mjt: yeah i used external patch for .30
mjt: cleans up his mess in /build....
panfist: i know i dont need a kernel that new because the vanilla debian install is not that new
T-Hawk: ^ Xorg log of failed session, seems error do occur when actually starting from the correct config file
T-Hawk: but still same result
T-Hawk: to the terminal it complains that module radeon not found, but i have installed ati-drivers and xf86-video-ati, do I need any others?
mjt: panfist: it's wrong. kernel includes necessary bits since .31. it has nothing to do with debian
mjt: unless debian folks backported the needed bits to their .30 kernel
panfist: i know it has nothing to do with debian /except for the fact that that debian installation is not using .31 or even .30/ so there must be some other solution, maybe not radeon or radeonhd, that gets me better 2d performance
soreau: T-Hawk: Have you tried with exa rendering?
mjt: panfist: other solution is vesa
T-Hawk: soreau, exa rendering?
UnNamed: panfist: debian sid has .30 (i think experimental got something for .31)
soreau: T-Hawk: Yes, EXA ass opposed to XAA
mjt: UnNamed: backports has .40
mjt: UnNamed: backports has .30 even :)
T-Hawk: soreau, since i have no idea what you're talking about, no ;)
panfist: i am using vesa and my 2d performance is awful...takes 2 seconds to redraw the terminal
soreau: T-Hawk: EXA will give a noticeable speed boost when using X server 1.5.0 (or recent versions from git) and the open source intel/ati drivers. Otherwise, you should stick with XAA. In order to use EXA add the following line to the Device section of your /etc/X11/xorg.conf file: Option "AccelMethod" "EXA"
UnNamed: soreau: it gave me a noticeable slow down for me :] (i will try to figure why gimp and also FF redraw so poorly)
T-Hawk: soreau, no difference, but i complains that module radeon not found, could that have something to do with it?
soreau: T-Hawk: Also make sure fbcon module is loaded before starting X
soreau: uh, yea...
mjt: is fbcon really needed?
UnNamed: i do not use fbcon
T-Hawk: any idea why that might be so?
mjt: i mean, except of for the console
T-Hawk: and fbcon really shouldn't have anything to do with X
mjt: T-Hawk: with kms it isn't the case anymore
soreau: T-Hawk: What is the output from modinfo radeon?
T-Hawk: well it is absolutely correct that radeon doesn't exist... is it somewhere in the kernel config and not a package?
mjt: it's a kernel module
T-Hawk: any idea where it's located in menuconfig?
soreau: T-Hawk: Yea, you need to configure your kernel correctly
mjt: if it's in a separate package in your distro is another question
soreau: It's like Device Drivers>Graphics Drivers>DRM>Radeon
soreau: mjt: gentoo
mjt: there's a nice search in kconfig...
agd5f: ossman: load detection is disabled by default in the ddx since the dac is shared with vga and you can end up with false positives one way or another
agd5f: for the tv dac
T-Hawk: found it, recompiling kernel modules...
agd5f: primary dac was vga only so, so load detection works there
soreau: ossman: Update still running here...
T-Hawk: psh, as if a correctly configured kernel could have any influence
soreau: agd5f: I thought it was enabled by default...
soreau: at least for the fedora kernel
agd5f: soreau: not for the ddx
agd5f: kms might be
ossman: soreau, I'm off to bed, but just post just results here and I'll see it in the morning
soreau: ossman: Ok
soreau: agd5f: I must be misunderstanding you.. I thought he said with KMS and only S-video plugged, the kernel halts
agd5f: soreau: yeah. I was talking about ums
speps: hey guys does radeon drivers support drm initialization on multiple Xorg istances?Does it need some compilation flags in order to get it?Thanks
soreau: agd5f: Ok, forget I said anything then. I thought you were referring to the bug ossman was talking about earlier
T-Hawk: i get this line now: "(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI." and still a blank screen, any ideas? :(
soreau: T-Hawk: Your kernel still isn't compiled properly. You need to enabled the correct chipset for your mobo in Graphics Drivers>AGP
T-Hawk: it has been way too long since i got X up and running on a machine it seems :(
soreau: Also, you need to compile your xserver with VIDEO_CARDS="radeon" (in /etc/make.conf)
T-Hawk: soreau, okay, any other kernel stuff i should take care off before?
soreau: T-Hawk: You might consider compiling with KMS support too
T-Hawk: KMS? and compiling what, Xorg?
soreau: no, in your kernel
soreau: Do you know how to search in menuconfig? (Hint: / ) Search for KMS
speps: hey guys what about GLSL implementation with radeon drivers?Is there a development in course?Any plan?Thanks
T-Hawk: soreau, actually no, i didn't know that... awesome... thanks :D
soreau: speps: Yes, development is underway. It will appear in the gallium driver, r300g first
[Enrico]: gallium driver :Q_______
[Enrico]: hopes to see it soon :D
soreau: [Enrico]: The gallium driver already exists in (certain branches of) mesa. You have to compile with --enable-gallium-radeon
[Enrico]: soreau: yeah i know thanks :D
[Enrico]: soreau: but not for my card i think (r600 :D )
[Enrico]: well i also have a r200
soreau: [Enrico]: I thought there was r600g too(?)
[Enrico]: and my laptop with my r300 is burned :'(
[Enrico]: soreau: oh don't look at me. i have no idea if it exist! i just guessed :D
soreau: I doubt glsl will do too much on r200 :p
[Enrico]: soreau: but gallium dirver is worth anyway i think :D
[Enrico]: r200 doesn't have glsl support afaik, so i don't care of it (but i care for my r600 :D )
soreau: is excited for glsl too
soreau: on all capable radeon cards :)
[Enrico]: soreau: eheheh i think that with .32 kernel and mesa 7.7 i will enjoy a lot the new radeon driver (i can't use git now couse i need a usable pc :D i use it for study)
stikonas: git and studies are not mutually exclusive
stikonas: at least I am able to study and run git at the same time
soreau: I use git with little to no problems
frej: git works mostly here as well, the crashes I get are in stable as well.. and in games... so actually mesa is good for studies ;)
T-Hawk: :( it still doesn't work... get a blank screen, back light on, and the only error is the following: "(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI."
math_b: is ddx driver CustomEDID parameter working with kms ?
ajami: agd5f: What bugs need to be squashed and which mesa test progs are not working perfectly for the classic r600 driver?
ajami: agd5f: I am interested in helping getting that driver to 'perfection' if there is such a thing.
ajami: btw, I am using an HD2400
stikonas: ajami: you can run ten test programs yourself :)
agd5f: ajami: http://dri.freedesktop.org/wiki/R600ToDo
stikonas: and compare them to reference rendering
agd5f: ajami: https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fr600&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
ajami: Where can I look up cards vs r####? Like the Radeon HD2400 would be an r-something.
UnNamed: ajami: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
agd5f: ajami: hd2400 would be rv610
soreau: T-Hawk: You should have AGP built-in (*) and DRM as a module (M) but you need to make sure you get the right AGP chipset/driver for your mobo
soreau: It is not necessarily ATI
UnNamed: agp can also be module
soreau: Well it can, but for a failsafe method, you should compile it in
UnNamed: failsafe is text console (get of my lawn... ;] )
soreau: T-Hawk: You can also try manually loading radeon without agp before starting X
T-Hawk: radeon is also built in... and according to lspci it's a ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)
ajami: Where are the reference inamge for the sample progs at?
soreau: I would recommend building agp>(your chipset) in and drm>radeon as module at least for testing purposes
soreau: ajami: What?
soreau: ajami: If you are referring to the mesa demos, you need to run the prog from the directory it's in
ajami: I am.
soreau: So don't do /path/to/prog, do cd /path/to && ./prog
ajami: I know. I am curious where the reference iamges are located so that I may know if the progs are working.
MostAwesomeDude: Use LIBGL_ALWAYS_SOFTWARE=1 to see swrast's version of each prog.
ajami: with current mesa, drm, and rawhides 2.6.31 kernel (kms enabled) clear-fbo is not working for classic r600_dri.so
stikonas: ./tri-stipple also misrenders
stikonas: all stipple progs work incorrectly
ajami: stikonas: that's not entirely true, linestrip-stipple seems to work just fine.
ajami: however, linestrip-stipple-wide does not.
roel__: can somebody help me with my compiz artifacts problem with opensource radeon driver?
roel__: I have the same corruptions as shown on http://www.phoronix.com/forums/showthread.php?t=18349&page=12 in my terminal and othe places
MostAwesomeDude: roel__: Are you using DRI1?
MostAwesomeDude: It's a known bug; current workaround is to use DRI2.
roel__: how do i use that it says my screen isnt capable
MostAwesomeDude: Update X server, probably.
MostAwesomeDude: Haha, wow. readPixSanity passes now, as a side-effect of surface_fill being gone.
roel__: i have 1.6.4
MostAwesomeDude: Could you pastebin your Xorg.0.log?
MostAwesomeDude: You're not using the experimental DRM.
roel__: enlighten me
MostAwesomeDude: Hm. I forget how to get it set up. There used to be a link in the topic...
MostAwesomeDude: airlied, agd5f : How to get KMS for r600 set up?
soreau: There is a link in the topic..
MostAwesomeDude: soreau: Yes, there is. I'm not sure if it's also got r600 KMS instruction.
roel__: if i use KMS (modeset=1) i have the same problem
soreau: roel__: Did you see this thread? http://www.phoronix.com/forums/showthread.php?p=88050#post88050
virtuald: Is power management working on an rv570 with KMS?
soreau: MostAwesomeDude: AFAICT, it does
roel__: soreau, yes but that is referring to the error post above and isn't the same problem
soreau: roel__: Well you either don't have your kernel setup correctly or you haven't configured libdrm with --enable-radeon-experimental-api (and subsequently built mesa/ddx afterward)
roel__: why would you say that
roel__: i have drm
soreau: Loading radeon with modeset=1 wont do anything if your kernel doesn't have KMS support
roel__: i have kms support
roel__: but don't use it because the wiki says its slower
virtuald: Is there any power management on KMS?
soreau: roel__: Then what is different from what you see as opposed to what's in the forum thread there?
roel__: soreau, i have the problem with artifacts showing up on typing text and moving my cursor over my awn
soreau: roel__: When did you last install libdrm, mesa and ddx?
soreau: Well I would make sure to follow the suggestion in that thread and build with those CFLAGS
soreau: ossman: Confirmed. With kms and only S-video connected to the card the machine locks hard
soreau: Here on latest drm-next with rv350
soreau: With nomodeset it boots and loads X but of course there is no tv-out with dri1
ajami: agd5f and anyone working on classic r600: here is a link to my trivial prog tests. download the file from pastebin and view it in a browswer. http://pastebin.com/mbe4d4a7
ajami: I took a couple hours and decided to compile this list
ajami: Also, please, let me know what you think and if you have questions, want me to do more, anything, let me know.
ajami: I forgot to mention that I am using a Radeon HD2400 (rv610)
ajami: I was tinkering around with r600_context.c and got the tri-query trivial prog to not crash. However I believe I am enabling GL_occlusion_query when it's not implemented...? If anyone knows of a more sane way to do this that would be nice. A triangle is being drawn, but the the test itself fails.
MostAwesomeDude: AFAIK ARB_occlusion_query works but is not implemented on r600. If you've got patches that make it behave better, they're welcome.
ajami: Define better, I think it just allows queries to not crash progs, but still doesn't work by any means.
MostAwesomeDude: Not crashing == improvement. :3
ajami: True, :D