Nightwulf|work: Hi all
osiris_: bridgman_: I'm almost certain the clamping is the problem. I tried setting GA_ROUND_MODE.RGB/ALPHA_CLAMP to <-8,8> but I was only able to use fog coords from range [0..2]
wenchien: hi
wenchien: i have a question about rhd_atombios.c:rhdAtomInit()
wenchien: should we try to read the BIOS from PCI config space first before trying to get it from legacyBIOSLocation?
Nightwulf|work: emmes: thx for the answer...my response is on it's way too :)
emmes: any good news? :)
Nightwulf|work: emmes: well, yes and no....but read yourself ;-)
emmes: Nightwulf|work: you have mail :P
Nightwulf|work: damn...you're fast :)
Nightwulf|work: LOL...."Ach was" should tell my you know the answer but would have to shoot me if you would tell me the answer, shouldn't it?
osiris_: MostAwesomeDude: I've made it!!! EXT_fog_coords is finally working
osiris_: dances around
Nightwulf|work: osiris_: congratulations
osiris_: thx
osiris_: Nightwulf|work: I was few days from leaving it. so many sleepless nights...
Nightwulf|work: osiris_: well, my last device driver i worked on was a module for a multiport serial card...that's not really compareable but i know that sleeplesss nights stuff ;-)
osiris_: Nightwulf|work: I just hope that other missing features aren't that tricky, otherwise we will get full featured radeon driver in 2020
Nightwulf|work: osiris_: hehe...well, for my part it would be good enough if blender and co would work ;-)
osiris_: Nightwulf|work: which features are required for blender?
Nightwulf|work: osiris_: all features opengl 1.2 needs
osiris_: Nightwulf|work: radeon implements opengl 1.3 so it should work, unless there're some bugs
Nightwulf|work: osiris_: but there is mesa stuff missing right now, isn't it?
osiris_: Nightwulf|work: if you're talking about r600 and newer hw then yes. currently we only support r100-r500
Nightwulf|work: osiris_: R680 here
bridgman_: osiris; congratulations !!
osiris_: bridgman_: thx. I was right yesterday. it was the color clamping. I'm sending fog coords now as tex coords and it works
bridgman_: so you can send numbers <0 and >1 that way ?
osiris_: bridgman_: with tex coords I can send whole FP32 range, and with colors only [0..1]
bridgman_: yeah, that's gotta help ;)
osiris_: bridgman_: so if there's no reg that turns off clamping for colors we won't be able to use fog unit
bridgman_: I'm really sorry, I had forgotten you were running on a 690 and swtcl, most of my suggestions weren't very useful
bridgman_: we can use fog unit if we normalize fog value to 0..1 in vertex shader, can't we ?
bridgman_: although AFAIK we just do everything in shaders these days for consistency
bridgman_: also AFAIK we can turn off clamping for colours with SQ_CONFIG, it's just that we normally want to leave clamping turned on ?
osiris_: SQ_CONFIG? never seen that reg before
bridgman_: hold on, sorry... that's for something agd5f is working on
bridgman_: whatever register you mentioned last night
bridgman_: GA_ROUND_MODE, sorry
osiris_: bridgman_: according to R3xx docs, r300 hw allows only for colors inside [0..1] or <-8, 8>, and r500 hw [0..1] and FP20 range
bridgman_: ahh, I was looking at r500, looks like 300 has lesser range (and 690 is more like 300)
bridgman_: got it
bridgman_: fp20 seemed like enough accuracy and range for fog ;)
osiris_: bridgman_: if r300 wasn't so limited in pixel stack size, and frag prog size we could just forget about the fog unit and do everything in shaders
bridgman_: yep... so I guess it's still important to understand whether the fog scale/offset (going from colourN.alpha to fog value) happens before or after the colour clamp
bridgman_: or do you think it is feasible to do fog value calc in frag shader and blend in fog unit ? seems easier to either use all fog hardware or none if possible
bridgman_: now that you have "broken the code" ;)
bridgman_: I'm told we do fog in shaders on r300 ourselves, let me double-check that
osiris_: bridgman_: yeap, I checked fglrx. fog unit isn't used at all
MostAwesomeDude: XD
MostAwesomeDude: They know something we don't
osiris_: depth based fog case seems little bit off for exp2 case, but that's a minor issue
bridgman_: MostAwesomeDude; I suspect that having a shader compiler three times as smart as me probably helps too ;)
osiris_: bridgman_: yeap, they do exp fog in only 3 insts, while we do it in 5
MostAwesomeDude: We're not fully using some of the insts.
MostAwesomeDude: Presubtract voodoo and such.
osiris_: MostAwesomeDude: yeap, but fglrx doesn't use presubstract in fog fp
MostAwesomeDude: Hm.
bridgman_: GSA lets you run shaders through our proprietary compiler if that helps
bridgman_: and for those who don't wanna run Windows I can do it for you ;)
osiris_: bridgman_: it's not really that much important right now. I think it's better to make the driver feature complete then optimize
osiris_: be back in 30min
osiris_: bridgman_: what do you suggest, should I leave it as it is (shader based fog) or dig some more to use dedicated fog unit?
kcodyjr: uninformed opinion: it is better to leverage all hardware present than not, unless investigation shows it really is useless
osiris_: agd5f: are there any r500 card without hw tcl?
agd5f: osiris_: nope
bridgman_: IGP parts come out on a slower schedule so we jumped straight to 6xx for the next part
bridgman_: I'm sure someone tried to take the vertex shaders out but it didn't happen ;)
agd5f: you can test by setting the pvs_bypass bit
glisse: kcodyjr: it's easier to do things in shader as we can then share shader infrastructure across wide range of card
glisse: especially given the resources we have
kcodyjr: glisse, i can understand that reality may push it that way, but the question was, which is "better"
osiris_: agd5f: I just saw non tcl path for r500 hw in r300 dri, so it can be probably removed
agd5f: osiris_: it's there for testing sw_tcl
kcodyjr: the days of 100% shader-driven cards may be coming, but they're not quite here, and even when they are, not all cards will be like that...
agd5f: kcodyjr: doing it in the shader is more flexible
kcodyjr: no doubt. i'm just saying, don't forget all the partially shaderful cards that are out there
kcodyjr: those cards may have other needs for what shading resources they've got
kcodyjr: being able to offload to whatever dedicated hardware is available may mean the difference between the card's being adequate, or not
kcodyjr: that said, i agree, leave it till later - just don't shoot yourself in the foot now and make it impossible to be flexible later
kcodyjr: bbl...
agd5f: kcodyjr_away: this only affects the cards in question
Commie_Cary: sp how is the x600/x700 drivers goib
lucxxx: hy all
lucxxx: is somone on?
Obscene_CNN: yes lots
lucxxx: who can help?
yangman: lucxxx: just ask the question. if someone's willing and able, you'll be answered
libv: hrm.
nanonyme: Gathering reinforcements? :) Must be a tough question.
lucxxxxx: so?
adamk_: Again, just ask your question. If someone can answer it, they will.
lucxxxxx: ok
lucxxxxx: thankyu
kcodyjr_away: agd5f, it was my understanding that some of the newer cards do indeed still have significant amounts of dedicated hardware. if that's not correct then it seems i am talking through the backside
agd5f: kcodyjr: each new gen loses more fixed function stuff
kcodyjr: agd5f, but not all at once, right? and there is a pretty wide gap in shader power between the bottom and top of each series
agd5f: no, r3xx-r5xx could do fog in shader or fog unit, r6xx can do some stuff in fog unit, but shader fog is best performance, r7xx drops dedicated fog all together
kcodyjr: so the r6xx's fog unit is vestigal. like the human tailbone.
agd5f: pretty much
kcodyjr: it can't actually do what it was meant to do then
agd5f: it can, just not optimally
kcodyjr: well, define 'optimal'; it may still be of value for no other reason than to free up a shader resource
nanonyme: Slower? :)
kcodyjr: it's not fair to consider only the execution time of the fog operation; so what if it takes longer on the fog unit, if the shader unit is doing other work it wouldn't have been able to squeeze into the time available if it had been using the shaders for fog
agd5f: kcodyjr: it comes down to resources. there are only so many developers...
kcodyjr: which i'm 100% getting. i'm just saying don't set it in stone that fogging must be done in a shader. leave it flexible enough for someone to finish later.
agd5f: yeah
kcodyjr: and -try- to make it clear where a dedicated hw fog implementation should hook in, but that's even more optional ;)
kcodyjr: i'll bet you diamonds against little green apples, that some years after most cards are pure shader machines, someone will find a job that really is best done with dedicated hw, and we'll see a resurgence of dedicated hw.
kcodyjr: pendulum back the other way again. remember the amiga - had dedicated hw for just about everything
kcodyjr: and i've heard people have had some success porting gnome and such to amiga; pretty impressive for a machine that predates the 386
osiris_: kcodyjr: we won't benefit much with fog done by dedicated fog unit. it's not that much complicated math that r300 frag shaders couldn't deal with. disabling fog in test app resulted in barely observable fps increase
chomwitt: hi. in lenny except installing the xserver-xorg-video-radeonhd do i need the radeon kernel module?
nanonyme: osiris_: I suspect he meant responsibility more. You get to do multiprocessing if you have a separate unit (if things are designed in a clever way).
yangman: chomwitt: only if you have a X1xxx series card and want 3D acceleration support
chomwitt: i have X1650 so i guess i have to?
adamk_: chomwitt, Yes, though it has been available in the standard linux kernel for a little while.
nanonyme: Lenny has 2.6.26, I think.
chomwitt: yes 2.2.26
chomwitt: yes 2.6.26
adamk_: I don't know if that is recent enought.
nanonyme: Nothing that can't be fixed though, right? The kernel modules are written to be downwards compatible so he could just compile them again if there's trouble. :)
nanonyme: (As in, could try as is, then current DRM if things don't work)
adamk_: Yes, I believe that is possible. Sometimes backwards compatibility breaks, but I don't recall hearing anything about that happening recently.
nanonyme: Yeah, though that'd be a bug. ^^
chomwitt: i see a /lib/modules/.../radeon.ko and radeonfb.ko
nanonyme: The radeonfb is just for non-X framebuffer afaik.
adamk_: radeon is the one... IF you don't have fglrx installed, just run 'sudo modprobe radeon' and check the 'dmesg' output. If it detects a supported card, it will let you know.
kcodyjr: osiris_, if it's a question of math complexity then fine, but if it's about how many units are available...
kcodyjr: bridgman was laying something on me about how the newer cards have finally added more shaders than pipelines, but there's still a lot of variance in how -many- shaders are available per pipeline
kcodyjr: it would suck if a simple op was what it took to make it run two passes instead of one
kcodyjr: granted that probably only matters when you're trying to push the card, e.g. gaming with it
rindolf: Hi all.
chomwitt: adamk_: thanks again
nanonyme: kcodyjr: How about a shader instruction priority system (least-intensive ones first)? :)
adamk_: chomwitt, No problem. If you aren't sure if the DRM driver detects your card, use a service like http://pastebin.com/ to show us the output of 'dmesg | grep drm'
chomwitt: adamk_: ok
rindolf: Hi all! In http://www.x.org/wiki/radeonhd:r6xx_r7xx_branch - it says {{ make radeon.ko drm.ko }}
kcodyjr: nanonyme, with the ability to drop steps if it's coming up against limits. yes, that would prevent the app from seeing the sort of overload i'm talking about, but it wouldn't provide an alternate way to make it happen...
kcodyjr: notwithstanding that limitation, that probably qualifies as a sufficient fix
kcodyjr: put it in gaming terms, whether you get shot or not shouldn't depend on how many shaders per pipeline your card has ;)
nanonyme: kcodyjr: Note that I'm not a developer and that was just a quick idea while watching SGA. ;) I'm not saying it's the right one.
nanonyme: (Or even that it wasn't a terrible one)
kcodyjr: actually it probably is the right idea; the problem is that no driver i'm aware of provides a framework for doing stuff like that
rindolf: But it says: make: *** No rule to make target `radeon.ko'. Stop.
rindolf: make radeon.o works though.
nanonyme: rindolf: Have you run autogen.sh?
rindolf: nanonyme: in the drm?
nanonyme: Erm, actually. You didn't type make radeon.ko, did you? That's not the right way to do it.
nanonyme: make DRM_MODULES="radeon" # seems to be the one from the guide
rindolf: nanonyme: http://www.x.org/wiki/radeonhd:r6xx_r7xx_branch - that's what is written here.
nanonyme: I suspect that's wrong.
nanonyme: http://www.x.org/wiki/radeonhd:DRI says 'make DRM_MODULES="radeon"', use that instead.
chomwitt: i have problems with the radeon kernel module in lenny debian with x1650 card. http://pastebin.com/m327e5768
adamk_: chomwitt, (EE) RADEONHD(0): The fglrx kernel module is loaded.
chomwitt: adamk_: mm. sorry , i'll try again
nanonyme: You'd need to stop it from loading, then power cycle.
nanonyme: The open driver likely will not work after fglrx properly without it.
chomwitt: adamk_: in /etc/modules i had a fglrx intro, but i cant understand where the module was found. i removed all the relative packages.
adamk_: Most likely the kernel module wasn't installed by a package, but built by module-assistant or some other mechanism.
adamk_: Blacklisting the module might be enough to keep it from loading.
chomwitt: adamk_: that makes sense, since i tried different thinks trying the days before to make the fglrx work. I rebooted with /etc/modules right. know modprobe radeon worked.
chomwitt: adamk_: thats my new xorg.conf http://pastebin.com/m4245d542 , modprobe radeon worked. but i dont know if dri works.
adamk_: chomwitt, A few things... Xorg isn't enabling direct rendering. You might need this line in the Device section of your xorg.conf file:
adamk_: Option "DRI" "on"
adamk_: Oh wait...
chomwitt: adamk_: my xorg.conf http://pastebin.org/d6f01831e
adamk_: You are using a very old version of the radeonhd driver.
nanonyme: Also looks like the system library symlinks got broken while removing fglrx.
chomwitt: adamk_: my xorg.conf http://pastebin.com/d6f01831e
adamk_: Yeah, that too.
adamk_: Yeah, I saw that the first time :-)
adamk_: But, still, I don't believe the version of the driver you have installed supports direct rendering.
chomwitt: :-)
yangman: you want >=1.2.3
chomwitt: do u mean xorg-module or kernel module?
adamk_: xorg-module
adamk_: xf86-video-radeonhd
nanonyme: Could always try the ModulePath trick and install radeonhd inside another path.
nanonyme: Erm, another prefix even.
adamk_: chomwitt, Be aware, you will also need to have Mesa 7.2 installed, as I recall.
nanonyme: Heh.
chomwitt: if i try to open a small door to download for experimental repository?
adamk_: And, then, if you want to use AIGLX (for compiz, for example), you'd have to update your X server to 1.5.*
nanonyme: adamk_: Lenny has 1.4.x :/
adamk_: Ugh...
nanonyme: I'm personally running a schrooted Lenny on top of my main system that pulls X from experimental.
nanonyme: It's a current one.
chomwitt: little confused. whats my best option if i want to stay in lenny (with little risk)
nanonyme: Considerably more effort and you have to give up on gdm and so but at least the experimental packages can't break your main system anyhow.
da1l6: hi
da1l6: i get massive corruption of desktop and panels (kde4.2) with radeonhd r6xx-r7xx-support on my M76 (mobility radeon hd 2600) if exa+dri is enabled.
da1l6: Is this "normal" in the current state of development or worth investigating?
yangman: da1l6: there's still a handful of known corruption issues being tracked down
da1l6: okay
Obscene_CNN: corruption is due to blagojevich bug ;)
da1l6: ?
Nightwulf: emmes: ping
Nightwulf: emmes: ping
Nightwulf: emmes: ping
Commie_Cary: I luaghed my ass off what do I do
rindolf: Hi all.
rindolf: I tried to install the r6xx-r7xx branch, but now the scrolling, etc. in the X server is very slow.
rindolf: How can I make it more respsonsive?
rindolf: I reverted to the old radeonhd_drv.so and to the old xorg.conf.
reid: hey all
reid: is anyone familiar with the ATI Mobility Radeon X1250?
reid: its an integrated card
rindolf: Hi all.
reid: yo
reid: nobody is talking in here lol
rindolf: The good news is that X here is working here again.
reid: what card u workin with?
rindolf: The bad news is that the r6xx-r7xx branch does not work on my AGP-based Radeon HD 2600
rindolf: reid: ^^^
reid: ah
reid: ah I have no experience with ATI on desktop cards >.< I only know about r6xx laptop cards
reid: and how they are supported poorly if at all by any drivers, including fglrx =P
rindolf: reid: I tried fglrx now.
reid: you use envyNG to install? or you compile yourself
rindolf: I was told at #ati, it does not support XServer-1.6.x which is what Cooker has.
rindolf: reid: I've used the MDV Cooker packages.
reid: ah i see
rindolf: So after all this work, I'm back to where I started.
reid: r u running ubuntu? or a different distro
rindolf: reid: Mandriva Cooker.
reid: ah lol
rindolf: reid: Cooker is the Mandriva bleeding edge.
reid: was gonna say =P that might be ur problem haha
reid: damn wish I could help you
Obscene_CNN: yippie a new r6xx/r7xx commit
reid: anyone here have RS690M chipset on ubuntu?
osiris__: reid: I have
reid: how are your drivers functioning?
reid: and which ones are you using
osiris__: reid: both are working
reid: both? by both you mean radeon and radeonHD?
osiris__: yeap
reid: compiz can run smoothly? 3d support, etc?
reid: cause I get decent 2d support with radeonHD
reid: but in order to be remotely comfortable with the performance of the card outside of 2D I have to use fglrx
reid: and I still kinda feel like im getting 25% capacity from my card
reid: e.g. I get 800 fps on glxgears
reid: and 100 fps on fgl_glxgears
osiris__: reid: GINAB
osiris__: I don't run compiz, I have kde
osiris__: 3d is working with both drivers
reid: hmm thats strange lol
osiris__: don't expect much from gpu that don't have tcl unit
reid: Mobility Radeon X1250?
agd5f: rindolf: did you try the latest drm and rhd bits? I added agp support, but YMMV
rindolf: agd5f: yes.
rindolf: agd5f: I followed the instruction on the r6xx-r7xx branch on the wiki.
agd5f: rindolf: hang?
osiris__: reid: no, desktop model
rindolf: agd5f: http://www.x.org/wiki/radeonhd:r6xx_r7xx_branch
reid: oh thats most likely why
rindolf: agd5f: well, the thing was that the server started but only showed a sluggish cursor on a blue background.
rindolf: And even Ctrl+Altr+Backspace did not work.
osiris__: reid: do you have intel or amd cpu?
rindolf: agd5f: so I ssh'ed from one of my windows machines, and tried to kill X.
rindolf: It will only kill with -9
agd5f: rindolf: sounds like a GPU hang
rindolf: agd5f: ah.
reid: amd
reid: Turion x2 TL-60
rindolf: agd5f: the CPU survived the pkill -9 X
rindolf: agd5f: bash still run on ssh.
rindolf: agd5f: I have an AGP-based RadeonHD 2600
agd5f: rindolf: you can try forcing your card to use the pcie gart stuff
agd5f: that should work
rindolf: agd5f: ah.
rindolf: Well, tomorrow.
rindolf: Now it's 01:26 here.
osiris__: reid: it should work. is 3d working for you with radeon or radeonhd?
rindolf: But OTOH, I don't really feel tired.
agd5f: rindolf: try this patch: http://www.botchco.com/alex/xorg/force_pcie_mode.diff
agd5f: against rhd
reid: neither
reid: I use fglrx currently
reid: I tried both of the above, and got pretty bad results
reid: even from a fresh install
osiris__: reid: bad results = slow or corruption,crashes,etc?
reid: mostly things along the lines of screen tearing, choppy video
reid: I got direct rendering with RadeonHD, but still only got maybe 500 fps with glxgears
reid: and not the good kind of fps either =P
reid: the kind that bugs all across the screen, etc
reid: the last version that I used of radeonHD was the first version that said it supported X12xx cards
reid: how often is the driver updated?
osiris__: reid: don't know. you would have to ask package maintainer. I used current git version
reid: ah ic
reid: well I appreciate you tryin to help me out, sorry I didn't have more information, I was just comin in here to see if RadeonHD has made some progress, and apparently it has
adamk_: rindolf, Did you get it working?
rindolf: adamk_: get what working?
adamk_: Ah, never mind. You won't get 3D acceleration via Mesa on your card.
adamk_: You were talking on #ati about trying to get radeonhd working.
rindolf: adamk_: ah.
rindolf:
rindolf:
adamk_: Gotcha... I didn't read that far :-)
rindolf: adamk_: k
nrg-: anybody else having stability problems running EXA with latest radeonhd drivers?
bridgman_: nrq; which GPU and what kind of stability problems ?
nrg-: HD3650
nrg-: slight font corruption and X server crashes within a few minutes when using apps using Xv
bridgman_: ok, so you're running the 6xx-7xx branches of radeonhd and drm ?
nrg-: like vdr
nrg-: yes i am
nrg-: from 2 days ago
bridgman_: if so, font corruption is expected, but I don't think we've seen crashes recently
nrg-: git i meant
nrg-: 2 days old
nrg-: try running vdr using libxineout, crashes everytime
nrg-: or xine when set to use Xv
bronson: Anyone know why my subscribe requests to the radeonhd mailing list are being ignored?
bridgman_: 2 days is totally ancient, I think the crash fixes were after that ;)
bridgman_: seriously, pull the latest
nrg-: ok, will try to pull latest
bronson: It's been 3 hours... I'll keep waiting.
bronson: Just trying to get my 3650 working: http://lists.opensuse.org/radeonhd/2009-02/msg00030.html
nrg-: in the meantime, is it normal if Xv is not working under XAA?
bridgman_: bronson, most of the SuSE guys are sleeping
bridgman_: I'm taking a look at the link
airlied: Xv under XAA doesn't work usualy.
bronson: bridgman_, true, and their mailing list is too. :) Thanks for taking a look.
bronson: I'm trying Jaunty alpha 3... maybe I should try to get it working on Intrepid first?
bridgman_: never hurts to start with Jaunty; just curious, Jaunty should have booted up with radeon on your card by default, did that work ?
nrg-: how do you update with git, git checkout?
nrg-: or pull?
bronson: bridgman_, not really.
bridgman_: nrg; I hear conflicting things; I didnt' think Xv would work with XAA but at least one person said it did
bronson: It came up 2560x1600 but in YCrCb or something.
bridgman_: how is it connected ?
bronson: Instead of Ubuntu brown, the whole screen is cyan and I can see rippling that looks like endianness issues.
bronson: Dual-DVI
bronson: If I drop the res to 1280x800, the colors appear fine.
bridgman_: for clarity, that's a single DVI cable supporting dual-link ?
bronson: Using radeon.
bronson: bridgman_, yes
bridgman_: ok, just picking through your log, give me a minute
bridgman_: when you try to subscribe to the list, do you get any kind of message back ?
nrg-: damm, crashed again, even under xaa
bronson: I can send the log for radeon if you'd find it useful.
yangman: nrg-: don't use XAA
bronson: No, no response at all.
nrg-: did not have time to finish git pull
bronson: Maybe someone just needs to kick a mail queue somewhere.
bridgman_: and you sent to radeon+subscribe@... or whatever ?
bridgman_: radeonhd+subscribe..
nrg-: yangman: so EXA is best?
bronson: radeonhd+subscribe, precisely
bridgman_: XAA is not implemented
bridgman_: so EXA wins ;)
nrg-: ok
nrg-: hopefully the latest git fixes the stability issues
bronson: The radeon driver in Jaunty and Fedora 10 do the exact same thing: almost readable cyan with rippling.
bridgman_: might have something to do with picking "incoherent" mode by default for the signals, I still think that's wrong :)
bridgman_: not sure what the option is to enable Coherent mode on TMDS though... anyone ?
bronson: You mean for the radeon driver, not radeonhd?
bronson: Oh, I tried Intrepid's closed source ATI driver... it doesn't even offer 2560x1600, and it does list a whole bunch of modes that the monitor definitely does not support.
bridgman_: whatever driver you're running at the moment
bridgman_: yeah, the monitor only seems to offer 2 modes
bronson: Well, since I can't get radeonhd to work at all I'm using radeon at 1280x800. Looks awful.
bronson: That's right, only two modes. Dell cheaped out on the scaler. :)
bridgman_: btw the BIOS thinks your first connector is HDMI not DVI, is that possible ?
bronson: Perhaps... The video card claims to support HDMI with a dongle but I don't remember getting one in the box.
bronson: On the back is just two DVI ports.
bridgman_: wierd; according to BIOS you don't need a dongle ;)
bronson: Guess Asus screwed that one up!
bridgman_: anyways... ok, give me a minute to check the source code
bronson: This is the card: http://www.asus.com/products.aspx?l1=2&l2=8&l3=637&l4=0&model=2205&modelmenu=1
bronson: Wait... "Single dual-link DVI output which supports 2560 x 1600 at 30Hz resolution displays"
bronson: 30 Hz??
bridgman_: odd, the EDID says 50 Hz I think
nrg-: running new git
nrg-: font corruption looks a bit worse
nrg-: glxgears at about 450 FPS
nrg-: and Xv still crashes after about 15 seconds
nrg-: anything I can try?
bridgman_: yeah, some time in the last few days Alex made a radeonhd change which also needs new drm, and it will crash with old drm
bridgman_: 2 days is right on the edge
nrg-: i updated both drm and radeonhd to latest git
nrg-: http://www.x.org/wiki/radeonhd:r6xx_r7xx_branch
nrg-: following these instructions
bridgman_: then (he trys to say with a straight face) it should work
bridgman_: for some reason people updating drm seem to have trouble, not sure how best to confirm that
bridgman_: maybe edit one of the messages, rebuild, and confirm the edited message gets into the log ?
bridgman_: version nubmers would be nice, I know ;)
nrg-: i had to copy drm.ko and radeon.ko manually
nrg-: can i look in Xorg.0.log?\
bridgman_: dmesg, not x log
nrg-: ok, i get [drm] Initialized radeon 1.29.0 20080613 on minor 0
nrg-: hmm
nrg-: does this meain it's still using old drm?
bridgman_: I don't know, that message never seems to change ;)
bridgman_: you can look in the source code
nrg-: 20080613
nrg-: that's 2008 06 13
bridgman_: change it so something else in your copy, rebuild, and make sure the new message shows up
bronson: When the radeonhd driver produces the blank screen, is there any way for me to figure out what mode it thinks it's producing?
bronson: By sshing in?
bridgman_: I think xrandr should tell you
bronson: Actually, the log file tells me: (II) RADEONHD(0): On Crtc 0 Setting 59.9 Hz Mode: Modeline "1280x800" 71.00 1280 1328 1360 1440 800 803 809 823 +hsync -vsync
bronson: The radeon driver produces that mode without any problems.
bronson: Hm, I'm stuck. What's the next step in figuring out why radeonhd is producing a blank screen?
bridgman_: we find the option to enable tmds coherent mode
nrg-: what is that?
bronson: ah, ok.
bridgman_: it's a subtle difference in the relative timing of data and clock signals over the TMDS link
bridgman_: TMDS is used by DVI and HDMI
nrg-: still have crashes on latest git
bridgman_: ok, good to know; what GPU again ?
nrg-: HD3650
bridgman_: AGP ?
nrg-: pci expiress
nrg-: expres
nrg-: express
nrg-: also, it looks like there's no acceleration
bridgman_: can you set the EXANoComposite option in Device section and see if that helps ?
bridgman_: no acceleration or just slower than shadowfb ? no acceleration is "three seconds per update"
nrg-: Option "EXANoComposite" "on" ?
airlied: bronson: did the other DVI connector work at all?
bridgman_: sounds right.. "true" I think
bronson: airlied, dunno. How do I switch?
airlied: bronson: physically connect the monitior to the other one?
bronson: Just swap the cable, restart, and hope the card senses it?
airlied: pretty much
nrg-: just locked up when i tried that option
nrg-: when loading X
bronson: I'll try but I think it's just blackness.
_Steve_: http://pastebin.com/f2a44040a
_Steve_: oops, w/w
nrg-: now that i rebooted, looks the same performance wise
nrg-: runvdr
bridgman_: are you running with a compositor ?
nrg-: and vdr crashes x as well
nrg-: no change
nrg-: no
bridgman_: sorry, is it crashing at the same point in the same app ?
nrg-: yes
nrg-: i'm running Xfce window manager
nrg-: disabling composite helped a bit with the font corruption though
nrg-: any other settings i can try?
bronson: Can you guys suggest a place where I can ask about the radeon driver issue? (2560x1600 being driven, except the endianness or color mode is wrong)
bronson: Just the Ubuntu or Fedora bug trackers?
bridgman_: here is good; I just can't find the option in the source code ;(
bridgman_: the xorg and radeonhd mailing lists are best
bronson: Even though it's not the radeonhd driver?
airlied: bronson: thats wierd also why I suggested trying the othe connector
airlied: with radeon
bridgman_: airlied, do you know the option for coherent mode in radeon ?
bridgman_: I couldn't find it in man or a quick skim of the source
airlied: bridgman_: xrandr --output DVI-0 --set coherent_mode true
airlied: or something like thqat
bridgman_: d'oh, it's in randr
bridgman_: did I mention d'oh ?
bridgman_: thanks
bridgman_: bronson, can you try something like that É start with xrandr -q and get the output names from that
bronson: OK, rebooting into Jaunty...
bridgman_: nrg, there used to be crashes whenever a program used OpenGL, is there any chance vdr uses GL É
bridgman_: É means question mark
bronson: My monitor is outputting on HDMI-0. I need it to output on DVI-0. How do I change this?
bronson: (II) RADEON(0): Output HDMI-0 using monitor section 3007WFP-HC
airlied: bronson: that shouldn't matter juts xorg.conf legacy
bronson: airlied, really? It would explain what I'm seeing.
bronson: The card appears to find the correct mode and everything.
bronson: The monitor just doesn't see any sort of sync signal (apparently from the color of the power button)
bronson: airlied, I'm pretty sure it is using HDMI-0!
bronson: (II) RADEON(0): Output HDMI-0 using monitor section 3007WFP-HC
bronson: (II) RADEON(0): Output DVI-0 has no monitor section
kcodyjr: bronson, likely you have a different issue. i saw the same xorg.conf weirdness
airlied: bronson: if you can run xrandr -display :0 from ssh you'll see more
bronson: crud.
airlied: you don't need a monitor section in xorg.conf thees days
bronson: well that's good news
bronson: airlied, xrandr -display :0 produces "No protocol specified; Can't open display :0"
bronson: over ssh
airlied: when X is running
bronson: oh effin...
bronson: right.
bronson: Blank screens all look alike. :-/
bronson: I take it back, it is: /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
bronson: X is definitely running.
bronson: control-alt-backspace kills it off.
airlied: try DISPLAY=:0 xrandr
bronson: same thing
bronson: Doesn't this mean it's outputting on HDMI-0? (II) RADEON(0): Output HDMI-0 using initial mode 2560x1600
bronson: There's no similar message for DVI-0. I've deleted any mention of monitors from xorg.conf.
bronson: is starting to grasp at straws...
airlied: yes thats probably not so good, post the full xorg log