Nightwulf|work: hi all
bremner: is radeonhd 1.2.1 (packaged for Debian) likely to be usable on RV530 (FireGL V3400) on amd64? Or should I go for HEAD?
adamk: I'm pretty sure it will be usable for 2D.
adamk: 3D support depends on your version of Mesa.
bremner: adamk: thanks, sounds worth a try anyway.
libv: bremner: but go for 1.2.3 as that should also be packaged
libv: bremner: failing that, our driver should build nicely for whatever you might be using
ndim: If you have all build requirements installed.
ndim: Debian has some magic incantations to ensure that.
Obscene_CNN: oh goody, egbert patch goodness :)
ndim: Obscene_CNN: Does it work? :)
Obscene_CNN: haven't had time to check it yet. although I did do a git pull
ndim: I have done my usual "git fetch -v && git rebase-subtree" as well.
egbert: ndim: so does it work for you?
bremner: libv: thanks for the feedback. 1.2.1 seems mostly to work. There is occasionally some weirdness with cursor trippled up. I'll try to get a screen shot next time I see it.
ndim: bremner: Better get a driver update first.
ndim: egbert: No idea. I have not booted for some time, and really should do so before making any statements on what works or not.
libv: 1.2.1 is ageold
bremner: ndim: good point. no point reporting bugs no one cares about.
ndim: bremner: No point reporting bugs which have been fixed ages ago.
bremner: right, that's what I meant. Anyway, ancient or not, 1.2.1 is running the two heads on my FireGL V3400, yay for that
Obscene_CNN: egbert, it appears to work for me but I have not and am not able to test the rotation at the moment.
bremner: oh, I see, 1.2.3 is in debian experimental. OK, I will see about installing that.
egbert: Obscene_CNN: ok.
bremner: ooh, 1.2.3 is noticably faster, and cursor weirdness seems fixed
bremner: I spoke too soon. Cursor weirdness is back. It is intermittent; I guess I will live with it until I get a chance to try the latest git
yangman: bremner: http://bugs.freedesktop.org/show_bug.cgi?id=13405 ?
bremner: yangman: I'm not 100% sure if this is the same problem. Once it goes wonky (like 4 vertical copies), it seems to be like that everywhere. But I could try the patch anyway.
yangman: bremner: that's a different issue, then
rafi_: Is there a way to verify if my gpu is a RS690 or RS600? And does it matter?
Obscene_CNN: rafi_ in your Xorg log file the radeonhd driver should report what chip it found
rafi_: (--) RADEONHD(0): Detected an RS600 on an unidentified card
rafi_: So that's definitive?
rafi_: I have a dell with "ATI Radeon Xpress 1250 for Dell/Parker"
rafi_: I've just been a bit confused by the x1250 and Xpress 1250 being 600 and 690
rafi_: So, I guess being an RS600, is there anything I can do to get better accelleration working at this point?
Obscene_CNN: enable dri support I think
Obscene_CNN: as well as EXA support
rafi_: I tried exa with dri, and that doesn't make much of a difference
rafi_: And I've been having trouble getting the drm modules to work right, but perhaps that was cause I was trying to get it to work as a rs690
Obscene_CNN: well, someonme else may have to help you with this as I haven't got this working because my card isn't supported yet.
rafi_: Doesn't look like the drm code has anything for RS600
rafi_: I don't suppose there's a simpler chip that is compatible enough? :)
Obscene_CNN: libv might be able to help
yangman: rafi_: you use the r300 dri module for r500-like chips
rafi_: yangman: What does that translate, in terms of what I should put in drm_pciids.h?
rafi_: (or is there another way to force load the driver)
yangman: rafi_: it's all already available in released code
yangman: rafi_: radeonhd >=1.2.2, mesa 7.2, and recent enough kernel
rafi_: ok. running radeonhd and the kernel from git
rafi_: mesa, I'll have to check
rafi_: I'm getting error messages about init_mm not available on my kernel. Is there some option that I might've flipped?
rafi_: Ah, unused symbols
agd5f: rafi_: there is no drm support for rs600 chips yet. it has a different weird gart setup compared to other chips
rafi_: oh, ok
rafi_: So no 3d or XV for now?
rafi_: What about EXA accellerated rotation?
yangman: rafi_: DRM is required for hardware acceleration in general
rafi_: oh well, thanks, I'll keep an eye on the lists for now
El_Angelo: where can i download atomtools?
Dumble: hello everyone
Dumble: I'm about to by a laptop and would like to know if the ATI Mobility RADEON HD 3650 is well supported by the readeonhd driver ? or if there are some limitations, which are they ?
yangman: Dumble: no video acceleration yet
Dumble: no 3D or no XVideo ?
adamk: Dumble, Both.
Dumble: and, will it be supported in the short term ? and with the closed driver, will it works well ?
adamk: There are hints that support might be available by the end of the year...
adamk: It should work with fglrx, but discussions of that are probably better off in #ati
Dumble: if I use it with the current radeonhd stable version, will it work ? (even if some fonctionnalities are missing)
yangman: modesetting would work
Dumble: ok, but no 3D, no XVideo and no fancy effects with compiz
Dumble: *do not know what to do*
Trou: buy intel ?:)
Dumble: I have the choice between the almost same machine with an intel card
Dumble: or this ati
Dumble: I think I will follow Trou's advice ;)
Dumble: and by a radeon another day
Trou: well, pb is intel performance is likely way < radeon
Dumble: thanks !
Dumble: I know that
Trou: but since fglrx would probably not work correctly...
Dumble: that's the problem
Trou: (and it's not free)
Dumble: that's also a problem
Dumble: although I have nvidia on my current lapt
Trou: i personaly bought an ati to support the opening of their drivers
Trou: i just hope xv support will come soon ;)
Dumble: that is what I was thinking, but I want to be sure I can use the card with something else than vesa driver
agd5f: Trou: I already have Xv mostly implemented. just a matter of getting approval to release it
Trou: i understood that from the post on phoronix today
Trou: and also that there is no ETA, right ?
Zajec: Trou: bridgman posted his hope to see this in 2008
Trou: yeah, btw is there anything better than "x11" as video driver for mplayer ?
Trou: without xv
adamk: sdl is usually pretty good.
Trou: x11 is SLOW :(
Trou: ah nice, faster than x11, but no switching :(
Trou: hmmm, quality is not that good with sdl
Trou: yeah, x11 is definitely way better
Trou: doesn't :)
Honk: thought so ;P
ndim: egbert: upside down rotation works, but all X11 window drawing ops are dog slow while rotated.
ndim: (mobile X1400, XAA)
airlied: ndim: you need EXA I think
ndim: BTW... white of XAA/EXA is the preferred one nowadays?
ndim: airlied: Indeed, you need EXA.
airlied: ndim: not sure for radeonhd, with a modern server I recommend EXA, as you get more features.
ndim: egbert: Strange behaviour with rotation. Rotating display (normal: 1400x1050) to the left (1050x1400), then starting torcs (which sets mode to 1024x768), then quitting torcs messes up the display state a little.
ndim: I end up with a 1050x1400 framebuffer but it is not actually rotated.
ndim: "xrandr --output PANEL --auto --rotate normal" fixes the issue.
ndim: airlied: OK, then I'll set stuff to EXA now.
ndim: egbert, libv: Is there any reason why 'Option "DRI" "on"' is not default (for supported cards)? And, relatedly,... why is XAA the default and not EXA?
dmb: MostAwesomeDude, so can the graphics card itself compile and link the glsl stuff directly, or is that the drivers job?
dmb: does the driver compile the glsl script into something the video card can understand?
airlied: dmb: GLSL is translated/compiled into GPU vertex/frag progs
dmb: airlied, why is it so hard to find documentation of this stuff on the net?
airlied: dmb: because most people aren't interested in how GPUs work :)
dmb: airlied, these gpu vertex/frags progs, what kind of format is it?
dmb: is it some kind of video card assembly?
airlied: pretty much.
ndim: Cute. Reproducible system hangs after a few seconds of torcs. Might be the kernel version, though. IIRC 2.6.27.* frequently hangs, 2.6.26.* works. (F9, radeonhd 078842c7, kernel 18.104.22.168-41.fc9.i686.PAE)
ndim: I guess I need to do some more systematic tests.
MostAwesomeDude: dmb: The formats for R300, R500, and R600 assembly are documented; check out x.org/docs/AMD.
yangman: ndim: http://bugs.freedesktop.org/show_bug.cgi?id=18097
ndim: yangman: Section "Extensions" Option "Composite" "Disable"
ndim: yangman: I would assume that this turns off any composite stuff...
yangman: ndim: iirc, that only disables the composite extension hooks, not the internal composite code
yangman: I forget the details. Trying it from a plain X session is the quickest way to find out, I suppose
ndim: OK... I'll check that and the kernel issue tomorr... later today.