vehemens: airlied: got it. it wasn't written, then it was, then it wasn't. :/
JohnNy64-konik: When I have two monitors connected to one card, VGA-0 and DVI-0, how can I make the DVI-0 one the ``first'' one? (E. g. for Xinerama...)
mikkoc: mesa/drm doesn't compile with 2.6.27.. is it known?
mikkoc: linux-core/drm_ttm.c:75: error: too many arguments to function 'on_each_cpu'
mikkoc: more info: http://zlin.dk/p/?M2ZjNzBi
jcristau: yes, it's known
jcristau: there are some patches on dri-devel
mikkoc: thx
pbdl: agd5f: are you here?
spstarr: has a Radeon HD 3650
peterz: spstarr: welcome to the world of unaccelerated 2d :-)
spstarr: peterz: worse, the DDX didnt detect my old CRT right and did wrong mode..
spstarr: so.. i have to use the fgrlx period ;(
spstarr: peterz :)
peterz: tsss
gentoofu: i wonder if Tungsten's gonna have a 1 day testing and release Mesa 7.1 officially
spstarr: clones agd5f and airlied
spstarr: x 10
_neuron_: how's the quality of fglrx anyway? Maybe I should use that until they push tvout for pal, got a R500 chip.
damentz: _neuron_: it's pretty good, they just seem to have late kernel support
damentz: if you use something like ubuntu though, you should be fine
damentz: they only use mature kernels
diogo: does anyone knows if the new releas (todays release) of mesa DRI's (7.0.4 and 7.1-rc4) fixes the problems of blender and Xpress 200?
MostAwesomeDude: diogo: Are the problems detailed in a bug on fdo?
diogo: I don't... actually the problem is that with mesa 7.1 rc I couldn't select things with xpress 200 on blender and on mesa 7.0.3 there were ashes and also buggy traces on the screen of blender... I think so they were related as a bug but not sure
MostAwesomeDude: Well, if your problem is related to rendermode != GL_RENDER, then no, probably not fixed.
MostAwesomeDude: Otherwise, yeah, 7.1's got some fixes.
diogo: do you know how can I install this 7.1 rc4 on gentoo? don't hav expertise on it?
diogo: !
diogo: gonna ask on gentoo IRC
gentoofu: diogo: git
gentoofu: there are git overlays
MostAwesomeDude: diogo: x11 overlay will have an ebuild shortly, I'm sure.
MostAwesomeDude: Until they do, mesa-9999 will do.
diogo: k
MostAwesomeDude: Or just mesa-7.1rc3
diogo: hey question how do I disable on the configure to not compile the intel DRI's they are givin errors :(
diogo: ?
chithead: diogo: probably you need drm from git, too
diogo: I do have it already
MostAwesomeDude: nha isn't on, damn.
MostAwesomeDude: agd5f: I'm thinking of estimating partial derivatives using MDH and MDV. Any comments on how fglrx might do it, and whether or not that's gonna be sufficient?
agd5f: pbdl: send me the radeondump log before and after turning on the tv
agd5f: pbdl: alexdeucher at gmail dot com
agd5f: MostAwesomeDude: not sure. best bet is to chcek the shader compiler
pbdl: agd5f: will do. note that i did it with atitvout. is that ok? i tried vbetest but it complained "... must be run from the console" even though i was.
agd5f: pbdl: yeah, that's fine
agd5f: thy both do the same thing in the end
pbdl: ok
pbdl: i didnt do a before, can i just run it now while x is running? or only console
agd5f: preferably console since that should mimimize the diff, but I just need a state where the tv is off
agd5f: bbl
pbdl: ok will do. in 5-10 min ill send it over
RTFM_FTW: MostAwesomeDude is this R5xx?
RTFM_FTW: if so then yes
MostAwesomeDude: RTFM_FTW: Yes, r5xx.
MostAwesomeDude: Okay, thanks.
MostAwesomeDude: XD, using "dFdx" or "dFdy" makes the shader analyzer hang.
MostAwesomeDude: RTFM_FTW: What should we do for r3xx? Just refuse to compile?
RTFM_FTW: yep SW fallback for older ASICs is a viable approach
pbl: agd5f: email sent
MostAwesomeDude: Hm, alright.
RTFM_FTW: specifically considering that partial derivatives are a PS 2.0a / PS 3.0 specific feature
MostAwesomeDude: Well, yeah, but also an NV_f_p feature.
MostAwesomeDude: Which is why I wanted to get them out of the way before, say, the noise.
RTFM_FTW: heh last I checked this isn't Nvidia HW... :P
MostAwesomeDude: True, but a lot of people still write for NV_f_p. Every NV-specific extension we can do is another step towards improving programs written with them.
RTFM_FTW: ugh... I have vast amounts of hatred for the lower level shading extensions (i.e. NV_[vertex, fragment]_program[1,2,3], ARB_[vertex, fragment]_program, ...) if only because they attempt (and ultimately fail) to expose lower level HW specific details of the underlying ISA
RTFM_FTW: [end of rant] :P
MostAwesomeDude: Dude, if you can't target it with C, it's not worth the time.
RTFM_FTW: adopt GLSL, HLSL or at least (god forbid) Cg people!
MostAwesomeDude: Seriously, if I hadn't come here because I have a Radeon, I wouldn't have come here, period.
MostAwesomeDude: I'd get a job, and get paid to work on OLPC, and I'd be happy.
MostAwesomeDude: Maybe not challenged, but happy.
MostAwesomeDude: No, wait. I'm still happy here.
MostAwesomeDude: Just frustrated.
MostAwesomeDude: WTF do we need to know the derivative of the pixel's values with respect to the window anyway?
MostAwesomeDude: Stupidest inst evar.
RTFM_FTW: no its not actually
RTFM_FTW: its commonly used for procedural AA for example
RTFM_FTW: it happens to be an extremely handy operation
MostAwesomeDude: Ah, I see. Cheaper than doing the whole multisample thing?
MostAwesomeDude: Oh, wow. I just realized how fglrx does smoothed polys. I think.
RTFM_FTW: they are also used for gradient calculations
MostAwesomeDude: Hm.
MostAwesomeDude: So d(texel)dx = MDH left, -1, right?
MostAwesomeDude: Just the difference?
MostAwesomeDude: Let's see, ~d/dx = slope of secant, secant is difference in colors over distance, which is only one pixel...