Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-17

Search This Log:


agd5f: whoever was having problems with scaling on pre-avivo chips, try this patch: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-fix-legacy-rmx.patch
Nightwulf|work: hi all
cxo: you know... you are a proper night wolf
cxo: you always come round in the middle of the night, its 1:42am
MostAwesomeDude: Or he lives in a different timezone.
MostAwesomeDude: It's only 10:43pm here.
hifi: 8:43am
hifi: holy cow, we live around the world!
hifi: amazing, the internets!
Nightwulf|work: 07:44 here :)
Nightwulf|work: oehm....07:44 *am* of course :)
soreau: It's nearly midnight here
Nightwulf|work: well, my "here" is germany (GMT+1)
wsnelr: I know the lack of firmware as free software is some what of a sour point but shouldn't there be a little diagram at the x.org site explaining the black box that is the binary blob on the video card, and the surround drivers that are free software? It took a little hunting to identify I had to get the firmware, and abide by the ati license.
MostAwesomeDude: wsnelr: Well, the firmware is nearly free.
MostAwesomeDude: We have no limits on its redistribution.
MostAwesomeDude: And, to be honest, before the deal with AMD, the firmware was still there, reverse-engineered from fglrx.
eosie: it's 7:59am here ;)
JohnDoe_71Rus: [09:59:31] morning
agd5f: it was never RE'd from fglrx
cxo: wsnelr, yeah, asking for open source microcode on cutting edge graphics hardware is a little... much
agd5f: the ucode that is
zhasha: eosie, MostAwesomeDude: morning
eosie: morning
eosie: though I have to admit I haven't slept yet
zhasha: I finally got off my ass and made rsim useful
zhasha: you can now use it to view a CS down to the individual bitfields each DWORD sets
zhasha: http://imagebin.org/75703
eosie: looks good
zhasha: hope it helps *someone*
zhasha: next up is a state machine, and then a shader viewer
eosie: what about helping with the driver? ;)
eosie: too bad that Gallium doesn't handle depth compare modes (luminance, intensity, alpha) at all
zhasha: I would but I'm not smart enough to do anything useful
eosie: it's not about being smart, it's rather about patience and nerves
zhasha: patience to read the accel guide in its entirety is something I do not have
eosie: and patience to read all important source files in gallium
zhasha: well that I could do
defaultr0: good afternoon folks. I just got compiz running on fedora 12. When I play a video using mythfrontend outside of compiz, playback is fine, no video tearing. Once I turn on compiz, the same video I play using mythfrontend is now showing video tearing. How do I fix this?
soreau: defaultr0: Does playback still tear with mplayer -vo xv ?
defaultr0: yes
defaultr0: i just tried it
defaultr0: then metacity --replace & it and reran mplayer -vo xv, tearing is gone
defaultr0: the fedora folks told me to file a bug at https://bugzilla.redhat.com
airlied: I don't think it'll help anytime soon
airlied: its a big job to get compiz tearing fixed
defaultr0: yep, I'm fine
defaultr0: i'm not in a hurry :)
defaultr0: but am so glad to see compiz
airlied: are you playing video fullscreen?
airlied: I think there is a compiz option to unredirect fullscreen windows
defaultr0: i'm just wondering back in the days since I also encountered tearing on my nvidia 6600GT card. All I did was to modify a setting in xorg.conf
airlied: not sure where that is hidden
defaultr0: yes, it's fullscreen
airlied: gconf-editor, apps->compiz->general->screen0->options
airlied: unredirect_fullscreen_windows
airlied: see if that helps
defaultr0: oh ok
defaultr0: wait, I'm lost with that
defaultr0: so gconf-editor is what I should type right?
airlied: yeah its an gnome-app
defaultr0: ok
defaultr0: doing it now
airlied: it might be in Apps->System Tools->Configuration Editor
defaultr0: i don't have that command
defaultr0: i typed it
defaultr0: it said command not fond
defaultr0: found
defaultr0: let me check the menu
airlied: as root, yum install /usr/bin/gconf-editor
defaultr0: ok, yep, not installed
defaultr0: installing
defaultr0: ok, installed try now again, brb
defaultr0: it's not check
defaultr0: should I check it?
defaultr0: i mean, unredirect_fullscreen_windows is not check
airlied: yup check it
defaultr0: ok
defaultr0: what's next
defaultr0: machine is far :)
defaultr0: keep running back and forth, hehehe
defaultr0: do I test a video after doing that?
airlied: yes test fullscreen movie playing
defaultr0: k
defaultr0: brb
airlied: I've no idea if it'll help, but its the best quick suggestion I hvae
defaultr0: tearing is still there
defaultr0: like i said earlier, no tearing if not playing within compiz
airlied: ah well thats me out of ideas, other than trying different mplayer (gl or xv)
defaultr0: i've tried xv and tearing is still there
defaultr0: but since we just modified something, let me try xv again
defaultr0: tearing was still present using mplayer -vo xv
defaultr0: then I ran metacity --replace & and reran mplayer -vo xv, tearing gone
defaultr0: fedora folks told me to file a bug and it could be a Mesa bug
airlied: its kinda a bug across the whole stack, server, drivers, compiz
defaultr0: ok
airlied: filing a fedora bug will just put you in contact with me ;-)
defaultr0: oh :D
defaultr0: I created an account in the fedora filing bug website but I haven't receive the email yet
defaultr0: so if I buy an nvidia card, will it fix it?
defaultr0: or is it the same behavior?
airlied: not sure, the binary drivers might have proper supprot for it
airlied: but I can't tell
defaultr0: ok
defaultr0: i used the binary earlier and compiz wasn't running
defaultr0: then soreau assisted me
defaultr0: then someone from fedora told me to install mesa
defaultr0: then compiz worked
defaultr0: everything was great
moobie: Hello. Does pm for kms and r700 works?
defaultr0: so the playback video tearing is actually minor
moobie: Or said in another way. How well does the experimental patch works?
defaultr0: so airlied, looks like it's a major overhaul?
airlied: defaultr0: its on the list of things todo, just not sure when it'll get high enough
airlied: sorta waiting to see if the Intel driver can get it working first :-)
defaultr0: cool
moobie: airlied, do you got anything todo with pm?
moobie: or know anything about the status of powermanagement
defaultr0: i'm jealous :) I also would like to learn how to write like what you do
defaultr0: but not sure where to start
airlied: moobie: not really, there are patches on dri-devel, working on the pm infrastructure
airlied: they don't save much power yet, its more about getting the framework correct first
moobie: thx for the information
moobie: yet I won't switch to the oss drivers. I got a laptop
defaultr0: goodnight airlied, I'm sleeping now, it's past 3am here
airlied: night
amarks: airlied: any ideas on http://bugs.freedesktop.org/show_bug.cgi?id=25622
airlied: amarks: wierd, you can probably jsut do xset force dpms off
airlied: and hit a key to get it back instead of using xrandr
juergbi: is there a list of r600/r700 cards that work best with 2.6.32 kms and ati master? (especially when used with two dvi connections in case that matters)
airlied: juergbi: all of them?
amarks: airlied: it's happening more regularly since moving from 2.6.32 stock to +drm-linus
amarks: airlied: is there any more info i can provide?
airlied: amarks: just thinking, you could grab avivotool and dump regs to see if there are any differences
airlied: though I can't imagine there is too many
juergbi: airlied: a friend had various issues with 3 out of 4 r600/r700 cards he tried, some only worked with radeonhd, some only worked with one monitor... (i told him he should file bug reports)
amarks: airlied: where is the avivotool tarball?
airlied: http://people.freedesktop.org/~airlied/radeontool/
airlied: its inside radeontool
juergbi: so i thought i ask here before buying the next card
airlied: juergbi: we don't have any known cards which are worse than others I don't think
airlied: maybe some of the rv740 have some wierd suspend/resume issues
airlied: but most other things seem pretty okay
juergbi: ok, thanks for the info, will just get the cheapest card with two dvi, then
juergbi: which is a rv740, however, i'm not using suspend/resume on the desktop currently
amarks: airlied: "avivotool regs" dumps a whole bunch of stuff, i assume that is dumping all?
mcgreg: hi
mcgreg: since recently kms stopped working here and lead to a crash. I believe this is some framebuffer problem which could be loaded. curently it loads only VGA VESA (I really dont know why suddenly) ... so what frambuffer need to be enabled for kms working radeonfb?
amarks_: airlied: i tried "avivotool regs all" and it hard locked the machine
amarks: is that a no no cmd or something
mcgreg: 30.144397] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
mcgreg: [ 30.145725] fb1: radeondrmfb frame buffer device
mcgreg: is that the problem?
glisse: mcgreg: disable all fb device in your kernel
glisse: radeon kms will create radeondrmfb
mcgreg: oh ok
mcgreg: at least I can ssh connect and see whats happening
mcgreg: oh cool, when I try to un load radeon module the kernel crashes :)
mcgreg: but I dont see any vga vesa or silimar module loaded in the module list
glisse: mcgreg: maybe you have built them in
glisse: disable all of them
glisse: it's a recipe for trouble with kms
mcgreg: hmm that quite impossible, is wasn that wayall the time , except something changed suddenly forno obvious reason
mcgreg: as I said lsmod doesnt show any vga vesa stuff...
glisse: if they are builtin they don't show in lsmod
glisse: best is to wait for your distro to package kms
mcgreg: glisse, I was using my own buit kernel and it stopped working
mcgreg: it wortkked all the time since weeks
mcgreg: *worked
airlied: amarks: try with just regs and regs pll1 and pll2
amarks: ok
airlied: see if there is any differences
airlied: but i can't imainge there would be
amarks: what is pll
airlied: its the piece of hw that create the clocks
airlied: that are used to scanout the display
amarks: if it happens seeminly randomly, perhaps a timing issue?
amarks: or is init pretty basic ?
airlied: it might a timing problem, maybe we have to wait longer sometime for something to settle
EruditeHermit: airlied, if you are still interested, I will be able to further debug that bug this weekend
EruditeHermit: i got a hard drive
airlied: EruditeHermit: got a new hdd? cool, me will have to page it all back in ;-)
amarks: airlied: is there any difference at boot versus coming out of dpms?
EruditeHermit: airlied, I see you've done a lot of other stuff in the meantime =p
EruditeHermit: airlied, its not a NEW one per say. It is a used one.
EruditeHermit: per se*
airlied: amarks: not really, since we shuold dpms off at bot now
airlied: but I've seen wierd stuff happen at boot on other gpus
amarks: airlied: just triggered it via dpms force off, and did a diff on the avivo output regs, pll1, pll2 - nothing :(
amarks: i tried to recover with force off again, but didn't work, had to force off twice to reover
amarks: recover
amarks: can i shove udelay somewhere?
airlied: amarks: not sure whre thebest place to guess would be, maybe in between pll program and next things
airlied: it may also be an ordering issue
amarks: well let's try to eliminate something
Zajec: what is Bloom in openarena?
Zajec: it makes my fps 2-3
lordheavy: it bloom your fps :-)
Zajec: :P
lordheavy: same problem here
dileX: hi
darkbasic: Zajec: fps? if they aren't spf you're lucky :P
Zajec: i've borrowed Sims 3 from friend
Zajec: installing it whole night ;)
Zajec: and doesn't work with r600
dileX: installing it whole night? from 500+ floppy-disks :-)?
mcgreg: sound liek good old amiga times, hehe
Zajec: dileX: it's wine.... ;)
Zajec: i've to manually kill some defunceted app and wine doesn't support some patched versions
dileX: mcgreg: hehe. yeah. got an a500/a2000/2xa3000.
mcgreg: ok,I have been fighting wit my problem for some time now. I have blacklisted several fb modules -> http://pastebin.org/65949 and started dpkg-reconfigure linux-image-$(uname -r) so the initramfs image gets refreshed but nothing changed. damn. wtf is wrong
dileX: mcgreg: which distro and arch?
mcgreg: debian unstable. it worked totaaly normal ... I did some upgraded ion the while and suddenly I got that crap error I really cant get rid of-> [ 10.532316] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 10.533614] fb1: radeondrmfb frame buffer device
mcgreg: [ 26.675312] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
mcgreg: I thought by removing the fb module from the initrd image should solve the problem
mcgreg: but either that doesnt work (liek it should) or the problem lies elsewhere
dileX: which arch?
mcgreg: unstable
mcgreg: this is the arch
mcgreg: which is also naned as sid
mcgreg: named
dileX: i386/amd64?
mcgreg: oh
dileX: thats branch :-)
mcgreg: sry I misunderstood amd64
dileX: hmm, no ready-to-go kernel for you
mcgreg: dileX, I have been using a self-compiled kernel for at least a few months now which worked totally fine with kms... itsuddenly stopped a few days ago
dileX: shouldnt it be /etc/modprobe.d/blacklist.conf?
mcgreg: hmm the guys in #debian told me that ... altough I can add that lines there too
dileX: or symlink
dileX: did you uncompress your initrd.img and investigated what k-m are in?
mcgreg: no I havent test that yet... but adding the modules to /etc/modprobe.d/blacklist.conf didnt change anything
dileX: what did you add?
mcgreg: http://pastebin.org/65949
mcgreg: those modules
dileX: culprit should be radeonfb.ko (I have disabled that)
dileX: # CONFIG_FB_RADEON is not set
dileX: extra-configs for kernel-buildsystem:
mcgreg: ok,I'll retry since I as too stupid and added .ko to the module name -.-
dileX: mcgreg: oops
mcgreg: ok. I changed that. no change as well :(
mcgreg: I think I'll give it up :(
logari81: hi, a user who I am trying to help has flickering on 1280x1024 while 1024x768 work well, here is his xrandr result
logari81: http://pastebin.ca/1718143
logari81: he has a X2100 card, any tip I can give him?
chithead: describe "flickering"
logari81: chithead: his screen flickers randomly
chithead: this description is still not precise enough
chithead: you mean get distorted screen, black screen, monitor goes into powersave mode, how long does it persist etc.
logari81: chithead: he says, his whole screen flickers and sometimes it goes off for some seconds and comes back again
chithead: so the screen is blank and monitor loses signal
logari81: chithead: thats what I understand
chithead: if it works with 1024x768 but not 1280x1024, try to set refresh rate to 60 hz
adamk: This is a DVI monitor? Have him try disabling coherent_mode via xrandr.
logari81: at 60Hz he has the same problem
chithead: also you could try to set displaypriority to high in xorg.conf. what version of xf86-video-ati does he use?
logari81: chithead: here you have his log http://pastebin.ca/1718175
logari81: reading about coherent_mode
adamk: IF he's using KMS, it's probably just coherent, and not coherent_mode, but 'xrandr --props' would let him know.
adamk: Looks like he's not using the DVI port, though.
logari81: adamk: hmm, yeap its HDMI
adamk: I don't think coherent_mode applies in that case.
logari81: adamk: ok
logari81: I ll get some feed back about how it works with display priority set to high and come back if necessary
twnqx: if i replace 31.y with 32.y in the build docs from topic - will it still work?
darkbasic: twnqx: yes, it works
twnqx: right. and where was that pm patch that was needed on tob? :X
twnqx: top*
darkbasic: twnqx: do you mean this? http://sourceforge.net/mailarchive/forum.php?thread_name=b170af450912161802r37f0aa97u31410dfb37f7ad3d%40mail.gmail.com&forum_name=dri-devel
twnqx: possibly, i've just overheard someone else talking abt it
twnqx: will hold darkbasic responsible if the laptop goes up in smoke
darkbasic: twnqx: you shouldn't use it, because it will clock down the core only of 50Mhz. you shouldn't use kms if you want power management
twnqx: well, without kms i have more problems
twnqx: like... i can't switch to console because the backlight goes off, and similar
darkbasic: twnqx: ums is the only way to have power management right now (you have to forget about dynamic pm, of course)
twnqx: meh.
twnqx: changes 50mhz to 500mhz and waits for screen corruption
BioTube: Zajec seems to have decreased the number in the latest patch - mine ownly downclocks by 5MHz
twnqx: rdev->pm.min_mode_engine_clock = rdev->clock.default_sclk - 5000 seems to confirm this :P
BioTube: that would explain why some people never see upclocking
spreeuw: whats the problem with getting memory above 256MB working?
spreeuw: is it a kms issue or drm?
spreeuw: or radeon?
spreeuw: is it available in 3d?
Pallokala: yes
Pallokala: it you are talking about the message in Xorg.log
Pallokala: the grahics-card sees it and can use it
twnqx: iirc there's an entry in /proc where i can see the current clock speeD?
BioTube: debug/dri/0/radeon_pm_info
twnqx: mh
BioTube: in debugfs^
twnqx: i never enable debugging ;_;
bjaglin: why is the minimum engine/memory clock 5Mhz below the default in the pm patch? I mean, what is this magic number?
twnqx: it's experimental
BioTube: bjaglin: the main goal is to just get the framework going
BioTube: magic numbers get replaced after that
bjaglin: but what would be the problem of a too slow clock?
ConnorBehan: can someone tell me ideal versions of libdrm, xf86-video-ati, mesa, xorg-server and the kernel required to get good performance with modesetting?
darkbasic: ConnorBehan: what do you mean with "good performance"?
BioTube: ConnorBehan: git master for everything but the kernel, for which you'll want drm-radeon-testing
ConnorBehan: so vanilla 2.6.32 is known to be horrible?
BioTube: bjaglin: an overslow memory clock will cause graphical corruption, while such an engine clock would cause constant upclocking to deal with anything
BioTube: ConnorBehan: no, but more work's been done since then
ConnorBehan: BioTube: I started off using 2.6.31 and got 200 fps in glxgears with an r500 card
ConnorBehan: I was told framerate would improve significantly with 2.6.32 because it has drm-next
ConnorBehan: however upgrading the kernel caused my framerate to go down to 2 fps
ConnorBehan: upon which I was told to recompile my userspace
ConnorBehan: I did that and now I get 15fps
bjaglin: ConnorBehan: i had sensible improvements with xserver 1.7 on my RV250 (gtkperf)
ConnorBehan: using 1.7.2 now
bjaglin: BioTube: ok i see... but don't we have dynamic pm in UMS already? how is that working?
twnqx: clocks down both cpu and mem by 200mhz for no and watches what will happen
darkbasic: bjaglin: no dyn pm for ums
BioTube: bjaglin: not for r600 and the kernel's in a better spot to actually get it right
bjaglin: what does the DynamicPM flag do in UMS?
twnqx: uhhh
twnqx: the patch... it doesn't apply :X
BioTube: twnqx: it relies on another patch that sould already be in drm-radeon-testing
ConnorBehan: which of these is the most likely culprit for my slow framerate: libdrm 2.4.16, xf86-video-ati and mesa compiled from git yesterday, xorg-server 1.7.2, kernel 2.6.32.1?
twnqx: BioTube: 2.6.32.y git (2.6.32.1) + allied's drm-next
glisse: ConnorBehan: it sounds like you don't have gl accel, glxinfo | grep render will tell you for sure
ConnorBehan: direct rendering: Yes
ConnorBehan: Mesa DRI R300 (RV515 7187) 20090101 x86/MMX/SSE TCL DRI2
BioTube: twnqx: drm-next doesn't have it
twnqx: rrrr
twnqx: where do i get *that* testing thing, then?
ConnorBehan: is it because I didn't pass --disable-gallium to mesa? I think I forgot to do that
BioTube: twnqx: git pull drm-radeon-testing
darkbasic: BioTube: what's the differce between allied's drm-next and drm-radeon-testing?
BioTube: darkbasic: drm-radeon-testing gets the radeon patches well before drm-next
bjaglin: BioTube: but is there dyn pm for legacy cards in UMS? RV250 here
BioTube: bjaglin: I don't know
darkbasic: BioTube: how can I patch the latest stable kernel with drm-radeon-testing branch? sometingh like explained here (http://xorg.freedesktop.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3)
BioTube: it should pull right on
darkbasic: BioTube: isn't it a 2.6.33 branch?
twnqx: git doesn't work like that
BioTube: darkbasic: it's based on 2.6.29
ConnorBehan: should I compile and install the entire drm-radeon-testing kernel? or is compiling the drivers/gpu/drm modules and copying those sufficient?
darkbasic: BioTube: I don't want a 2.6.29... is there any way to patch a 2.6.32 kernel with drm-radeon-testing?
BioTube: darkbasic: yes - clone the 2.6.32.y repo and pull drm-radeon-testing on top of it
ConnorBehan: and is there anything special I should have in my .config?
BioTube: not as far as I know
ConnorBehan: ok I'll try this but I still can't believe a kernel WITH drm-next is 50 times slower than a kernel WITHOUT drm-next
BioTube: it has what was in drm-next AT THE TIME
BioTube: as I've said, improvements have been made since then
ConnorBehan: ok well drm next at the time was worse than regular drm at the time :P... cya
maderat: how switch on debugfs for PM?
BioTube: maderat: it's done automatically
BioTube: just mount debugfs and look in dri/0/radeon_pm_info
twnqx: BioTube: just assume i'm stupid and clueless about git, but i got a 2.6.32.y + drm-next according to the topic. how to go to drm-radeon-testing from there? :X
BioTube: just use drm-radeon-testing as the branch name instead of drm-next
BioTube: ie, insetad of git pull airlied_drm_remote drm-next, use git pull airlied_drm_remote drm-radeon-testing
twnqx: so... how to i remove the drm-next from my sources again? :X
maderat: i need to do something in xorg.conf?
twnqx: or do i have to dl a clean copy?
BioTube: twnqx: they're different branches of the same repository
maderat: how to mount debugfs for radeon?
twnqx: i understood that, but i pulled the drm-next in, and dling a gb to the kernel takes... long
intgr: maderat: mount debugfs -t debugfs /sys/kernel/debug
BioTube: twnqx: just git pull airlied_drm_remote drm-radeon-testing and it will grab the new commits
twnqx: ah
maderat: PM does not work for me :(
darkbasic: maderat: as far as I know PM is disabled for untested cards
maderat: default memory clock: 800000 kHz current memory clock: 796500 kHz
maderat: disables in kernel code or xorg?
maderat: disabled?
bjaglin: darkbasic: i think Zajec enabled it for all cards in v6
bjaglin: yesterday i had to patch its v5 patch to enable it on my RV250, but it worked fine then so i think he removed the protection
darkbasic: bjaglin: good to know
darkbasic: maderat: lowered clock is only few MHz lower
twnqx: drm-radeon-testing on top of drm-next has conflicts >_>
dileX: maderat: PM? depends on GPU. rv515 and rv250 need additional patches on top of v6. see dri-devel ML. r600 works with v6. kernel? latest linus-tree or drm-linus (I tested both)
BioTube: twnqx: really? try resetting to 2.6.32 and pulling drm-radeon-next from there
twnqx: how do i reset? :(
BioTube: git reset --hard v2.6.32
dileX: rv250:
twnqx: i'm SO lost with git >_>
dileX: rv515:
twnqx: BioTube: thanks, now it worked
twnqx: right, now the v6 patch applies
maderat: i done that 2 min for reboot
darkbasic: is trying drm-radeon-testing
bjaglin: dileX: actually, this patch is not required, since the memory clock cant be changed anyway, it just enables reading the current memory clock
bjaglin: for RV250
dileX: bjaglin: OK
agd5f: adamk: coherent applies to any tmds signal, so dvi or hdmi
agd5f: twnqx: the units are 10khz, so 5000 = 50 Mhz
twnqx: oops.
twnqx: so i just set it to go down by 2ghz....
twnqx: i wonder if that will work as expected.
honk: what is expected? running backwards?
twnqx: no, using less power.
maderat: M96 PM work but there is no reclocking only downclocking default engine clock: 600000 kHz current engine clock: 548430 kHz
darkbasic: BioTube: I've just compiled 2.6.32+drm-radeon-testing, but there isn't any arch/x86_64 directory O_O
bjaglin: is there a way to remove/reload radeon when radeon is active with KMS?
darkbasic: can someone help me with git and drm-radeon-testing?
bjaglin: darkbasic: i am pretty new to git... what's wrong?
darkbasic: bjaglin: I just compiled 2.6.32+drm-radeon-testing following the guide on the freedesktop wiki (using drm-radeon-testing instead of drm-next), but therisn't any arch/x86_64 directory and so bzimage
darkbasic: *there isn't
BioTube: is it looking for one?
BioTube: it looks like it shraes the arch/x86 folder
[Enrico]: BioTube: yes x86_64 is just a symlink to x86
darkbasic: BioTube: there is no bzimage in x86 too
[Enrico]: darkbasic: try with make bzimage (or bzImage i don't remeber)
darkbasic: yes
darkbasic: I tried both
[Enrico]: or it is make image..... oh never used it but i know there is a way
roysjosh: `make help' shows what you can do
darkbasic: uhm... maybe I found the problem! I forgot R600_rlc.bin!
evil_core: bjaglin: rmmod -f radeon
evil_core: there were also some toold called vgareset or someting like that to hardreset gfxcard and get back vga console
bjaglin: evil_core: i get ERROR: Removing 'radeon' : Resource temporarily unavailable, which i can understand since i am on a native resolution console doing that
bjaglin: do you reboot each time you want to reload radeon?
agd5f: bjaglin: you need to unbind the console before you can unload it
agd5f: bjaglin: but you'll need remote access as you'll lose your console when you do that
bjaglin: agd5f: ok thanks
bjaglin: grr and the wireless won't work beacause gdm kills network-manager
bjaglin: tricky
evil_core: bjaglin: I was losing console, but was able to load w/o kms, and start kdm
dileX: oha Merge branch 'glsl-pp-rework-2'
dileX: hmm
dileX: /bin/bash: ../../../../../src/glsl/apps/compile: No such file or directory
dileX: +GLSL_CL = $(TOP)/src/glsl/apps/compile
evil_core: what should I use to get r500 with GLSL?
otaylor: evil_core: there's no usefully usable GLSL support yet there for the free radeon drivers
evil_core: I heard that openarena/nexuiz work afdter disabling bloom
evil_core: and that I can switch between UMS and Gallium on the fly, so it wouldnt be problem
evil_core: will I get bettrer performance on r500 by upgrading 2.6.32 to drm-radeon-testing?
Ghworg: dileX: Change configure.ac line SRC_DIRS="mesa glew" to SRC_DIRS="glsl mesa glew"
dileX: Ghworg: OK. thx.
dileX: have an old GIT tarball here. re-newing
dileX: Ghworg: thx - works. I put the patch here .
Ghworg: dileX: No problem. I'm still compiling here, you must have a much faster machine than me :-)
Ghworg: Then again, I do compile a bunch of junk I don't need to make the deb packages
dileX: Ghworg: no. maybe script :-) 5min with ccache on a T7200. .
dileX: hmm
dileX: make[3]: Entering directory `/home/sd/src/mesa/mesa/src/glsl/apps'
dileX: make[3]: *** No rule to make target `install'. Stop.
evil_core: mipmapping or texture filtering is broken for me
bjaglin: dileX: same here, i had to revert the last commit
evil_core: textures in quake3 looks like pixel art
dileX: bjaglin: thats a big revert and I am interested in it :-)
agd5f: otaylor: actually GL2 is pretty much done in the r600 driver
Ghworg: dileX: I guess a dummy install target is needed in that Makefile, that's what I'll be trying first anyway (still compiling)
dileX: Ghworg: I did [src/glsl/Makefile] -SUBDIRS = pp cl apps +SUBDIRS = pp cl (ugly, but does it job for make install)
dileX: glxinfo.txt: http://pastebin.ca/1718458
Ghworg: Nice
dileX: oops, OA anholt demo slows down
dileX: Ghworg: glsl_Makefile.diff: http://pastebin.ca/1718480
kdekorte: dileX, I applied your patch and still can't compile mesa
otaylor: agd5f: ah, cool, guess I'm not paying close enough attention
kdekorte: seems like a make file ordering issue
kdekorte: might have something to do with the fact that I am running make -j 4
dileX: kdekorte: http://pastebin.ca/1718494 (both fixes sent to dri-devel ML)
kdekorte: I had problems with the glsl pp and cl subdirs not being compiled before apps
Ghworg: mesa has always failed with anything other than -j 1. The build system is horridly broken
kdekorte: Ghworg, been working ok for me for quite awhile
Ghworg: kdekorte: You've been lucky then, it fails 80% of the time for me
dileX: kdekorte: try that two fixes. compiled fine here.
kdekorte: interesting
kdekorte: ok gotta reboot... new xserver
cxo: isnt hdmi audio also complete? http://www.x.org/wiki/RadeonFeature
MrCooper: dileX: Mesa patches should go to the mesa3d-dev list
dileX_: MrCooper: sorry, you are right.
moo_: is it possible to change the resolution of radeondrmfb? i tried fbset on 2.6.32.1, but got 'ioctl FBIOPUT_VSCREENINFO: Invalid argument', and in dmesg there is '[drm] TV-9: set mode ^Af'.
darkbasic: am I the only one who can't compile mesa git master with glsl today?
darkbasic: gmake[3]: ../../../../../src/glsl/apps/compile: Command not found
darkbasic: gmake[3]: *** [slang_common_builtin_gc.h] Error 127
dileX_: darkbasic: Patches here
darkbasic: dileX_: thank you
dileX_: n.p.
cxo: which gpus does glsl work? what version of glsl is that?
cxo: Its -16degC outside, -26degC with the wind chill
stikonas: cxo: R600-R700 have experimental OpenGL 2.0 ie glsl 1.1
stikonas: r300g has experimental support for OpenGL 2.1, glsl 1.2
mokoloko: very cool!
dileX_: [18:51:45] glxinfo.txt: http://pastebin.ca/1718458
dileX_: cxo: ^^
cxo: well there is glsl 4.0 isnt it?
cxo: or 5 even?
mokoloko: is it usable in any way?
mokoloko: it's in 1.3 or something
MostAwesomeDude: Technically, no GPU out there supports GLSL.
cxo: yeah,
MostAwesomeDude: NOISE isn't present without fallbacks, DDX/DDY are at half the required res, nobody's got the correct calling ABI, etc.
MostAwesomeDude: But most of it's there for r300 and r600.
Ghworg: 1.5 is the latest GLSL spec IIRC
cxo: i guess i just dropped the 1.
dileX_: Ghworg: with my script build-time
Ghworg: dileX: I don't understand it. No matter what I do mesa ignores ccache on my system. Why does it work for you? :-(
agd5f: Ghworg: I don't think mesabuilds properly with -j
maderat: Technically radeon mobility have full support for ogl3.0 or 3.2?
agd5f: maderat: depends what generation mobility
Ghworg: agd5f: I set -j1 otherwise the build falls over most of the time as my system defaults to 8-way compiles via distcc
dileX: Ghworg: simply installed ccache on Debian/sid.
agd5f: Ghworg: I meant greater than 1
maderat: M96
Ghworg: sighs
agd5f: maderat: 3.1 IIRC
maderat: agd5f full or like r500?
agd5f: maderat: r500 is gl 2
maderat: wikipedia say M96 ogl 2.1 :) why?
agd5f: maderat: it's a wiki. says 3.1 here: http://en.wikipedia.org/wiki/Radeon
agd5f: I'm pretty sure the hw supports 3
maderat: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
maderat: Mobility 4650
agd5f: I suspect that was the highest gl available when that page was written
agd5f: maderat: http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-4000/hd-4600/Pages/ati-radeon-hd-4600-specifications.aspx
agd5f: 3.1
wsnelr: hello. are /lib/firmware/radeon/RV610_pfp.bin and /lib/firmware/2.6.32/radeon/RV610_pfp.bin the usual places to put these firmware files? My `uname -r` reports 2.6.32 yet I'm still seeing dmesg report this: platform radeon_cp.0: firmware: requesting radeon/RV610_pfp.bin and r600_cp: Failed to load firmware "radeon/RV610_pfp.bin". This happens when I run insmod ./radeon.ko by hand.
maderat: agd5f thx
agd5f: wsnelr: /lib/firmware/radeon should take care of it
wsnelr: agd: well my dmesg does report lines like [drm] Connector 0: ... and [drm] Connector 1: .. with a description of the VGA and TV out connectors. so maybe it loaded ok after all?
wsnelr: agd: however dmesg reporting [drm:r600_startup] *ERROR* Failed to load firmware! looks pretty fatal. I'm going to get a more modern drm or drm-next and try again
darkbasic: dileX: the patch doesn't work...
darkbasic: *the patches
darkbasic: *don't
agd5f: wsnelr: it will still load with a recent enough drm, but you won't get accel
dileX: darkbasic: doesnt apply or compilation fails?
darkbasic: dileX: I still have the same error
darkbasic: gmake[3]: ../../../../../src/glsl/apps/compile: Command not found
darkbasic: gmake[3]: *** [slang_common_builtin_gc.h] Error 127
dileX: darkbasic: did you do a 'make distclean' before new start of compilation?
darkbasic: dileX: I'm using portage, it should do it automatically I think, am I right?
dileX: portage? gentoo?
darkbasic: yes
dileX: dunno
darkbasic: dileX: I asked it and portage should do make distclean automatically
dileX: darkbasic: my build-script: http://pastebin.ca/1718568
darkbasic: dileX: do you use the -DR600_ENABLE_GLSL_TEST cflag?
dileX: no
darkbasic: I use it, maybe the problem is due to it
dileX: whats that CFLAG good for?
darkbasic: to enable the testing code for opengl 2
darkbasic: does someone use the -DR600_ENABLE_GLSL_TEST cflag?
Ghworg: Yes, I do
koolfy: Anyone knows the difference betweet che mesa-dri and mesa-glx packages in ubuntu ?
dileX: darkbasic: its R600_ENABLE_GLSL_TEST?
Ghworg: darkbasic: I enabled it in code though, not as a build flag
koolfy: between*
Ghworg: dileX: This is my build script for mesa http://git.trollgod.org.uk/?p=misc.git;a=blob;f=bash/build_mesa.sh;hb=HEAD
dileX: Ghworg: from where is your debian-dir?
darkbasic: dileX: yes, it is -DR600_ENABLE_GLSL_TEST cflag
Ghworg: dileX: I took it from the debian source package then modified it manually to get it to work with git master
darkbasic: Ghworg: can you compile the latest mesa git master with R600_ENABLE_GLSL_TEST enabled?
dileX: # Set parallel-make-jobs to "3" (respectively 'make -j3').
dileX: export DEB_BUILD_OPTIONS="parallel=3"
dileX: Ghworg: ^^
dileX: simple debuild call
uyf: which mesa branch is best to use for r600 (if i want 3d functonality)? i read somewhere mesa7_6 branch because its going to be 7.6.1?
darkbasic: uyf: mesa git master
dileX: uyf: 7.7
dileX: (minimum)
Ghworg: dileX: Yes, but that causes mesa builds to fail. Anything other than 1 makes mesa not build
Ghworg: dileX: http://trollgod.org.uk/tmp/mesa_7.7.0-2373-g885e214.diff.gz has my modified debian dir if you are interested
Ghworg: darkbasic: With the two changes already discussed here, yes it compiles and installs fine for me
dileX: Ghworg: I didnt debianize a new version because of r300g dri/st: /usr/lib/dri/radeon_dri.so -> /usr/lib/dri/r300_dri.so (and have not found time to look for a solution)
uyf: darkbasic:ok thanks, i'm going to try the latest gits now
Ghworg: dileX: Ah, I'm on r600 so haven't been affected by that
dileX: uyf: update ddx, kernel, libdrm, etc. (see build-howto in topic)
uyf: dileX: Thanks
dileX: uyf: I recommend to read yangman's blog
dileX: (to understand the correlations)
darkbasic: Uhm... I think those patches have been just committed to master
dileX: darkbasic: yupp
darkbasic: now seems to compile fine O_O
darkbasic: it's impossible
darkbasic: the patches committed to master are the same I applied O_O
uyf: dileX: thanx for the link great info
dileX: uyf: yeah, thats really great informations, but thank yangman
Ghworg: darkbasic: gentoo was probably doing something weird like replacing your changes from a pristine tarball or something
uyf: dileX: yes i will
darkbasic: Ghworg: no, I'm using bashrcng-patching, I verified and the files in the portage temp dir were correctly patched!
darkbasic: its REALLY REALLY strange
darkbasic: *it's
darkbasic: dinner time
darkbasic: bye
amarks: dileX: since i applied your drm-linus patch, there are a few problems
dileX: amarks: which ones?
amarks: scrolling in firefox leads to a total grey screen for 2 seconds or so then the system locks, can't ssh in, happened 3 times
amarks: and the screen turns off
amarks: 2) there is corruption on restore from dpms
dileX: which GPU?
amarks: rv790
dileX: brand-new :-)
amarks: why do we shut off the display when we crash
amarks: really need a diag bsod
amarks: dileX: have to go back to 2.6.32 stock kernel, FF scrolling is too painful
amarks: (the crash)
amarks: how do i get/see any dying gasp kernel msgs when crashing?
Ghworg: Serial console if you can, or netconsole
amarks: my machine is too new for a serial port lol
amarks: btw firefox locked up while scrolling http://www.alsa-project.org/main/index.php/Changes_v1.0.21_v1.0.22
spreeuw: is there flash on the firefox page?
spreeuw: I noticed thats real slow to scrioll here oto
spreeuw: and theres a pointer trail
spreeuw: especially for the floater cursor
spreeuw: but its hardly the slowest it has ever been
spreeuw: and I have no crashes
spreeuw: seamonkey 2.0.1 Os build
amarks: lucky you
amarks: i don't think it has any flash
dileX: amarks: tried to deactivate DFS/UTS (EXA) for a test?
amarks: when i say scrolling, i mean with the mouse scrollwheel
amarks: i tried to scroll again, won't crash now
dileX: Section "Device": Option "EXANoUploadToScreen" / Option "EXANoDownloadFromScreen"
amarks: what do these actually do
DanaG: amarks: somebody told me about "netconsole" the other day... it's worth a try, perhaps?
dileX: Disables acceleration of uploading/downloading pixmap data to/from the framebuffer.
amarks: what is the acceleration? some compression or something?
MostAwesomeDude: No, DMA.
agd5f: amarks: the gpu copies data to from/system memory
agd5f: to/from
amarks: i see
amarks: agd5f: do you mind if i open a bug for some type of layman kms bsod? if things go bad, dump something to the screen, at the moment the crashes i've seen turn the display off, which is rather unfriendly
amarks: i assume this is possible?
amarks: (in all but the most catastrophic events)
agd5f: amarks: already possible
amarks: agd5f: do you mean it is possible to do, or that something is actually implemented but i just haven't seen it
agd5f: amarks: already implemented IIRC
amarks: agd5f: never seen one :(
airlied: if we get an oops or panic it should jump to a vt to show it
airlied: it sounds like your gpu crashse complettelyu
airlied: we certainly don't turn off outputs on purpose
amarks: so if the display is shut off, that's rather catastrophic
amarks: is this done on purpose in the code, or just something that happens naturally when the gpu dies
airlied: never seen it with my gpus, hence I'm wondering what you are doing
amarks: i'm wondering too
seb_: hi everyone
seb_: can you help me please?
amarks: 2.6.32 stock worked ok
adamk: seb_: We can only help if you tell us the problem :-)
amarks: just happens during normal desktop use
amarks: nothing too exotic
seb_: i try to enable KMS on a R700 on 2.6.32 kernel and have a blank screen everytime i boot it
adamk: seb_: Presumably it works if you disable KMS?
seb_: dunno i compiled KMS in the kernel
kdekorte: seb_ do you have all the firmware?
adamk: seb_: And did you compile in support for the framebuffer console?
seb_: CONFIG_DRM_KMS_HELPER=m
seb_: CONFIG_DRM_RADEON_KMS=y
seb_: i tryed to get rid of everything involving framebuffer device (at least in the customed kernel)
adamk: You need framebuffer support, just not any specific framebuffer driver.
seb_: adamk: only framebuffer support ?
adamk: I'm not in front of my linux boxes at the moment, but I do know that CONFIG_FB=y is needed.
adamk: That's probably all (well, in addition to CONFIG_DRM_RADEON and CONFIG_DRM_RADEON_KMS
seb_: thx i gonna give a try
amarks: crashed again
amarks: so i tried to switched VTs, it successfully shows me the login prompt but if i switch back, kde is gone
amarks: what is needed for vt switching
amarks: i don't run any graphic login mgr
adamk: What do you mean by "kde is gone"? Does the system hang? Is KDE still running (ie. showing up in the process table)? Does X crash and takes KDE with it?
adamk: Are you definitely switching back to the correct VT?
amarks: kde is still there, it's just showing the console display, stderr etc
amarks: so i have to control-c to kill x
adamk: If you are seeing the stderr from X, it sounds like you switched to the VT you started X from, not the VT that X is running on.
amarks: how do i know what VT kde is on?
adamk: Different distributions run X on different VTs by default, but many use vt7.
amarks: ah yes i see VT7 in xorg log
amarks: so when we crash which VT is it meant to jump to?
adamk: That one I don't know the answer to. My initial guess would be vt1
airlied: amarks: depends on what crashes
airlied: if we don't get a kernel panic we acn't do anything
amarks: i'll setup netconsole and see what happens
spreeuw: ut2004 still rocksteady
spreeuw: great game I ordered it, love the tribes like outdoors scenes
evil_core: ut2k4 works on radeon for me, only lack of shader
evil_core: shaders*
evil_core: but quake3 looks strange
evil_core: http://carme.pld-linux.org/~evil/q3a_radeon.png
evil_core: its not related to game settings, it started to look like that after MEsa/libdrm and xf86-ati update from master
spreeuw: evil_core: interesting, should install it sometime again
spreeuw: kinda switched to openarena
spreeuw: ut2k4 has some shaders working for me
spreeuw: like shiny water
spreeuw: so the gamers wishlist is videoram > 256MB, s3tc
spreeuw: and opengl2 for long term
honk: and performance tweaks ;P
eosie: osiris: do you happen to know when S3TC will be pushed to the kernel and which repo? (drm-radeon-testing?)
airlied: eosie: s3tc fix is already in Linus tree
eosie: oh cool
mokoloko: will it land rawhide soon? :)
airlied: probably next week
airlied: since its Friday
airlied: and doing stuff on Fridays always means fixing it on Saturdays
kdekorte_: evil_core, did you compile with GLSL?
MostAwesomeDude: eosie: Always assume shader compile will succeed.
MostAwesomeDude: Because that's how the API goes.
eosie: MostAwesomeDude: you mean my note concerning FS fallbacks, don't you?
soreau: airlied: Latest drm-radeon-testing has broken tv-out on rv350. any possible reason why?
airlied: soreau: did it work before?
soreau: yes, works with 2.6.32
soreau: It works until X starts, and then trying to use it results in a total bad timing
soreau: airlied: I was wondering if there might be any interesting commit I could find as good to bisect with
airlied: soreau: the last one that works ;-)
airlied: soreau: it works in the console?
soreau: hehe
airlied: wierd X starting shouldn't affect it really, does xrandr let you get it back?
soreau: airlied: Well, let me check while I'm complaining ;)
soreau: No, xrandr does not
soreau: hang on
evil_core: kdekorte_: no, its nonm-KMS UMS
evil_core: r500, abd heard that shaders are unusable on it
eosie: i would beg to differ
evil_core: eosie: dont understand
soreau: airlied: Ok, it works on console up until X starts, then it's an obvious bad signal. Switching to tty thereafter X is loaded and it is still a bad signal
eosie: evil_core: i disagree with your statement that shaders are unusable on r500
airlied: soreau: and its KMS?
soreau: airlied: Correct.
soreau: airlied: Works with 2.6.32 on kms
soreau: as expected
airlied: I'll just test my r100 as its beside me
MostAwesomeDude: eosie: Yeah. Fallbacks need to be at a higher level.
soreau: airlied: I can still turn it --off with xrandr, but turning it back on with any config and the signal is bad
airlied: soreau: what mode is X trying to use on it?
soreau: airlied: 800x600 afaik
soreau: airlied: The xrandr output looks normal, should I check anywhere else? (x log)
soreau: or do you want to see X log?
airlied: soreau: pastebin the log, does dmesg report anythingwierd
airlied: also xrandr --verbose might help
evil_core: GLSL == pixel shader?
soreau: airlied: http://pastebin.com/m760b910f
soreau: airlied: and x log http://sprunge.us/GJIa
soreau: airlied: and xrandr --verbose http://pastebin.com/m5befd503
soreau: evil_core: GLSL = GL Shader Language
evil_core: when I was asking hjalf day ago if should I use drm-radeon-testing, sombody told me that Gallium is slower and pointless, and use master with UMS
soreau: evil_core: Why don't you try for yourself?
evil_core: I know that there were some Vertex and Pixel shaders
airlied: soreau: tv standard is okay?
eosie: evil_core: todays 3D hardware can't draw pixels without a pixel shader (though there are subtle exceptions), so the support must be there in some form
soreau: airlied: What do you mean? Like NTSC/PAL?
soreau: airlied: It works on this exact setup with 2.6.32 and afaik, it uses ntsc
airlied: soreau: its using pal now ;-)
airlied: try xrandr --output S-Video --set "tv standard" ntsc
soreau: airlied: http://pastebin.com/m433dadc0
soreau: oh crap, typo
soreau: That fixed it airlied
soreau: airlied: What is going on then? Why is it selecting pal?
airlied: soreau: we might have started to read the standard preoprly from the card
airlied: or your gnome session might have it stored
airlied: not sure
soreau: Who said anything about gnome?
soreau: I am using X standalone session :)
airlied: or whatever you are running
TCW_: soreau, what was your typo?
airlied: wierd
soreau: TCW_: It was airlied's typo ;)
soreau: S-Video -> S-video
airlied: soreau: ed160143c6967e89aee05b0685e73c4103bb3e38
bjaglin: Zajec: hi, i was playing around with your patch, trying to decrease more than 50Khz to see the effects (ideally wanted to put it at half of the default), but when I reduce too much, the value returned by get() is half of the value returned by set() for the engine clock. Is this a knows problem in get() or in set() ?
airlied: we never hookd it up to the userspace properly
airlied: the init_val is wrong in that actually
soreau: airlied: And now hooking it up properly breaks the default mode? lol
airlied: so that might be it
TCW_: http://pastebin.com/m433dadc0 <- you corrected the paste as well?
airlied: soreau: it probably needs to get the initial value from someone where
airlied: somewhere else even
soreau: airlied: I thought it got stuff from bios?
evil_core: eosie: like HUD?
airlied: soreau: it isn't passing it in though, it just using 1 :-)
soreau: airlied: Ok, well if you want me to test anything, just ping-it! :)
soreau: TCW_: No, the correct value is S-video
soreau: S-Video is incorrect
TCW_: ah :)
mokoloko: airlied: I decided to play with fire and updgraded from f12 to rawhide and now when I try to play xmoto (sdl ogl game) it fails and this is the output from dmesg relating to radeon http://pastebin.com/m79f804ed does it make any sense?
mokoloko: "drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info." this is the output from konsole when running "xmoto"
mokoloko: I guess I got burned :P
eosie: evil_core: well, HUD in 3D games is often drawn using the 3D engine, therefore pixel shaders are involved
eosie: mokoloko: which GPU?
mokoloko: 4850
mokoloko: xorg-x11-drv-ati-firmware is installed
kdekorte_: mokoloko, usually means the kernel and libdrm don't match
airlied: mokoloko: oops, rawhide needs new mesa
mokoloko: ah thx glad there's a fix (coming) :)
mokoloko: heh rawhide's mesa packagages are all still .fc12
airlied: we aren't really dealing with rawhide yet
airlied: normally we leave it along for a month or two until F12 has had most of the bugs beaten out of i9t
soreau: mokoloko: You can just grab mesa from git and compile it
mokoloko: is just mesa from git enough in this case?
airlied: at the moment yes,
airlied: when I break the libdrm api in a few hours probably not
mokoloko: ok
MostAwesomeDude: This'll be a fun test. "How well did I armor radeon-gallium and r300g against libdrm changes?"
airlied: MostAwesomeDude: badly ;-)
airlied: it should be okay, I'll try and build it first
MostAwesomeDude: I think r300g should be fine, as it doesn't actually get to see radeon_bo and radeon_cs. radeong might not fare so well.
airlied: well I mainly only hid some stuff away
airlied: uggh, calling space_flush_fn directly
airlied: not sure why you need a flush before buffer delete
MostAwesomeDude: Not mine, I swear.
airlied: it should be refernce counted fine
airlied: map is more understandable
amarks: airlied: i noticed that the corruption coming out of dpms, my monitor osd shows 1280x1600, so it is restoring to the wrong res, should be 2560x1600
amarks: airlied: this is different to the boot corruption which shows blurry 2560x1600
dileX_: trying to gdb an xorg/evdev/hal issue. results into a black screen. shouldnt it fallback to init-3 (vt1)?
airlied: soreau: patch on the list from agd5f
soreau: airlied: Sorry, where?
airlied: on dri-devel
soreau: Do I need to test it?
soreau: Or will it make it in eventually regardless?
airlied: soreau: it would be handy, I can push it into drm-radeon-testing if you liek
soreau: Could you?
soreau: Or I will have to track down this dri-devel ml ;)
airlied: soreau: okay its in drm-radeon-testing in about 5-10 mins
eosie: airlied: you can revert the patch concerning flushing before buffer delete, when you're at it
soreau: airlied: This? http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg45691.html
soreau: Ah ok
soreau: airlied: thanks
soreau: will test
eosie: it's 417ce06306962a9355cbb35cefcdea1951b0ce85
airlied: eosie: I've just fixed up the code here to avoid looking inside the libdrm cs for now
airlied: as I want to push the libdrm api fixups
agd5f: soreau: or reference: http://www.botchco.com/alex/xorg/0001-drm-radeon-kms-set-proper-default-tv-standard.patch
soreau: Thanks agd5f
soreau: I am pulling latest drm-radeon-testing now and updating whole system
soreau: agd5f: I just found the live cd I can get fglrx working on the other day, what regs did you say i need to dump to get all necessary codes for 1024x768 S-video timings? Something about everything in radeon_tv.h or so you said last IIRC
spstarr: hmm
spstarr: I still can't use IRQs
spstarr: still too much stalls
spstarr: airlied: if you still have a W500 it would be great to test irqs on it
spstarr: VBOs still crash also
aszlig: hullo
aszlig: short question (at least i hope so) about the RV730 (HD4650): is the HDMI and the DVI port some kind of hard-wired? meaning: is there a triple head configuration possible? (VGA/HDMI/DVI)
aszlig: or could it be a bug that DVI/HDMI can't be splitted up?
BioTube: aszlig: I believe that card can only drive two displays without cloning
aszlig: both connectors show state connected but if i try to split them (for example DVI-0 --left-of HDMI-0) i get the visuals (left side) on both screens
aszlig: mhm, okay, but even if i leave the VGA connector disconnected i still can't split HDMI and DVI
aszlig: fyi: ddx/drm are both latest git
eosie: is there any R300 hw that doesn't support 16 texture image units?
spstarr: goes back to Intel GPU
spstarr: this is even hotter than before
spstarr: I need to wait until Power Management is merged into drm
spstarr: i really can cook an egg under my laptop
spstarr: :/
spstarr: but, thats coming, i will just wait
Wizzup: My laptop doesn't become too hot, even though I am using kms with no power management
Ghworg: Some laptops are really badly designed with respect to thermal management. I can crash my laptop so hard when gaming in Windows that I have to remove the battery to get it to restart
Ghworg: I know it's the GPU overheating because I stress tested the CPU and it never goes above 65
spstarr: na, the driver runs full tilt
spstarr: you have to program it to not get so hot
spstarr: once the PM stuff is added to the kernel driver, it will autoclock itself
DanaG: Same thing here for me: power management is critical.
DanaG: It won't crash.. but it's pretty dang noisy.
DanaG: I've also revived an old Athlon XP desktop with a 9800 Pro.
steltho: What is the RADEON_SOFTPIPE environment variable for?
dileX: hehe, radeon PM info at phoronix
cxo: phoronix!yeah!!
cxo: sounds like some sort of syndrome
cxo: ". One of the first changes made is disabling by default the spatial view mode for Nautilus and enabling the browser mode by default. This is exciting news"
cxo: 10 points for enthusiasm
dileX_: linux-2.6.33-rc1 released
spstarr: has it basically
cxo: has it too, basically
spstarr: looks at his git log
spstarr: Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.
RobbieThe1st: I have a bit of a problem: When running Metacity or Kwin, my screen looks like this - http://img683.imageshack.us/img683/6756/kwinfromcompiz1.png If I run Compiz, everything looks as it should.
RobbieThe1st: My GPU is a radeon 7500 mobile(laptop), and I should be running the Radeon driver.
porjo: I'm using the proprietary ATI driver fglrx, and it appears to be working OK. w
porjo: when I do an 'lsmod' I can see both radeon *and* fglrx listed!!??
basilgohar: Hey all, I posted this earlier but never got a response (or, at least, never saw one).
basilgohar: I was unable to get my 1600X AGP nor my HD3650 to work under Fedora 12.
basilgohar: They would boot, but the text would be garbled once F12 was loaded, and then, if I could login, the system would lock-up after that
cxo: basilgohar, can you pastebin X log and dmesg as well
soreau: airlied: agd5f: That fixed the tv-out issue, it works now with latest drm-radeon-next
soreau: Thanks
cxo: so how come the fix for that makefile issue with mesa hasnt been commitd yet?
apanda: hm i get very low performance (10 fps in spring rts for example) with the default radeon driver install and a radeon 9600 pro / athlon 2400+ xp.. and there are black blocks appearing on the screen from time to time..