PovAddict_: AstralStorm: I got a ruler, measured the viewing area of my monitor, and set it explicitly as DisplaySize :)
PovAddict_: text looks OK now :)
PovAddict_: and now I just found my monitor spec sheet
MostAwesomeDude: AstralStorm: Can't remember how to downscale with this.
MostAwesomeDude: And TBH for downscaling you should just use bilinear and go with it.
PovAddict_: MostAwesomeDude: so this thing can do 3D in theory?
MostAwesomeDude: But for upscaling, you find the nearest texel to the pixel, center your convolution grid on that texel, do your sampling and weights, and then add the whole thing together.
MostAwesomeDude: PovAddict_: It can do 3D, but there's just...quirks, sometimes. :3
PovAddict_: ooh, XRender seems to work
PovAddict_: KDE panel transparency is back! :D
PovAddict_: it's slow as hell but whatever :P
PovAddict_: I didn't really need 3D
PovAddict_: just my composited desktop (either OpenGL or XRender)
PovAddict_: damn...
PovAddict_: of course it can't compete with the GeForce 8600GT I was using, but considering it's onboard and sharing system memory, this thing is pretty fast
PovAddict_: hates having to deal with hardware issues
AstralStorm: MostAwesomeDude: downscaling is trivial
AstralStorm: upscale to integer ratio of size
AstralStorm: then decimate
AstralStorm: I forgot how to upscale ;p
AstralStorm: to be exact, what size of the kernel to pick
AstralStorm: or how many extra pixels for fill
MostAwesomeDude: Dunno. I'm reading http://www.worldserver.com/turk/computergraphics/ResamplingKernels.html right now.
AstralStorm: I know how to build the kernel
AstralStorm: esp. that it's symmetric, so you first vertical then horizontal or vice versa
AstralStorm: but I don't know how to pick the right size of the kernel
AstralStorm: there's but one tunable in lanczos, that being scaling constant alpha
AstralStorm: oh and of course the kernel size
AstralStorm: good alpha being 2 or 3
AstralStorm: I prefer 3.
AstralStorm: as I said downscaling is fairly trivial
AstralStorm: http://gpuexperiments.blogspot.com/2009/02/image-convolution.html - hmm
AstralStorm: so it seems that for downscaling, I should decimate then run a filter, hmmh.
AstralStorm: I thought upscale then decimate should be better, but I might be wrong
MostAwesomeDude: I dunno. We don't have to follow *all* the rules, since we're doing this for video frames instead of stills.
AstralStorm: sure we have to
AstralStorm: otherwise it'll look wrong ;p
MostAwesomeDude: Oh, don't worry about "compute" shaders. I'm aiming at r300 still.
AstralStorm: I know one has to pad the image about half of the shade
AstralStorm: yeah I don't worry about them
AstralStorm: heck, ATI sdk even has a sample implementation of separate axis convolver
AstralStorm: in assembly
AstralStorm: brute force though, not DFT ;p
AstralStorm: oh hell
AstralStorm: I have all this wrt sound... literature
AstralStorm: fell into disuse
AstralStorm: let me check there
AstralStorm: there's bound to be a chapter about sinc resampling
AstralStorm: and that's essentially the same
MostAwesomeDude: What do you mean by brute-force? I didn't know this had anything to do with crypto.
Tecan: anyone here have a x300 ?
AstralStorm: http://en.wikipedia.org/wiki/Upsampling - blah blah
AstralStorm: it's there ;p
AstralStorm: MostAwesomeDude: I mean by not using DFT to compute it in n * log n time
AstralStorm: the multiplications
AstralStorm: strassen algorithm.
AstralStorm: this one I have is brute force n^2 algorithm
AstralStorm: strassen's is noticeably faster
MostAwesomeDude: You mean, computing the weights for each pixel?
AstralStorm: yes, it's still faster :)
AstralStorm: because that computation is O(n)
AstralStorm: and it's fast too
AstralStorm: while next step - DFT evaluation with a fast algorithm is fast
AstralStorm: >>> 1920*1200 * 9*9
AstralStorm: 186624000 MACs
AstralStorm: >>> 1920*1200 + 9*9 + math.log(1920*1200 + 9*9,2)
AstralStorm: 2304102.1357600051 MACs
AstralStorm: a few orders ;p
AstralStorm: oh, messed upt
AstralStorm: >>> (1920*1200 + 9*9) * math.log(1920*1200 + 9*9,2)
AstralStorm: 48698503.047989145 MACs
AstralStorm: that's correct N*log N
AstralStorm: about 25% of the original value
AstralStorm: 4 times faster
AstralStorm: :)
AstralStorm: adding the n preprocessing step, this takes 27.3% of the time of the brute force method
AstralStorm: actually, the n^2 is wrong too, it's larger
AstralStorm: because there are hidden texture fetches that you can reduce overlap in the fft way
AstralStorm: and fft is parallelizable easily
AstralStorm: so the GPU will run it fast
AstralStorm: http://en.wikipedia.org/wiki/Strassen%27s_algorithm - this one
AstralStorm: better, multiplication is O(n^3) ;p
AstralStorm: since one matrix in question is huge and the multiplication is ran n times, the result is win
AstralStorm: http://en.wikipedia.org/wiki/Convolution - for DFT convolution
AstralStorm: and then Strassen's for multiplication of the result
MostAwesomeDude: Hm.
MostAwesomeDude: Maybe I'm misunderstanding, but...
AstralStorm: no, I am
AstralStorm: just DFT is necessary
MostAwesomeDude: I think you might be overthinking this.
AstralStorm: because those aren't multiplications, but MACs
AstralStorm: ;p
MostAwesomeDude: Okay, so first you take the dimensions of your image, and calculate the normalized coords. (Or use RECT and non-normalized coords, probably easier TBH.)
MostAwesomeDude: And then you calculate one kernel, right?
AstralStorm: so, compute DFT of the input, DFT of the kernel, use the circular convolution theorem
AstralStorm: yes
AstralStorm: and the kernel is the same for given scaling factor
AstralStorm: so that's fine
MostAwesomeDude: Then. For each tap on the kernel, you sample that texel, using your adjusted coords, weight that texel, and add it to your destination color.
AstralStorm: the whole operation becomes computing DFT of the input image and MACing it with the kernel
MostAwesomeDude: And you're done.
MostAwesomeDude: But we're doing this per-pixel.
AstralStorm: that is brute force
AstralStorm: DFT is done once
AstralStorm: MAC is done per pixel
MostAwesomeDude: MAC?
AstralStorm: in your brute force multiplication, you run n^3 multiplication-addition ops
AstralStorm: MAD
AstralStorm: horrible thinko
AstralStorm: multiplication-add
AstralStorm: while in DFT version, you run n^2*log^2 n MADs
AstralStorm: after an n preprocessing step
AstralStorm: that's a huge difference
AstralStorm: if you're extra smart, you can run convolution in parallel
AstralStorm: the parallel way works if your convolution is symmetric
AstralStorm: which lanczos is
AstralStorm: you can run each line on a different core
AstralStorm: that's even not using a parallel DFT
AstralStorm: but I'm sure OpenGL assembly doesn't have commands for parallelism ;p
AstralStorm: this isn't OpenCL after all
AstralStorm: hmm, funny
AstralStorm: instead of tons of MADs, it should be possible to factor it into DP4 instructions
AstralStorm: dot products
AstralStorm: could be faster
MostAwesomeDude: Well, that's trivial.
airlied: MostAwesomeDude: any suggestions to figuring out where swtcl went wrong?
MostAwesomeDude: airlied: Not really. Just gotta resurrect the bits that got destroyed in the switch to HW TCL.
MostAwesomeDude: It should be a bit easier since we don't have to compete with the rhw path anymore.
MostAwesomeDude: AstralStorm: That's just the way it is. You gotta process per-pixel.
airlied: MostAwesomeDude: currently r300_create_vertex_elements_state is triyng to process vertex attribs before vs is bound
MostAwesomeDude: And honestly, doing e.g. 16 MADs per pixels isn't too bad; I've seen shaders with 100+ insts.
MostAwesomeDude: airlied: Alright, let's do this.
airlied: MostAwesomeDude: looking a other drivers they do the attrib emits at derived state update time
MostAwesomeDude: Yeah, we can only get away with it when we're in HW TCL. In SW TCL, we need to do that at derived state update.
airlied: MostAwesomeDude: so r300_update_derived_shader_state is probably where it sohuld live?
MostAwesomeDude: airlied: Yeah, I'm moving it back right now.
MostAwesomeDude: Hm. Should we update derived shader state every time a new vert shader is bound?
MostAwesomeDude: In SW TCL, at least?
airlied: yeah since the attribs may change
MostAwesomeDude: Hm, I think I got clear working again?
airlied: good start
suokko: f12 livecd in my USB stick failed to boot :/
suokko: And I suspect it might be radeon causing trouble but I don't know how to get info out from the livecd boot
suokko: We really should queue more rendering command in ddx before flushing. Line by line drawing in terminal looks funny :) ("a bit" swapping going on)
MostAwesomeDude: Hm. tri works, gears doesn't. :T
AstralStorm: MostAwesomeDude: 16?
AstralStorm: must be kidding
AstralStorm: 2x scale up is 6x6
AstralStorm: a lower res movie can be 5x scale up
AstralStorm: e.g. 24x24
MostAwesomeDude: Most of the code I've seen was 6 taps at most?
MostAwesomeDude: Oh! I just realized how the hell the bilinear assist works!
MostAwesomeDude: Damn, now I need to find that white paper again.
AstralStorm: yeah, exactly ;p
AstralStorm: but it's of course losing quality
AstralStorm: oh wait, no, scaling doesn't work that way I just said
AstralStorm: the filter is constant length
MostAwesomeDude: Not really. You're not losing quality because when you load the fragment colors from texels, you magically acquire 24 or so guard bits.
MostAwesomeDude: And those bits are pre-filled with the result of your bicubic.
MostAwesomeDude: Er, bilinear.
MostAwesomeDude: airlied: If you pull, most of the trivial dir should work as before.
MostAwesomeDude: gears needs some kind of state flush, also we need to only invalidate the PSC state occasionally instead of regenerating on every derived update.
AstralStorm: but bilinear is bad enough already
MostAwesomeDude: No, no, see? When you do a bilinear sample, you're just letting the HW pick a couple of weights and taps for you. You can still influence it.
AstralStorm: true, and?
AstralStorm: you compute an inverse of a bilinear filter?
AstralStorm: that won't be fast
AstralStorm: and no, bilinear has no weights/taps
AstralStorm: it's called bi*linear* for a reason :)
MostAwesomeDude: You can write it out as a convolution.
AstralStorm: but no hardware does
MostAwesomeDude: Same maths though.
AstralStorm: it's slower to convolve that 2x2 kernel
AstralStorm: than to separately linearly solve
MostAwesomeDude: But the results are identical.
AstralStorm: one linear for x, one for y
AstralStorm: yeah, but convolution is slower
MostAwesomeDude: Maybe I'm on the wrong path, but onestone definitely managed to accelerate his bicubic solves this way.
AstralStorm: that's *not* bicubic
AstralStorm: it's corrected bilinear
AstralStorm: it won't look like bicubic
MostAwesomeDude: It's all in his paper; I can't find the damn thing though.
AstralStorm: it's as if you did piecewise bilinear
AstralStorm: more precise
AstralStorm: to be exact, it's a linear spline filter
AstralStorm: it's *not* bicubic
AstralStorm: fairly good though :)
suokko: splines can be very good approximation of actual values
AstralStorm: just how cubic spline filters are better than direct cubic
suokko: actual formulas that is
MostAwesomeDude: Hm. Clearly I need more thought put into this.
MostAwesomeDude: AstralStorm: Found it! http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.560&rep=rep1&type=pdf
suokko: MostAwesomeDude: Link doesn't work in links2 :/
MostAwesomeDude: Yeah, it's an iffy link. I can provide a better one, one sec.
MostAwesomeDude: http://people.freedesktop.org/~csimpson/gpu-assisted-filters.pdf
suokko: Another problem is of course if evince spaws too much ;)
MostAwesomeDude: AstralStorm: Does this paper help you at all?
suokko: Btw, Make sure that the textures are tiled ;)
MostAwesomeDude: Mirrored repeat :3
MostAwesomeDude: But yeah. If I understand this right, an Xv client could upload 4 helper textures and do one-pass 4x4 sinc?
MostAwesomeDude: Er, not client, server.
suokko: We have limit of 4 RTs in r300?
MostAwesomeDude: Yes.
MostAwesomeDude: Oh, I see! Haha, yes, you could do that.
suokko: So only trade of is memory vs number of passes?
suokko: How much faster is single pass instead of 4 passes there?
suokko: We can even embed video upload to the one pass sinc to reduce vram bandwidth requirements
MostAwesomeDude: The speed would come from not having to invalidate state and upload new shaders.
MostAwesomeDude: I'd have to think on this more, but it seems possible, if a tad slow.
edwin: hi
edwin: mesa deadlocks
edwin: in _mesa_GenTextures
suokko: edwin: backtrace?
edwin: https://bugs.freedesktop.org/show_bug.cgi?id=27340
edwin: and I think I found the bug too
edwin: double locking
suokko: edwin: yes
suokko: edwin: And that only happens when there is hash coallision. I guess
edwin: when hash is full
suokko: aah. yes
edwin: ... and I patched it
edwin: lets see if everything else works
suokko: edwin: http://sprunge.us/PBKA <- Something like this? :)
edwin: suokko: I did this https://bugs.freedesktop.org/attachment.cgi?id=34502
edwin: you missed an UNLOCK_MUTEX ;)
suokko: yep
suokko: edwin: Btw, naming function name should be _locked instead of unlocked. But if you post the patch to mesa3d-devel with git send-email it should get accepted :)
suokko: firefox
suokko: surprisingly irssi doesn't know to launch ff
MostAwesomeDude: suokko: You can do your part. Confirm https://bugs.freedesktop.org/show_bug.cgi?id=1833 no longer occurs. :3
suokko: btw, that hashlookup should use RW lock. THere should be a lot more reads than writes to that hash table
suokko: MostAwesomeDude: I can check if 16bbp mode works ;)
evil_core: hi all
suokko: edwin: It is better to use git format-patch -1 && git send-email --to
edwin: suokko: ok
edwin: sent
MostAwesomeDude: suokko: Does tuxracer/ppracer look right to you on r200?
suokko: MostAwesomeDude: ppracer has some trouble
suokko: still
MostAwesomeDude: :T
MostAwesomeDude: #6090 has been around for a while now.
suokko: MostAwesomeDude: There is something funky going on and if rendering is puhed at max speed ppracer based levels in etracer are getting some incorrect vertex data
glisse: MostAwesomeDude: so did you have the raw cmdstream ?
MostAwesomeDude: glisse: Oh, that's right. Yeah, I can get that.
MostAwesomeDude: tries to remember what he was doing to cause it
MostAwesomeDude: Oh right, shadowmap GLSL test.
glisse: otherwise i can retransate the one attached
glisse: i am just lazy to do the prog for that
MostAwesomeDude: No, it's fine. The tool that I wrote to do that isn't exactly the same as the old CS format anyway.
MostAwesomeDude: http://pastebin.com/PAkd7b2J
MostAwesomeDude: Fresh off the press.
glisse: i will release soon tools which use xml to decide cs stream and other tools to replay cmd stream
glisse: decode*
MostAwesomeDude: Hey, no worries. It took me maybe 5m to slap together that one, and it works well enough for me.
Shuren: hi
chisholm: does anyone know what i need to setup to get tear free video working with the radeon driver?
MrCooper: chisholm: http://bugs.freedesktop.org/show_bug.cgi?id=27192 should have a pretty good summary of the dos and don'ts
chisholm: thanks
chisholm: MrCooper: do you know if xv just doesn't work with kms enabled?
MrCooper: it does work with KMS
MrCooper: check with xvinfo
chisholm: MrCooper: xvinfo - http://dpaste.com/176697/
chisholm: it seems ok to me, i'm using mplayer. I've tried getting it to use vo xv, but it doesn't work all that i can seem to use is x11 which tears
Shuren: chisholm, what card do you have?
chisholm: its a x1600
Shuren: ah ok
soreau: chisholm: Is 3D working?
chisholm: yes, i believe so
suokko: What happens when you try xv?
chisholm: glxinfo - http://dpaste.com/176705/
chisholm: when i try xv in mplayer i get sound but no video and there is an error message
MrCooper: xvinfo looks fine, what's the mplayer error?
chisholm: it's: Error opening/initializing the selected video_out (-vo) device.
MrCooper: paste the full output
chisholm: that's with '-vo xv'
chisholm: mplayer output - http://dpaste.com/176710
MrCooper: that doesn't really say anything about what the problem is, please take it up with mplayer folks
chisholm: ok thanks
soreau: chisholm: Does it make a difference if you try -vo xv:port=63 ?
chisholm: soreau, no
chisholm: I've got the attention of a few over on #mplayer, hopefully they can work it out
Shuren: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/ <--- maybe need this patches
Shuren: if the trouble is connected with tear-free
MrCooper: no, VA API is about accelerated video stream decoding, XVideo just about scaling and colourspace conversion
Shuren: ok
MaDMaLKaV: hi people. two quick questions. 1) You know if anyone is working on adding support for XBox 360 GPU? 2) Is there any documentation you recomend me to read related to adding new models to the driver? I'm probably undeskilled for doing it but learning about it surely can't do me any damage ;)
glisse: xbox 360 gpu shouldn't need much change, their was a project once upon a time
glisse: google should help
MaDMaLKaV: glisse, thanks for the info , I was out so I couldn't reply earlier
MaDMaLKaV: only info I can find is about the frambuffer we are currently using on free60 , not about a complete graphic driver
MostAwesomeDude: Hopefully, it's a special framebuffer + modesetter for the TV hookups, and then a regular Radeon-ish GPU.
MostAwesomeDude: But that might be asking too much. :3
MaDMaLKaV: probably not, I know theres a chip called ana on the 360 that efectively is in charge of setting the graphic mode, for the little I understood from libxenon -a library for developing OSless apps for 360 and that have most complete graphics function that current linux patches-
Delahunt: anyone play second life? i'm looking for recommendations for a card that does OpenGL well, on Linux, that has open source drivers
Wizzup: both ati and nvidia have open source drivers, but I think generally radeon is considered more mature (ati)
adamk: Yeah, I suggested he ask here specifically about that game with the r600 driver since I have no experience with it.
Delahunt: any specific card then that you would recommend?
adamk: (the game, not the driver, which I have plenty of experience with).
Delahunt: the driver has to be open source if possible
Delahunt: second life is heavy 3D OpenGL
adamk: I wonder if I can try installing it.
Delahunt: as for other features like TV card and such, i have absolutely no need
MostAwesomeDude: SL performs best on cards with lots and lots of VRAM. Also it's buggy as balls with non-proprietary graphics, so good luck.
adamk: Ahhh, guess that answers that.
suokko: Delahunt: Second life had trouble with texture uploads when I last teted it with r600
adamk: Delahunt: Sorry, looks like it's not a great choice for SL. But, then again, it looks like no open source drivers are.
Delahunt: so in linux it's like playing untextured, or that some don't load up?
Delahunt: and how bad is it? just a minor annoyance or a major pain?
suokko: Delahunt: You jsut get hiccups when game is reloading some textures
Delahunt: so it doesn't make the game unplayable?
suokko: Delahunt: It is not playable in my option yet. But quite close
MostAwesomeDude: You could ask spstarr about it, but (strangely) he's not around.
adamk: That is unusual.
MostAwesomeDude: He's an SL dev, IIRC.
Delahunt: thanks
MostAwesomeDude: And normally in this channel.
Delahunt: k thanks
suokko: MostAwesomeDude: He got a new job so no more time I guess
adamk: Heh... He usually never shuts up on here.
MostAwesomeDude: suokko: Ah. Well, good for him, at least; I know he's been looking for work for a while.
MostAwesomeDude: adamk: :3
Delahunt: well that's good, at least he didn't allow his second life to become more important than his first one 8-)
MostAwesomeDude: Yeah, no kidding. I remember kicking my MMO habit a few years back.
MostAwesomeDude: I seem to have replaced it with a coding habit, though. :T
hnsr: oh god eve online
hnsr: :(
hnsr: still amazed i managed to recover.. somewhat
Delahunt: has met people for whom their second life is more grand than their first ... strange
Wizzup: used to play runescape
Wizzup: probably the most boring mmorpg
Ghworg: Life is the most boring mmorpg
Ghworg: Grind for 40 years and then you don't even level up
spreeuw: 1st life yeah
spreeuw: good theres IRC to bemoan it
spreeuw: why is the nexuiz armour and helath powerup textured with a whiteish body?
spreeuw: almost looks like a texture problem
spreeuw: or is this intended?
BioTube: any idea what would cause an image to suddenly pop up on VT switch?
BioTube: I was browsing with Iceweasel and it called up the last tab shown after I locked my screen(invoking an OpenGL screensaver) and switched to another screen(which was running a non-OGL one)
MostAwesomeDude: agd5f: We never talked about it at all... I assume PACKET3_MPEG_INDEX is busted somehow on r300?
MostAwesomeDude: Also! PACKET3_COND_EXEC means we can do NV-style conditional rendering.
MostAwesomeDude: Yay, I guess.
AstralStorm: MostAwesomeDude: our failure! there's EXT_convolution that we could use
AstralStorm: OpenGL 1.2
MostAwesomeDude: AstralStorm: Well, if you're in GL, yeah.
MostAwesomeDude: I'm thinking towards Gallium.
AstralStorm: yeah
MostAwesomeDude: But yeah, there is that. Dunno if Mesa supports it.
AstralStorm: it does
AstralStorm: it's standard OpenGL 1.2, it'd be a crime if it didn't ;p
AstralStorm: I wonder then why mplayer isn't using it
AstralStorm: instead relying on scaling shaders
MostAwesomeDude: Might be a software fallback.
AstralStorm: aaah, no
AstralStorm: it's because it installs a fragment shader
AstralStorm: for YUV to RGB conversion
AstralStorm: and shaders replace *everything*
AndrewR: hello all. I tried two things with my rv280, and both give me not what i wanted. First, i've created patch like this http://pastebin.ca/1854245 for disabling DRI2 vsync. But it makes no difference for me. Second, i tried to enable _mesa_meta_bitmap for r200, it "fixes" most of text in teapot but made it nearly 2x slower (fallback? but still around 10 fps). I run with kms colortiling on, it broke blender for sure :)
MostAwesomeDude: Oh, also, you need ARB_imaging for the really useful stuff.
MostAwesomeDude: Which we don't have.
AndrewR: MostAwesomeDude, at least r3xx and up should be able to emulate some things needed for ARB_Imaging, but unfortunately i have only rv280 .....
AndrewR: MostAwesomeDude, if i understand imagin subset at all (some per-pixel matrix ops)
MostAwesomeDude: Anything shaderful should do it, really.
AndrewR: MostAwesomeDude, if you can write some helper/util function for gallium, i have nv40 + nouveau here :)
MostAwesomeDude: AndrewR: It'd be something for the mesa st.
AndrewR: MostAwesomeDude, sorry if this idea sounds bad for you right now
MostAwesomeDude: Nah, it's a good idea, but it can't be a priority.
AndrewR: MostAwesomeDude, i've read most mails about various changes, but understand very small part from all this :/
AstralStorm: time to draw some teapotahedrons for testing of the convolution
AstralStorm: :>
AstralStorm: whoops, overflow
AstralStorm: forgot to pad the texture ;p
TheBrayn: howdy folks
TheBrayn: is there a version of radeon that can regulate the graphic-card fan?
BioTube: not directly
TheBrayn: is there a way to do this?
TheBrayn: I don't want to use fglrx anymore
BioTube: but drm-radeon-testing has engine reclocking support, which should make the card run cooler and slow the fan if it's temperature controlled
TheBrayn: not sure if it is
TheBrayn: it's a hd4870
TheBrayn: saphire afaik
BioTube: I'm pretty sure the newer cards have temp-regulated fans(mine's a fanless 3450)
agd5f: MostAwesomeDude: as far as I know it should work fine. I think it even works on older chips. I'm not really sure what sort of context is expected to use it though
TheBrayn: http://wiki.x.org/wiki/radeonhd%3Aexperimental_3D <- this?
BioTube: TheBrayn: that
BioTube: 's ancient
BioTube: see the link in the topic for more up-to-date instructions
TheBrayn: ok
TheBrayn: it's not possible to install this testing build directly with portage?
BioTube: I don't use Gentoo
TheBrayn: which version would this testing build with power management be?
BioTube: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing
TheBrayn: hm
TheBrayn: glxinfo can't be found
TheBrayn: is it part of a specific package?
BioTube: it's shipped with Mesa, IIRC
TheBrayn: ok
TheBrayn: mesa-progs maybe
TheBrayn: well X kinda works
TheBrayn: but the fan is really loud again
BioTube: the PM code requires radeon.dynpm=1 to be passed to the kernel
TheBrayn: http://codepad.org/bXft0Ddz <- this is not the way it should be, right?
BioTube: nope
BioTube: Xorg.0.log should give a hint
TheBrayn: http://codepad.org/i3yp3Vp7
TheBrayn: hmm
TheBrayn: i have an idea
TheBrayn: nope
TheBrayn: I really don't know what this is
spstarr: :)
Jonimus: spstarr: you missed the SL discussion
spstarr: when was it?
spstarr: i will check logs
spstarr: http://www.radeonhd.org/?page=archive_display&c=radeon&m=3&y=2010&d=2010-3-27
TheBrayn: ldconfig -p | grep libGL.so
spstarr: MostAwesomeDude: not a SL dev, i gave them one patch :)
TheBrayn: wrong window
spstarr: slaps adamk
spstarr: im still on SL but much much less
spstarr: the SL texture issue is OpenJPEG related (1.3.x sucks balls)
spstarr: the stalls are a real issue (i need to check since many changes have been made this week in mesa/drm)
spstarr: im on the i965 and im getting 20-30 FPS in game on avg now
TheBrayn: http://codepad.org/8tEM1rx2 <- does this mean that mesa and libdrm aren't loaded from /opt/xorg?
TheBrayn: http://codepad.org/QscqSSzG <- and what is wrong here?
TheBrayn: I'm trying to do this here: http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingExtraFirmwareforR600.2BAC8-R700
TheBrayn: ok, solved
TheBrayn: I shouldn't try to do things like this at 05:42 am :>
TheBrayn: damn it
TheBrayn: DRI_DRIVERS="radeon,r200,r300,r600,swrast"
TheBrayn: where do I have to put lines like this?
TheBrayn: you need to build mesa with --with-dri-driverdir=/opt/xorg/lib/dri/ (or --with-dri-driverdir=/opt/xorg/lib/dri/ for 32-bit) <- this is exactly the same
MostAwesomeDude: TheBrayn: --with-dri-drivers=r600,swrast or whichever drivers you like.
TheBrayn: ok
TheBrayn: so swrast won't be available as a fallback solution?
MostAwesomeDude: No, each DRI driver you build is in a separate library.
TheBrayn: because atm swrast seems to be used
MostAwesomeDude: Lemme look at your pastebins.
MostAwesomeDude: Uf, you're on Gentoo.
TheBrayn: yeah^^
MostAwesomeDude: They did something to handle this, dunno what.
MostAwesomeDude: Go ask them. :3
TheBrayn: what exactly?
MostAwesomeDude: How to do multilib Mesa. :3
TheBrayn: ok
MostAwesomeDude: Mesa's build system isn't equipped for the idiosyncracies of ebuilds or cross-compiling, so it needs special TLC per-distro.