osiris__: fpoibaf: pong
fpoibaf: osiris__: I finally found what caused my lockups with mesa master: https://bugs.freedesktop.org/show_bug.cgi?id=21849
spreeuw: what card can you recommend now with working 3d and xv?
dileX: fpoibaf: you installed libdrm >= 2.4.9 or what did you do?
fpoibaf: after installing libdrm 2.4.9 some lockups apparently got fixed (e.g. saurebraten instant lockup)
fpoibaf: but only after downgrading the drm radeon module I get the lock up free experience I got with Ubuntu 8.10
max_r: spreeuw: hd4350 has working 3d with fglrx, so if your distro uses 2.6.28 kernel (read it is ubuntu 9.04 or older) than you could get it and wait for coming oss support
rah: max_r: that's a response you would expect from in #fglrx
max_r: rah: do you think that it will be better to buy obsolete card?
max_r: btw, I'v just seen a commit to mesa/r6xx-r7xx-support
nanonyme: rah: Itym #ati
max_r: what does it mean?
max_r: I thought that all efforts are going into r6xx-rewrite now
nanonyme: Who says the rewrite on the older cards got done?
nanonyme: Afaik this is still bug hunting season.
max_r: afaik rewrite was meant to work with both scenarios (non-kms and kms/dri2/...)
max_r: and it seems pointless to spread resources on two non-working drivers. Maybe I didn't understand something?>
nanonyme: Well, yes but they're hoping afaik to get the newttm stuff to 2.6.31 if I understood properly.
nanonyme: So it takes priority.
max_r: what takes priority? r6xx-rewrite is meant to work with and without newttm stuff
nanonyme: True, that. There *are* employed devs working on that, I think.
nanonyme: That is, r6xx-rewrite.
osiris__: nha: are you going to work on some radeon related stuff?
max_r: nanonyme: and r6xx-r7xx-support will never be used, right? Than what's the point of fixing bugs in it?
phoenix64: having a reference for the rewrite branch?
nanonyme: I was under the impression that they are not fixed.
nanonyme: *shrug*
nanonyme: But yeah, that would be a good reason to do it if they are.
nanonyme: Maybe
nanonyme: Though isn't r6xx-rewrite sort of a reference for r6xx Gallium in turn? :)
rah: max_r: if you want a working free software driver, yes I think it would be better to buy an obsolete card
erjc: Fedora Linux 2.6.29.3-140.fc11.i686.PAE, KDE=4.2.3, Sempron2200+, 498MB
erjc: RV350-AS[Radeon 9550], OpenGL=1.4, Mesa=7.5-devel
erjc: DRI R300 20090101 x86/MMX+/#DNow!+/SSE TCL DRI2
erjc: I see artifacts on window open
erjc: compiz and/or kwin give me nothing
erjc: do I need newer builds or Is rawhide up to date?
rehabdoll: i get random freezes with mplayer and this message in xorg.log: exaCopyDirty: Pending damage region empty!
rehabdoll: known issue?
rehabdoll: latest git i think, r7xx
spreeuw: rehabdoll: disable all override settings in xorg.conf
spreeuw: maybe it helps
spreeuw: is the mplayer selfbuilt ?
rehabdoll: override?
rehabdoll: my conf only contains some screen stuff, nothing else
spreeuw: non default
spreeuw: ok
rehabdoll: yes, built mplayer from svn a few days ago
rehabdoll: but this has happened for around ~1-2 months
erjc: I figured the [Radeon 9550] with 256MB DDR (128MB addressable) would give a big boost to this legacy box, yet I see little improvement over the integrated via-KM400A besided more memory
erjc: any config tips appreciated
Neo_The_User: Yes.
Neo_The_User: I have several memorized in my head. Its all about how much work you want to do.
Neo_The_User: erjc: post your /var/log/Xorg.0.log so I can see if everything is at least working correctly first
Neo_The_User: on pastebin please
Neo_The_User: welcome back bryce_
erjc: http://pastebin.com/d197e56df
erjc: new fedora user... everything takes me forever
Neo_The_User: When I tried fedora for 1 day, my graphics seemed slower no matter what i did.
Neo_The_User: on archlinux its much faster
erjc: actually the rv card makes this the snappiest fedora I ever used
erjc: now one week of fedora use, ten year record for me
erjc: debian for life
Neo_The_User: I hate all those modelines. can you please stop your desktop manager (sudo /etc/init.d/kdm stop) or something and run "sudo Xorg -configure" without quotes in command line then without testing the config, move it over to /etc/X11/xorg.conf and overwrite it
Neo_The_User: i cant see anything with 100000 modelines everywhere
erjc: hehe
Neo_The_User: Just so you know, I'm not reading that without the modelines out
mjg59: Neo_The_User: You realise that there's not going to be anything of consequence in that, right?
mjg59: And please don't suggest to people that they generate config files
Neo_The_User: ok you can go read it then. im busy right now
mjg59: It contains no errors or unexpected warnings
Neo_The_User: oh ok. dri works?
mjg59: There's some nice handy letters at the beginning of each line that let you find those
Neo_The_User: ...I always had slower graphics with fedora.
Neo_The_User: Personally, my solution was switching to archlinux. I am just saying...
ajax: existence proof in the form of numbers plz.
Neo_The_User: ?
Neo_The_User: OK Mathematically speaking, when playing anything in OpenGL such as a screensaver, DVD etc, I calculated an average of 20 - 25% lower CPU usage on Archlinux.
Neo_The_User: I had 30 more FPS on GL-117 Flight Simulator
valqk: hi guys
Neo_The_User: Hello!
Neo_The_User: How are you? How may I help you?
valqk: I have an ati X1600 which I use with radeon driver. but I have a problem. I have two monitors and a config that makes one of the letf of the other. all fines but one is 17'' LCD the other 22'' lcd and they run different resolutions. 17 - 1280x1024@60hz 22'' - 1680x1050@60hz . the problem occurs when I try to set correct resolutions. When I have no resolutions in the config the 22'' starts just fine, but the 17'' starts in 1280x1024 but not in
valqk: 60hz mode but in 59hz mode and the monitor can't be adjusted to fit screen. When I set resolutions on both monitors I get 22'' ran in 1280x1024 (that's ugly). If I use xrandr to set both resolutions I get them ok, but then there is another problem. I can't drag/fullscreen windows on the second (22'') monitor....how can I get both monitors running in corect resolution and to be able to use them as they should work, not show me the background,
valqk: but not to be able to move the app to the end of screen or fullscreen not to work?
valqk: thank!
valqk: *thanks!
Neo_The_User: so you want a big desktop rather than 2 indepent displays?
valqk: I'll run two more X over the desktops and will have two indipendent gdms/xfces working after I make the proper driver tune up
valqk: yes. I want to have so called Xinerama desktop - one monitor next to the other but in different resolutions.
valqk: I can't understand why I get resolution of the second screen overriden by the first...
Neo_The_User: My dad did that before but he's the only person I know who figured out how to do that
valqk: can u ask him pls?
rah: mjg59: I feel like I recognise you from somewhere
ajax: he's from the internet
Neo_The_User: He'll be on IRC in a bit if nobody responds. You can talk to him directly. I'll give you his screen name and what channel he is on
Neo_The_User: ajax: hahaha!
rah: ajax: ah, that'll be it
valqk: as I said I can tune the resolutions after X starts but then the bigger desktop acts werid and can't move the window to it's right end or can't get fullscreen mplayer...
valqk: Neo_The_User: ok
rah: ajax: really, though, what I'm saying is "where do I recognise mjg59 from on the Internet"?
mjg59: http://www.google.com/search?q=mjg59
Neo_The_User: hes still sleeping ATM
valqk: let me know when he's on pls
mjg59: rah: Debian?
ajax: mjg59: i'm disappointed that angryfacts isn't on the first page of results
jcristau: heh
rah: mjg59: ah, yeah
mjg59: Kernel stuff, Ubuntu, Fedora, random other projects
rah: mjg59: #debian-uk on oftc?
mjg59: Ah, yes
rah: right
rah: hello :)
erjc: Xorg.0.log-EDITED-2009-05-21 http://pastebin.com/d3d79af45
erjc: radeon-fedora11-glxinfo-modinfo-2009-05-15 http://pastebin.com/d2742fd38
kdekorte: valqk: I have a dual head setup with different resolutions.. it was quite easy to set up
erjc: radeon-fedora11--X-config--xorg-2009-05-15.conf http://pastebin.com/d4a73c596
Neo_The_User: Oh good
Neo_The_User: erjc: you didn't have to edit that file
kdekorte: valqk, sounds like you are using fglrx, I had that same problem where the smaller display's resolution was reported weird, I don't have that with the radeon driver
Neo_The_User: valqk: if you are using fglrx, "man aticonfig" then run commands as sudo. then go to #ati
erjc: radeon-fedora11-Xorg.0-2009-05-15-EDITED http://pastebin.com/d3f9909d8
erjc: THATS IT
erjc: any more I bill you
Neo_The_User: ...That wasn't necessary what you did but thank you
spstarr: neat
erjc: the old ones from before I break everything I hope
spstarr: is in the Intel GMA 4500 MHD GPU while the r6xx is in development
kdekorte: spstarr, that is exactly what I am doing... G35 until r6xx is ready
Neo_The_User: I just don't use fedora. I found even Ubuntu faster than Fedora's video preformance off the bat
spstarr: kdekorte: switchable graphics?
Neo_The_User: spstarr: you're obsessed with that aren't you?
kdekorte: spstarr, on board video and a pcie card (r635)
spstarr: Neo_The_User: na, its just neat that I have 2 GPUs in laptop
spstarr: so ican use eyecandy until radeon is ready to go and then get all 512MB video ram used
erjc: last rawhide update to kde 4.2.3 really fixed a lot af stuff
kdekorte: spstarr, I'm messing with clutter, and so I need working opengl
Neo_The_User: How do I get DRI2 working? KMS?
Neo_The_User: It only worked for me once in fedora
Neo_The_User: Never got it working in arch
tball: Hello everyone.
tball: I got some screen corruptions with latest git
tball: Anybody know about that?
glisse: git of what ? ddx ? mesa ? ...
Neo_The_User: what thing from git?
tball: radeon and drm
Neo_The_User: what branches?
tball: drm x600 branch
tball: And the radeon too
chithead: "which branch of which repo" would be the correct question ;)
Neo_The_User: haaahaaha............
Neo_The_User: :|
tball: _gitroot="git://git.freedesktop.org/git/mesa/drm"
tball: _gitname="drm"
tball: _branch="r6xx-r7xx-support origin/r6xx-r7xx-support"
Neo_The_User: did you compile drm by compiling linux-core?
Neo_The_User: if so, don't do that
rah: O_o
rah: Neo_The_User: why not?
rah: I do that
Neo_The_User: rah: the latest radeon code isn;t in there
rah: oh
tball: Hmm
rah: erm
rah: isn't it?
Neo_The_User: check the logs
tball: I don't wanna use radeon-rewrite, because of the lack of r600 support
glisse: for r6xx/r7xx the drm bits are there
Neo_The_User: exactly
tball: <- Confused. I did af co from git://anongit.freedesktop.org/xorg/driver/xf86-video-ati, and one of the branch mentioned before. Should I do otherwise?
rah: rah@myrtle:~$ cat /usr/src/ati-free/git/drm/.git/HEAD
rah: ref: refs/heads/r6xx-r7xx-support
rah: rah@myrtle:~$ dmesg | grep drm.*radeon
rah: [drm] Initialized radeon 1.29.0 20080613 on minor 0
rah: rah@myrtle:~$ egrep 'Chipset|DRI GL' /var/log/Xorg.0.log
rah: (--) RADEON(0): Chipset: "ATI Radeon 4800 Series" (ChipID = 0x9442)
rah: (II) GLX: Initialized DRI GL provider for screen 0
tball: rah: Was that an answer to me? :P
rah: tball: no, Neo_The_User
rah: Neo_The_User: You, sir, I accuse of lies!
tball: rah: You don't have small screen corruptions, specially with icons?
rah: nope
rah: working fine
tball: did you pull latest git from git://anongit.freedesktop.org/xorg/driver/xf86-video-ati main branch?
tball: and the drm r6xx-r7xx-support branch?
rah: from r6xx-r7xx-support
rah: hmm
rah: sorry, no, from master
tball: drm or radeon?
rah: rah@myrtle:~$ cat /usr/src/ati-free/git/xorg/driver/xf86-video-ati/.git/HEAD
rah: ref: refs/heads/master
tball: k, and the drm?
TigerTjader: Ever since I switched from fglrx to radeon Team Fortress 2 and other Source-based games stopped working for me. Is that because radeon doesn't support something fglrx supported on r500's or is it more likely to be some interaction between radeon and wine?
rah: [16:07]
rah: [16:07]
tball: Okay, then we are using the same bits
tball: But why the h... do I then have screen corruptions :P
rah: nobody taught your screens the value of integrity?
TigerTjader: I don't know if it helps, but wine keeps printing out "fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElements @ ../../../dlls/wined3d/drawprim.c / 269" when I try to run it.
rah: TigerTjader: I doubt anybody here knows anything more than you do about it
tball: rah: heh,
valqk: kdekorte: sorry I was out of the office
rah: TigerTjader: pay attention to what you're saying, 'I can't play a game under wine and wine is printing an error from a GL function'
valqk: I don't use fglrx
valqk: I use radeon
tball: Neo_The_User: Should I compile drm from another place than linux-core?
TigerTjader: rah, so, it wouldn't be radeon's fault?
rah: TigerTjader: if the driver is the only thing that's changed..
rah: TigerTjader: I would point out, though, that it might only appear that it's the only thing that's changed
TigerTjader: It's the only thing I remember to have been changed,
tball: TigerTjader: Don't expect radeon to run wine. Radeon doesn't support more than openGL 1,4 think?
tlp: well, you can run some stuff in Wine, but not a lot
tlp: http://www.x.org/wiki/RadeonProgram
rah: TigerTjader: IIRC, fglrx adds its own GL libraries which need to be removed in favour of mesa's libraries
valqk: I use xen kernel and radeon was the primary reason to get x1600
valqk: neither fglrx nor nvidia drivers are compatible with xen
valqk: :(
rah: TigerTjader: but yeah, I wouldn't be too hopeful
rah: bbiab
TigerTjader: Thanks for the help :)
dreamy: does the m6 ly mobility (7000) can run games ?
dreamy: anyone helping ?
nanonyme: Is it with newttm and radeon-rewrite, btw?
dreamy: my video card?
tball: nanonyme: You know if I can use r600 with rewrite?
nanonyme: No, lost in backlog.
nanonyme: Meant that Wine thing.
tball: rah: Hello again
tball: What were the git version you used again?
rah: xf86-video-ati: master
rah: drm: r6xx-r7xx-support
tball: Pulled today?
rah: not today
rah: earlier in the week
nanonyme: Wouldn't personally expect much to run with Wine without memory manager and the OpenGL extensions that it will allow to be written.
tball: What do I have to do, to get you to try the latest git from today? :P
rah: I thought you might ask that :)
tball: :)
rah: give me £10? :)
rah: j/k
tball: Account number?
tball: ;-)
rah: if this stops my X from working I'll not be impressed
rah: I'll be filing a bug and make no mistake about it!
tball: I have my finger crossed
tball: fingers*
nanonyme: rah: I thought the changes in the ddx were nowadays in master for r6xx/r7xx and the r6xx-r7xx-support branch was mostly dead. :o
rah: nanonyme: *shrug*
rah: nanonyme: I did what the wiki said to get Xv et al.
nanonyme: Well, that requires r6xx-r7xx-support only from drm.
rah: http://wiki.x.org/wiki/radeon%3Ar6xx_r7xx_branch
nanonyme: Master is fine for xf86-video-ati.
tball: nanonyme: Are you saying that we don't need r6xx-r7xx-support from drm?
nanonyme: No.
rah: nanonyme: I'm using master for xf86-video-ati
rah: [16:22]
rah: [16:22]
tball: me2
nanonyme: tball: That's exactly the opposite of what I said.
tball: nanonyme: Actually you are right :-)
nanonyme: rah: Ah, read wrong then.
rah: heh
nanonyme: (Kernel 2.6.30 can also do it)
rah: someone's smoking weed nearby
rah: I can smell it through the window
rah:
tball: Hehe :)
rah: nanonyme: is it a different set of code or is it based off of r6xx-r7xx-support?
rah: (in 2.6.30?)
rah: (hold that thought, bbias)
nanonyme: Rather the code in r6xx-r7xx-support got based on it. ^^ (the code in it was made similar to drm-next kernel tree)
nanonyme: Though yeah, I guess the original development was in the r6xx-r7xx-support branch of drm.
tball: rah: soo?
rah: seems to be working fine
tball: :S
rah: no corruption
tball: Do you have any powermanagement specified in the xorg.conf?
rah: yup
rah: Option "DynamicPM" "on"
rah: Option "ForceLowPowerMode" "on"
rah: Option "ClockGating" "on"
tball: k
rah: regardless, I'd file a bug if I were you
tball: When I use Option "ForceLowPowerMode" "on" my system crash in a black screen when ctrl + alt + f1 or shutdown.
rah: I can switch VTs fine
tball: Yeah I probably will. Do you have other things specified in you xorg.conf?
rah: nothing but monitor configurations
nanonyme: isn't personally expecting much from current power management code since he heard it would move to kernel with KMS anyway
rah: anyway
rah: -> out
tball: Hmm, anyone else using arch 64 in here?
tball: rah: thx for your help btw
rah: np
rah: -> gone
Neo_The_User: tball: me
Neo_The_User: ah he left!!!!!!!!
tball: Hmm I get screencorruptsion with icons and stuff, with bot radeon and radeonhd? :S
Neo_The_User: tball: i use arch 64
tball: Neo_The_User: You said before the I should be compiling drm from linux-core?
Neo_The_User: i said you should not
tball: that I shouldn't*
tball: yeah exactly, why?
Neo_The_User: it doesnt have the latest drm code. ask any of the devs in here. they all say linus's tree
Neo_The_User: http://bbs.archlinux.org/viewtopic.php?pid=527139
Neo_The_User: read the 5th message
tball: Will that support xv and exa ?
Neo_The_User: xv and exa is the DDX
Neo_The_User: not kernel
Neo_The_User: you want xf86-video-radeonhd or -ati
Neo_The_User: i say -ati
glisse: tball: for r6xx/r7xx drm is at git://anongit.freedesktop.org/git/mesa/drm various r6xx branch
tball: I want ati
Neo_The_User: Alex Deucher (agd5f) made the xf86-video-ati so bad ass
Neo_The_User: go with xf86-video-ati
glisse: also agd5f got his own drm repo for r6xx
tball: Yeah I know :)
tball: glisse: Ok?
Neo_The_User: tball: follow this guide http://neo-technical.wikispaces.com/xf86-git
Neo_The_User: sudo pacman -S git-core
Neo_The_User: then the guide
tball: Neo_The_User: I used AUR to get the latest git code
tball: for ati
Neo_The_User: eh i do everything against the package manager
Neo_The_User: i know.. its bad
Neo_The_User: who cares
tball: hehe
mjg59: Neo_The_User: You know that you can pass compile flags in environment variables, right?
tball: But IU should be using this? : http://aur.archlinux.org/packages.php?ID=24235
tball: But I shoudn't*
Neo_The_User: look, i like doing what i want
Neo_The_User: you use AUR. I use my own stuff
Neo_The_User: im too lazy
Neo_The_User: mjg59: yes i know
Neo_The_User: stop asking random questions though
mjg59: Neo_The_User: So don't recommend that people hack makefiles
tball: Neo_The_User: Yeah but I don't mind using another way. I just want to know if I should install drm another way, than from the link before
Neo_The_User: thats how they learn how to write makefiles
Neo_The_User: by tinkering with stuff. anyway, back to #radeon
Neo_The_User: DDX is not DRM
mjg59: No, people learn to write automake by looking at the automake input
Neo_The_User: All that Xv stuff and EXA stuff... ok im ignoring you. is all done in the DDX
nanonyme: Neo_The_User: You're not supposed to manually write makefiles.
tball: mjg59: Please don't hijack Neo :P
mjg59: Trying to learn makefiles by reading automake output is like trying to learn optometry by stabbing yourself in the eye
Neo_The_User: ah i love /ignore
mjg59: tball: Better than letting him try to tell you anything, tbh
nanonyme: thinks /ignore is rather childish
Neo_The_User: ok how do i ignore everybody in a channel except for certain people?
mjg59: tball: A great deal of his advice is wrong
Neo_The_User: no its not
mjg59: I thought you'd ignored me?
Neo_The_User: i lied
mjg59: Well, you're also lying about it not being wrong
Neo_The_User: ok im going to stay on topic like a good boy
Neo_The_User: tball: sorry about all this
tball: Its okay
tball: Okay, I try to explain what I have done already
tball: 1. I downloaded radeon git - master from AUR. I have tried it manually once, but I just shiftet to arch, so I like the AUR way
Neo_The_User: which is fine
Neo_The_User: its good for people who dont want a broken system
tball: 2. Then I downloaded drm: r6xx-r7xx-support branch
Neo_The_User: i just perfer broken
tball: fair enough
tball: But step 2. is wrong? Should i fetch drm from another place?
Neo_The_User: no no no
Neo_The_User: just linux-core is wrong
Neo_The_User: just run sudo make install without compiling linux-core
tball: ahh
nanonyme: You don't need sudo for make.
tball: Neo_The_User: Please take a look on this PKGBUILD file, I guess its doing it wrong then: http://aur.archlinux.org/packages/drm-radeon-module-git-r6xx-r7xx/drm-radeon-module-git-r6xx-r7xx/PKGBUILD
nanonyme: Only for make install.
Neo_The_User: none of this: "cd linux-core && make DRM_MODULES="radeon"
Neo_The_User: nanonyme: i know
Neo_The_User: im saying for install to /usr
Neo_The_User: yeh thats wrong
Neo_The_User: ahhaha dumb idiot posted a broken pkgbuild. thats funny
tball: :)
mjg59: ...
tball: Maybe thats why I get screen corrpution with radeon AND radeonhd git
Neo_The_User: mjg59: you don't use arch you have no idea what a PKGBUILD is. dont even comment
mjg59: tball: No
Neo_The_User: oh god here he goes again
Neo_The_User: watches him rant
tball: mjg59: No?
nanonyme: tball: What's your libdrm version, btw?
mjg59: tball: If that builds you a radeon.ko then it's perfectly fine. It won't differ as a consequence of whether you build just the module or the entirity of the drm checkout.
tball: nanonyme: libdrm 2.4.11-1
nanonyme: tball: If you have a relatively new libdrm, you definitely don't need to do more than just compile the kernel modules.
nanonyme: tball: Plenty new.
nanonyme: I think.
tball: Okay so I am good using the pkgbuild posted before?
mjg59: Yes
Neo_The_User: i think so
mjg59: Any bugs you have are unrelated to it
tball: Okay thx everybody
tball: The funny part is that the corruption started after playing with power management options in xorg.conf
mjg59: tball: That's entirely plausible
nanonyme: Does it disappear if you disable the power management options?
tball: But it could also be after a git upgrade though AUR
tball: nanonyme: No
tball: I mean some of it
kdekorte: tball, yes that is possible, I was getting corruption on my laptop with power management
mjg59: Enabling low power mode will force a low clock
kdekorte: tball, also are you using KMS?
mjg59: Which may not be sufficient for scanning everything out
mjg59: And so you may get some graphics corruption
nanonyme: kdekorte: It's r6xx/r7xx.
tball: It was low power mode, which made corruptions and freeze my computer with VT shifting
mjg59: I'm working on a better approach to that, but there's nothing ready for general use yet
tball: ok
kdekorte: I didn't think that the power mode stuff worked at all with r6xx
tball: But there is still corruptions :S
nanonyme: kdekorte: I thought it should.
mjg59: It just makes an atom call, so it should
tball: Want a pastebin of the corruption?
kdekorte: sure
agd5f: works on all the r6xx/r7xx cards I have
nanonyme: mjg59: But if it was due to PM, surely the corruption should disappear with a clean xorg.conf?
agd5f: although some cards have problems changing pcie lanes
mjg59: nanonyme: Well, given he's also seeing corruption with radeonhd
nanonyme: Hrm.
mjg59: There's clearly some other issue as well
nanonyme: Yeah.
kdekorte: Agree
agd5f: sometimes the pcie lanes don't change properly and you have to reboot to fix them
mjg59: agd5f: It also takes about three frames to change the pcie lanes for me
nanonyme: wonders if it was an PCIE card
tball: Could it be some registers not changing back to default?
agd5f: mjg59: some r6xx cards get stuck in pcie x1
nanonyme: tball: Did you try shutting down and starting the computer again?
agd5f: which causes corruption with UTS/DFS
mjg59: agd5f: I'd have expected aspm to provide the same benefit
tball: nanonyme: Yup, and completely power it off
kdekorte: agd5f, does it require a complete power off to reset the card, or will a warm reboot correct it
nanonyme: Well, complete power off would be bound to clear all registers.
agd5f: kdekorte: full power off to be sure
nanonyme: Theoretically a warm reboot might not be enough.
kdekorte: Some boards even need 5 to 10 seconds off to completely power down too
tball: http://img190.imageshack.us/img190/3550/corruptions.png
agd5f: tball: that's looks like DFS corruption
agd5f: probably related to the pcie lanes
tball: agd5f: How do we fix it?
agd5f: tball: I think it's related to cache snooping on gart memory when we render to it and then read it with the CPU
mjg59: agd5f: Do you have anything on aspm implementation?
agd5f: mjg59: aspm?
mjg59: agd5f: Active state power management. Puts idle PCIe links into low power states.
mjg59: Which /ought/ to be providing the same power benefit as the PCIe lanes stuff, but isn't
agd5f: tball: Option "EXANoDownloadFromScreen" will also work around it
tball: agd5f: Is there something I should try, or need anything for debugging?
tball: agd5f: Already tried that. Didn't work
mjg59: Which makes me wonder whether something else is broken
agd5f: tball: disable the pcie lane switching code and
kdekorte: tball, are you overclocking?
tball: kdekorte: No, I'm on a laptop :)
agd5f: mjg59: I haven't seen anything on that. who's supposed to handle that? chipset?
fcami: agd5f: is there a documented list of these options except in the code ?
mjg59: agd5f: OS has to enable it, but then it's supposed to be handled by the chipset and hardware
agd5f: fcami: radeon man page
mjg59: Maybe I'll dig into that again later
agd5f: fcami: it's all off by default at the moment
fcami: either the man pages F11 ships are out of date or I'm missing something
kdekorte: tball, you may want to disable some BIOS options for power management and see if that help. My Thinkpad would lock up on plugin if I had PCI power manament enabled
fcami: agd5f: OK.
agd5f: fcami: it's not in F11
agd5f: code is not in a stable release yet
agd5f: you have to use git
tball: kdekorte: That might explain the freezing when doing VT switching?
kdekorte: tball, worth trying
tball: kdekorte: But again, I don't know if there exist any such option in the bios
fcami: agd5f: OK, thank you :)
tball: But my mainproblem right now is corruptions around icons. I don't really care about powermanagement right now :-)
tball: agd5f: How do I disable the meantioned code?
agd5f: tball: then remove all the power options for now
kdekorte: tball, have you tried gnome or xfce? And do you get the same corruption there?
tball: agd5f: I tried that also. Didn't help
agd5f: tball: did you power off after removing the options?
tball: kdekorte: No, but I am really sure its the driver
tball: agd5f: I change all the opstion in xorg.conf to "false" -> power off -> didn't help
agd5f: tball: you using git or 6.12.2?
tball: git
agd5f: tball: does the 6.12-branch work better?
tball: agd5f: Acutally I am not 100 % sure I did a poweroff or just a reboot after changing the options to false. Should I try it again?
agd5f: tball: sure
tball: Okay brb
rafael2k: people, I got a radeon 9550, and I need to use the TV-Out ouput. well, it's working fine, but when I try to play a video using the XVideo extension, the video gets all blue or all green in the TV-OUT output, while in the VGA output, the video plays as expected.
rafael2k: is that o known bug?
kdekorte: rafael2k, use the textured xv port
kdekorte: xvinfo should help with that
nanonyme: agd5f: Do you think it'd be sane that the BIOS would initialize that kind of stuff on boot on the card?
rafael2k: kdekorte: can I especify it to mplayer?
kdekorte: yeah mplayer -vo xv:[port]
rafael2k: kdekorte: thanks :)
nanonyme: Was just wondering whether or not all cards need a cold shutdown to get to default state.
agd5f: rafael2k: you can also switch the crtc that the overlay displays on using xvattr -a XV_CRTC -v 1
agd5f: nanonyme: reboot should be ok in most cases
kdekorte: I was incorrect on how to specify the port.. it is mplayer -vo xv:port=[port]
nanonyme: Right.
agd5f: tball: does Option "EXANoUploadToScreen" help?
tball: agd5f: Already tried that unfortunately
tball: I could try again, but I'll poste my xorg.0.log first
agd5f: tball: what version of kds/qt?
agd5f: *kde
tball: http://pastebin.com/m332ff8d7
kdekorte: agd5f, have you seen cases where KDE/QT has problems but Gnome/GTK is fine?
tball: qt: 4.5.1-2
agd5f: kdekorte: yes
tball: kde: 4.2.3
agd5f: also seen cases where some versions of qt work while others don't
tball: But I didn't have those problem with qt/kde yesterday?
agd5f: tball: so this just cropped up today?
tball: A wild guess. There has been an upgrade of libgl
tball: yes
agd5f: probably something upgraded
tball: [2009-05-21 13:25] upgraded libgl (7.4.2-1 -> 7.4.2-2)
kdekorte: tball, what does 'dmesg | grep drm' give you.. should give a version #
tball: [2009-05-21 13:27] upgraded xf86-video-ati-git (20090517-1 -> 20090521-1)
tball: [drm] Initialized drm 1.1.0 20060810
tball: [drm] Initialized radeon 1.29.0 20080613 on minor 0
tball: [drm] Setting GART location based on new memory map
tball: [drm] Loading RV635 Microcode
tball: [drm] Resetting GPU
tball: [drm] writeback test succeeded in 2 usecs
tball: Hmm, thats an early date :S
MostAwesomeDude: Not really.
tball: I think the corruption started after:
tball: [2009-05-21 13:25] upgraded libgl (7.4.2-1 -> 7.4.2-2)
tball: [2009-05-21 13:27] upgraded xf86-video-ati-git (20090517-1 -> 20090521-1)
tball: MostAwesomeDude: It isn't?
kdekorte: tball, not those look close to what I have...
MostAwesomeDude: tball: Those dates are a bit misleading; those were the dates of the last version bump IIRC.
tball: ahh ok
tball: Does the code for radeon and radeonhd follow each other closely? I mean has there been any changes to them both for the last 4 days?
tball: Changes where they share the same code
yangman: tball: yeah. only accel code is really shared, though
tball: k
tball: brb, will try Option "EXANoUploadToScreen" again.
agd5f: glisse: new kms patches http://www.botchco.com/alex/xorg/for_glisse/
agd5f: glisse: this should get kms going for mac and sparc cards
rafael2k: agd5f: thanks!
glisse: agd5f: thanks i will push
rafael2k: kdekorte: :)
kdekorte: rafael2k, so it all works now?
tball: Nope
agd5f: tball: try the 6.12-branch or reverting to the older ddx package
tball: I even booted my Vista, which I btw never use. Just to see if that had any effect to the corruption
tball: agd5f: k.
tball: Do you know by any chance the branch name?
agd5f: tball: 6.12-branch
tball: But again, why is radeonhd also affected?
agd5f: shouldn't be
agd5f: if it's the ddx
agd5f: does kde use GL?
tball: Yeah I think, but I have not enabled composition
chithead: kwin can do opengl compositing, then there are apps like avogadro which use it
tball: or any kind of desktop-effect
chithead: kwin does xrender or opengl compositing, depending on configuration
tball: I'll try the 6.12-branch
tball: brb, trying the 6.12-branch
tball: Now using the 6.12-branch -> Still corruption
tball: So it isn't related to radeon / radeonhd whatsoever
nanonyme: Could a libdrm regression cause that?
nha: osiris__: did you talk to fpoibaf about that lockup? Perhaps we could point him to a kernel bisect guide, if you know of a good one?
tball: nanonyme: I don't think libdrm or drm has been updated lately
nanonyme: Right.
tball: Could it be related to libgl? I mean;
tball: [2009-05-21 13:25] starting full system upgrade
tball: [2009-05-21 13:25] upgraded libgl (7.4.2-1 -> 7.4.2-2)
tball: [2009-05-21 13:27] upgraded xf86-video-ati-git (20090517-1 -> 20090521-1)
nha: osiris__: oh and yeah, I don't have a real plan as to what I'm going to do. I'll testdrive current radeon-rewrite this weekend, and then it depends on how buggy it is. I think we could use a good collection/test set of realistic, but more complex shaders.
nanonyme: tball: Well, since this was r6xx-r7xx, I'd consider that highly unlikely.
MostAwesomeDude: nha++
nanonyme: Since it doesn't have hardware accel for OpenGL in any releases.
tball: Yeah that was my though also. But really don't know anymore. I'll try a kernel reinstall, and then reverting back to distro radeon / drm and see if that helps
nanonyme: Sounds good.
nanonyme: Did you file a bug, btw?
tball: Not before I'm certain its not my own fault :P
nanonyme: Well, yeah.
tball: When kernel / reinstall of radeon is finished, I will probably try install radeon/drm git again
tball: I'll let you all know how that went
tball: btw. Is it enough installing drm git r600 branch, if radeon in repository is version 6.12.2-2?
tball: okay reinstallation done. brb
tball: Didn't help reinstall kernel / drm / original radeon :|
zhasha: MostAwesomeDude, nha, does radeon-rewrite actually support shaders?
zhasha: tball, problem?
MostAwesomeDude: zhasha: Yes, certainly. Just not the shader extensions.
tball: zhasha: Icon corruptions... They appeared suttendly
tball: suddently*
tball: http://img190.imageshack.us/img190/3550/corruptions.png
zhasha: couldn't that be kernel related guise? the heal of PAT issues apparently present in 2.6.29
zhasha: heap*
tball: zhasha: ?
zhasha: MostAwesomeDude, so ARB_fragment_program/ARB_vertex_program
zhasha: tball, I get that sort of issues too, though not as bad
zhasha: I'm on r500 though
zhasha: basically because the kernel memory manager messes up
MostAwesomeDude: zhasha: Yeah, only arb_f_p and arb_v_p are supported. Classic Mesa needs some hoop-jumping to do arb_v_s, arb_f_s, arb_s_o
tball: zhasha: Hmm the odd thing is, that I got them today! I haven't seen them before. <- On arch 64
zhasha: og forresten davs
zhasha: did you update the kernel today?
tball: ;-) dav dav
tball: zhasha: Just did, but the corruption persist
tball: Wauu. The screenshot I sended you... Actually the exactly same corruption persist after serveral reboots and shutdowns. I mean its like the kde icon is drawed that way. Not like normal corruption you see varying thing on the screen, but mine is static even after reinstallations and reboots :O
tball: Hmm anyone know where to find kde icons in arch?
zhasha: /usr/share/icons I think
kdekorte: tball, can you try some other desktop, like gnome
scarabeus: /usr/share/icons/oxygen/
scarabeus: if we expect they folow FHS
zhasha: I have arch, icons are stored in /usr/share/icons, and if you're using oxygen, then yes, /usr/share/icons/oxygen
tball: lol, http://img40.imageshack.us/img40/8986/corruptions2.png
zhasha: lol, persistence
tball: Maybe its acutally my icons, which is all screwed up and not screen corruptions :S
tball: Is that even possible? How the h..l have all the pixmaps changed?
ajax: we call those "bugs"
tball: Damn, I wonder if my text files also is screwed up
jcristau: ajax: lies. X doesn't have any of those.
tball: ajax: But itsn't not actually how they are showed. They have acutally changed on the disk? That means ext 4 is not the way to go? :P
agd5f: tball: have they actually changed on disk?
tball: agd5f: I think so yes
zhasha: tball, /usr/share/icons/oxygen/32x32/places/folder.png should be that particular icon
amarsh04: Is it just me, or does KDE 4.2.X stuff make heavier demands of Xorg than KDE 3.5.X?
agd5f: amarsh04: kde choose pretty much every hard to accelerate path possible
tball: agd5f zhasha: Reinstalling every single lib, which has something to do with kde now
tball: <- reboot. After I will let you know
amarsh04: running Debian unstable with xserver-xorg-video-radeon 1:6.12.2-2 , Radeon 9200SE [rv280]
amarsh04: thank agd5f
tball: Well I don't even have to reboot after all
tball: All the corruption are gone
tball: It was acutally my icon picmaps, which had changed on the disk!! Scary though
zhasha: heh
zhasha: well, I doubt it's ext4's fault
zhasha: I've been running it since it came out of dev status
zhasha: and not a single corruption since
tball: After a freeze with xorg (were trying low power mode), my system freeze within a VT switch. Then I hold down the power button to power of the computer
tball: After that, I got the corruption
tball: zhasha: But something did some nasty things with my icons :S
zhasha: next time do: Alt+SysRq+{R,E,I,S,U,B}
tball: ?
zhasha: http://en.wikipedia.org/wiki/Reisub
tball: zhasha: wau didn't know that. Thanks
DanaG: and wait a bit between each.
amarsh04: loaded default modules, dbe, error about not being able to load freetype, lots of enable primary dac/disable primary dac
amarsh04: will downgrade this KDE 4.2 app to KDE 3.5.X version then
tball: bye, and thx for this friendly irc channel
rafael2k: kdekorte: I'll test the bahavior of changing the xv port to make the TV-Out output video tomorrow, and then I post the result here, thx !
koolfy: ahem, is there a link where one can learn the signification of all the specefic vocabulary used here ?
koolfy: it looks interesting :p
PommesDieFritte: Heyho, I get some strange Watereffects with the radeon driver: http://img219.imageshack.us/my.php?image=strangewater.png
nha: koolfy: I don't know about a centralized dictionary; a lot can be gleaned from the various wikis, though they tend to be out of date
nha: e.g. dri.fdo
nha: dri.freedesktop.org
koolfy: ok… I'll look there
nha: I recall bridgman writing some nice forum entries on phoronix, as well
PommesDieFritte: I have a radeon 9600 pro, the driver version is 6.12.1 on Ubuntu 9.04
PommesDieFritte: What could be the problem?
zhasha: PommesDieFritte, depends, what does MBS use to draw? (SDL i think, but what SDL driver)
PommesDieFritte: Where can I see this?
ZitZ: hey guys, could an incompatible Ram stick be the culprit for why my video card crashes any time I enable dri with my x1650?
MostAwesomeDude: There's much more likely causes.
ZitZ: probably, but I've tried quite a few, I'm having trouble thinking of them
ZitZ: can I ask about things that might cause an x1650 to crash only when dri is enabled? I'm about to pull out a spare hard disk to install windows to see if it works there.
koolfy: ZitZ: I have no such crashes with the x1650 :/
ZitZ: neither did I, until I decided to switch motherboards so i could have sata
koolfy: it raises the likilyness of a hardware problem, doesn't it ?
koolfy: probability* :p
ZitZ: yeah, that's what I'm afraid of, but what? and can I fix it, like in the bios or something?
agd5f: ZitZ: does removing the ram stick help?
agd5f: might try memtest
agd5f: memtest86
ZitZ: I haven't tried, I only use one ram stick, I have another that is less mem. But i think the ram is below the min speed or whatever supported by the mobo
koolfy: maybe the pci-e slot of the motherboard has a problem :p
ZitZ: it's agp 8x
koolfy: maybe that's the problem :p (free troll)
ZitZ: yeah, i know, agp is such crap
koolfy: (mine is AGP too ;p)
ZitZ: so memtest will run automatically next time i boot?
agd5f: ZitZ: most distros provide it as an otption in your grub menu. if not, you'll have to run it from a CD. most install CD's have it on them
ZitZ: yeah, it's on my sidux disk, i might as well try it, by the way when I run the sidux live cd, the same crash happens when it tries to start x
TheBrayn: howdy folks
MostAwesomeDude: Yarr.
lucxxx: hey
lucxxx: is the r6xxx-rewrite mesa branch ready for tests?
MostAwesomeDude: No.
lucxxx: ok
MostAwesomeDude: I mean, you can test it, but it's not gonna do much.
lucxxx: is beter then 6xxx-support?
nanonyme: lucxxx: r6xx, not r6xxx. :)
nanonyme: And no, not really. At least the last I've heard.
lucxxx: yea
lucxxx: so it is
lucxxx: ??
lucxxx: ha
lucxxx: aha
nanonyme: Hmm?
lucxxx: i see now
lucxxx: did not read all for the first time
lucxxx: how much time do you think r6xx-rewrite branch will need to get to master?
MostAwesomeDude: Lots.
lucxxx: of montsh years?
lucxxx: of montsh, years?
MostAwesomeDude: I think months.
nanonyme: A lot of other stuff might happen in months though.
nanonyme: Like KMS+mm for r6xx/r7xx and work on Gallium starting. :)
MostAwesomeDude: Hey, I'll wire up Gallium for r6xx as soon as the KMS+GEM is ready. :3
nanonyme: I would personally suspect things would start happening after 2.6.30 release.
lucxxx: and when is KMS+GEM ready?
lucxxx: like how much time?
nanonyme: Since the newttm is supposed to get to 2.6.31 so likely development effort mostly goes to bug hunting in newttm until then.
MostAwesomeDude: When It's Done.
koolfy: nanonyme: what will 2.6.30 change ? :o
lucxxx: ok sorry if i do some harm with my questions
lucxxx: by now
nanonyme: koolfy: I'll rephrase: newttm should be in a mergeable state before 2.6.30 gets released or there will be massive suckage. :p
koolfy: okay :p
nanonyme: Since it might at worst mean newttm only gets into 2.6.32.
nanonyme: (Kinda the same situation as was with r6xx/r7xx EXA+Xv for 2.6.30)
koolfy: You know you're doomed when you realise that even google can't define the main word in a sentence…
koolfy: (here: newttm)
bnijk: radeon xpress 200m 5955 on PCIE, runs like shit
MostAwesomeDude: koolfy:
MostAwesomeDude: http://www.tungstengraphics.com/wiki/index.php/TTM_Memory_Manager
bnijk: how do i make it go faster :( want to play xmoto
nanonyme: koolfy: Afaik mostly: TTM used in kernel to fulfil the GEM interface for userspace to use.
koolfy: ok ty
koolfy: I'm trying to get to understand all that stuff, it wil take some time :p
koolfy: what does GEM standr for ?
koolfy: standr*
koolfy: stands**
koolfy: damn dvorak keyboard
nanonyme: Graphics Execution Manager, apparently.
nanonyme: It's by Intel.
koolfy: okay
koolfy: omg, a french wikipedia page for it, I'm in heaven
nanonyme: radeon won't be using Intel's GEM implementation (which supposedly is tuned for integrated GPU's) but it does use the GEM interface.
nanonyme: (As far as I've understood)
koolfy: and UXA is the next step ? or is it "integrated GPU's" specific too ?
kdekorte: This is the kind of blog post that just makes me shake my head in despair http://onlyubuntu.blogspot.com/2009/05/howto-enable-ati-unsupported-cards-in.html
nanonyme: koolfy: Only Intel seems to be interested in it.
otaylor: kdekorte: uxa is very unified memory specific - it's mostly about enabling some optimizations that only make sense for uma
koolfy: you mean me ? :p
otaylor: koolfy: yeah
otaylor: koolfy: the basic thing it is enabling is taking hte same chunk of memory and mapping it either for the cpu or for the gpu
nanonyme: Sounds very neat when CPU and GPU share memory.
nanonyme: Otherwise not so.
kdekorte: sounds slow
nanonyme: kdekorte: Not necessarily.
nanonyme: For integrated GPU's it sounds quite sensible.
mjr: not more slow than unified memory architectures anyway...
mjr: yeah
otaylor: kdekorte: if you have to switch between cpu and gpu access a lot, it's the greatest thing since sliced bread
otaylor: kdekorte: but better, avoid needing to do that
nanonyme: Holy shit, I think I got the big picture for the first time. :p
kdekorte: otaylor, I know there was a lot of discussion about shared memory systems in the past and how performance could suffer. Ie GPU/CPU contention for the memory bus. How a visually active program could slow down the system due to the video card the cpu fighting for access to the memory
kdekorte: but perhaps many of those issues have been worked around
otaylor: kdekorte: I think partially it's just that there's just so much memory bandwidth available that something like the scanout process doesn't matter a lot
otaylor: kdekorte: (scanout bandwidth is why servers have typically not had UMA graphics even when the graphics requirements are really low)
kdekorte: I think it came down to texture manipulation be the GPU
kdekorte: I agree that the new tech (performance) has really removed some of these items.
otaylor: kdekorte: But certainly a card with dedicated memory has a *lot* more bandwidth the vram than a uma system gets
otaylor: kdekorte: for pixel pushing, uma can't compete, but I dont' think it's much worth worrying about it slowing down your compile
kdekorte: I was thinking more of 3d visualization where the CPU is computing what needs to be shown and the GPU is doing the drawing.. something like Second Life
otaylor: kdekorte: well, there's certainly competition
koolfy: is XAA still the default in xorg 1.5 ?
nanonyme: I thought this was an X driver decision.
nanonyme: And not related to X server version.
MostAwesomeDude: koolfy: It's up to each driver.
koolfy: I found a wikipedia page about EXA telleng to write it in xorg.conf
koolfy: telling*
MostAwesomeDude: Yes, the setting goes in xorg.conf.
MostAwesomeDude: But it's a driver setting, not an Xserver setting.
koolfy: ok
agd5f: radeon git defaults to EXA, but the last release still used EXA. EXA tends to be slower if the composite hook is disabled or the system has really limited vram
agd5f: last release still defaulted to XAA rather
agd5f: can't wait for kms...
koolfy: ok
MostAwesomeDude: agd5f: No kidding.
MostAwesomeDude: So many awesome things when KMS really starts being prevalent.
MostAwesomeDude: We should totally resurrect xf86-video-modesetting.
phoenix64: wouldn't xf86-video-modesetting always be quite a bit slower than the "normal" driver?
phoenix64: I mean, it cannot be that optimized
MostAwesomeDude: Yeah, it's slow, but it'd be a much better default driver than vesa.
agd5f: phoenix64: all teh accel would go through gallium
MostAwesomeDude: phoenix64: If you wanna see something really cool, checkout the EXA-enabled Gallium modesetting DDX. It's awesome.
otaylor: phoenix64: or you could have a system of loading acceleration modules
agd5f: that too
nanonyme: Sounds good to me.
nanonyme: Would the ddx need to be able to detect the actual GPU or would it Just Work (tm)?
MostAwesomeDude: nanonyme: Yes.
MostAwesomeDude: The modesetting DDX uses generic calls.
nanonyme: Right.
MostAwesomeDude: The Gallium DDX uses generic calls for the buffer setup, but the EXA is chipset-specific, so it needs to know in advance which winsys it's using.
MostAwesomeDude: Really, I should fix the build system to call it radeonms_drv.so or something.
MostAwesomeDude: *radeonkms_drv.so, even.
phoenix64: hm. Wouldn't it even be possible to run an accelerated X server in a window with that? As gallium could just use that surface to render everything? :D
MostAwesomeDude: phoenix64: Well, Gallium can get access to the big FB too, by using KMS calls.
nanonyme: MostAwesomeDude: Hrm, wouldn't making it the default require having a generic KMS driver though?
nanonyme: KMS modules, whatever.
nanonyme: s/les/le/
MostAwesomeDude: nanonyme: Well, if there's no KMS available, fallvack to vesa.
nanonyme: Aight.
nanonyme: Would imply when designing support for a new card, always start with KMS. ^^
MostAwesomeDude: nanonyme: Oh, definitely.
nanonyme: Then move on to mm, then Gallium and it's done. Hey, that's actually straightforward. Now only if it could also be easy. ;P
MostAwesomeDude: That's the idea.
Neo_The_User: What do I need for DRI2? And no, I'm not switching to Fedora just to get it
Neo_The_User: I have an r300 and it works on fedora 11 by default for me
agd5f: Neo_The_User: that should do it. otherwise: http://jglisse.livejournal.com/1822.html
Neo_The_User: But then 50% of my text is gone
Neo_The_User: I can't read or do anything
Neo_The_User: What about airlied's drm-rawhide tree with airlieds cs3 DDX?
Neo_The_User: what will that give me?
nanonyme: would suspect a less mature KMS
nanonyme: (Or DRI2 *shrug*)
Neo_The_User: ugh i guess ill just switch to fedora 11 when it comes out
nanonyme: F11 has the less mature stuff too...
Neo_The_User: shoots himself
nanonyme: Neo_The_User: Just use the instructions in the blog entry and file bugs if it doesn't work for you?
Neo_The_User: I'll just stick with the master branches of everything
Neo_The_User: agd5f: how can I tell if I have an atombios?
Neo_The_User: like your last fix to xf86-video-ati had something to do with that
Neo_The_User: I was wondering if that fix would impact me at all
mjg59: If you have r300 you don't
Neo_The_User: thanks
Neo_The_User: mjg59: sorry for snapping at you earlier
nanonyme: mjg59: Wouldn't happen to remember which GPU generation is the first with AtomBIOS?
MostAwesomeDude: R420, I think? Or maybe RV480?
nanonyme: Aight.
onox: RV350 ftw!
nanonyme: Been with us for a considerable time then.
spstarr: onox: I once used those ;)
onox: spstarr: nice :)
spstarr: I still have that laptop but now im on a r6xx / Intel GMA
nanonyme: Also, is there AtomBIOS documentation (as in, how it works and so) lying around somewhere?
spstarr: in GMA mode
MostAwesomeDude: nanonyme: Kgrids. The kernel's Atom parser is really clear-cut and well-documented.
nanonyme: Right.
nanonyme: knows now what to do if he has spare time
MostAwesomeDude: If you get *really* bored, you could nm the XvBA libs and see if there's anything useful in them.
MostAwesomeDude: Or you could test Gallium.
agd5f: r4xx were the first cards with atombios
nanonyme: MostAwesomeDude: I've an r6xx.
spreeuw: nanonyme: does it have xv and 3d accel?
MostAwesomeDude: nanonyme: Ah.
nanonyme: Xv yes, 3D accel not really.
nanonyme: And no Gallium driver at this point.
nanonyme: I also tried booting the machine in Windows to run 3Dmark and noticed that 3870 is quite an impressive GPU even though it isn't the newest available. :)
nanonyme: (rv670)
nanonyme: It's amazing how good graphics it can actually run without choking.
nanonyme: Seems I seriously underestimated the card when I bought it.
MostAwesomeDude: nanonyme: Yeah, graphics cards don't suck as much anymore. :3
nanonyme: Would've tried the newest but didn't have a Vista to try it on.
spreeuw: are any of the HD chips supported by now?
spreeuw: xv and 3d
nanonyme: (And yeah, it's also far more than I'd probably require from the open drivers, probably ever)
nanonyme: spreeuw: All of r6xx-r7xx is WIP.
spreeuw: for instance the HD2400
MostAwesomeDude: spreeuw: No, no 3D for any of them yet.
nanonyme: MostAwesomeDude: Apparently some evil marketing people started using the HD term with pre-r6xx cards too. :(
nanonyme: Someone here had a card which had HD at the end of the name.
nanonyme: And it was iirc r5xx.
spreeuw: how about x1950?
nanonyme: It's an r5xx so yes.
spreeuw: 3d and xv?
nanonyme: All of r1xx-r5xx have 3D and afaik have DRI2 code for testing.
nanonyme: (Xv can mostly be taken for granted, I think all chips have the support :)
spreeuw: it wasnt that for granted a year ago
nanonyme: Yeah, well. Things changed quite a bit this year.
nanonyme: As far as I've understood, all cards should have out of the box Xv with kernel 2.6.30.
nanonyme: (Of course excluding possible different future cards)
adamk_: I think that r500 HD was something like a Mobility 2200HD...
Enrico|ITA|: x2300 if i remeber well
adamk_: Ahhh.
nanonyme: adamk_: Wonder why it's named like that. Is it still Avivo HD?
adamk_: No idea.
nanonyme: (As in, has UVD and so)
nanonyme: That's imo the only relatively sensible reason for the naming. :)
nanonyme: MostAwesomeDude: Hmm, wouldn't studying the XvBA code mostly be interesting for using it to implement VDPAU?
nanonyme: Recalling your (hopefully) jokish suggestion. ;)
nanonyme: As in a "let ATi keep their interface and use it for whatever they wish, we'll use whatever already has support in opensource players" approach.
cra_: has anyone had any luck with R300 EXA? I get a black screen unless I use AccelMethod "XAA" and then I just get an eventual hang/crash
soreau: cra_: Which distro?
cra_: Fedora 11
zhasha: cra_, which card?
cra_: https://bugzilla.redhat.com/show_bug.cgi?id=498278
cra_: 9500 Pro
agd5f: x2300 was the rv550 which was rv515 + UVD
agd5f: hence the HD
zhasha: agp or pci?
GerbilSoft: i'm having an issue where enabling compositing causes the GPU to lock up shortly after
GerbilSoft: using kernel 2.6.30-rc6-git6, mesa 7.5-rc2, xorg-server-1.6.91.901, and radeon from git
GerbilSoft: GPU is rv530
cra_: zhasha: agp
Enrico|ITA|: cra_: i'm using EXA on my radeon 9250 (r200 based) without problems
cra_: EXA appears to hang in the same spot each time: drmIoctl at xf86drm.c:187
cra_: (or drmDMA at xf86drm.c:1229 when using nomodeset)
cra_: i haven't yet ran gdb for the XAA case to see why that is eventually locking up
cra_: i wonder if it is worthwhile trying different servers, going back in time til I find one that works
cra_: the really old one which has been perfectly stable is 6.6.0
cra_: server 1.1.0
cra_: (Fedora Core 5 btw)
MostAwesomeDude: nanonyme: If you want VDPAU, my suggestion would be to talk to marcheu and get an idea of the different pieces of pipeline, then read the VDPAU interface and write software pipeline matching it.
spstarr: MostAwesomeDude: since i have a GMA i can probably try Wayland and see how that is going krh mentioned radeon might work
spstarr: but < r5xx
spstarr: ..of course
MostAwesomeDude: spstarr: I haven't tested Wayland yet.
spstarr: :)
agd5f: benh: I put together some initial patches for radeom kms on non-x86 against glisse's kms drm tree
agd5f: http://www.botchco.com/alex/xorg/for_glisse/
benh: agd5f: ah cool
benh: agd5f: I had it somewhat working a while ago ... haven't had much chance to do anything with it lately tho
benh: agd5f: do you have some non-x86 HW to toy with ? specifically big endian ?
agd5f: nope
agd5f: need tp pick up an ppc board at some point
benh: agd5f: I might be able to get that organized
benh: agd5f: for mac model autodetect
benh: agd5f: the cool thing is that in the kernel, you can very easily access the OF device-tree
benh: agd5f: I don't know if you have access to the folks at ATI who did the Mac drivers back in the OF/ppc era
agd5f: benh: cool. that's what I figured, but I'm not familir with how to do that
benh: agd5f: but they might be able to tell you what properties are useful in there... I think it's mostly all based on the "name" of the card
benh: agd5f: ie, they gave a different nickname to every variant
benh: agd5f: you can see some example of how to do that in radeonfb, it retrieves the clocks from the device-tree
agd5f: I know of a few, but I'm not sure how much info exists any more
benh: agd5f: best first would be to see if you can get from those guys what properties you need
benh: agd5f: and then I can tell you how to get them
benh: agd5f: well, they may still have the source code :-)
benh: agd5f: the code for D2 on M6/7/9 in radeonfb comes from them :-)
benh: agd5f: initially they sent me incomplete bits of what lookd like the MacOS 8/9 driver and then they actually fixed up the linux one to work, that was quite cool (and earned them some champagne, dunno if they remember)
agd5f: yeah, I need to port that and the asic init stuff over
benh: yeah, I have all sort of DLL & PLL setup code in there
benh: that works
benh: some of it I actually reverse engineered in fact :-)
benh: (the M10 related bits were entirely R-E)
benh: agd5f: if you want the machine model in the kernel, you can just do machine_is_compatible()
benh: ie. if (machine_is_compatible("PowerBook5,3")) ....
agd5f: oh nice
benh: but you may be better off actually testing for specifics in the device-node of hte ATI card itself
benh: you can get it with pci_device_to_OF_node(pdev)
agd5f: I assume that stuff is only available in ppc builds?
benh: and then do get_property(node, "name", &len); to get properties
benh: yes
benh: some of it may be on sparc too but stick to powerpc for now
benh: the device-tree for recent ATI stuff in ppc mac is a bit more complicated
benh: the node you get with the above represent the card
benh: but it has 2 sub-nodes (one for each CRTC I suppose, unclear)
benh: there's code in radeonfb to get EDID info from there
benh: which is useful with some laptops that don't have working i2c
agd5f: ah, good to know
benh: older cards just have one node
benh: with two properties, EDID1 and EDID2 :-)
benh: iirc
benh: anyway, the code in radeonfb should deal with those cases
benh: though it would be good to know what the "proper" method is from the Mac drivers
benh: a lot of that is the result of trial and error
benh: one thing we never got quite right is the LVDS up/down sequence
benh: on various models, it's still common for the panel not to sync properly when changing modes
benh: the sequence seem to be different for pretty much every panel out there and I couldn't find a way to retrieve infos about it from OF, so I wrote something in radeonfb
benh: that -sort-of- works for everybody but isn't always very reliable
agd5f: I looked into that, and got some info which I used in the kms code
benh: ah cool
benh: looks like I really need to start using that kms and testing it out :-)
benh: there's two basically different class of issues on ppc
agd5f: the firmware folks said it tends to be oem specific though, so it's hard to get right everywhere
benh: those "mac" (or in general "open firmware') cards
benh: so no x86 ROM
benh: and x86 cards
benh: with or without an x86emu based boostreap
benh: agd5f: yes, it does tend to be that way... the mac folks may be able to dig something from their old macos drivers
agd5f: proper LVDS_GEN_CNTL bits and delays are in the lcd info table on x86 roms
benh: agd5f: yes, so the case of an x86 card in a ppc is pretty much solved nowadays as long as we can POST it
benh: agd5f: minus endian bugs etc...
agd5f: yeah
benh: agd5f: the "mac" cards advantage is that there isn't that many of them
agd5f: should be able to post x86 cards using bios tables as well
benh: agd5f: it should be possible to manufacture tables of what we need based on the card OF "name"
benh: agd5f: right, works with ATOM fine nowadays, I haven't tested with old style tables yet
benh: agd5f: if we could get a hand on the info that's hard wired in the MacOS drivers
benh: agd5f: we should be able to construct some kind of table
agd5f: olt tables seem to work ok at least on x86 expect for IGP chips
benh: agd5f: based on the card OF "nickname"
agd5f: benh: tcore has reference init stuff as well for older asics
benh: ok
spstarr: Good morning bridgman
bridgman: hi spstarr
bridgman: joys of living in the country... thought I heard a funny noise in the heating duct, turned out to be a big 'ol porcupine trying to eat his way into a vent on the outside wall
bridgman: we cut a deal; I gave him a carrot and he went away ;)
spstarr: haha
spstarr: has never seen a porcupine yet
spstarr: ive had a close call run in with a skunk
spstarr: but calmer heads prevailed