zce: im trying to get VGA working for radeon igp 320m, but it does not. restarting the system and opening X with vesa driver, VGA out works fine. but if i switch to radeon driver, the VGA monitor turns off. if i switch back to vesa, it does not work too, i have to restart so it works again... some tips?
MostFailDude: zce: You can't turn it on again with xrandr?
MostFailDude: Also vesa can't do multimonitor stuffs.
zce: MostFailDude, no, xrandr tells me a selected resolution for VGA-0, i can even change it, but the monitor keeps turned off.. i tried setting --output VGA-0 --off, and then changing mode again, and still nothing
zce: vesa is cloning the monitor, which is just what i want at the moment
spstarr: airlied: any reason libdrm-2.4.0-0.15 needs 2.6.27 kernel?
spstarr: something for kernel? GEM/TTM? :))
spstarr: nope
spstarr: kernel headers no longer in libdrm-devel now tracks kernel-headers
joecool: damn, still tears..
joecool: i think it's improved a bit though...
odz: :(
joecool: yeah, i tested the vsync_accel branch :(
odz: i was hoping it would work
odz: i was just going to test it
joecool: i'm gonna go back to head for a sec and see if it really improved or is just placebo
MostFailDude: Hmm, it seems pretty improved to me.
joecool: as i said.. i'm going back to check
joecool: right now..
joecool: dunno, it's different... can't say if its improved though
joecool: the tearing for me for mostly at the top third of the screen, now its on the bottom third.. which i guess is less noticable
joecool: for some things..
joecool: nah, still there.. forget it :(
odz: :(
gentoofu: multi-head or just single screen?
joecool: give em time... i still can't believe how far r500 has come in the open source department
joecool: gentoofu: single, no virtual
gentoofu: ic
joecool: xvid and exa were tested, both had exactly the same tearing
joecool: gentoofu: dual-head tears as well.. not tested with this latest branch, but i plugged a 1680x1050 lcd monitor in via vga a couple nights ago, and the tearing is MUCH more noticable on a larger screen
joecool: it's bearable here.. just high speed scenes really get it
odz: ya :/
joecool: btw, off topic, is there a powerplay tool for the opensource radeon driver?
gentoofu: i think airlied has a branch, only for r400 though
gentoofu: if i remember right..
joecool: got an R500 (or R520 i think is more accurate)
joecool: i do have dynaicclocks enabled though
joecool: got these two lines in xorg.log
joecool: Static power management enable success
joecool: Dynamic clock gating enable success
joecool: so i assume something is working
gentoofu: nvm, agd-powerplay
gentoofu: r4/5xx
joecool: gentoofu: you have an ebuild handy?
gentoofu: is bad with memory
gentoofu: nopes
gentoofu: i just remember being mentioned in here lol
joecool: bummer.. i'll do it tommorow then
joecool: Sun Jul 20 03:04:52 EDT 2008
joecool: nah, not doin an ebuild for it now
gentoofu: i better go to bed as well
joecool: soo...
joecool: wonder how the radeonhd camp is doing
odz: same here
libv: joecool: on what?
joecool: 2D
libv: you mean 2d acceleration i guess.
joecool: yes
libv: quite well and getting better :)
joecool: libv: EXA still slow on it?
libv: atm, yes, as there still is no render accel in master
libv: but it's there in the quick and dirty branch
joecool: your branch?
libv: no, alex his branch
libv: i never do quick and dirty
joecool: ah, k
libv: anyway... off to gliding, as long as the weather allows
joecool: later
z3ro: damn I really need to get my opteron running again... bisecting a 7 meg git tree really sucks on this box. :(
glisse: z3ro: btw you were right ib buffer are better for submitting cmd (stability pov) :)
z3ro: glisse: well, I'm not sure whether it directly makes a difference, but I think it's easier to undstand if you just have "
glisse: z3ro: it does make a diff, libv noticed that ring queue goes berserk sometimes
buggs: z3ro, if you need access to a reasonably fast machine send me your private keys
glisse: while ib seems more stable
buggs: should only take a minute or so
z3ro: glisse: hmm interesting.
z3ro: buggs: thanks for the offer, but it's debugging some 3d engine code, so I really need to run it locally.
buggs: i see
z3ro: actually AI code, but I've got to compile the whole thing to see what the bots are doing.
MrCooper: glisse: sounds like you're just avoiding the ring queue problem instead of addressing it directly...
z3ro: MrCooper: I guess ring queue going berserk is a hw problem...
z3ro: maybe it doesn't like too many writes too quickly or something.
z3ro: shrugs
MrCooper: anyway, off for a bit, bbl
glisse: MrCooper: well the solution seems to be
glisse: updating wptr n quadwords boundary
glisse: n=4
glisse: or 1 too seems to work
MrCooper: that can be achieved without IBs
glisse: MrCooper: yup but ib seems more solid than queue
glisse: and fglrx allmost never use the ring for rendering operation
MrCooper: so there's still another problem you're just avoiding? :)
glisse: it allmost only write ib in it
glisse: MrCooper: i am spending my life avoiding problem :)
z3ro: imho we should follow fglrx here. we don't know whether there are some subtle hw bugs.
z3ro: and from what libv said it sounds like there could be...
nha: you think their might be a caching problem?
nha: that could be an explanation for why updating wptr to boundaries is relevant
glisse: nha: if you look at CSQ_AVAIL reg you will see than ring space lost 2 dwords after a while
glisse: and then cp never report idle again
glisse: well this is in one soft lockup case
z3ro: well, I really have no idea, but I just don't see the point in doing it differently just because we can. we *know* fglrx's method (IB's and rb for basic dispatch and sync) works without lockup
z3ro: but we only know that our method *should* work, but it sometimes does lockup even though it shouldn't.
glisse: z3ro: well our lockup are also due to bad things like two rb3d_dstcache in a row
glisse: and others things like not always writting to some unpipelined reg at top of pipe
glisse: before wait_until
z3ro: glisse: right, but this becomes easier to handle when using ib's, because we know it will always be ib dispatch, then sync, then repeat.
z3ro: right now everything is just stuffed into the ring, with either too much or not enough sync commands in between.
z3ro: at least from what I understand, anyway.
glisse: z3ro: yup it's pretty much that
z3ro: anyway I should get some sleep... I'm leaving for Hong Kong in about 16hours.
z3ro: I'm going to try and get on irc every so often just to see whats happening... but I might not be around much for about a month. :(
bobbens: meh, captchas suck, only time I get it right it doesn't let me use "GOLD" (must use "G0LD").
bobbens: so a bit of help please with: Give the model name of a [not so recent] graphics chipset from Intel?
bobbens: i've gotten at least 5 wrong
glisse: we should use captcha on beer name :)
bobbens: well it asked for the same one except with nvidia
bobbens: i answered 6600, it said wrong :(
bobbens: i don't know nvidia nor intel chipsets at all :(
bobbens: so do you know the answer? :)
z3ro: bobbens: the nvidia answer is "geforce" iirc.
z3ro: I don't know the intel one.
bobbens: so the ati one is probably radeon
bobbens: and intel is... intel? :)
bobbens: my laptop has an i815, but idbout it'll accept i815 :)
glisse: i810,i830 for intel
glisse: yup i815 sounds good
bobbens: \o/
bobbens: thanks
bobbens: i810 worked :)
TobiasTheCommie: ehm, just wondering, what is "reducedblanking"
glisse: TobiasTheCommie: on lcd you don't have to wait for the beam to get back to begining of next scanline
TobiasTheCommie: ah, oki :)
glisse: well back to the begining of screen
glisse: is more about what it's
glisse: so you can reduce vblank in modeline this way iirc you have a lower mode frequency and should use less power too
TobiasTheCommie: sounds nice :)
TobiasTheCommie: so, does the radeon driveer support it? i think i saw radeonhd had it implemented.. so i suspect radeon has as well
glisse: dunno i guess yes
glisse: look at man page
glisse: otherwise forcing a modeline shoud do the trick
TobiasTheCommie: hehe, oki, thanks :)
z3ro: ok, time to sleep. night.
zce: im trying to use the VGA out using radeon driver without success. i can do it with vesa driver with no configuration (clone mode), but with radeon driver, it keeps the vga monitor off. if i change to vesa after trying radeon, however, it does not work too. thats the xorg log diff of vesa, before and after trying radeon driver: http://pastebin.com/m247c1928
zce: the DDC thing looks relevant
zce: and radeon driver log is: http://pastebin.com/f6c1396e2
mattmatteh: zce, i probably can not help, but is only an analog vga device plugged in?
zce: mattmatteh, yes, along with the laptop screen
mattmatteh: zce, ohh
mattmatteh: laptop
mattmatteh: no idea on that
mattmatteh: i assume the default is off
mattmatteh: for external
mattmatteh: i have a vga out on my laptop but have never used it, and dont think i will since its outdated
mattmatteh: just like the modem
zce: i just trived tvout with xrandr, and doesnt work too.. garbled output, doesnt matter the tv standard i try
mcgreg: I thought tvout is disabled?
zce: disabled how? i used xrandr addmode explained in http://www.x.org/wiki/radeonTV
mcgreg: points at airlied/agd5f
zce: now i tried attvout with vesa, and it worked too (but it was either tv or laptop lcd) (atitvout doesnt work with radeon, and xrandr S-video doesnt work with vesa)
zce: and changing to vesa, then to radeon again also makes nothing works... i think radeon is changing something it shouldnt or something like that, how can i check that?
zce: (i mean changing to radeon then vesa again)
zce: more xrandr experiments.. if i set the LVDS to off, svideo gets completly garbled, but if it is set to ON, it looks like the tv standard is not set properly, because i can see some shapes of the desktop... in both cases, changing the tv standard does not have any effect
syntropy: well that's weird....I made a shared library which overrode glBegin() and supplied my /own/ version...yet under radeon, it has no effect whatsoever.
syntropy: it inverts all rendered colors.....it worked under fglrx, but not under radeon...
airlied: glisse: where did libv document that?
airlied: glisse: he was working on ring in framebuffer RAM.
airlied: glisse: which was a big mine field..
airlied: as the HDP path has flushing/caching rules..
LeastAwesomeDude: agd5f, airlied: So, I think I got the tex coords uploaded right. But it's not working. Before I go back and debug 700+ lines of FP instructions, could somebody confirm that I'm doin' it right WRT everything non-FP? http://rafb.net/p/3HuuQe37.html
LeastAwesomeDude: ...Wow, that sounded really rude. Sorry.
joecool: i don't think vsync is working right on my x1400
joecool: i think that's where the tearing is coming from
dmb: joecool, mobility?
joecool: yes
joecool: forcing sync on vsync on with driconf, i get ~32fps with glxgears... my vsync is 60hz, i can easilly do a couple thousand fps with it off
joecool: i should be getting 60fps, no?
joecool: i'm running the vsync_accel branch right now as well
dmb: for some reason, i get under a thousand whether its on or off for me :/
airlied: LeastAwesomeDude: this channel then :)
LeastAwesomeDude: airlied: 'k.
LeastAwesomeDude: I set the tex coords, the VAP prog, the tex unit, the RS inst, and of course, the 700-line FP. :3
joecool: i'll ask my question after he's done :P
LeastAwesomeDude: I'm starting to think I messed up the FP, but I'm not looking forward to debugging it, so I wanted one other pair of eyes to tell me "Yeah, you fucked up the FP, get back to work, peon."
airlied: LeastAwesomeDude: in that patch the RS code is commented out.
LeastAwesomeDude: airlied: I changed it; turns out that I don't need to change RS_INST_1, I just need to change RS_INST_COUNT. Should be set in the very last patch.
airlied: is RS_INST_1 already written?
LeastAwesomeDude: Yeah, in RADEONInit3DEngine, it's set to route two tex components from tex1.
airlied: LeastAwesomeDude: you only need two then?
LeastAwesomeDude: airlied: Well, only need two texcoords, yeah.
airlied: LeastAwesomeDude: so does it hang or just draw crap?>
LeastAwesomeDude: airlied: Well, if I try to set RS_INST_1, it hangs. Otherwise, it just draws black.
airlied: LeastAwesomeDude: you don't seem to mess with VAP_PROG_STREAM_CNTL_0
airlied: which you probably need to emit VAP_PROG_STREAM_CNTL_1
LeastAwesomeDude: Hmm.
airlied: you need to route some DATA_TYPE_FLOAT_2 to 7 dst vec
LeastAwesomeDude: Eh? I'm not understanding.
airlied: see R300_VAP_PROG_STREAM_CNTL_0?
LeastAwesomeDude: The one thing that I was really unsure on was whether or not the EXA-no-mask VP would also work for this.
LeastAwesomeDude: Yeah, I see it.
airlied: and the big comment above it?
airlied: that routes the position and textures 0 to the GA.
airlied: you also want to route tex1 .
LeastAwesomeDude: Hmm. Yeah, I see. I figured I'd mess with that later, since I don't need it for TCL?
LeastAwesomeDude: But maybe I should poke it right now.
airlied: you do need it for TCL.
airlied: otherwise it would be in the !has_tcl path
airlied: its just differrent for TCL
LeastAwesomeDude: I see.
airlied: those numbers 0, 6,7 are use in the VAP code I think
LeastAwesomeDude: Yeah, the VAP numbers go 0,0 1,6 2,7
LeastAwesomeDude: I don't know what they mean, though.
airlied: LeastAwesomeDude: they are just so we can set the regs up the same for tcl/non-tcl
LeastAwesomeDude: Only that the comments in the commonfuncs suggest that it's for routing two textures and a color.
airlied: LeastAwesomeDude: have a look at STREAM_CNTL_1 in the exa code
airlied: when we have a mask.
LeastAwesomeDude: Ooh, I see.
LeastAwesomeDude: Haha, now it makes sense.
LeastAwesomeDude: BRB, testing stuffs.
MostAwesomeDude: Well, that was delightful.
MostAwesomeDude: Writing to VAP_PROG_STREAM_CNTL_1 causes softlock.
airlied: MostAwesomeDude: really you want codepaths like EXA with the mask
airlied: if all you are doing is adding another texture
MostAwesomeDude: Wonder if I'm not putting the texture up right.
airlied: just copy the paths for if (pMask) and replace with if (bicubic)
MostAwesomeDude: Yeah, I learned a lot from EXA w/mask.
airlied: btw your texture setup llooks a bit sparse.
MostAwesomeDude: Yeah.
MostAwesomeDude: Just a bit.
airlied: but you shouldn't get alockup just garbahge
airlied: if you need rectangular texturing you might need to change it.
MostAwesomeDude: Oh, duh. I'm still thinking in old terms.
MostAwesomeDude: No lockup on invalid memory access, since there's no executable stuff on the card.
MostAwesomeDude: The card will just display whatever I give it.
MostAwesomeDude: So it's definitely a register messup.
airlied: if the texcoords you use expect rectangular texturing then you need to at least do the pitch enable on the texture I think
MostAwesomeDude: Well, it's a 128x1 texture.
airlied: so in theory POT.
airlied: you on r500?
MostAwesomeDude: Yeah. Well, in practice, too.
airlied: if so then be careful with the unscaled vs scaled bit then
MostAwesomeDude: Yeah, I'm on r500.
airlied: and the texcoords you give it.
MostAwesomeDude: Hmm.
airlied: MostAwesomeDude: probably easier to treat the texture as rectangularl
airlied: keep the codepaths the same as exa code
MostAwesomeDude: Hmm, alright.
onestone: airlied: but for r300 you will need to use texcoords in the range of 0..1
airlied: onestone: well the current code does that already.
airlied: onestone: so he just needs to follow it :)
dmb: MostAwesomeDude, what are texcoords? (mind my stupidity)
joecool: hrm.. i'll give it a shot
joecool: what could be going on if i have vsync enabled and glxgears holds at 53fps on a screen running 60hz
joecool: with vsync off i can run at nearly 2000fps
MostAwesomeDude: dmb: Texcoords are the coordinates of texels.
joecool: i think i got tearing to stop with gl2 output on mplayer and vsync on... xv still tears like a mofo
joecool: even on the vsync_accel branch
joecool: r500
MostAwesomeDude: Hmm, looks like I've got everything that the EXA w/mask codepath does.
airlied: MostAwesomeDude: so it should work fine then :)
MostAwesomeDude: airlied: Yep. :3
MostAwesomeDude: Hmm, I just thought of something.
MostAwesomeDude: What if r5xx shader is so smart that it doesn't even bother to look up tex1 since it's not "enabled" right?
MostAwesomeDude: And now that it's enabled, it's causing softlocks because the shader isn't properly handling something?
MostAwesomeDude: I remember that we had similar issues when first writing shaders for Mesa...
airlied: MostAwesomeDude: well if the shaders references the right inputs it should be fine.
airlied: try replacing your shader with the exa one :)
MostAwesomeDude: airlied: Yeah, "if."
MostAwesomeDude: Hmm.
airlied: and fix stuff until it stops hangning.
airlied: then work on your shader
joecool: airlied: would you happen to know if mplayer vsyncs with xvideo output? I force enabled it with driconf, but I believe that may only apply to 3d
airlied: joecool: with the textured video adapter it can't.
airlied: joecool: agd5f is trying to fix that but it is messy.
airlied: joecool: with the mplayer gl2 plugin it might work
joecool: it does work with the gl2 plugin
agd5f: zce: you need at least 6.9.0 or git master
redeeman: airlied: is there a reason there is only texturedvideo available?
airlied: redeeman: because the hardware doesn't have overlay.
redeeman: oh, well that makes sense :)
redeeman: is this so for X1950 also?
agd5f: MostAwesomeDude: also make sure you add info->fbLocation to the offset of your new texture
airlied: redeeman: everythign from r500 up
agd5f: since the engines all take MC addresses
redeeman: airlied: but isn't textured slower?
redeeman: is there an advantage to textured xvideo over an opengl output driver?
zce: agd5f, only for tv out? or even vga out?
agd5f: zce: vga out
agd5f: tv-out doesn't work on IGP chips
airlied: redeeman: only its simple for the players.
airlied: and may be more efficient.
zce: agd5f, GREAT i was almost giving up, i only care for vga
agd5f: no one ever figued out the proper plls for tv-out on IGP since it uses a different ref clock
zce: agd5f, tvout works with that atitvout program using the vesa driver, wouldnt that somehow help?
agd5f: zce: some one needs to dump the regs and add support
zce: agd5f, is there any way i can contribute with the reg dumping?
agd5f: same could be done for non-800x600 tv modes
agd5f: brb
spstarr: agd5f: you coming to OLS??
MostAwesomeDude: airlied: Hmm, still softlocking. Guess I'll have to keep staring at the code. It looks like I'm doing all the things that EXA is doing.
airlied: MostAwesomeDude: execpt the most important one :)
MostAwesomeDude: airlied: Which, of course, I won't figure out until agd5f gets bored and points out a small typo which caused bit 23 instead of bit 24 to be set, and then magically everything will work.
airlied: MostAwesomeDude: yeah I'd go with copy the exa codepaths and work from there :)
MostAwesomeDude: Or, more likely, I need to untangle all of the ridiculous stuff that's currently going on, and figure out exactly which register EXA touchs that I don't.
agd5f: MostAwesomeDude: make sure you add info-fbLocation to your new txoffset
agd5f: *info->fbLocation
MostAwesomeDude: agd5f: Found something.
MostAwesomeDude: pPriv->bicubic_src_offset = pPriv->video_offset + info->fbLocation + pScrn->fbOffset;
agd5f: MostAwesomeDude: ok
MostAwesomeDude: Should be: pPriv->bicubic_src_offset = pPriv->bicubic_offset + info->fbLocation + pScrn->fbOffset;
MostAwesomeDude: XD
MostAwesomeDude: Let's see what happens now.
MostAwesomeDude: If that was it, I'm gonna be massively ticked with myself for making such a lame typo.
agd5f: zce: what you'll want to try and do is dump all the regs using glisse' radeondump tool patched to dump all pll regs when tv-out is configured for 800x600
zce: agd5f, i will look into that as soon as i get vga out working! once i get it, where do i send it to?
agd5f: zce: you can send it to me alexdeucher AT gmail DOT com
MostAwesomeDude: Heh, nope, that wasn't it.
joecool: agd5f: hey, i'm giving the vsync_accel branch of yours a shot, i get no tearing with mplayer's gl2 output, but xv and x11 still tear just like before.... does mplayer draw to the front buffer?
joecool: and i only get no tearing with gl2 if vsync is enabled with a tool like driconf
agd5f: joecool: the code is more of a sandbox. there's no guarantee that rendering will finish before the screen starts scanning the active area again
agd5f: gl has real support for vsync, so that's the way to go
joecool: agd5f: yeah, i knew it wasn't finished (phoronix would like people to think that)
joecool: the issue with gl though is it can't keep up on 720p video :(
agd5f: joecool: the real fix is composite and pageflipping
MostAwesomeDude: joecool: What agd5f said. Xv needs to be able to keep regular updates without regards to vsync; 60fps video doesn't sync well to 50Hz refresh rate.
MostAwesomeDude: joecool: Also try -vo gl2; it should be a bit faster.
agd5f: bbl
joecool: i'm running a 60hz refresh.. and i already said i used gl2
joecool: i do have the composite extension disabled... but i didn't think that would have any effect on this
MostAwesomeDude: Ooh, I thought you were using -vo gl. Sorry.
joecool: eh, its ok
joecool: i really can't complain right now, more or less i'm just trying to get a handle on how certain things work
zce: agd5f, didnt quite work.. the vga monitor is still off, but the leds are blinking, i dont know what that means... at least when i change to vesa, it works again without rebooting
agd5f: zce: 6.9.0? or git master?
dmb: zce, sounds like its a resolution or refresh rate it can't handle
zce: agd5f, 6.9.0, from ubuntu intrepid alpha 2
agd5f: ok
agd5f: got a log?
zce: agd5f, http://pastebin.com/f773d71c9
zce: dmb, i changed to a standard one (1024x768@60) via randr but no change
agd5f: zce: do any other modes work? can you change the mode on VGA-0 via xrandr?
dmb: try 800x600, that always works :D
zce: i changed it to 800x600 and didnt work.. then i changed LVDS to 800x600 too (it was 1024x768) and it worked
zce: no WAIT
zce: i think when i changed LVDS it changed VGA-0 instead
zce: yes, i can confirm that changing LVDS changes both lvds and vga-0, changing vga-0 changes nothing
zce: changing VGA-0 actually tries to change LVDS (well, it just flickers, but dont actually change), and then sets the VGA in the blinking state
gentoofu: maybe something is funky in your xorg.conf
zce: i dont think so, but just to be sure will comment Load modules section and all the Option
zce: by the way, switching to a terminal and then going back to X makes VGA off, but comes again setting the LVDS resolution... now im rebooting with naked xorg.conf
zce: no difference
zce: no difference
zce: ops, sry
agd5f: zce: does using git master help any?
zce: agd5f, i can try that tomorrow (here 2am)
agd5f: zce: ok