udovdh: yes its probably a bug in our server
udovdh: I see.
udovdh: so that explains the radeonhd bug status. sure.
udovdh: I guess the case could have been handled a bit better although the direction is more or less understandable.
udovdh: you could have left it open and/or related it to supported drievrs with similar issues
udovdh: it was not your problem
udovdh: so we run a distro kernel because the better stuff in there has not reached the kenrel.org kernel?
udovdh: same for other enhancements.
udovdh: also: the features I use from the readeonhd driver are quite basic, so there was no need to break them.
udovdh: and now that someone admits that it is a problem in 'our server' we know enough.
MostAwesomeDude: Who was "we" and "our" in there?
udovdh: thanks for reminding me of updates-testing
udovdh: and what's in there.
udovdh: well, the corruption is gone, as far as this quick test tells me
udovdh: but the messages didn't stop
udovdh: got 1 so far
udovdh: drm] writeback test succeeded in 1 usecs
udovdh: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 20
udovdh: where should I report these findings?
kurudisease: do you know how to switch off the radeon card using atombios calls?
kurudisease: i'm using a switchable gfx capable thinkpad and i'ld like to turn off the dedicated card when not needed
yangman: it's not something the drivers can do yet
kurudisease: i've read on opensuse radeonhd forums that someone made it work
Travis1: ok so installed Karmic 64bit. Graphics driver not working. Tried removing the "vesa" driver from my xorg.conf file and ended up with blank screen on loadup. Any help appreciated at this point
udovdh: airlied, https://bugzilla.redhat.com/show_bug.cgi?id=539571
udovdh: `yes its probably a bug in our server but we arent going to look for it, you should run an upstream X server as well`
udovdh: still not going to look at it?
udovdh: it really isn't just a redeonhd issue anymore, right?
udovdh: that was already so when I filed 'my' bug. see the link I put there when I first filed the bug.
udovdh: but politics appear to be more important than technical stuff.
umtc: can i ask a question about 3d in here?
adamk: umtc: Most of the 3D development discussion is done on #radeon
adamk: However, if you ask for help there, they'd be much much happier if you were using the radeon driver.
umtc: i'm asking what are the steps needed by various projects to get a totally unsupported card to full 3d support?
umtc: is this correct? documentation -> driver 3d support -> os drm support -> mesa3d card support -> done?
adamk: umtc: I suggest following the wiki in the topci on #radeon
adamk: There are three components... The Xorg 2D driver (radeonhd or radeon), the OS DRM, and the mesa 3D driver.
adamk: Oh, and libdrm, which acts as a glue between various parts.
corecode: what's the forecast for r8xx usability?
corecode: i saw some fedora description claiming that r8xx is supported by radeonhd, but i didn't find this anywhere else
gnubien: corecode: http://wiki.x.org/wiki/radeonhd http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units
corecode: ah, call it evergreen then
corecode: specifically, i'm interested in the hd5770
gnubien: corecode: google radeonhd evergreen
corecode: i am
corecode: not really useful information
gnubien: great minds think alike ;)
corecode: that's why i'm asking here
gnubien: corecode: stay on this channel and ask others
corecode: of course i was asking all
adamk: It's not supported yet. modesetting mostly works in some development "radeon" code that I think needs to be approved for release by AMD, but even digital outputs didn't work last time I heard.
corecode: so for non-linux users, it is pointless to get a hd 5xxx card?
bridgman: yeah, the sequence is usually "figure out how to make it work, at least minimally, write docs, release"
bridgman: is that what you meant to type ? there are drivers for all the oses available today, it's just programming docs for open source work that are being worked on
adamk: bridgman: r8xx :-)
adamk: bridgman: There are certainly not drivers for all the OSes available today :-)
corecode: execpt vesa
bridgman: sorry, all the oses for which we provide drivers ;)
corecode: we == ati?
bridgman: yep, ati/amd
adamk: I'm guess corecode is inquiring about some sort of BSD support :-)
corecode: yes indeed
corecode: if only porting the binary drivers wasn't such a pain
adamk: Yeah, the libdrm/mesa code for r6xx/r7xx hasn't even been committed to ports yet, but it's at least usable.
udovdh: any estimates on 3d being 'ready' for r6xx?
bridgman: adamk, that's a "I want a driver but not the one you have already provided" thread ;)
bridgman: depends what you mean by "ready"
corecode: it is getting worse and worse... intel only supports linux/drm2/kms, nvidia sort of works, except on >2GB RAM
adamk: corecode: Even with the latest changes to FreeBSD? The FreeBSD developers did a lot of work to help support better functionality from the nvidia drivers.
corecode: not using freebsd
adamk: corecode: Which BSD are you using?
adamk: I wasn't even able to get my X850 working with 3D acceleration on Dragonfly.
bridgman: what is it that prevents the different bsd variants from leveraging the same driver work ?
corecode: bridgman: which driver work?
corecode: bridgman: the binary drivers?
bridgman: there's been a lot of porting effort to get the current drivers working on freebsd as adamk said
bridgman: no, open source
adamk: bridgman: Probably a lack of developers :-)
corecode: oh, open source works
corecode: as long as a driver exists
bridgman: a light just came on, by "non-linux" you didn't mean "windows and macos" you meant *bsd ;)
corecode: yes, of course windows works
adamk: bridgman: There's one maintainer for the openbsd DRM and one maintainer of the FreeBSD DRM. I'm not sure how much code overlap there is.
bridgman: that's why I was confused.. that and the coffee not taking effect yet
bridgman: goes for more coffee
corecode: the problem is that linux drm2/kms is just pushing so quickly forward
adamk: bridgman: NetBSD picks up bits and pieces, mostly based on the openbsd code, probably. Dragonfly is most similar to FreeBSD, but the kernels have separated quite a bit since the fork.
corecode: i mean, i don't have issues porting code, etc.
corecode: but of course i'd rather spend time on something else
adamk: corecode: Thankfully the r100-r700 Mesa driver does not require KMS. Some specific features do but, for the most part, the open source drivers on FreeBSD are on par with how they operate on linux. Of course, it still requires the dfly folks to port the code over from fbsd.
corecode: that's no big problem
corecode: i also don't need 3d
corecode: not in any way. 2d + xv, that's all what i want
corecode: if i want 3d, i use windows
adamk: corecode: Unfortunately, 2D acceleration + Xv requires DRM support.
corecode: i see
corecode: well, also no big problem
corecode: as long as there is something
udovdh: bridgman, ready is perhaps 'stable enough for enduser'?
udovdh: would be nice to have
udovdh: so far 2d is working fine
bridgman: wierd; cbrill's logger pages aren't capturing for radeonhd
udovdh: except for fedora 12 issues here
bridgman: what do you think is unstable today ?
bridgman: the only place I have seen a hang in a couple of months is exiting a couple of screen savers and they seem to be problematic across many drivers
udovdh: 3d was 'experimental'?
bridgman: sure, but since nobody knows exactly what that means it's not clear what the criteria are for exiting the state
chithead: many wiki articles are horribly outdated
bridgman: I think it means "I haven't had a chance to spend time with the code myself" ;)
udovdh: hmm ok
bridgman: or, to be precise, "I haven't had time to assure myself that the code isn't total crap"
udovdh: so it should mostly work now?
bridgman: it seems to.. if it doesn't we want to know
udovdh: aha ok.
udovdh: so I perhaps firstw ait for the fedora issue to be fixed and then try 3d.
udovdh: (so not to confuse issues)
bridgman: makes sense
bridgman: although the two are probably pretty independent these days
udovdh: ok thanks
udovdh: yes, but still...
bridgman: I guess it depends on how easily you can "pull the plug" and remove its influence
bridgman: I think it's just adding a package to get 3d, then removing it to go back to sw rendering
udovdh: hmm. maybe ask someone to see how much outdated that 3d wiki article is
bridgman: it's *totally* outdated, maybe I'll nuke it, hold on...
udovdh: what will take it's place?
udovdh: a small howto?
bridgman: yeah, probably just "use kernel 2.6.32 or newer, get mesa from your distro packager, IRQ support in mailing list today but should be in 2.6.33 soon"
udovdh: and xorg.conf settings?
udovdh: mesa 7.6?
bridgman: as long as DRI is enabled and you're using EXA (both defaults these days AFAIK) then you shouldn't need anything in xorg.conf
udovdh: aha, cool.
bridgman: 7.6 was the first with 6xx/7xx support, but newer is usually better
bridgman: master is at 7.8 now
bridgman: I think most distros are already packaging at least 7.6
bridgman: for fedora just enable the option to get 6xx 3d
udovdh: radeon_dri.so is what we need?
bridgman: did you read the phoronix article ?
bridgman: r600_dri.so I think
udovdh: not really...
udovdh: r600 dri is not in the drivers rpm for f12...
udovdh: so I'll have to build it myself then
adamk: There's a separate package for it.
udovdh: what name/where?
bridgman: yum install mesa_dri_drivers_experimental or sth like that
udovdh: ah I see
adamk: Yeah, something like that :-)
bridgman: the article is 6 weeks old, a veritable lifetime for open source drivers ;)
bridgman: just checking something 'cause we're in the radeonhd forum - you are running the radeon/kms stack from fedora, right ?
udovdh: don't think so
udovdh: or at least: not sure
udovdh: kernel.org kernel
udovdh: not a fedora one
udovdh: rest is fedora
udovdh: except radeonhd which is git
bridgman: are you running what came with fedora, or did you disable kms at boot and change xorg.conf to use radeonhd ?
bridgman: ok... I guess the package should still work but most of the testing was probably with f12 kernel and kms code paths
bridgman: give it a try ;)
udovdh: I run my own kernel
udovdh: did not consiously disable kms
udovdh: I did edit xorg.conf for radeonhd of course
bridgman: not sure what the vanilla kernel defaults are these days
bridgman: my guess is that kms is off, not sure though
bridgman: if radeonhd works then kms is off ;)
bridgman: so, like, is the 3d working ?
udovdh: would have to restart xorg I guess.
udovdh: can do so.
bridgman: for indirect rendering at least; you should be able to test direct rendering without a restart
bridgman: so progs/demos/gears would work without restart, glxgears needs restart
udovdh: lemme see xorg.log
udovdh: nothing happened there
bridgman: you can't turn on kms with radeonhd, so all you're doing is adding r600_dri.so
bridgman: and the binding to that file is dynamic when the opengl app starts
udovdh: yes but I see nothign about that in xorg.log now
bridgman: about what ?
udovdh: about dri
bridgman: if you have 2d acceleration then you have dri
udovdh: I mean the mesa experimental rpm I just installed
bridgman: you wouldn't see anything about that in xorg.log, xorg doesn't care
udovdh: would that be mentioned in xorg0.log?
udovdh: so how do I test?
bridgman: run glxgears (after restarting xorg once) and see if frame rate is different
udovdh: right now it doesn't run
udovdh: perhaps due to the fedora issue
bridgman: did it run before ?
udovdh: (II) AIGLX: Loaded and initialized /usr/lib64/dri/r600_dri.so
udovdh: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
udovdh: so glxgears does not run
bridgman: ok, your drm is too old; what is your kernel version ?
bridgman: eww, ancient ;)
bridgman: the f12 kernel included 6xx support; you'll either need to patch in new drm or pick up a 2.6.32 kernel
udovdh: glxgears ran ok before
bridgman: sw rendering
udovdh: will do that
udovdh: (get 2.6.32)
udovdh: I see it was released
udovdh: thanks for the explanation
bridgman: yep, just recently IIRC
bridgman: no prob
politas: Hi all!
politas: I was wondering if the radeonHD driver is doing OpenGL for HD 3400 Series cards yet
adamk: politas, radeonhd is just a 2D driver.
politas: I thought it was supposed to be 3D?
adamk: politas, Mesa handles 3D acceleration, and yes, it supports HD3400, but most distributions do not ship with that code.
politas: Mesa, I haven't heard of that.
politas: Is that easy to add to an Ubuntu system?
adamk: I have no recent experience with Ubuntu.
adamk: I know that some PPA's have newer versions of Mesa and libdrm, but I don't know any details.
adamk: You could check on #radeon or #ubuntu.
politas: Ok, thanks.