dmb: hello MostAwesomeDude
MostAwesomeDude: Hey, who had the tree with the WIP skellie Radeon driver for Gallium?
airlied: MostAwesomeDude: glisse.
airlied: agd5f: good point.. I'll try and remember :)
MostAwesomeDude: ...Of course.
MostAwesomeDude: Hmm.
MostAwesomeDude: Coupling radeon/r300 directly to winsys seems just a bit weird.
MostAwesomeDude: But then again, I know nothing.
MostAwesomeDude: Not to mention that writing brand-new code is hard, and I am probably not a good person to tap for the task "Write a bunch of new code for a brand-new interface describing a piece of hardware that you've been acquainted with for less than two months."
airlied: MostAwesomeDude: what do you mean coupling directly to winsysS?
airlied: MostAwesomeDude: I don't know glisse gallium code at all.
MostAwesomeDude: airlied: glisse's gallium stuff is built on radeon DRI, if I'm parsing it right.
MostAwesomeDude: It's like...well, I'm not sure what it's like.
airlied: MostAwesomeDude: not sure I can see his gallium code in his tree :)
airlied: MostAwesomeDude: its in the radeonms branch
glisse: MostAwesomeDude: i think i only pushed the winsys at the time
glisse: MostAwesomeDude: there is example of one the 3d test at http://people.freedesktop.org/~glisse/ somethings called 3d demi
glisse: i have done quite a lot of experiment on how to submit 3d cmd stream
glisse: anyway the real 3d driver is yet to be written but i have some idea on design flaw to avoid
MostAwesomeDude: glisse: Design flaw #1: Letting Corbin write it.
MostAwesomeDude: ...Back to bed.
glisse: good night
stefan1: Hmm git changes from the future :-)
onox: is this the channel for questions related to drm (1.1.0)?
elbeardmorez: agd5f: if you're there?.. ..regarding the issue have with my secondary radeon agp card not being posted when set as secondary.. ...I tried to bisect git but ended up having to revert back to an older xserver version (and all the woes that came with) as HEAD~380 ish wouldn't compile. Then I couldn't even get back to my old 'working' state... ..untill I tried reverting kernel to 2.6.22.5...
elbeardmorez: .....which worked. So the problem lies within drm modules right?? Well i'm trying to bisect drm git now but am struggling. I can't get older revisions to compile.. ..can you suggest where I go from here please??
onox: the kernel says it needs lockdep annotation
elbeardmorez: ..hold on.. i've gone too far back.. ..i'll be back.
adamk: Any thoughts as to why glxinfo gives me "disabling 3D acceleration" but shows that direct rendering is enabled anyway?
glisse: hooorayyy lockup free world :)
glisse: airlied, agd5f: to tell the true there is still a lockup but ssh in and kill the app give you back a workable X :)
glisse: so i will let you track down where in the kernel the app is spinning around while gpu is still functional
glisse: also i needed to brack blit with isync otherwise hard lockup
glisse: i guess we need to avoid bus contention btw 3d & 2d engine
glisse: i will push my tree latter as i am not near my key
AlexStacey__: Hi, I'm trying to set up my Radeon X1200 Series to display 1680x1050 and not having much luck. I haven't installed any drivers other than the ones that came with Gutsy. Can anyone offer any advice on what I should be doing? Thanks =]
glisse: AlexStacey__: try xrandr 1.2 tutorial on the net
glisse: AlexStacey__: also pastebin your Xorg.log
AlexStacey__: glisse: ok, thanks. Will do that now
AlexStacey__: http://pastebin.com/m45e9fbec
AlexStacey__: i'm wondering if perhaps my card is not compatible with this resolution
AlexStacey__: i've even edited xorg.conf so it only has one display mode in it but i'm still getting a list that doesn't contain that resolution
AlexStacey__: is lost
glisse: AlexStacey__: for some reason you are using the vesa drier
glisse: edit xorg.conf
glisse: i guess you are ubuntu ?
glisse: with the stupid failsafe things
mcgreg: glisse: so I read you almost fixed the lock ups?
nh_: glisse: I'm going to upgrade to 2.6.26-rc and check if that fixes the mysterious bug I'm seeing
glisse: mcgreg: well the things is complexe at least here i can log in and kill app and get back usable X
glisse: nh_: well as airlied said this is likely the gpu which is not yet flush
mcgreg: better than rebooting, indeed
glisse: nh_: my lockup work should change that
mcgreg: well, fixing the lock ups would be the next major step I think :)
nh_: glisse: so I might try your lockup fixes as well...
glisse: nh_: it's not pushed anywhere
glisse: i will push it in few hour
glisse: i don't have my key with me
nh_: that would be nice
mcgreg: yeah
mcgreg: I'll tets them as soon as possible then
dmb: adamk, yeh, in driconf, or your driconf files, you disabled 3d acceleration
adamk: dmb, D'oh. Thanks. That's simple enough.
dmb: :P
dmb: glisse, what other kind of fixes did you add recently?
glisse: dmb: well it's mostly for r34xx
glisse: r5xx is a lot more stable
dmb: oh
dmb: ok
nh_: okay
nh_: this is really
nh_: really
nh_: creepy
nh_: I compiled software-rendering Mesa, and glean/texCube fails with the same failure mode using stand-alone Mesa, but *only* on my r300 test system and not on this intel-based laptop
nh_: how the heck can that be?
glisse: nh_: does a sleep help ?
nh_: glisse: it does
glisse: so cpu cache get in the way ?
glisse: it could also be gcc instruction reordering
glisse: try compiling test with all optimization disable
glisse: got to go bbl
xnguard: nh_: Using the same compiler for both?
nh_: xnguard: yes; in fact, I'm just building everything on one machine and then using rsync to mirror stuff to the test machine
MostAwesomeDude: nh_: That's just weird.
nh_: okay, so I've rebuilt everything with optimizations disabled, and the bug remains
xnguard: nh_: Soo... what two architectures are you building for?
MostAwesomeDude: nh_: Could you test using the vesa driver, and not the accelerated X drivers?
nh_: hmm? one's an Intel Core Duo, the other (where it's broken) is an Athlon XP; I'm not giving gcc any architecture flags
nh_: MostAwesomeDude: I will; I really don't understand how that could make a difference, but who knows
MostAwesomeDude: nh_: You're still loading DRM?
MostAwesomeDude: xlib calls still have to go through the driver...
nh_: okay, it works with the vesa driver
nh_: does stand-alone mesa use xlib calls for everything, or does it render to an offscreen surface and then blit that onscreen on glXSwapBuffers?
nh_: okay, it can go through the driver
nh_: hmm... I wonder if I'm reading that code correctly
nh_: okay, the code definitely does go through the driver for reading and writing
nh_: that makes the failure at least a little more believable
MostAwesomeDude: nh_: Right. I think it's something to do with radeon, and not Mesa.
nh_: okay, the bug depends on the coordinates of the pixels I'm reading
nh_: this has got to be the weirdest fscking bug I've ever seen
nh_: I'm going to write a routine to test which coordinates are good
xnguard: Just out of curiosity, is there enough related work going on in git that I, as a present R423 user, should be recompiling from git now and again?
MostAwesomeDude: xnguard: Prolly not.
MostAwesomeDude: If it works for you, I'd just stay there.
xnguard: That's sort of what I thought. Most of the work's going on in the R5xx code, right?
MostAwesomeDude: There's not really a lot planned for 7.1 that's not already in the tree.
MostAwesomeDude: xnguard: Sorta. Some of the stuff we fix affects all cards, like AF, but the core functionality's not going to change.
xnguard: nods.
xnguard: I'm already on the git driver, and I've been recompiling about once a week since I moved to it about a month ago. I take it I should just wait to hear someone say that AA or AF has been fixed/improved before I pull again... ?
MostAwesomeDude: xnguard: Yeah. Actually, at onestone's request, I'm looking into fogcoord right now.
MostAwesomeDude: nh_ is fixing some texcube errata that I don't really understand, and I'm not sure what glisse is doing.
MostAwesomeDude: But I'd say that the big work is done, unless somebody comes up with a bug that blocks everything.
xnguard: *nods* 'kay.
MostAwesomeDude: Okay, so fog_coord is about setting fog depth per-vertex instead of per-fragment?
MostAwesomeDude: But also not using the standard fog regs?
nh_: I'm happy to report that a workaround to that weird bug has been committed to Mesa
nh_: so glean/texCube works correctly now for me
nh_: it wasn't actually a bug in cubemapping, mind you, but a subtle bug in glReadPixels
nh_: the DDX still has the bug atm
MostAwesomeDude: XD
MostAwesomeDude: That's hilarious?
nh_: MostAwesomeDude: I really don't know much about fog, but it looks like it
nh_: hilarious... well.
nh_: was cursing a significant amount of the time
nh_: but then again, I learned some lessons as well
MostAwesomeDude: nh_: New applications for old curses?
nh_: or old applications for ncurses ;)
MostAwesomeDude: XD
nh_: hmmm... did Germany win a soccer game?
nh_: people are honking a lot outside
GerbilSoft: yes
GerbilSoft: germany 2, poland 0
arekm: and the guy who did 2 shots for de wanted to play in pl team
arekm: but pl decision makers didn't use brain at that time ;)
osiris_: :(
MostAwesomeDude: osiris_: ?
osiris_: i'm polish
MostAwesomeDude: Oooh.
arekm: it's one success and one failure per day
osiris_: arekm: yeah, Robert Kubica saved the day
arekm: so it's 0, like nothing happened today ;-)
PSYCHO___: what could cause this:
PSYCHO___: File r300_render.c function r300Fallback line 451
PSYCHO___: Software fallback:ctx->RenderMode != GL_RENDER
PSYCHO___: ?
MostAwesomeDude: PSYCHO___: TBH I don't know.
PSYCHO___: ok nm game is playable
MostAwesomeDude: I think that's one of the low-impact fallbacks, but I'm not sure.
MostAwesomeDude: Okay, nevermind.
MostAwesomeDude: Looks like fog coord is about specifying a custom number to replace the depth in fog calculations.
MostAwesomeDude: And it can be done per-vertex.
MostAwesomeDude: agd5f: Ping?
MostAwesomeDude: agd5f: Wondering about fog_coord. Specifically, whether or not you guys need to tack on a fragprog extra in order to write correct depth coords.
TobiasTheCommie: just wondering, the gl support in the ati driver, is it gl2 or gl1.2(or something else)?
TobiasTheCommie: what is the support right now
MostAwesomeDude: TobiasTheCommie: Technically, OGL 1.3.
lupine_85: isn't it gl2 -(a few bits that nobody uses)?
TobiasTheCommie: ah, oki, thanks
MostAwesomeDude: lupine_85: GLSL is the main feature of OGL 2.0, and we don't support it.
MostAwesomeDude: And technically, we advertise 1.3, so that's what we are.
GerbilSoft: what's the difference between GLSL and GL_ARB_fragment_program?
MostAwesomeDude: GerbilSoft: Plenty. GLSL is a high-level language that spans both vertex and fragment programming.
GerbilSoft: ah
MostAwesomeDude: Needs a high-level parser, and has advanced chip requirements like flow control.
GerbilSoft: i don't really know that much about OpenGL yet
GerbilSoft: k
MostAwesomeDude: Mesa supports it, but the r300 DRI driver doesn't.
GerbilSoft: any approximate date on GLSL support in r300?
GerbilSoft: like what has to be done to get it in
MostAwesomeDude: GerbilSoft: Don't know. Prolly not until Gallium.
GerbilSoft: k
GerbilSoft: that's a long way off :(
MostAwesomeDude: For starters, r300 shaders can't do it.
MostAwesomeDude: Only R500+ shaders can do GLSL.
GerbilSoft: i've got an RV530
GerbilSoft: http://www.ticalc.org/archives/files/fileinfo/361/36173.html wtf
GerbilSoft: someone wrote an OpenGL implementation for the TI-89
MostAwesomeDude: Yep.
lupine_85: hahaha
legume: I just tried mesa/progs/demos/gearbox on my RV539 and see low fps. Is this software fallbacks or a problem?
legume: it's 25 fps with vesa+swrast, 11fps radeon and 1000 fps fglrx.
MostAwesomeDude: legume: Yeah, I'm only getting ~40 FPS.
legume: OK it's not just me then RV530 not 539
legume: None of the three drivers seem to get it right - I assume the top left box is supposed to have something drawn.
legume: swrast is black and the other two are junk.
MostAwesomeDude: legume: I get the box drawing correctly.
legume: the main box is OK - I should have written the top left square not box.
MostAwesomeDude: Yeah, that's what I get, too.
MostAwesomeDude: Okay, so it looks like, from arb_f_p, the "correct" thing to do is pass fogcoord as a stuffed texture into the fragment program, and then tell the fragment program to do fog at the very end of the program?
MostAwesomeDude: agd5f? bridgman? Any thoughts?
bridgman: MostAwesomeDude: I didn't really work through all the details of fog; there were
MostAwesomeDude: ?
bridgman: a couple of "fog settings" and fog used to be easy so I didn't go any further ;)
bridgman: MostAwesomeDude: just dialed in and reading backlog from a couple of hours ago
MostAwesomeDude: Ah.
MostAwesomeDude: Yeah. onestone from opencompositing wanted fog_coord and I wasn't doing anything else.
MostAwesomeDude: But we have basically two scenarios.
MostAwesomeDude: First scenario, we need to pass arbitrary depth values (the fog coords) to the fog system in order to let the hardware do its thing.
MostAwesomeDude: Second scenario, we need to respect fog options in the FP and correctly obtain fog, either as a param (fog coords) or from the RS (depth).
bridgman: maybe a dumb question, but I'm not parsing "fog coords". I was kinda still thinking
bridgman: fog was processed by the render backend by doing a depth-driven blend of fp
MostAwesomeDude: fog coord is just an arbitrary number passed in from userspace. It can be changed per-vertex.
bridgman: output (or default colour) and the fog coloru
bridgman: Is that what they call scalar fog ? 5xx manual talks about it going in alpha
bridgman: channel of one of the colours
bridgman: ref p69
MostAwesomeDude: But yeah, right now we just let the HW do its thing.
MostAwesomeDude: Interestingly, it looks like the fog HW still does the fog step even if we have an FP.
bridgman: sorry, light just came on. "onestone wanted fog_coord", so it must mean something ;)
bridgman: That was what I assumed; fog processing happened after fp...
MostAwesomeDude: Basically, it's for doing any kind of fog that doesn't depend on depth.
bridgman: (in my best Bruce Willis voice) fog does depend on depth. I like fog, leave it the hell alone
MostAwesomeDude: bridgman: Watching Die Hard too?
bridgman: Last Boy Scout
MostAwesomeDude: :3
MostAwesomeDude: Yeah, fog is "supposed" to be subsumed by FP.
MostAwesomeDude: But we're not quite doing that. Whatever.
bridgman: ? I didn't think fog was supposed to be subsumed by FP, unless for this fog_coord thingy ;)
RTFM_FTW: implementing per fragment fog support for GL_ARB_fragment_program in the driver?
MostAwesomeDude: bridgman: Nope, tex and fog are replaced by FP if it's available.
MostAwesomeDude: RTFM_FTW: Well, it's per-vertex.
MostAwesomeDude: I should add fog into FP, so if we have something like "OPTION ARB_fog_linear" then we'll be able to handle it.
RTFM_FTW: that depends upon how you are doing it
RTFM_FTW: and what OPTION is specified
MostAwesomeDude: RTFM_FTW: No, I mean, the fog_coord spec is done per-vertex.
RTFM_FTW: correct
MostAwesomeDude: Or rather, it's calculated in a HW-dependent fashion (usually per-fragment), but the state can be changed per-vertex.
bridgman: just checking, we're talking about GL_EXT_FOG_COORD here ?
MostAwesomeDude: bridgman: Yes.
RTFM_FTW: yep its calculated per fragment
bridgman: OK, that doesn't look like something that would be "stuffed" (ie forced in rather
bridgman: than coming down with the rest of the vertex information)
bridgman: presumably it's supposed to be interpolated across the tri before being fed
bridgman: into the fp, right ? Then in a perfect world it would just magically go
bridgman: into the fog hw rather than depth and fp wouldn't have to do anything ?"
RTFM_FTW: so how much of GL_ARB_fragment_program have you guys implemented?
bridgman: I find the FG:FG_DEPTH_SRC register on page 164 strangely compelling, but
bridgman: I'm not sure what the normal setting is so not sure which option is calling me ;)
bridgman: what I don't know is whether option 00 picks up the actual depth value or can
MostAwesomeDude: RTFM_FTW: We're finished with ARB_f_p. The fog options belong to fog_coord.
bridgman: somehow be pointed to the interpolated fog value
RTFM_FTW: how about ARB_fragment_program_shadow?
MostAwesomeDude: bridgman: Already looked. FG_DEPTH_SRC has the "correct" depth by default by scanning quad depths.
MostAwesomeDude: If you set it to 1, then it picks up depth values written by FP.
MostAwesomeDude: Which means that fog is always done last.
bridgman: OK, I haven't played with arb_f_p -- is fog one of the outputs you can over-ride ?
MostAwesomeDude: bridgman: Well, not really, but you can write to the depth fifo, and then the rest of the pipeline will use that.
MostAwesomeDude: Right, in a magic world we could just place it at the beginning, and let the HW just run its course.
MostAwesomeDude: But, FP can still modify or overwrite that value.
bridgman: http://www.gamedev.net/community/forums/topic.asp?topic_id=386237 last post
bridgman: looks like you're right, we do need to handle it in the fragment program
bridgman: question is whether that means arb_f_p instructions or just having the driver do
bridgman: something
MostAwesomeDude: I'm thinking that we stuff it and then tell the FP generator to "unstuff" it and place into the depth fifo.
MostAwesomeDude: Then the rest of the driver will insta-handle it.
bridgman: am I reading the extension spec correctly, that the fog_coord values are passed
bridgman: down as vertex attributes which can either be passed through or modified
bridgman: by the vertex program ?
bridgman: stuffing is a post-vertex shader thing, right ? driver provides the value, not the app ?
MostAwesomeDude: Aw, man, you're right.
MostAwesomeDude: So it has to be passed into the VAP...
bridgman: have you looked at the FOG_SELECT field in GB:GB_SELECT register on pg 182 ?
MostAwesomeDude: Bery intarestink.
bridgman: If the fog source is
bridgman: FOG_COORDINATE_EXT, then c is the interpolated value of the fog
bridgman: coordinate for this fragment
bridgman: that was a messy paste, but this is from the extension spec; seems pretty clear
bridgman: that fog coord does get passed in as a vertex attribute and interpolated...
dmb: so i fog is a hardware thing?
MostAwesomeDude: dmb: Yep, thankfully.
MostAwesomeDude: Lots of math.
RTFM_FTW: nah the math is pretty easy actually
MostAwesomeDude: RTFM_FTW: Gotta do it on each pixel, though.
bridgman: I dunno. It still looks like you might be able to have the driver stick the fog
bridgman: coord onto the alpha channel of one of the colours, flip the register bits
bridgman: and maybe magic happens. The question is whether the hw passes two separate values
bridgman: into the shader and on to the back-end, ie "real" depth and "fog value, normally depth"
MostAwesomeDude: Hmm. Not sure. Reading the docs right now.
MostAwesomeDude: I never read the VAP chapter before....
bridgman: MostAwesomeDude, is it easy to check how that field is set by the driver now ?
dmb: is it a lot of computation involved with fog?
MostAwesomeDude: bridgman: Sure, lemme look it up.
bridgman: guessing it's set to 04 or 05, and we just need to set it to something between
dmb: like hardware doing the fog stuff if more helpful then cpu?
RTFM_FTW: MostAwesomeDude yes and thankfully we have *many* ALUs (4-5 wide) in order to make this sort of thing viable per fragment :D
bridgman: 00 and 03 depending on where the colour gos
bridgman: RTFM_FTW: good point, I would like to see that 5th ALU get used more ;)
bridgman: so it doesn't rust...
RTFM_FTW: oh its used quite a bit
RTFM_FTW: I'm not sure how much in your driver but its used heavily in ours
MostAwesomeDude: bridgman: I don't think it's being set. We define it, but AFAICT we're not actually using it.
MostAwesomeDude: RTFM_FTW: Exactly who are you? You know a lot about this stuff...
bridgman: that seems like something bound to cause pain
bridgman: the not setting it part, not RTFM_FTW
RTFM_FTW: did you get my PM MostAwesomeDude?
MostAwesomeDude: Just did.
MostAwesomeDude: Yeah, definitely not actually setting it.
MostAwesomeDude: Thankfully it has pretty sensible defaults.
MostAwesomeDude: ...Wait a sec. We're setting it as part of a larger register write. One sec.
bridgman: It defaults to 0, ie pick up the alpha channel of colour 0. That doesn't sound right
bridgman: oh, ok
MostAwesomeDude: Okay, so we're only setting the fog selection.
MostAwesomeDude: Alright, so we're just selecting 1/1/W == W as the fog value.
MostAwesomeDude: If we're using a coord, I suppose we should upload a different value and then change that appropriately.
bridgman: exactly... stuff the per-vertex fog coords into the alpha of one of the colors
bridgman: then set the value accordingly and let the interpolaters do the walking
MostAwesomeDude: And everything else should magically work.
bridgman: IIRC we have 4 colours but 2 are for front and 2 are for back of the tri ?
bridgman: probably not relevent here unless we use the alpha channel of colours for
bridgman: anything else
MostAwesomeDude: Yep.
MostAwesomeDude: I'm reading the docs so I won't be completely clueless when I go mucking around in everybody else's code.
bridgman: sounds like a Good Thing
bridgman: need to be up soon so will have to ring off; good luck ;)
MostAwesomeDude: 'k.
Nyle: hi
Nyle: should I ask questions about radeon driver for r580 here or in #radeonhd?
dmb: here
Nyle: does this driver support dual head?
MostAwesomeDude: Ish. Technically.
Nyle: hm
MostAwesomeDude: I've had mixed success.
Nyle: oh hey its the most awesome dude
MostAwesomeDude: You should try it and tell us the results. :3
Nyle: hey man how are you
MostAwesomeDude: Just fine. You?
Nyle: I'm great, with a little back pain but great, thanks.
Nyle: I'll try it
Nyle: MostAwesomeDude, fglrx used the big desktop 'horizontal' thing
Nyle: for radeonhd should I nmake two monitor/screen/device sections and adjust serverlayout accordingly
Nyle: or what is the preffered method here
MostAwesomeDude: Well, first try it live.
Nyle: plus I'm on debian/sid and hang on and how do I find out the version of the driver I have
MostAwesomeDude: Use xrandr.
Nyle: MostAwesomeDude, xrandr yes
MostAwesomeDude: Um, the driver version is in Xorg's log.
MostAwesomeDude: You could also check the apt version of xf86-video-ati.
Nyle: Package: xserver-xorg-video-radeonhd
Nyle: Version: 1.2.1-2
bridgman: that's a different driver
Nyle: but that is what I have in my xorg.conf
bridgman: but it's for the "radeon" chips :)
Nyle: I am confused
bridgman: ok, so you could ask the same question over in the radeonhd channel and we can go
Nyle: what is radeon vs. radeonhd
bridgman: answer it there instead ;)
Nyle: radeonhd == 500/600 driver only
Nyle: ?
Nyle: bridgman, oh I see
bridgman: yep; radeon was r1xx-r4xx, but when radeonhd went with hardcoding rather than atombios
bridgman: the radeon devs used atombios to support r5xx-r6xx on radeon as well
Nyle: bridgman, so if i I have radeonhd instead of radeon in xorg.conf which driver am I using
Nyle: scratches his head
bridgman: you are using radeonhd. If it says radeon or ati you are using the radeon driver
bridgman: ati is a wrapper around radeon, r128 and mach64 which automatically loads
bridgman: the right driver; probably not needed any more but still used sometimes
Nyle: I see
Nyle: I have X1900 XT
Nyle: which driver should I be using
bridgman: radeonhd is in the xorg/driver/xf86-video-radeonhd tree
bridgman: radeon is in the xorg/driver/xf86-video-ati tree
bridgman: you can use either but today radeon has more acceleration functionality
Nyle: really?
Nyle: they both work?
MostAwesomeDude: Yeah.
Nyle: oh since I suppose its because radeon released the specs or something
Nyle: so now its opensource?
MostAwesomeDude: bridgman: They split mach and r128 into their own trees.
bridgman: fglrx is a different driver again; that's our closed source driver
bridgman: there's also avivo and Dave Airlie's private r500 driver, but both are kinda EOL'ed
bridgman: radeon already had the 2d and dri infrastructure for 5xx 'cause it didn't change
bridgman: much from 3xx/4xx, so most of the acceleration work was done there
Nyle: I see
bridgman: we're trying to port the code over to radeonhd now but the two drivers are
Nyle: so I would have better luck with radeon?
MostAwesomeDude: Yeah, most of the r5xx fixes I commit end up helping r3xx people too.
MostAwesomeDude: Nyle: You can use either one, but radeon will probably be better in the long run.
bridgman: pretty different
MostAwesomeDude: radeonhd will be better for r6xx+ once we get docs.
Nyle: now that 3d works in opensource ati
bridgman: we're trying to keep common acceleration code between radeon and radeonhd for
Nyle: I can keep my card
bridgman: 3xx-5xx parts
Nyle: I was thinking about selling it and buying a nvidia
bridgman: nah ;)
Nyle: but ati seems better chocie now
Nyle: due to specs being open
Nyle: somewhat
Nyle: nvidia is fully closed
MostAwesomeDude: Been an ATI fan for years, and they haven't let me down yet.
Nyle: fglrx let me down hugely
MostAwesomeDude: Well, there was that period last year where fglrx just didn't work.
MostAwesomeDude: That was sad.
bridgman: Nyle: is it still giving you trouble ?
Nyle: plus the fact that this card is hardly overclockable (not so important) but it runs extremely hot to begin with
Nyle: bridgman, lately it won't even compile on 2.6.25
Nyle: but anyway
Nyle: other than extremely loud fan noise and very hot running card, its not bad
Nyle: I bought it because it had much better performance at the time of its rival the latest greatest geforece 7900 GT
MostAwesomeDude: ...There appears to be a spot on the VAP for fog.
bridgman: Nyle: I thought we had powerplay starting to kick in on the latest drivers; is
MostAwesomeDude: Nyle: Personally, I think that most of nVidia's performance advantages are just in well-written drivers, and in coding NV-exclusive GL stuff that speeds up games.
MostAwesomeDude: AFAIK PureVideo doesn't actually exist, it's just a bunch of driver code.
MostAwesomeDude: Or at least until the nouveau guys figure out where it is and how it runs.
Nyle: ok
Nyle: I restarted X with radeon instead of radeonhd, and now I can't see 1680x1050 anymore
Nyle: its not even listed in kde
Nyle: 1680x1050 60.0 +
Nyle: its listed in Xrandr
Nyle: not sure which to do here
MostAwesomeDude: Use xrandr to set it. Ignore KDE's settings.
MostAwesomeDude: If it works, put it in xorg.conf.
Nyle: oh ok
Nyle: ignoring kde (thanks for verifying)
MostAwesomeDude: bridgman: WB
dmb: looks like the server your on is dieing bridgman :/
MostAwesomeDude: That one's always dying.
dmb: freenode sucks :P
Nyle: hey i have another question related to xrandr not radeon
Nyle: I get error that i set screen size larger than something or other
Nyle: I have to specify Virtual size somwhere
Nyle: where exactly in xorg.conf do i do this? which specific section?
Nyle: and also, I have 1680x1050 <-- space --> 1600x1200 (dual head setup) what should my size be for the virtual size
Nyle: I would guess 1680+1600(3280)x1200?
Nyle: ?
agd5f: nh: the HDP on radeons have a cache flush as well
agd5f: hdp being the host data path (i.e., where fb reads/writes from the CPU go through)
MostAwesomeDude: agd5f: How's things over there?
agd5f: not too bad. busy weekend. little cousins in towns
MostAwesomeDude: Arg. My brains are jellied.
MostAwesomeDude: Is there anybody left who actually understands the VAP?