alpha_one_x86: for 3d -> #ati ?
osiris_: alpha_one_x86: no, #ati is for fglrx
alpha_one_x86: ok, thanks, what R* is X200M? OpenGL3 and power saving is planed for when?
osiris_: X200M -> RS480
alpha_one_x86: what is difference between radeon and radeonhd drivers?
osiris_: opengl3 can only be supported on r600 and r700 chips, and there's no opengl driver for them
osiris_: so don't expect it anytime soon
osiris_: radeon supports r100->r700, radeonhd r500->r700
alpha_one_x86: then (I have too 4670) what is the advantage to go to radeonhd (for me radeon drivers work, but not radeonhd)
osiris_: for power saving some docs would have to be released and IIRC Alex and John are working on docs for 3d programming
logari81: osiris_: what is RC410? I have one for which I think lspci also claims to be X200M
osiris_: alpha_one_x86: both drivers should support your card, if don't report a bug. currently more devs are working on radeonhd
osiris_: they're working on EXA support for r600 and r700, when they're finished they will probably port EXA support to radeon driver
airlied: logari81: also an rs48x
libv: they? it's alex who is doing that work
libv: while emmes is working on a dri driver
airlied: osiris_: its already in radeon
libv: i've never seen bridgman write any code.
osiris_: libv: writing they I meant Alex, you, Matthias, Christian and Yang
osiris_: libv: but yeah, Alex probably will be the only one porting rest of EXA patches to radeon
alpha_one_x86: because I have poor performance and perwor saving on my X200M, and for my radeonhd 4670 critical powersaving and poor performance and openGL 1.3 only
libv: nah, i'm not immediately working on radeonhd anymore. only have this laptop left with an rs690 in it
alpha_one_x86: why have do 2 project (radeon and radeonhd)? Have diffente performance? Compatibility? Fexibility?
libv: when i get really bored, i might continue my r5xx direct CP work and exa overhaul. but i have tons of funner things to do
libv: alpha_one_x86: ask those who didn't want to work inside radeonhd
MrCooper: hahaha, that's a good one
libv: when we started radeonhd, we had valid reasons not to continue the avivo codebase.
libv: the work in radeon was only started 2 months after AMD allowed us to publically speak about radeonhd
osiris_: my fogcoord patches are almost ready for inclusion, anyone else willing to test them on r300-r500 (with HW tcl)?
alpha_one_x86: and for the user what is the difference?
airlied: alpha_one_x86: not much
libv: alpha_one_x86: that one works on some combinations and that the other works on other combinations. Cool how split work also splits up the userbase and that people don't report bugs to one when the other works.
libv: but then, redhat doesn't care about the desktop, so it doesn't need a stable driver, just facevalue
libv: airlied: you might have heard, i talked to some of your recruiters, was a fun little discussion
MrCooper: libv: one driver can work on all Radeons, the other can't...
libv: MrCooper: one driver is good code, the other isn't
MrCooper: right, that's objective after all
alpha_one_x86: Yes, that's not help my for do choice the free drivers, I thinks test both and decide after
libv: alpha_one_x86: yea, see which one works and use that, and don't look back or report issues against the other driver
libv: MrCooper: i kept on hearing bs from bridgman initially where he stated that the radeonhd driver was unnavigationable
libv: such a lie, but then, there have been tons of those in this whole story
alpha_one_x86: I have not can try radeonhd drivers in 3d when I had try, but no drivers have level of intel drivers for support (EXA, openGL3, powersaving), :( .
MrCooper: I honestly don't know, but I wouldn't feel entitled to consider my code 'better' than other code
osiris_: MrCooper: you've commited a few EXA related patches recently. should they give some significant performence boost?
libv: MrCooper: i do, because we worked to keep the radeonhd driver nice and modular so that it is easy to navigate, easy to fix, and easy to throw different hardware bits around
libv: this was a clear design choice from the onset
MrCooper: libv: great, just don't pretend it's black/white
libv: because both suse and amd wanted a good enterprise level driver, with good support
MrCooper: because reality just isn't
libv: MrCooper: it isn't black/white, but the difference in shades is _very_ large
MrCooper: osiris_: the glyph cache change I pushed today should give a text rendering boost in some rare cases, but otherwise I wouldn't expect anything big
libv: i wrote up CS, and had to spend ages making sure the right bits of the old radeon cp code made it into the right places. it was hell.
airlied: wow we ship radeon to lots of enterprises and support it fine.
libv: airlied: sure.
airlied: libv: you mean we don't?
libv: i'm sure you don't. how many preloads does redhat do?
airlied: libv: the last bug I fixed in radeon for enterprise was actually fixing a bug properly that Novell/SuSE papered over.
libv: yeah, because we didn't have the manpower or the will to do further archeology
arekm: heh
airlied: libv: don't customers pay for that?
libv: thanks to provo idiots, the manpower situation is even worse
libv: airlied: to some extent, some bugs, on especially radeon and intel, we file as wontfix or upstream, because it is just untrackable
airlied: we ship RHEL on lots of laptops for customers, the same customers who wanted r500 accel,
libv: airlied: well, most of the preloads are intel. how does redhat deal with that?
libv: do you really ship the latest of the latest?
libv: i doubt it.
airlied: libv: we backport Intel every release
libv: oh my.
airlied: every 6 months we backport Intel, AMD and nv
airlied: and mga
libv: and how do you achieve that? with intels dependance on the latest drm and libdrm bits all the time?
airlied: libv: we backport kernel patches
airlied: we don't claim the driver is userspace only
libv: so it goes all the way to the kernel... that must make QA very happy
airlied: we take it as any parts in any component
airlied: libv: they have to QA the kernel every release anyways
airlied: we have a suitably sized QA team to do the job.
libv: ah, manpower... something novell doesn't believe in it seems
airlied: granted we've avoided backporting 3D drivers for the last few Intel
libv: well, even then you have issues
libv: modesetting bits get applied on top and this driver always has deps all the way, and hard ones with no wiggleroom except doing massive workarounds
airlied: ah we just rewrite if we have to, and have lots of hw to test on.
libv: this is not how things should be done, drivers should be modular enough that keeping things bw compatible, with a few features disabled, should be easy.
libv: but only few drivers get developed in that fashion
airlied: libv: it'd be nice but it still doesn't absolve you from having to QA it all, the codepaths don't get tested if nobody is running them.
libv: well... novell is investing in qa manpower in china...
libv: these guys are using their very meagre wages for buying their first linux books.
libv: who needs clued people when you can get cheap ones
libv: actually, the intel folks in china are notsobad (some are quite good), i'm sure they're getting paid quite a bit better than what some provo company is willing to pay
marcheu: are we trolling still or am I too late ?
libv: still trolling, the workmen are putting the last hand on my windows.
airlied: marcheu: why doesn't nouveau build on RHEL4?
marcheu: because I hate freedom
airlied: you should call it GNU/nouveau
airlied: gnuveau
marcheu: totally, can we get back on-topic trolling though ?
twoerner: airlied: do you know when there will be a public mesa branch for r6xx+?
libv: twoerner: ask emmes or alex
airlied: marcheu: ah thats less fun :)
marcheu: (also whoever said opengl3 was supported on intel is, like, totally wrong)
twoerner: libv: thanks
chithead: intel gma500 hardware supports opengl 3 :p
airlied: wonders what glxinfo on gma500 looks like
MrCooper: certainly no OpenGL 3
marcheu: and he knows, he wrote it
MrCooper: not much of it fortunately
airlied: poor bastard who gets to write it next :)
marcheu: looks at glisse
TobiasTheCommie: !pin
dvandyk: hi
dvandyk: can somebody tell me how to diagnose xrandr problems with respect to missing resolution?
dvandyk: i got a r350 based card here with VGA-0 and LVDS. LVDS output supports the native resolution of 1280x1024, but for the VGA-0 connection it doesn 't detect 1280x1024
dvandyk: however, it does detect 1360x768
dvandyk: which actually works! but this is not what i want
adamk_: You can use the xrandr command to create a new mode and add it to the VGA-0 port.
adamk_: Or add a modeline for it in the xorg.conf file and use the PreferredMode option.
adamk_: But, yeah, if it supports 1280x1024 then, ideally, the driver should detect it.
dvandyk: adamk_: "xrandr --addmode VGA-0 1280x1024 ; xrandr --output VGA-0 --mode 1280x1024" works
dvandyk: adamk_: however, the latter doesn't work w/o the former
adamk_: dvandyk: Well that's becuse you need to add the mode before you can use it, so it's not surprising you have to run the former before the latter.
dvandyk: is there a dpms dump utility so that i can check if the monitor sends the wrong data?
adamk_: DPMS is just power management, isn't it? I don't think that's what you need to check. You're probably thinking of the EDID data.
dvandyk: i'm sorry, you're right
adamk_: GO to http://pastebin.com/ and paste in your /var/log/Xorg.0.log file.
davem1: posts today's work...
davem1: All of this code I wrote years ago is disabled :)
davem1: grrr, too large, needs moderator approval
davem1: :-/
dvandyk: adamk_: http://dpaste.com/1837/
MrCooper: listadmins
adamk_: The "Detected Monitor Type: 0" seems odd but, by no means, am I an expert.
adamk_: Combined with the lack of any EDID information, the X server clearly isn't receiving any information.
adamk_: So I'm guessing your monitor either isn't sending it, your using a KVM or adapter that isn't passing along the data, or there's some bug in the driver.
dvandyk: i'll try with my laptop then, it has intel graphics, so we can exclude one of the three
dvandyk: there is no kvm
adamk_: Cable extender?
dvandyk: nope
dvandyk: and my laptop doesn't detect it, either
dvandyk: so it's the monitor
adamk_: Well, alternatively, it could be a bug in the X server.
adamk_: Or just a missing feature. That could impact both machines.
adamk_: Someone more familiar would really have to comment, though.
dvandyk: ok, we just hooked up a different monitor, and it works flawlessly
dvandyk: so i presume it's just this monitor
dvandyk: i'll add a bash script and we're done
dvandyk: thank you!
adamk_: You could add a modeline to the monitor section in xorg.conf, too.
davem1: is there any way to get at the old mesa3d bugs?
davem1: the ones that were on sourceforge
davem1: nevermind...
davem1: I'm stupid sorry :)
Tuju: http://pastebin.com/d26bf114a in fedora 10
Tuju: Caught signal 11. Server aborting
twoerner: agd5f: do you know when there will be a public mesa branch for r6xx+?
agd5f: twoerner: not off hand. we still have to do the IP review for the shader compiler
bschindler|lapto: Hi - I just connected a secondary screen via vga and the output is quite fuzzy. I looked at the refresh rate, but the screen only offers 60hz which seem selected
bschindler|lapto: is there something I can do about this?
mjt: bschindler|lapto: yes... sorta -- use a TFT ;)
bschindler|lapto: mjt: well, this is a tft... :)
mjt: seriously, I had numerous probs here and there (unrelated to radeon, -- all drivers) with refresh rates, till i switched to tft
bschindler|lapto: mjt: and the other machine connected to that screen produces a perfect image
mjt: and for a tft, 60Hz is ok
bschindler|lapto: unfortunatelly, not here :(
bschindler|lapto: it seems
mjt: i mean, are you sure your prob is due to the refresh rate and not something else?
bschindler|lapto: mjt: I tried the same thing at home, where I got the same issues - 60hz was bad
mjt: oh
bschindler|lapto: mjt: but that screen also was able to handle 75hz
bschindler|lapto: and then it suddenly was okay
mjt: that's... interesting
mjt: i haven't seen a TFT monitor that is unable to work at 60Hz - be it cheapest or expensive model.
bschindler|lapto: mjt: well, that screen does work with 60hz
bschindler|lapto: mjt: the other machine proofes that point
mjt: usually there's no difference at all between 60 and 75Hz
bschindler|lapto: well, may be some driver issue
mjt: but you said the other machine showed the same bad pic @60, no?
bschindler|lapto: no, the other machine is okay
mjt: 18:05 < bschindler|lapto> mjt: I tried the same thing at home, where I got the same issues - 60hz was bad
bschindler|lapto: mjt: yes, that was another screen
mjt: wug
mjt: you're confusing :)
bschindler|lapto: heh :D
bschindler|lapto: connect laptop via vga to screen 1-> fuzzy at 60hz, 1600x1200. Connect to screen 2 -> fuzzy at 60hz, okay at 75hz
bschindler|lapto: all of these screens work just plain sharp in any of these modes with the primary machines connected to them
mjt: some time ago i experimented with dual screens in 'doze, with AMD690 chipset. Primary display was connected over DVI, secondary over D-Sub (vga). At that time, 'doze driver didn't let me choose anything BUT 60Hz refresh rate for the D-Sub.
bschindler|lapto: hm
mjt: make that D-Sub monitor the primary one, and it shows other frequencies
bschindler|lapto: that problem doesn't seem to occur here.
mjt: i'm not saying the same will work for you. Just something I observed
bschindler|lapto: lemme try though
mjt: with relatively old (end of 2007) windows drivers
mjt: the vga monitor I tried was CRT, so refresh rate was important and 60Hz was unacceptable.
bschindler|lapto: yeah, of course
bschindler|lapto: well, I cannot even select a primary monitor via the gui... but I'm able to select various refresh rates when they're available (and some of them are)
mjt: (pri/sec - i mean which one is present during system bootup. If both are presend it used DVI one)
bschindler|lapto: ah ok
agd5f: bschindler|lapto: you can use xrandr to change the mode and refresh rate
bschindler|lapto: agd5f: yes, but at this resolution, the monitor only supports 60hz
agd5f: probably all it supports then
bschindler|lapto: yes... but the image should still not look smoothed out
bschindler|lapto: that's why I'm asking here - I assume it's not normal for the image to be so washed out even when working over VGA
agd5f: bschindler|lapto: does the monitor provide an edid?
bschindler|lapto: yes
agd5f: ok
bschindler|lapto: I even parsed it :)
bschindler|lapto: myself to check ^^
glisse: davem1: you are on sparc ?
mikkoc: agd5f: about your post: http://phoronix.com/forums/showpost.php?p=64300&postcount=43 can you tell me which commit is that?
agd5f: mikkoc: 69f080cefced8b3395cdf179c107303a1013d196
mikkoc: oh ok
mikkoc: thx
arekm: glisse: isn't davem1 the "kernel" davem?
MrCooper: yeah, he's the Linux sparc guy
glisse: i was confuse by sparc atomic code but i missed a *
rnoland_: adamk_: ping
adamk_: rnoland_: pong
rnoland_: adamk_: got the card today, everything seems in good shape.
adamk_: Cool.
rainbyte: hi
rnoland_: i was surprised that it showed this quickly.
adamk_: Happy fragging with it :-)
adamk_: That was pretty quick.
rnoland_: adamk_: hehe, yep, thanks.
oga: I really need to get a r600 or r700 so I can look at porting that branch over
CE: just read r6xx/7xx acceleration was mergerd
CE: thanks for the hard work :)
CE: ... but I am a bit puzzled, is radeon now ment to replace radeonhd in the long run by AMD?
arekm: no one knows, both drivers compete
Tuju: how do i disable dri?
CE: so why did AMD's alex merge it into radeon then?
Tuju: Option "DRI" "off" does not work
CE: maybe just the article was wrong I read
Tuju: http://bugzilla.redhat.com/480699
CE: http://www.phoronix.com/scan.php?page=news_item&px=NzA5NQ
tuju__: doh, Section Module, Disable "dri" made the whole screen black
mjt: bah
mjt: where has r6xx-r7xx-support branch gone?
mjt: oh
mjt: funny thing, fglrx does not work for me since about Oct-2008
mjt: and radeon is getting better all the time.
glisse: CE: with KMS no more fight btw radeon or radeonhd
CE: only radeon?
glisse: kernel modesetting and common exa code
CE: great :)
mmp: hello, sorry for previous spam...
mmp: I probably also missed something, if someone wrote me message..
spstarr_work: looks at cgit/cvs
spstarr_work: airlied is busy on radeon-rewrite right now :)
spstarr_work: we are pending the DDX
otaylor: airlied: anything in particular you'd like me to do with the fuzzy-textures-test-case? Stick it in bugs.f.o ?
airlied: otaylor: yeah probably for the best I took a quick look yesterady and coulnd't spot anything obviously wrong.
otaylor: airlied: OK. I may try looking it into myself if I get bored or too annoyed, but mesa is a lot more obscure to me than the ddx
airlied: otaylor: me too :)
otaylor: airlied: How's 3d looking in rawhide?
airlied: otaylor: better than F10 hopefully, I have DRI2 gears inside compiz
airlied: just trying to push it out now
otaylor: airlied: Cool. I'll have to make the plunge soon with my laptop.
otaylor: (Bug filed as https://bugs.freedesktop.org/show_bug.cgi?id=20340)
spstarr: hmmm
spstarr: corruption scattered all over
Brains: Just tried out the latest git radeon driver and seem to have lost the ability to do anything other than clone my dual head setup. Anybody else seeing this or PEBCAK?
Brains: It seems to dump a fair bit of stuff into the log... Looks like repeated EDID info and modes.
Brains: (Radeon HD4850)
spstarr: has that card
spstarr: but, i dont have a LCD screen or any monitor yet
spstarr: then i can do full testing with the r6xx
moeSizlak: can someone remind me how i d/l a drm-rawhide branch of teh kernel?
airlied: use git to clone or if you already cloen use git pull --rebase