dennis_: what bugzilla should I use to file bugs?
MostAwesomeDude: Theirs. :#
MostAwesomeDude: :3
MostAwesomeDude: Um, bugs.freedesktop.org, I suppose, but could you tell us a bit about it first?
dennis_: I have a X300 card with one DVI connector but the driver detect two
MostAwesomeDude: Hmm.
dennis_: and it think my monitor is connected to both
MostAwesomeDude: Ah. That could be a problem.
dennis_: this is the log anyone is curious http://rafb.net/p/j0cmCF15.html
MostAwesomeDude: airlied: Ping? Know who I should ask about Fedora 9 fglrx packages?
airlied: MostAwesomeDude: not me :), not sure if fglrx runs on F9 at all.
MostAwesomeDude: airlied: Well, given that I have an F9 box, and a Gentoo laptop that cannot run fglrx, I would rather have it on the F9, even if I have to do stupid/risky stuff to it.
MostAwesomeDude: After all, it IS a fresh install. :3
MostAwesomeDude: Dang, git's down again? And just when I have something to push?
MostAwesomeDude: Conspiracy, I say!
rx__: ;)
rx__: what's cooking?
MostAwesomeDude: rx__: Just some cleanup that should help me rewrite LIT tomorrow in-between fixing Windows comps for cash. :3
airlied: MostAwesomeDude: what's wrong with git?
MostAwesomeDude: Well, nothing now, I guess.
MostAwesomeDude: Huh.
dmb: hmm, i'm getting a compile error for xf86-video-ati
dmb: http://pastebin.da4.org/279
MostAwesomeDude: airlied: Okay, looks like I can either use livna testing, or be patient for a few days.
MostAwesomeDude: I'm opting for impatience. :3
airlied: dmb: missing pciaccess devel or something.
dmb: airlied, its installed
dmb: needed it when building xserver
airlied: dmb: wierd something isn't picking it up then.
dmb: isn't pciaccess optional for the radeon driver anyway?
dmb: erm ati
MostAwesomeDude: dmb: Used to be, not anymore.
airlied: if the X server needs pciaccess the driver needs it.
airlied: otherwise optional.
dmb: should be included in config.h right?
MostAwesomeDude: y
MostAwesomeDude: Whoops, wrong keyboard.
dmb: lets see if it works if i add it manually
airlied: dmb: it gets included when XSERVER_LIBPCIACCESs is et.
airlied: my guess is you have wong PKG_CONFIG_PATH
dmb: i'm using the debian installed version of libpciaccess-dev
dmb: PKG_CONFIG_PATH seems to be fine
MostAwesomeDude: z3ro: Does revenge still work with current fglrx?
dmb: its in the standard place
dmb: /usr/include/pciaccess.h
dmb: and /usr/lib/pkgconfig/pciaccess.pc
airlied: dmb: it may be too old.
MostAwesomeDude: airlied: We'll see what happens.
dmb: yeh, i added it myself, and now i get radeon_driver.c:383: error: ‘PCI_DEV_MAP_FLAG_WRITABLE’ undeclared (first use in this function)
dmb: interestingly, xserver was able to compile with it
dmb: whats the git url for pciaccess?
dmb: gitweb is being a dope right now
airlied: git://git.freedesktop.org/git/xorg/lib/libpciaccess
MostAwesomeDude: airlied: Huh, pretty snazzy setup that the livna guys have. It builds fglrx on-the-fly if not prepared.
airlied: glisse: btw no calling driver AMD, there are other AMD gpus..
MostAwesomeDude: Unfortunately, it doesn't work with the new kernel.
ubuntu: hey, stupid question, how can i fix the "No valid fontspath" after compiling and trying to start the git xserver?
MostAwesomeDude: I believe you need to configure xserver with --with-builtin-fonts
MostAwesomeDude: I could be wrong, though.
dmb: argh
MostAwesomeDude: Don't make clean, and it will be rebuilt in a blink!
dmb: i removed the directory though :(
MostAwesomeDude: ...
dmb: "well whos fault is that?"
MostAwesomeDude: Hey, you said it, not me.
rx__: fonts aren't necessary
dmb: yeh, who needs fonts?
airlied: or if you are installing the server someoewhere differnet.
airlied: you'll need to set fontpaths to where the fonts are.
airlied: or link them
dmb: yeh
dmb: i remember the good old days when the x11 servers were all one big package
dmb: non-modular-x days
dmb: using --with-builtin-fonts didn't work
dmb: is there a way i can provide a fonts path?
dmb: (which is in /usr/share/fonts)
MostAwesomeDude: XD, forgot to stop compiz before my screensaver started
dmb: i guess compiz and your screensaver don't get along?
dmb: gl screensaver i'm guessing?
MostAwesomeDude: dmb: Bingo.
MostAwesomeDude: Well, and I forgot to set my vblank_mode back from 2.
MostAwesomeDude: Wine apps need 2 in FS, everything else should have 0 or 1.
MostAwesomeDude: (Most Wine GL apps need vsync for timing, lawl.)
MostAwesomeDude: Gah, stupid fglrx.
MostAwesomeDude: Even from the bit bucket it taunts me.
MostAwesomeDude: Trying an earlier ball.
MostAwesomeDude: I'm gonna feel really useless if I can't figure out how to fix stuff because fglrx won't install.
MostAwesomeDude: ...Wonder if marcheu could install fglrx.
dmb: MostAwesomeDude: wine should be automatically switching that correct?
MostAwesomeDude: The unstoppable coder vs. the unmovable blob.
MostAwesomeDude: dmb: Nope.
MostAwesomeDude: Because some Wine apps are well-written and some are not.
MostAwesomeDude: It really varies.
dmb: thats like the windows philosphy of coding
MostAwesomeDude: Right.
MostAwesomeDude: Besides, most of the authors of those games recommend going into driver settings and setting vblanking manually.
dmb: a lot of it is microsofts fault anyway
dmb: everybody thinks msdn is like the greatest thing in the world
MostAwesomeDude: Wine SHOULD use EXT_MESA_swap_control to relay vblank requests from userspace, but I don't think it does.
dmb: if you take a look at it, the pages are inconsistant
dmb: and contradict eachother
MostAwesomeDude: dmb: I once wrote 100 lines of code for joystick userspace drivers, for Linux and Windows.
MostAwesomeDude: The Linux code was about 30% comments, and was very well-formatted, laid out nicely, etc.
MostAwesomeDude: The Windows code had maybe 5 comments, and was mostly spaghetti and recursive messes.
MostAwesomeDude: Did you know that in DirectX you have to register a callback for joystick buttons?
MostAwesomeDude: And it doesn't even do anything, just acknowledges, "Yeeep, it's a button. On a joystick."
dmb: lol
MostAwesomeDude: I can't even make this stuff up. Read DirectInput on MSDN sometime. Hilarious stuff.
dmb: windows programming is a bunch of hacks
dmb: to get around microsofts lazyness and incompetince
MostAwesomeDude: Okay, you know what, this is ridiculous.
dli: is vista somehow better?
MostAwesomeDude: When livna puts out prebuilt fglrx, I'll use that. Until then, I'll just have to put revenge work on hold.
MostAwesomeDude: dli: No, Vista is actually more painful.
MostAwesomeDude: All the new APIs are DRM-related.
dmb: i refuse to code anything for vista
dli: MostAwesomeDude, ah, that's where performance is sacrificed
dmb: oh well
dmb: compiz crashed latest xserver git + mesa git + dri git
dmb: for some reason compiz just does not want to run on the oss driver for me :D
dmb: http://entertainment.slashdot.org/article.pl?sid=08/06/01/0023244&from=rss
mikkoc: dmb: see http://www.phoronix.com/forums/showthread.php?t=10265
dmb: someone needs to create a livecd with the latest everything so each of us can test it without setting it all up :D
z3ro: MostAwesomeDude: yes, it should... but I haven't tested it myself.
z3ro: MostAwesomeDude: if it doesn't, let me know, and I'll fix it.
glisse: airlied: at least we can keep amd_* name for file, it's just that i was exhausted to have completion aliasing with old drm ;)
glisse: spstarr is not here but there is a bug in gart code for gart bigger than 32Mo
glisse: iirc correctly we only allocate a page table large enough for 32Mo
MostAwesomeDude: z3ro: When I get fglrx running, I'll let you know. :3
z3ro: MostAwesomeDude: yeah it's a bit of a pain to get fglrx to compile...
MostAwesomeDude: glisse: Is there really any need for a GART bigger than 64?
airlied: glisse: hmm maybe, I'd rather not use amd name at all in the driver.
airlied: glisse: AMD is cpu, geode, and ati cards.
z3ro: MostAwesomeDude: I usually have it set to 128 or something, else I end up running out of gart memory.
glisse: airlied: well i am fine with radeon_ but i am lazy when it comes to completion :)
glisse: MostAwesomeDude: well there could be need for bigger one
z3ro: I removed that option lately because it would lockup, which I guess is this bug.
glisse: z3ro: you should try with 32Mo gart this might fix some bug you see
glisse: z3ro: otherwise there is a secret option to ask for bigger page table
airlied: glisse: well radeon is more correct, I would hope there is a geode driver i nthe future.
MostAwesomeDude: Well, I mean, isn't the aperture size what matters? Or does a bigger GART do things besides let us have more objects in VRAM?
airlied: so stealing the amd namespace isn't nice...
dli: nothing on screen now, if I switch back to console
z3ro: glisse: yeah. I just removed the option from xorg.conf, which I guess uses the default
z3ro: but it means I run out of gart when using a lot of high res textures.
glisse: airlied: marcheu keep telling me that i am not nice ;)
glisse: MostAwesomeDude: bigger gart is usefull for big texture
glisse: as long as there is no memory manager...
z3ro: MostAwesomeDude: btw, at the moment I'm using fglrx-8.471.3 and linux-2.6.23.17... so if all else fails, give those a try.
z3ro: glisse: btw, whats the secret option for bigger gart?
airlied: we don't use the GART for textures do we?
glisse: z3ro: can't remember look in ddx dri file
z3ro: ok
glisse: airlied: oh maybe i thought we did
airlied: I thought r300 only used it for vbos..
glisse: long time i have take a look at this part
airlied: oh and dma bufs.
z3ro: airlied: haha, I guess my engine might be generating more than 32m in vbo's. =/
glisse: osiris: if you read backlog don't allocate pixel in your function just use a static array in context struct
z3ro: I wouldn't really doubt that...
glisse: osiris: and if (pattern & 1) pixel[i] =0xff else pixe[i]=0x0
airlied: ah we use it for texture upload also.
glisse: osiris: the idea is to use texkill tex instruction in shader
glisse: so i am wrong it should be if (pattern & 1) pixel[i] =0x0 else pixe[i]=0xff
glisse: and we should ask for signed texture
glisse: even though i am not sure i understand texkill properly
glisse: got to go bbl
marcheu: glisse: hey, I don't want to be responsible for your mistakes :)
MostAwesomeDude: Hey, who's working on the skellie driver for Radeons in Gallium?
MostAwesomeDude: I saw a short blurb about it, but it didn't name names.
airlied: MostAwesomeDude: the answer to all questions is glisse.
MostAwesomeDude: airlied:
MostAwesomeDude: airlied: Tell that to my calculus professor.
MostAwesomeDude: But seriously, I'm confused as to when we should shift focus exclusively to the Gallium side of things.
MostAwesomeDude: Maybe I should just sleep.
nh: is there a Radeon-on-Gallium branch somewhere already?
MostAwesomeDude: nh: Don't think so.
MostAwesomeDude: Sleep, BB.
airlied: I think glisse looked at it once.
airlied: http://cgit.freedesktop.org/~glisse/mesa/log/?h=radeonms
airlied: has bits of it.
papillon81: is anybody using the radeon driver under kde 4.x with composite and without an immediate crash after activation?
mikkoc: papillon81: me
mikkoc: papillon81: http://www.phoronix.com/forums/forumdisplay.php?f=43
mikkoc: i get a freeze tho, not a crash
osiris_: glisse: which r300 func is called during glBegin(GL_LINES)?
osiris_: I want to know where I should bind stipple textures to lines
papillon81: mikkoc: r300?
mikkoc: r500
papillon81: mikkoc: and no PPC, i assume?
mikkoc: x86_64
papillon81: well...
mikkoc: no ppc
mikkoc: different issue?
papillon81: mikkoc: I get a bad x crash as soon as i activate the opengl composite of kwin
papillon81: but other apps like glxgears work
mikkoc: i wish i got a crash :D I get a freeze
papillon81: and direct rendering is active
mikkoc: yes, other apps work
papillon81: xrender works, but it's very slow
mikkoc: do you have anything in xorg.0.log?
mikkoc: cuz i dont
papillon81: nothing helpful
papillon81: wait
papillon81: i'll post it
papillon81: oh well, looks better this time...
papillon81: 1 minute
papillon81: i get a backtrace
papillon81: http://pastebin.com/d223c7e23
mikkoc: you should post that in the thread.. in case it's the same problem..
papillon81: mikkoc: into the "Hard lockups during 3D/R500 in OSS radeon?"?
mikkoc: dunno... it looks similar..
mikkoc: at least the kde4 part
mikkoc: you have xserver from git?
papillon81: yes
papillon81: i have mesa, drm, xorg and radeon from git
papillon81: i also posted some info here: http://bugs.kde.org/show_bug.cgi?id=159280
papillon81: maybe you could do this, too. and also vote
mikkoc: yea, but i don't get any backtrace or anything..
mikkoc: for me it just hangs
mikkoc: but yea, i'll write and vote
papillon81: would be nice
mikkoc: still, not sure this is a kde bug
papillon81: mikkoc: nobody is sure about that, cause nobody seems to take any action
mikkoc: heh
azuwis: papillon81: have you set vblank_mode? I need to set vblank_mode=0 to get compiz running, I have a similar problem yesterday when enable kde4 composite.
papillon81: azuwis: where do you set this?
papillon81: i disabled the vblank in the dialog, but it changed nothing
azuwis: use tool like driconf
azuwis: or set environment variable 'vblank_mode'
mikkoc: azuwis: would "export vblank_mode=0" be enough?
azuwis: and you may need to add `` Option "GARTSize" "64" `` to Section Device of xorg.conf, just have a try.
mikkoc: ok
mikkoc: i'll try
azuwis: mikkoc: yes, it may work. but i recommend to set it use /etc/drirc.
mikkoc: what's that?
mikkoc: i dont have that file
azuwis: azuwis@azuwis-laptop:~$ cat /etc/drirc
azuwis:
azuwis:
azuwis:
azuwis:
azuwis:
azuwis:
azuwis:
mikkoc: do i need to create it?
azuwis: yes, create it manually, or use driconf.
mikkoc: i don't want to install driconf really
mikkoc: i'll create it
mikkoc: is it read automatically? or i need to set some stuff?
Phlogi__: I moved from fglrx driver to radeon and now my font size is a little bit larger, although I have added the same DisplaySize option to my LCD Monitor, how can that be?
azuwis: mikkoc: It should be read automatically.
papillon81: azuwis: MAN!
papillon81: that looks good!
mikkoc: it works??
papillon81: YES!
mikkoc: shiiiiiiiit... holddddd on lol
azuwis: LOL~
mikkoc: wish me luck
mikkoc: lol
MostAwesomeDude: Wow. I can't believe that nobody told me that FLR hadn't been added.
MostAwesomeDude: Well, whatever. It's there now.
papillon81: mikkoc: how is it going?
mikkoc: uhm
mikkoc: ok, it didnt freeze
mikkoc: but the screen went completely black
mikkoc: i could still so stuff, cuz i hear the kde sounds
mikkoc: i just can't see anything.. beside maybe some window shapes
mikkoc: i'll check if it freezes on kde logoug
mikkoc: *logout
papillon81: are you using EXA?
Phlogi__: is there a way to increase 2d performance? What options are performance related anyway?
mikkoc: papillon81: i didnt set any method in xorg.conf
mikkoc: dunno which is default
mikkoc: but yea, i still get the lockup at kde logout.. which is not a hard lockup, cuz the mouse cursor keeps blinking
papillon81: XAA
azuwis: Option "AccelMethod" "EXA"
mikkoc: should i use exa?
papillon81: yes
mikkoc: even if 3d is enabled?
papillon81: mikkoc: especially then
mikkoc: ah lol
mikkoc: atm things are really slow with 3d enabled
mikkoc: like moving plasmoids etc
papillon81: taht's because of XAA. exa is better for compositing
mikkoc: but i have no composite
mikkoc: i get a black screen when i enable it
papillon81: but you want to try it out, right?
papillon81: yeah, and that might be related to using XAA
mikkoc: composite? yea
mikkoc: ok
mikkoc: brb
Phlogi: is there a way to increase 2d performance? What options are performance related anyway?
Phlogi: wonders why no ones answers his questions :(
azuwis: mikkoc: my xorg.conf, http://pastebin.com/f55d93152, maybe you can take it as a reference
Phlogi: azuwis: where did you get those options from like ColorTIling? Performance related?
Phlogi: and I think there is no option DRI azuwis
MrCooper: Phlogi: yes there is, but it's enabled by default where supported, just like ColorTiling
MrCooper: Phlogi: see the radeon manpage
Phlogi: ok thanks
azuwis: Phlogi: http://wiki.x.org/wiki/radeon
mikkoc: still doesnt work with exa
mikkoc: the funny thing is... with exa moving plasmoids around is fast.. but on the other side.. moving/resizing windows is a pain
Phlogi: does DynamicClocks really work?
Phlogi: what about those options? http://rafb.net/p/UhBjYV82.html
MrCooper: Phlogi: the first one is gone with the current driver
Phlogi: thanks
MrCooper: Phlogi: the second one is nvidia blob specific
mikkoc: oh, btw... (WW) RADEONHD(0): Option "GARTSize" is not used
mikkoc: is that normal?
MrCooper: Phlogi: the third one makes XAA not suck as badly, probably better to use EXA in the first place
MrCooper: mikkoc: radeonhd != radeon
Phlogi: MrCooper: Ah ok, using EXA
mikkoc: yea i know
Phlogi: so is this config fine like this? http://rafb.net/p/UpnClu71.html
Phlogi: for r300
unverbraucht: i cannot get radeon git to display on the tv-out on rs690
unverbraucht: has this been implemented yet?
MrCooper: Phlogi: looks good; GARTSize 16 or 32 may be good for the Mesa r300 driver, and with an AGP card you can try Option "AccelDFS"
Phlogi: MrCooper: could you explain or give me a link for the GART stuff, what is it?
Phlogi: the other one I set to true I guess
MrCooper: it's a boolean option, so "true" is implicit
Phlogi: what about EnableDepthMoves
MrCooper: bad idea
Phlogi: yes true, 1 or on
MrCooper: Phlogi: generally, you shouldn't worry so much about tweaking options
Phlogi: oh really, ok :)
MrCooper: the defaults should be fine, or it's a bug
Phlogi: what about AGPFastWrite I should try that I guess
MrCooper: it tends to crash and burn, and otherwise probably won't make any noticeable difference, but feel free :)
Phlogi: ok thanks :D
unverbraucht: the strange thing is, even without an xorg.conf radeon seems to autodetect everything correctly
unverbraucht: resolution changes create flicker on the screen
unverbraucht: but it won't display any content :(
mcgreg: hehe now that ppl have heards r500 support 3d, it seems more and more people are testing it and are coming here :)
mcgreg: some time ago the channel had 20-30 pp,l around here, now it's almost 90 :)
nh: KIL should work correctly on R300 now.
MrCooper: nh: cool; btw, have you ever thought about handling the temp registers for rectangle tex instructions more smartly to minimize indirections, e.g. to make the compiz bicubic plugin work? I've hacked up something but it doesn't seem to work quite right
nh: thought about it, yes; but I haven't found a clean way to do it in the current framework, because that basically assumes that we go through the program in a completely linear fashion
MrCooper: right
nh: do you have a more-or-less self-contained example where we run out of indirections?
Phlogi: strange as soon as I enable the xinerama option my screen locks up after starting x
Phlogi: this is my configuration: http://pastebin.com/m399d136f
Phlogi: furthermore my DisplaySize option seems to get ignored :(
nh: has exactly zero clue about Xinerama
mcgreg: I thought xinerama is outdated since randr?
mcgreg: or was it something else?
Phlogi: nh: could be that I need to recompile more packages... I just added xinerama support
MrCooper: nh: http://people.freedesktop.org/~daenzer/r300-texrect.diff is my hack
Phlogi: (**) RADEON(0): Display dimensions: (287, 215) mm hmm it is picked up... strange, but the fonts are too big
peterz: mcgreg: you still need xinerama when using multiple cards - so outdated, no.
Phlogi: even more strange: after doing: xrandr --fbmm 287x215, the fonts are fine! Anyone can explain that?
leio: I believe libXinerama still provides monitor placement and such information with xrandr based dual-head?
Phlogi: peterz: but I don't need xinerama when I want to add a second montior and then drag the windows to that?
Phlogi: leio: yes I want dualhead
peterz: leio: yeah that too, single card multihead basically fakes a xinerama setup - so the client sees xinerama
Phlogi: (in the end)
MrCooper: Phlogi: you don't need Option "Xinerama" for that
Phlogi: MrCooper: thanks
nh: MrCooper: that's quite a hack indeed
Phlogi: what about the displaSize, thats my real problem now
MrCooper: RandR 1.2 exposes Xinerama to clients automagically
leio: so GNOME and everything will know through libXinerama what your dual-head setup looks like, even if randr1.2 is used
MrCooper: nh: :)
Phlogi: Or should I run that xrandr comment everytime?
Phlogi: *command I mean
MrCooper: nh: any shader that uses four or more rectangle tex instructions will exceed the indirection limit; the compiz bicubic shader uses 5 IIRC
nh: that makes sense, ugh
peterz: Phlogi: programming.kicks-ass.net/sekrit/xorg.log
MrCooper: nh: but onestone_ carefully reordered the shader such that it could be done with a single indirection
MrCooper: nh: the hack may actually work 'the first time around' but produces garabge 'the second time around', though I'm not sure exactly what makes the difference in between
MrCooper: I say 'may work' because I'm not sure it's really bicubic filtering :)
Phlogi: peterz: link does not work..
peterz: Hmm, my bad, try: programming.kicks-ass.net/sekrit/xorg.conf
peterz: I can't even type what I mean today
nh: MrCooper: true, but I'd feel much better with something that handles indirections in general a little less stupidly
MrCooper: nh: sure, that would be better
Phlogi: peterz: what about it sorry?
peterz: Phlogi: thats a dual monitor conf
MrCooper: nh: hopefully something like LLVM will help eventually, but I was hoping for some kind of short term solution
osiris_: MrCooper: i'm trying to implement stipple lines using textures. could you take a look at: http://pastebin.ca/1035808 it's WIP, but I want to know if what I've done so far is good.
Phlogi: peterz: yes but an old fashioned one ^^
Phlogi: peterz: can you drag your windows with this?
peterz: Phlogi: yes
MrCooper: osiris_: you'd better ask nh to look at it, see what he said about my patch above :)
Phlogi: peterz: I want to use the new stuff with randr :)
Phlogi: peterz: but thanks anyway:)
peterz: this is a new randr-1.2 config
osiris_: MrCooper: hehe :)
nh: osiris_: I'm taking a look
nh: but isn't there hardware support for stippling?
osiris_: nh: probably no, because r500 docs doesn't give enough details, and fglrx dumps showed that fglrx driver doesn't use regs described in docs for stipple lines
MrCooper: maybe the hardware support doesn't match GL semantics or something like that
MrCooper: anyway off for a bit, bbl
osiris_: nh: I need to write a frag prog that will kill fragments according to stipple texture, but I don't know how to do it. I know pretty much nothing about shaders
osiris_: ctx->stipple_textures holds pointers to generated stipple texs, so we don't generate new stipple tex if the pattern is the same that was used before
osiris_: glisse said that max 16 stipple texs per context should be enough
nh: osiris_: you should be able to use the same path that is used for shadow maps (the R compare)
nh: osiris_: I'm not sure whether that can be done in a single texture instruction there, or if you need a TEX + KIL combination, but since that feature is rather old, a single TEX instruction could do
nh: or maybe even something like colorkey/chromakey
osiris_: nh: could you point me to that shadow maps code?
nh: though that will probably just give you a zero alpha value instead of killing the fragment entirely
nh: oh wait; I may be mixing things up, I'm actually not sure whether the shadowmap thing kills a fragment
nh: hold on
nh: yes, I was thinking of TEXTURE_COMPARE_MODE, but that doesn't actually kill fragments
nh: see page 109 of the R5xx acceleration pdf, US_TEX_INST_KILL_LT_0 is probably what you want
nh: (and its colleage for the R3xx)
nh: if you're writing an ARB_fragment_program, that's the same as the KIL instruction
osiris_: nh: thanks. what about my patch? is the general idea ok?
nh: doesn't look too bad
nh: You probably don't need the r300->stipple_line_flag, I'm sure that's cached by Mesa somewhere
Phlogi: If I want to have dualhead and be able to drag windows directly, I need xinerama built in my packages in configure options? And for kde too? Or not?
nh: osiris_: Also, you definitely cannot die when the stipple_textures array is full; instead, you need to evict/overwrite one of the older textures.
osiris_: nh: that's what I thought, but glisse said that it will never happen
peterz: Phlogi: that config I gave you is a randr-1.2 config - and yes build all of userspace with xinerama support
nh: osiris_: well, there are 2^16 possible line stipple patterns, and we certainly don't want to reserve that much space for textures
osiris_: nh: where should I bind frag prog to primitive? r300RunRenderPrimitive?
Phlogi: peterz: hehe I read in thinkwiki that I should not have stuff with rightOf and such in my xorg
Phlogi: ok I'm still compiling lots of applications :)
nh: osiris_: you must still honour the user's fragment program setting, so this will get really, really nasty
nh: are you certain that fglrx modifies the fragment program when line stippling is activated?
peterz: Phlogi: then you read wrong - you need to specify the relative position of the monitors some way; when you run xrandr you also say rightof/leftof
peterz: Phlogi: also - you're better off at a user channel
nh: osiris_: so basically, if you want to use a TEX + KIL sequence to eliminate those fragments, you'd have to concatenate fragment programs :/
osiris_: nh: no, I'm not. but is there any other way?
nh: do you have a dump of fglrx with a program that uses line stippling?
osiris_: yeah
nh: Can you send it to me? I don't even have fglrx installed here, it's been so long since I've done any reverse engineering
osiris_: ok, just give me your email address
nh: nhaehnle@gmail.com
nh: osiris_: btw, you need some code to clean up those dynamically generated textures
osiris_: nh: sent
osiris_: nh: won't they be deleted when context is destroyed?
nh: I don't think so, because the texture isn't actually part of the normal texture pool
glisse: osiris_: i miss expressed my self
glisse: you need only one stipple texture
glisse: stipple texture is context
glisse: so whenever it change you can trash old
glisse: ie overwritte
osiris_: glisse: ok
glisse: nh: the idea with stipple is that you get texture coordinate from hw so in frag prog you lookup texture using hw supplied coordinate if texture < 0 then kill the frag
glisse: osiris_: you have to convert the 16bits pattern to 16x8bits texture
glisse: where one in pattern = 0 and 0 in pattern = -1
glisse: the only things i don't see is how stipple texture coordinate is routed
glisse: nh: for gallium their should be a branch in my mesa rep on fdo
glisse: can't remember if it's up to date with what i did have localy
glisse: MrCooper: btw i did play a bit with llvm and i am not sure it's the things to use for gpu like r300 up to r500, you loose many information that tgsi has
glisse: it's still the things to use for cpu and maybe newer gpu
glisse: tgsi is so well designed :)
MrCooper: glisse: please bring up your concerns with Zack or generally on mesa3d-dev
glisse: MrCooper: well i will once i get sometimes to test one simple opt algorithm directly on tgsi
nh: glisse: The nasty problem with stipple is that the fragments must still be processed by the normal fragment pipeline, which means that the "stipple pattern fragment program" must be linked together with the _Current fragment program
nh: as for TC routing, it looks like the GB_ENABLE register might be responsible for that
osiris_: glisse: which func should I use to evict texture?
glisse: nh: yup you need to change current frag prog
glisse: en gb_enable is the register to use to route coordinate :)
glisse: osiris_: i was trying to look at your patch but pastebin seems dead overhere
glisse: osiris_: depends on what you done i think you need to use r300DestroyTexObj
glisse: osiris_: you shouldn't use mesa tex function
glisse: osiris_: idealy you should upload texture using driver function and the program directly hw
glisse: osiris_: most of things should happen in *Update* in r300_state.c like updating to new fragprog
osiris_: glisse: so I shouldn't use gl_texture_object at all?
glisse: osiris_: yup
glisse: osiris_: basicly do a helper function which do what r300UploadTexImages does
glisse: just don't use r300texobj
glisse: eboettcher: btw all this texture upload/handling is a good place to start cleaning :)
osiris_: glisse: could you explain me drm_radeon_texture and drm_radeon_tex_image structs?
osiris_: drm_radeon_texture: pitch=1; format=RADEON_TXFORMAT_I8; width=16; height=1; ?
PSYCHO___: is GLSL suppoted by opensource driver?
bridgman: PSYCHO: just arb_fragment_program afaik, not glsl yet
PSYCHO___: ook
dagb: bridgman: thank you for your extensive reply regarding hd2600 and dl-dvi yesterday.
bridgman: no prob; hoping we can start answering q's more quickly as we learn more ;)
dagb: bridgman: not sure if AMD has anything to do with the wikipedia pages, but for hardware features I find this to be a useful resource: http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units
dagb: There is no column for dual-link capabilities or TMDSA/LVTMA, though. ;-)
marten_laptop: hi guys
marten_laptop: is there any chance to get my radeon RS690M work with radeonfb? I'm dev, but I'm not so experienced with kernel framebuffer drivers and if I can help, I need a mentor
bridgman: dagb: we only get asked to update the wikipedia page for the chips we haven't released yet ;)
dagb: bridgman: heh. who knows. you might fall for it sooner or later.
dagb: just realised pcie 2.0 cards can be used in a pcie 1.0 slot.
dagb: is falling behind on the pc-hardware knowledge front
bridgman: marten_laptop: give me a minute to re-acquaint myself with radeonfb...
bridgman: dagb: yeah, never hurts to try
glisse: marten_laptop: radeonfb is dead end
glisse: marten_laptop: the plan is kernel modesetting inside drm
glisse: osiris_: sounds good
glisse: looks
glisse: bridgman: becarefull or you will end up full time on irc ;)
osiris_: glisse: what about offset? and x,y, width, height in drm_radeon_tex_image?
glisse: osiris_: you need to get offset from driallocate texture iirc
glisse: for x,y = 0 and width=16, heigh= 1
marten_laptop: glisse: thanks. where I can read more about it?
glisse: marten_laptop: modesetting-101 branch of drm repository hold the code
glisse: otherwise there is somes slides here http://people.freedesktop.org/~glisse/xdc-glisse.pdf
glisse: and some more informations here http://planet.freedesktop.org/
bridgman: glisse: I just have to hold the fort until someone like you comes along ;)
bridgman: marten: what he said ;)
glisse: i won't be here for long too, i was doing an apple pie :)
glisse: some times when you write you get bore and hungry so you do somethings like a good old home made pie =)
marten_laptop: bridgman: yep.. thanks guys
bridgman: marten: if you worked on kernel modesetting I think lots of people would
bridgman: cheerfully mentor you, including glisse who would be happy not to have
bridgman: to write all the code himself ;)
bridgman: glisse: when I'm hungry making apple pie from scratch doesn't seem like instant gratification
nh: Does depth write work on R5xx?
marten_laptop: bridgman: but I didn't (worked) :P
bridgman: marten: sorry, make that "if you were willing to work on kernel modesetting
bridgman: instead of radeonfb"...
nh: wonders what magic incantation I need to get depth writes in fragment programs to work on R300...
bridgman: nh: how far have you been able to get, and what happens ?
glisse: nh: i think moving z test to bottom of pipe and using frag prog stuff in doc we have should be enough
nh: okay, so here's my checklist:
nh: 1. disabled early Z completely (for now)
nh: 2. set the OMASK_W bit in the alpha ALU instruction that writes the depth value
glisse: nh there is a wout field in US_CODE_ADDR too
nh: 3. set the W_OUT bit in the corresponding US_CODE_ADDR (the register that describes the computation node)
nh: 4. play around with the US_W_FMT register
nh: anything else I might have missed?
glisse: nh: no i don't see why it shouldn't work, i guess you set w_src to wsrc_us
nh: yes, though I'm wondering, because that's the default value anyway (see r300_state.c:2276)
nh: I've tried setting it to wsrc_ras, but that doesn't seem to make a difference
nh: (I'm testing with the glean fragprog test)
glisse: nh: did you play with fg_depth_src ?
glisse: it seems that us_w_fmt is boggus
glisse: and that you need to use fg_depth_src
glisse: fg_depth_src=1 should make this work i think
nh: i'll give that a try
glisse: iirc when i looked at that through fglrx dump there wasn't much than 1 or 2 register being different
glisse: nh: so you got time to work back on this stuff :)
nh: a little, yes
nh: ahhh!
nh: fragment.depth *is* overwritten, just not by the right number
nh: why didn't I check for this earlier...
glisse: :)
glisse: nh: murphy law as usual ;)
nh: indeed
glisse: i wonder why all physicians looks for the universal while we already know it :d
glisse: s/universal/universal law
nh: murphy's law ;)
glisse: yup they must be blind :)
nh: win!
nh: mixture of getting the driver right and fixing a stupid mistake in my test :}
nh: done.
nh: commit is for R3xx only, since I don't have an R5xx
nh: I don't like programming blind
MostAwesomeDude: nh: Ping?
MostAwesomeDude: We do depth writes on r5xx FP, but we don't detect them in the emission the way you rigged it up.
MostAwesomeDude: I'll add the flags and test if you want.
nh: MostAwesomeDude: well, if depth writes work on r5xx, there's no need
MostAwesomeDude: nh: What's the test?
nh: piglit's fragProg1
MostAwesomeDude: Because tri-depth, tri-depth2, tri-depthwrite, and tri-depthwrite2 all don't quite work.
nh: (which is almost the same as glean's fragProg1)
nh: okay, I haven't tested those yet with the new code
MostAwesomeDude: I'm not familiar with piglit. Where do I get it?
stefan1: MostAwesomeDude: google for it. there is a git.
stefan1: git clone git://anongit.freedesktop.org/git/piglit
nh: http://gitweb.freedesktop.org/?p=piglit.git;a=summary
nh: beat me
stefan1: needs cmake, libtiff-devel and libpng-devel
MostAwesomeDude: stefan1: On Gentoo, so got all of 'em. Making now.
stefan1: MostAwesomeDude: Some of the tests fail on r5xx
MostAwesomeDude: stefan1: Well, I shall fix them.
eboettcher: glisse: noted :)
eboettcher: I just woke up so I'll take a look in an hour or so -- no hot water so I'm going off in search of a shower.
nh: MostAwesomeDude: I suspect that if you hook up the flags for r5xx fragprogs, then depth writes should work on r5xx as well - assuming there are no other magic registers
nh: but feel free to change the details of the logic if r5xx needs some other setup to get it to work
MostAwesomeDude: nh: airlied and I already wrote out most of the logic; just need to add a couple flags and it should work.
MostAwesomeDude: XD, piglit massively fails and leaves artifacts on my screen.
MostAwesomeDude: I do wish we could do frag.pos, though.
MostAwesomeDude: Might let us do some of the NV_f_p stuff.
z3ro: MostAwesomeDude: what's required for frag.pos?
z3ro: I know it kinda-sorta works on r3xx, but I guess r5xx is going to be different again.
z3ro: imho the simple tri-pos test isn't good enough to test it. on r300, that works fine, but it will fail when I try to use it for reflections in my engine (lookup into texture)
z3ro: code is correct as it would work on fglrx.
MostAwesomeDude: z3ro: To be honest, I'm not sure; I haven't taken a super-close look.
MostAwesomeDude: I just know that it doesn't work. :#
z3ro: I see
nh: z3ro: have you got a simple standalone testcase for that?
z3ro: nh: no :(
nh: hmm
z3ro: although it should be possible to make one. I'll have a look at it sometime.
nh: that would be nice, we could add it to piglit and get automatic regression tests etc.
z3ro: but I think we should get frag.pos fixed. it's used a lot in newer games for various effects (heat haze, water, mirrors/reflections, etc)
nh: true, true
nh: though *ahem* cubemaps don't seem to be quite working, which is far more embarassing
z3ro: nh: yeah you wouldn't believe how long I spent hacking on a skybox fragprog before I realized that. :P
z3ro: dreams of the day when our drivers run something like ETQW at 90fps and without any visual errors...
z3ro: but I guess that will be some time after moving to gallium
nh: dreams of the day when our drivers run without visual errors
z3ro: that too. ;)
MostAwesomeDude: z3ro: At the very least, we need better memory management before we can have Composite+3D perfect.
nh: true
nh: the question is: when is the right cutoff point to move to gallium?
bridgman: when we have a memory manager and know how to program all the gpus ;)
z3ro: MostAwesomeDude: yeah... although I really don't care about flashy desktop graphics, I do care about 3d games more.
nh: bridgman: I remember the memory manager discussions from back when I started writing the r300 driver :/
nh: that's got to be something like four years
syntropy: heh
bridgman: yep... I find there's a natural order for things... I think once we get 6xx docs out
bridgman: and the kind of driver support you guys did for r5xx, everyone will
MostAwesomeDude: z3ro: I have Composite enabled, and you wouldn't believe how much it interferes with 3D just by being on.
z3ro: nh: so what actually is the big hold up? I'm not really in the loop with memory management, but is it really that complex?
z3ro: hmm
bridgman: pile onto memory management and put it to bed once and for all
MostAwesomeDude: z3ro: No, it's not.
MostAwesomeDude: But we have to move gobs of code over.
nh: exactly
MostAwesomeDude: Many people have been waiting for something like Gallium, which also requires code refactoring.
bridgman: MostAwesomeDude: I would say memory management *is* complex in terms of deciding
nh: somebody has to do it, and it's a scary bit of work
bridgman: what you want to do... the implementing doesn't seem as hard as the design
MostAwesomeDude: Move code to Gallium+DRI2+kernel modesetting all in one go.
nh: to me, memory management seems so scary because it means taking a huge leap of faith and potentially breaking a massive number of systems that I can't test on
z3ro: hmm anyone have any links to papers on gpu memory management? I guess there isn't really much out there.
bridgman: I think so, but you need memory management for KMS *and* for Gallium
MostAwesomeDude: nh: Good work. After fixing stuff up for r5xx, tri-depthwrite and tri-depthwrite2 work.
nh: yay :)
bridgman: Great. Um.. what are tri-depthwrite and tri-depthwrite2 ? Tests ?
MostAwesomeDude: bridgman: Yep. Writing alpha as a depth coordinate from the FP.
syntropy: if I download git kernel sources, can I just download git libdrm and it's kernel stuff and put those files directly into the kernel?
MostAwesomeDude: Also in piglit, shaders/trinity-fp1 appears to pass now.
syntropy: kernel source*
MostAwesomeDude: syntropy: Yeah, in theory, although I don't know many people that do it that way.
z3ro: forgets what trinity-fp1 tests (even though it's my arb prog iirc)
MostAwesomeDude: I guess if you were going to redistribute, that would be the way to go.
bridgman: Ahh, so tri as in triangle not as in three depths ?
syntropy: MostAwesomeDude, how can I integrate it any other way?
MostAwesomeDude: bridgman: Yes. All of the mesa FP tests operate on a simple blended triangle.
MostAwesomeDude: syntropy: Well, you could offer a package with the DRM out-of-kernel.
z3ro: damn gitweb is being slow. =/
MostAwesomeDude: But if you're going to redist an entire kernel, it makes sense to just update the in-kernel DRM to a git version.
syntropy: I mean to include it in a kernel, yeah
syntropy: is there a way to merge the live git drm into a kernel source tree other than manually copying the files?
MostAwesomeDude: Well, you could patch up, if you knew the revision in the kernel.
syntropy: hm
MostAwesomeDude: But many times airlied doesn't submit patches evenly; for example, the kernel had r5xx support before hitting version 1.29, which is not the same way it is in git.
MostAwesomeDude: So it would probably be easier to just replace files.
MostAwesomeDude: (No offense to airlied. :3)
syntropy: okay, thank you
z3ro: MostAwesomeDude: ah trinity-fp1 is basically the main lighting program used in my engine (probably a slightly older version)
z3ro: so thats good it passes. consistant with what I've seen with the newer mesa. :)
glisse: MostAwesomeDude: gallium need a rewritte, i don't see it as moving code
z3ro: glisse: well how stable is gallium right now?
z3ro: last I heard it was still changing quite a lot.
glisse: and memory manager is allmost sorted out i think we reached some kind of agreement
glisse: z3ro: it's still changing a lot
MostAwesomeDude: z3ro: Yeah, I noticed.
glisse: but you have to jump a one point
glisse: got to go bbl
z3ro: ok
MostAwesomeDude: Hmm, fp-kil doesn't work?
MostAwesomeDude: But the card doesn't seem to care that the last instruction is a kil.
bridgman: glisse: what was the agreement ? The issue with GEM and having vram
bridgman: objects always backed up by system memory still seemed to be open...
rx__: too bad glisse ran off :P
bridgman: yeah, pie must be ready
bridgman: the one thing that wasn't clear to me from the GEM spec & discussion was whether
bridgman: IGP was a special case, in the sense that vram = system memory so potentially no
bridgman: need to duplicate IFF the GPU could access all of system memory
bridgman: If it does avoid duplication in an IGP environment that seems to be a sufficiently
bridgman: useful optimization that it's worth trying to keep somehow even if it does
bridgman: have the potential for sucking in a discrete GPU situation
eboettcher: so I have just about zero clue how the memory situation works in the IGP stuff
MostAwesomeDude: Agreed, especially in systems where the GPU can take up to 128 MB of system mem.
MostAwesomeDude: But I need to go do some "real" work now. Later. :3
eboettcher: like this RS480 I have -- 128MiB of gpu memory + it can use 128MB of system memory -- but how does that work?
bridgman: eboettcher: where it gets complicated is that IGP chips can often have dedicated
bridgman: vram attached for higher performance or lower power consumption but most
bridgman: systems don't actually make use of that mechanism (we call it sideport memory)
bridgman: In most cases the GPU in the IGP just runs in system memory, so typically
bridgman: a chunk of memory is set aside for the GPU and driver to use and is marked
bridgman: as unavailable by the OS
eboettcher: bridgman: so then does the GPU treat both memory spaces as a contigious region?
eboettcher: can they be remapped to the GPU or is say the sideport fixed?
bridgman: Ahh, here's where it gets complicated and GART-y. The problem with system
bridgman: memory is that it tends to get fragmented so finding a bug chunk on the fly can
bridgman: be hard. GART lets you allocate a bunch of little bits of system memory and
bridgman: map them into a contiguous chunk for the GPU to access. Normally the GPU
eboettcher: so the UMA memory comes from GART?
bridgman: does not access system memory in general, only the area mapped by the GART
bridgman: UMA is kind of a misnomer. It's more like "un-unified memory which happens to
bridgman: be in the same chips" ;)
bridgman: but yes, the GPU normally accesses two areas of memory -- the contiguous chunk
bridgman: blocked out for GPU at boot time (the "video memory") and a chunk of CPU-accessible
bridgman: memory accessed via the GART
bridgman: I'm pretty sure that ring buffers & indirect buffers (aka DMA buffers) are
bridgman: all in the GART-mapped space and if they're not I'm sure someone will correct
bridgman: me quickly ;)
eboettcher: arg
eboettcher: comsh*t just called me to advertise their phone service
bridgman: do you pay for the call ?
eboettcher: no, otherwise I'd be peeved :P
bridgman: ;)
bridgman: The important thing is to understand how discrete cards & drivers work, then the
bridgman: IGP scenario is basically the same thing except the "video memory" is actually a chunk
bridgman: of system memory which is not available to the OS and is only accessed via the
bridgman: graphics driver if at all
eboettcher: so is there any way to get that sideport memory used? I know my laptop has 128MiB of it
bridgman: the interesting thing (which I suggest you try not to think about for a while ;))
eboettcher: (and to get the drm to allocate memory from there first :)
bridgman: is that there are some potential optimizations you can do if you know that video
bridgman: memory = system memory from a physical pov
bridgman: re: getting sideport memory used, I think so; it's just that the memory controller
bridgman: programming is kind of ugly and I don't think we've dug up all the info on it yet
bridgman: agd5f will know more
bridgman: The thing to bear in mind is that vram on a discrete card has a wide memory bus,
bridgman: sucks power, and is there to make things go fast. The vram on an IGP
bridgman: often has a narrow bus, uses little power, and is there to let the CPU go to sleep
bridgman: while still refreshing the display
bridgman: The best performance comes from splitting the accesses between the vram and
bridgman: system memory, which is the kind of memory management challenge that makes
bridgman: your brain hurt; and is one of the reasons that memory management tends
eboettcher: bridgman: can one interleve pages from both?
bridgman: to get really complicated once you start trying to optimize performance
eboettcher: in a contigious space that is
bridgman: eboettcher: not sure, will ask
bridgman: the problem is that you would probably want some kind of 3:1 interleave
eboettcher: indeed
eboettcher: but I wonder if that would help say with large textures
bridgman: because the system memory is usually quite a bit faster (wider bus) than the vram
bridgman: The interleave would have to be pretty coarse anyways since all the memory
bridgman: accesses have to be long bursts or performance really sucketh
bridgman: tiling is all about mapping graphics access patterns (2d) onto something the
eboettcher: but the GPU isn't the only thing using system memory whereas the sideport memmory is reserved
bridgman: memory technology can handle (long linear bursts)
bridgman: exactly, that's where it starts to become real fun, and dynamic load balancing
bridgman: starts to make a difference... and that's one of the reasons fglrx is about 100x
bridgman: the size of the open source stack ;)
Nyle: 100x?
bridgman: Now start thinking about things like HyperMemory, where we need to run fast in
bridgman: scenarios where we don't have anywhere near enough video memory
bridgman: Nyle: something like that; the open source stack is about 100KLOC and the closed
Nyle: Is there a way to make the video driver be able to use the gpu for regular load balancing tasks to lessent he burden on the cpu, when it is idle?
eboettcher: what is HyperMemory exactly?
bridgman: driver uses maybe 15,000 KLCO
Nyle: seems to me that my x1900xt just wastes itself away if not being used for 3d
bridgman: s/KLCO/KLOC/
bridgman: Nyle: yeah, it gets sad, sorta like pining for the fjords
Nyle: so why are gpu's still sitting idle when they could be working for us?
bridgman: They're smarter than we are
Nyle: its wasted money imo
eboettcher: bridgman: 15 KLOC or 15,000 KLOC?
Nyle: hehe
bridgman: seriously, if you look at a 3450 and 3850 they're pretty much the same
bridgman: chip except for the amount of 3D stuff
bridgman: maybe 170M transistors vs 670M, something like that
eboettcher: Nyle: perhaps as gpgpu picks up, more components of the system will be offloaded there...
bridgman: eboettcher; yep, 15,000 kloc. Total driver stack is about 28M lines
eboettcher: (neural net based image searches anyone?)
Nyle: I mean
eboettcher: bridgman: ALL of the sources on my machine in /usr/src/debug is about 34M
Nyle: gpu are pretty pwoerful processors you know
eboettcher: that's KDE+kernel+the entire GNU toolchain etc
bridgman: eboettcher: yep, welcome to the wonderful world of drivers
bridgman: Making them work doesn't need much code; making them work real fast makes the
bridgman: size go up exponentially
eboettcher: bridgman: I understand that but geez! That's a lot of code!
bridgman: eboettcher: yep, it is a lot of code. It does cover a lot of OSes and APIs though...
eboettcher: oh that reminds me -- because of the fact that any elf binaries installed on my system get their sources put in /usr/src/debug I can insert backtraces in fuctions to see how they're used by end software in general
z3ro: had better get some sleep... iirc I'm working at 10. =/
z3ro: and I haven't slept yet...
z3ro: misses having zopiclone. :(
bridgman: z3ro: yep, turn off the screen ;) Coding without sleep seems OK but working without
bridgman: sleep gets pretty miserable, never sure why
eboettcher: does Apple use the use drm in OS X?
eboettcher: err use the*
z3ro: yeah, especially when dealing with people all day (I'm working a crappy sales job at the moment)
bridgman: Nyle: yep, even a 3450 can do something like 60Gflops single precision
bridgman: if you count MAD as two instructions
bridgman: eboettcher: not sure; haven't really poked about inside quartz that much
eboettcher: bridgman: I've been thinking about getting a couple of those and using them to do fuzzy logic type stuff...
PSYCHO___: z3ro: know what are you talking, some people at work get sick and i had to do techsuppot, complete nightmare (linux/windows/etc...), after 8 hours my mind was like boiled :]
bridgman: yeah, I'm surprised we haven't seen more AI work on GPUs. It seems like a relatively
bridgman: good fit. My guess is that all of the current implementations are event based where
bridgman: you chase each firing neuron through all the paths it's connected to
Nyle: PSYCHO___, yup
Nyle: i know the feeling
bridgman: for a GPU implementation you would want to completely re-implement; evaluate all the
Nyle: but then after 4 years of doing bullshit work you go into management and call it a day
eboettcher: bridgman: well there's one thing I could ask for -- a lock instruction in the shaders
bridgman: neurons, update everything, then do another pass through everything
eboettcher: wait on lock*
z3ro: I'd love to find a nice coding job, but it seems there isn't anything around. :(
z3ro: or it's "we want someone with more experience"
Nyle: coding job? you wanna live hand to mouth?
Nyle: coders don't make nothing no more seriously
Nyle: unless you've been doing it for like 20 years and you are awesome
z3ro: well coding/sys admin/etc
z3ro: something I'd enjoy.
PSYCHO___: Nyle: not really i call shitty day when i have to teach from dawn till dusk, and i hope they let me in my office alone on my projects ;]
z3ro: kind of ironic that I'm RHCE yet I can't find a sysadmin job. =/
PSYCHO___: i dont mind teaching
PSYCHO___: i just hate freshmans
bridgman: z3ro: funny, I was thinking about driving a truck or something to get away
bridgman: from graphics ;)
Nyle: z3ro, I got a very many few certificatos
Nyle: mucho certificatos
PSYCHO___: there is so lot of them and i really dont know how some of them passed throught etering tests
Nyle: It mean not much only skill matters
z3ro: bridgman: yeah I can see the appeal in doing something like that.
Nyle: and its tragic, most people in HR only want to see a degree etc.
eboettcher: Nyle: that's why I'm getting a BS in EE here as soon as I can -- but moving strait on to an ECE masters program
Nyle: its a vicous cycle, you need exp to get a job, but you can't get a job without exp, or interning(which doesn't pay)
Nyle: eboettcher, I never finish college
Nyle: I drop out of high school too
GerbilSoft: that's odd
GerbilSoft: after suspend/resume, GL apps no longer work
GerbilSoft: i merely get a blank window
Nyle: I got GED fromusa and I don't care for school
Nyle: eboettcher, I make lots of money doing my own compure repair and IT consulting business
z3ro: Nyle: I found school kind of pointless too. I mostly ended up teaching myself anything I wanted to know.
Nyle: eboettcher, plus my day job as IT admin of a whole big company in the world pay good money
Nyle: z3ro, I in highschool tell my parents that I need no more school these people can't teach me
Nyle: (i used to read everything and anything, and still do, I love to learn, its a passion)
Nyle: same in college, I took generals, then when it came time to concentratge on my majors I saw how full of shit school and books were about computers
Nyle: I could do that in half the time on my own i can't waste money on school
Nyle: so I just did what I did now I do what I do and I do pretty good :)
Nyle: I'm not the kind of guy who can stand taking orders from a boss so I try to do my own business
eboettcher: bridgman: so is there anything of that sort? (or better yet -- some sort of sleep on lock that could let the shader unit be used for something else 'till the lock is free -- but that would require something to schedule the units locally...)
Nyle: eboettcher, I went however to school to learn what I needed to learn
Nyle: eboettcher, degree in music theory and composition, jazz and classical :D
z3ro: Nyle: well, I disslike taking orders from bosses (yes, current job has more than one. :() but I wouldn't really know how to run my own business.
Nyle: z3ro, street smarts are more important than academics but they are both very important
z3ro: I mean, I could probably figure it out, but I'm not sure I'd want to deal with the mountain of paperwork.
Nyle: every single aspect of life, from little to big, is about sales
Nyle: everything is about sales and marketing, yourself, your product, your skills, whatever
GerbilSoft: wtf gl is still broken
GerbilSoft: i guess this is due to a recent commit
Nyle: so get good at sales dude, learn how to talk to people and market
GerbilSoft: i'll try a bisect later
bridgman: eboettcher: the concept exists already in the sense that we wait for textures
Nyle: if life is about sales, then learn to sell
Nyle: :)
bridgman: and roll the threads out if textures aren't available; not sure how to make
Nyle: but this is just my opinoin, you guys obvious if didn't go to school probably wouldn't have coded a driver :D
Nyle: so school is good, just not for me
Nyle: stay in school and finish your degrees
bridgman: locks work well because you really want all the ALUs running in lock step
z3ro: I'll be leaving this job soon anyway. going overseas, and probably do some more courses when I get back.
bridgman: as much as possible, eg on a 38xx we have 16 pixels being processed at a time
bridgman: on a SIMD block, and you want all 16 doing the same thing as much as possible
eboettcher: bridgman: that's why I mentioned the sleep lock thing with the local scheduler -- then each node could simply be a different context that gets run when fired (IE: lock becomes available when fired)
z3ro: I got accepted for an organic chem course, but it's the same time as I'm going overseas. :(
Nyle: z3ro, whatever you do, do it honestly and do a good job. thats all
z3ro: so I hope there is another one in a few months time or something.
Nyle: money != success
bridgman: Even with flow control, if 15 pixels take a branch and 1 does not, the SIMD still has
Nyle: just to let you know :)
bridgman: to run all 16 pixels through the intervening code, it just masks off writes on the
bridgman: 15 pixels that took the branch
mcgreg: z3ro: you are studying chemistry?
Nyle: leading a successful ife and being rich or wealthy are completely diff things but thats just my opinoin z3ro
bridgman: kind of implies that locks would have to be global-ish as well
Nyle: anyway i think we are being very offtopic
z3ro: mcgreg: no, just another thing I'm interested in.
z3ro: mcgreg: or rather, not yet.
Nyle: z3ro, I join #music to chat about whatever/misc things/offtopic you can talk there with me
Nyle: if you want
eboettcher: bridgman: I really think that a cpu that is dedicated to accelerating neural nets would be a wonderful coprocessor if one could find a nice way to do it :/
bridgman: z3ro: the downside of being interested in lots of things is that you kinda have to
eboettcher: soo many things one could do (like fast image searches)
bridgman: shut most of them off in order to focus on one thing enough to make a living from it
bridgman: ... but the upside is that sometimes you get lucky and see opportunities in areas
bridgman: which cut across a bunch of areas where nobody else can see across them all
bridgman: ... but of course then the sales aspect comes in because nobody else will understand
bridgman: your good idea ;)
z3ro: yeah. I think I get interested in too many things. which is both good and bad.
eboettcher: bridgman: actually a 'neural net' ASIC would be my senior year project if I could get away with it :P
z3ro: eboettcher: heh another thing I've been meaning to get into for ages: fpgas.
eboettcher: z3ro: that's why I'm getting a BS in EE
bridgman: z3ro: looking back, I think the smart thing would have been to make a bunch of
bridgman: money first then be able to spend the rest of my life being interested in lots of things ;)
eboettcher: if nothing else I can get access(perhaps funding) to get a prototype of something much cheaper than if I were not a student
bridgman: eboettcher: check around and see if anything is being done with neural nets on GPUs
bridgman: and maybe give that a try; the shader cores certainly are not optimized for neural
z3ro: bridgman: yeah. I don't see the point of working hard until you retire, but then being too old to do things you wanted to do.
eboettcher: bridgman: well that waits -- for now I have gsoc to focus on
bridgman: net programming but they're so honkin' fast that you don't need to be totally
z3ro: of course, it isn't easy to make a lot of money so you don't have to work much.
bridgman: optimized anyways
z3ro: shrugs.
bridgman: z3ro: there are lots of jobs that pay well if you're smart; they just tend not to be
bridgman: in the areas you would get into out of curiosity. Law is the classic place where smart
bridgman: people make lots of $$$, for example, although exotic finance is getting up there
bridgman: as well (and exotic finance is primarily a computer game)
bridgman: I just have less confidence that the finance market will last, but by the same
bridgman: token the entry barrier is a lot lower if you're already seriously into computers
bridgman: z3ro: sleep ;)
bridgman: bbl
z3ro: I don't think I could find the motivation to to finance. it seems really boring, even with the prospect of lots of cash. :P
z3ro: but yeah I should at least try to get an hour of sleep...
z3ro: bbl
mcgreg: with the very current mesa git google earth work totally broken
adamk: It was fine as of Friday afternoon... I haven't tested it with anything newer.
mcgreg: http://mcgreg.dyndns.org/files/googleaerth-shot.png have a look
mcgreg: but now it is super fast ... ;)
mcgreg: the textures come and go by chance
mcgreg: http://mcgreg.dyndns.org/files/googleearth-shot2.png
GerbilSoft: with current mesa pretty much everything's broken for me
GerbilSoft: gears, neverball (though the HUD and menus work)
GerbilSoft: doing bisecting
GerbilSoft: ok, the problem is caused by "r5xx: Enable depth write emision."
GerbilSoft: it's a missing set of braces
GerbilSoft: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=915e49e0fd61d7b8eee304d756813455612e98d9;hp=c9ea62444c6969da8706ea88e12df8c458a6acce
GerbilSoft: r500_fragproc.c - there's a missing set of braces in the if block: if (fpi->DstReg.Index == FRAG_RESULT_DEPR)
airlied: GerbilSoft: thanks...
airlied: smacks MostAwesomeDude in absentia.
mcgreg: be nice too him, he's doing a good job ;)
airlied: mcgreg: hehe..
airlied: okay should be fixed.
Zajec: is there any chance to get valgrind rebased to glibc 2.8?
mcgreg: ahh glxgears works again :)
mcgreg: googleerth is still broken though :)
syntropy: any progress on r300 3d suport?
syntropy: support*
nh: fixed some bugs today
nh: anything particular you have in mind?
syntropy: not really, i'm figuring if I switch to 2.6.26 git, then i will have to drop fglrx anyway, so i'm wondering if there have been any major changes
airlied: syntropy: you don't need a kernel uprade for r300 eD.
airlied: 3D..
GerbilSoft: you're welcome
syntropy: yeah, but I have other reasons for upgrading my kernel, and i'm plaaning to put in newest git drm
nh: syntropy: oddly enough, I can't really say much about apps and stuff, because I'm looking at abstract tests most of the time
mcgreg: just tested quake3, which actually was okay...
nh: syntropy: the worst thing about r300 3D is broken cubemaps, and then of course the usual random assortment of broken less-traveled (i.e. non-quake) paths
airlied: nh: good to see you back :), nice work on the depthwrite..
syntropy: mcgreg, on r300? when i tried q3 the 2D hud and console worked,, but 3d was horribly borked
mcgreg: syntropy: r500
mcgreg: works very fine
mcgreg: the quality is like fglrx even, just the speed doesnt match it yet
syntropy: r300 is still broken for me, but i haven't tried in awhile
syntropy: i'm on the RS480 chipset
Zajec: syntropy: did you even connected sth to VGA-0?
nh: guess I should give openarena a try some time
syntropy: Zajec, everything except 3D worked, aside for a few small screen corruption glitches
Zajec: syntropy: i'm interesed if xrandr and detecting EDID data (info about monitor) works for you
nh: airlied: don't put your hopes up too high, though; who knows when school will strike back with loads of work...
syntropy: Zajec, it didn't. I had to do some jiffying to get proper 1024x768@32
Zajec: detecting optimal resolution, clculating modelines, etc.
nh: unfortunately, the relationship between my sparetime and my involvement in OSS is highly non-linear
Zajec: ok, thanks for info
syntropy: nh, same here
airlied: syntropy: wierd.. latest mesa code?
airlied: rs480 isn't supported very well with older mesa..
syntropy: -9999 by ebuiild
syntropy: ebuild*
syntropy: it was a few weeks' ago pull though
airlied: rs480 should be fine for most things, its like rs690, but I haven't played many games on it.
airlied: but it does use different codepaths to r300..
syntropy: once my kernel sources are ready, I will recompile it as necessary and upgrade mesa and such
airlied: nh: btw we have R300_NO_TCL=1 now, which runs like rs480/rs690..
nh: http://people.freedesktop.org/~nh/piglit/r300/index.html
airlied: it might be worth running piglit against that as wel.l.
nh: ah, that's a good idea
nh: mmh, various tests fail due to stencil buffer problems on r300
mcgreg: hmm just running .. the test Test: glean/blendFunc seems to be extra ordinary long though
mcgreg: from time to time the screen goes all black
nh: mcgreg: indeed it is; same goes for texCombine
nh: the screen going all black is because glean goes through all visuals, including fullscreen combinations
nh: but then it doesn't always swap the buffers, so you don't actually see what it's doing
nh: if the tests take too long for you, you can always create your own test profile, where you give glean a parameter like --visuals id==
nh: openarena looks fine to me from where I'm standing
nh: re piglit: the idea is that the tests should be exhaustive, but automatic; so you just start the tests, go take a walk in the huge room with the extraordinarily good graphics driver, then come back to collect the results and see if there are any regressions
mcgreg: any cares what reault I got from piglit on my r500 (rv515)hardware
nh: mcgreg: some kind of test result library would be cool
nh: for the time being, if you just mail them to me (nhaehnle@gmail.com) I'll put them up on my website where the other results are
nh: (not today anymore though, I'm off to bed rsn)
mcgreg: I'll mail you the results
adamk: airlied, You around? I'm trying to get the r500 stuff working on FreeBSD. drm/mesa/ati all compile and work using X server 1.4.0 from the FreeBSD ports tree. 3D acceleration works, but AIGLX doesn't since the X server isn't new enough.
adamk: airlied, If I update the xserver to the latest from git, I get similar problems to what I experienced on Linux with my AGP card before your fix on Friday. Mind you, I'm now using a PCIe card.
airlied: adamk: I'm here now but might disappear.
adamk: The X server never fully starts, and maxes my CPUs at 100%
airlied: adamk: hmm wierd thats a GPU lockup ..
airlied: adamk: they all look the same ..
adamk: Heh. Gotcha.
airlied: no idea why a new server might cause it though.
adamk: Well, if this tells you anything, here's the dmesg with debugging enabled:
adamk: http://pastebin.ca/1036190
airlied: are you using EXA or anything?
adamk: Yes, EXA.
airlied: adamk: try turning off render accel maybe..
airlied: option "renderaccel" " false"
adamk: I talked with rnoland since he's the FreeBSD guy, but he thought that someone with ATI knowledge might have a better idea of what's going on.
adamk: I'll give it a shot.
airlied: though its wierd the writeback test fails.
airlied: maybe ati_pcicgart.c needs updating
airlied: I think there is a BSD version of that.
mcgreg: nh: you're still there?
adamk: There is. There were issues with PCIe cards for the longest time on FreeBSD till someone (perhaps rnoland) fixed ati_pcigart.c... I've tested both my PCIe x1650 and x850 and get the same GPU lockup.
airlied: sounds like it needs more fixing.
adamk: Well, at least that's a starting point.
nh: mcgreg: ?
adamk: And disabling RenderAccel doesn't help.
airlied: adamk: the writeback fail points at the gart code.
mcgreg: nh: what results actually do you want? there is a file in results/all .. but it is 45MB large
mcgreg: or just the plain text output from the tool?
nh: ugh
adamk: airlied, Alright, I'll bring this up with the FreeBSD folks then. It's just odd that it works in X server 1.4.0 but not git. Maybe I can find the point at which it breaks.
nh: never mind then; we'll have to work on getting reduced reports (the 45MB may be useful when debugging stuff, but like that... no)
mcgreg: okay :)
glisse: bridgman: for backlog reading :) i think the outcome is that we map vram and always have a backing store but backing store doesn't mean you have to waste memory page allocation can be deffered at latter point
glisse: adamk: sounds somethings libpci related
glisse: anyway now zzzZZZZzzz :)
bridgman: nuts, glisse got away again ;)
bridgman: anyways thanks thats a good clue; will go re-read the GEM spec in that light
mcgreg: damn timezones, huh? ;)
bridgman: once I'm done reading tcore rc8
bridgman: agd5f: ping
eboettcher: bridgman: rc8? any estimates on when that last revision pops out?
mcgreg: good night
bridgman: it has to be close, I'm getting sick of reviewing it ;)
bridgman: found about a dozen issues so far, nothing hard to fix/check
eboettcher: bridgman: so is it a matter of revision at this point then? no redacting or anything like that needed?
bridgman: yep... so far it looks like this will be the last cover-to-cover review
eboettcher: well for the moment I take a break... I have $20 given to me to get dinner
bridgman: eboettcher; sounds good, I'm down to one slice of bread, have to make more ;(
eboettcher: bridgman: that sucks, I'd send you some bread if it wern't so far...
eboettcher: A friend of mine works at Panera bread, he gave me a 55lb bag of bread last night!
rx__: make fresh bread?
eboettcher: and I order pizza rather than buying milk, fruit, etc...
bridgman: rx: yeah, you have to do something like that when you live out in the sticks...
bridgman: I even have a sourdough starter going in the fridge
bridgman: shopping is basically vegetables, hunks of meat for the smoker, and big bags of flour ;0
bridgman: although it's getting increasingly hard to find big hunks of meat; heck, now
bridgman: I even have to shop around to find full racks of ribs that haven't already been cooked ;(
bridgman: used to be easy to buy unpopular cuts of meat for cheap, but seem to be all gone
bridgman: guess they go into some kind of upscale processed food now (or Alpo ;))
eboettcher: hmm.. I have a guy in #xorg asking about gl without X
eboettcher: I know there's something out there, but I can't remember names
eboettcher: bridgman: Alpo?
michaellarabel: eboettcher: Alpo is dog food
eboettcher: oh :P
bridgman: eboettcher: there's miniGLX, and various EGL implementations which are basically
bridgman: mesa and drm without X; once you have mesa and drm, you just need something to
bridgman: say "here's the window" and allocate memory etc...
bridgman: of course if modesetting and memory management get into the kernel this becoems
bridgman: s/becoems/becomes/
bridgman: even easier
michaellarabel: It's now going on like 7 hours of running universe-cli on VIA...
michaellarabel: oops, wrong IRC window...
bridgman: oh good, 'cause that meant nothing to me ;)
dmb: bridgman, is there any program itself that makes use of that?
bridgman: dmb: if you mean gl without x, it's pretty common in embedded applications
bridgman: but don't think I've seen it anywhere else
dmb: oh
bridgman: if you mean Alpo, no
dmb: i'm sure we might see them in the future once modesetting is in
dmb: maybe there will be a rise of non-x window managers :P
dmb: actually, that could be cool for things like mythtv
dmb: no need for x with mythtv
bridgman: yep; the only awkward thing is that Xv and XvMC are still X server APIs
bridgman: and the funny thing is that once we have kernel modesetting one of the big
bridgman: worries about x goes away because running X in user mode will suddenly be possible
dmb: yes
bridgman: so my prediction for what will replace X is... hmmmm... X ;)
dmb: that will be great
airlied: now we just need some magic to make it work...
dmb: airlied, your the magic :P
bridgman: yeah, I was just in the process of linking to airlied's blog ;)
airlied: dmb: I need more magic :), modesetting core finishes this week ...
bridgman: but I am on the aforementioned dial-up and so still waiting for the page to load
dmb: airlied, and glisse is working on the modesetting stuff for radeon?
airlied: dmb: hopefully..
airlied: dmb: its on my list next..
airlied: after I finished the !radeon bits.
bridgman: http://airlied.livejournal.com/59521.html
GerbilSoft: how many visuals is xdpyinfo / glxinfo supposed to be reporting with mesa on an RV530?
GerbilSoft: on my laptop with a FireGL V5200 it's reporting 0x21, 0x22, and 0x86
GerbilSoft: on another system with the nvidia binary driver it's showing at least 40 different visuals
airlied: GerbilSoft: we cut down the visual list to a useful set..
airlied: GerbilSoft: and use fbconfigs no in theory.
GerbilSoft: ok that makes sense
GerbilSoft: thanks
MostAwesomeDude: airlied: Oooops.
MostAwesomeDude: I'm too used to Python. No need for braces.
sickPups: im not going to find any randy birds in here am i?
sickPups: hey!
bridgman: sickPups: I doubt it
sickPups: i know
sickPups: horny girls prefer nvidea
sickPups: i gots a question though
MostAwesomeDude: ...
airlied: sickPups: too bad...
MostAwesomeDude: sickPups: Go ahead.
MostAwesomeDude: Wow, b& with burn.
airlied: I didn't have time to find the xkcd cartoon.
MostAwesomeDude: airlied: Understandable.
MostAwesomeDude: Ack, my nemesis. What are you doing here?
GerbilSoft: rofl.
airlied: http://xkcd.com/322/
airlied: is the one I was looking for.
spstarr: scratches head
bridgman: ... although in general I think we are trying to more of that work ourselves
MostAwesomeDude: bridgman: Wait, what are we talking about again?
bridgman: wrong window
bridgman: horny girls and nvidia
MostAwesomeDude: Ah.
MostAwesomeDude: Of course.
Saist: ... figures
Saist: I look back in the channel and the only thing that catches my eyes is bridgman's line about horny girls and nvidia
Saist: reads up...
Saist: ... ... I did not really want to read that.
Saist: um. anyways. trying to have a serious question : bridgman, I remember that there was some talk about specifications on AIW cards a while back.... have there been any changes on the chances of releasing AIW specifications? Or are the chances still "cold day in hades-ish"
bridgman: Saist: I was quoting sickPups ;)
Saist: yeah, I noticed when I read up. I'm guessing he was just a troll out for trouble.
bridgman: Anyways, for older AIW boards using the Theater and T200 it's possible if we can
GerbilSoft: aren't older AIW boards already supported via GATOS?
bridgman: keep the DRM bits in the Theater chips hidden. We don't make the tuners so that info
bridgman: will have to come from third parties anyways
bridgman: GerbilSoft: probably, not sure how far back/forward that goes though...
GerbilSoft: i've got an AIW 8500DV that i could test if needed
GerbilSoft: no breakout box though :(
Saist: ai. I've got 3 AIW cards that are still operational (8500, 7500, and a PCI that I think is the 7000 chip)
Saist: I haven't had any ... successful... luck with video input... although video output works great on the TV-out
airlied: wierd we should have some of input stuff, it should detefct the tuner chips and stuff.
Saist: airlied : I'll shove Fedora 9 onto the system with the 8500 and check the input then.
agd5f: current radeon supports theatre and theatre 200 via Xv, not v4l
spstarr: 7500 = r2xx
GerbilSoft: spstarr: though it's called rv200 it's actually R100-class
airlied: spstarr: nope is rv200 not r2xx
spstarr: rv :)
spstarr: i dont understand what the 'v' is
GerbilSoft: i've got one on my old desktop
Saist: ai, a higher clocked version of the original Radeon GPU if memory serves
GerbilSoft: there's a nice bug with the second RAMDAC that caues the second VGA out to be horribly fuzzy
spstarr: i watch tv in Fedora 9 with my Radeon AiW 7500
Saist: spstarr : that gives me some hope then :)
spstarr: avview from GATOS project lets me watch cable tv
spstarr: i have a patch to make it work with tcl/tk 8.5
GerbilSoft: question: is it possible on an RV530 to output component video via the VGA port? (using a simple pass-through adapter to convert the DE15 to 3 RCA)
airlied: GerbilSoft: should be. you'd have to write some code I think to do it..
GerbilSoft: ok
GerbilSoft: i'll take a look through the M56 docs to see what sort of mode setting is needed
GerbilSoft: i don't have a component video display available right now, but my CRT supports sync-on-green so i can tell if it's working
airlied: not 100% sure if atombios lets you do it , it might be possilbe to just the sync type.
GerbilSoft: closest i can find is DACA_WHITE_LEVEL and TMDSA_PIXEL_ENCODING
GerbilSoft: the latter won't help for VGA
GerbilSoft: still looking
airlied: I would guess its only disabling composite sync
airlied: and setting a mode... but I might be right off..
GerbilSoft: what would be the correct tool to set a register
airlied: you may need to play with TV stuff..
airlied: which isn't probably documented so well yet..
airlied: it might be easier to see if you can just change the atombios calls.
airlied: agd5f might know a lot more..
GerbilSoft: is there some sort of utility available that i could use to manipulate the registers directly
GerbilSoft: atombios might be useful but i'm going to try register manipulation right now
airlied: GerbilSoft: use avivotool..
GerbilSoft: i guess i'll have to edit it to add these regs
GerbilSoft: ok then
airlied: GerbilSoft: its on the avivo branch of git://git.freedesktop.org/~airlied/radeontool
GerbilSoft: oh, i was using the old old avivotool
airlied: GerbilSoft: its on the avivo branch of git://people.freedesktop.org/~airlied/radeontool
GerbilSoft: i'll try that one then
GerbilSoft: ok that register definitely wasn't it
GerbilSoft: it caused the image to wash out
GerbilSoft: resetting it to 0x02 (VGA) fixed it though
GerbilSoft: looks like YPbPr is missing from the docs. oh well
airlied: GerbilSoft: aren't the YPbPr levels different?
airlied: so it would change the image..
GerbilSoft: oh yeah
GerbilSoft: NTSC has a black level of 7.5 IRE
GerbilSoft: so that's what that register is for
GerbilSoft: it doesn't change signalling to YPbPr though
airlied: GerbilSoft: yeah I think you need some of the TV regs..
GerbilSoft: ok
airlied: you probably need to enable tv on the output and configure those.
GerbilSoft: so here's to waiting :D
airlied: but I'm not sure if they are in any of the docs yet..
GerbilSoft: i don't actually have any component video monitors so it doesn't really help me right now
airlied: ask agd5f if they are...
GerbilSoft: on the other hand, i have plenty of devices that output component video :(