MostAwesomeDude: dmb: But the assembly isn't very fun.
dmb: MostAwesomeDude, it works well on a 286 though...
dmb: erm, maybe 386, guessing it uses 32bit registers
MostAwesomeDude: It's 386 asm.
MostAwesomeDude: Anybody got requests? I'm tired of kicking fog coords, and I was just gonna go chill and work on music until my r6xx card gets here and the docs come out.
z3ro: I finally got my visa application sorted (with 19 days left, yeah, I'm organised. ;) and got tickets. :)
MostAwesomeDude: z3ro: Good work. :3
dmb: MostAwesomeDude, is there any games that don't work with the r5xx yet?
MostAwesomeDude: dmb: Out of the games I've played, they all work.
MostAwesomeDude: I don't play a lot of games, though.
z3ro: MostAwesomeDude: if you're sick of fog coords, you could fix two sided stencil. :D
dmb: i should go on a hunt trying to find games that don't work
z3ro: I'm actually not sure whats required... I think it's just writing the second reg.
z3ro: but there is some weirdness as r3xx doesn't fully support two sided stencil. I think r4xx and above does, though.
dmb: MostAwesomeDude, does doom3 work?
MostAwesomeDude: Um, on the list, the only one I haven't tested is Painkiller, and I don't want to pay for it.
MostAwesomeDude: dmb: http://wiki.x.org/wiki/RadeonProgram
MostAwesomeDude: z3ro: I looked very closely at the current code, and I can't figure out for the life of me why ati_separate_stencil and ext_two_sided_stencil don't work.
z3ro: MostAwesomeDude: hmm. I'll try and make some time to add a test to revenge for it.
MostAwesomeDude: z3ro: That would be helpful. Maybe just copy over the current test in mesa progs?
z3ro: does mesa have a test for two sided stencil?
MostAwesomeDude: Um, progs/tests/stencil_twoside is an atl_separate_stencil and arb_two_sided_stencil test.
Gantex: MostAwesomeDude: it would be nice if you optimize the drivers for compiz/composting. Right now compiz runs a bit slow with the current drivers
MostAwesomeDude: Gantex: Hmm. I'll run some oprofile stuff and see where it's slow.
z3ro: MostAwesomeDude: I see. I probably don't even need something that complicated. just enough to set the state, and make the card draw something.
MostAwesomeDude: My slowest plugin is Atlantis, for obvious reasons.
z3ro: run it a couple of times with different values, and diff. :)
MostAwesomeDude: z3ro: Yeah, pretty much.
MostAwesomeDude: You might want to also test for the two_sided_stencil ext as well, in case they're implemented differently.
z3ro: MostAwesomeDude: yeah probably a good idea to test both.
z3ro: but the generic EXT one should be the priority. iirc the ATI one is just a cut down version of EXT.
z3ro: eg for early hardware that didn't support the full extension.
MostAwesomeDude: z3ro: Yeah, the ATI one is all that r300 can do, but the EXT one is supported by all OGL 2.0 cards.
MostAwesomeDude: IIRC that's one of the big reasons r300 chips can't do full OGL 2.0 in HW.
MostAwesomeDude: But fglrx does it in SW, I guess, since they always advertise OGL 2.0 with them.
MostAwesomeDude: ...And now they have OGL 2.1 on r5xx and above. That'll be fun.
z3ro: also iirc there were some other limitations on the r3xx ATI separate stencil extension. eg you can't have differernt mask values for front/back faces.
z3ro: which makes it practically useless for stencil shadow volumes on r3xx hardware.
z3ro: although this could have just been lack of knowledge on our part.
z3ro: rather than the hardware not being capable.
z3ro: btw, can we do GL_ARB_occlusion_query with the current driver, or do we need the memory manager for that.
z3ro: etqw refuses to work without that extension.
MostAwesomeDude: That extension also blocks OGL 1.5.
z3ro: 1.5 replaces it with something else?
z3ro: I guess ETQW is detecting the GL version and choosing extensions based on that.
MostAwesomeDude: No, like a bug.
z3ro: oh, right.
MostAwesomeDude: I mean, we need ARB_occlusion_query in order to advertise OGL 1.5.
MostAwesomeDude: Although fog coords are blocking OGL 1.4...
MostAwesomeDude: Gah.
z3ro: yeah, I understand. :)
z3ro: hmm it could be tricky to write a revenge test for occlusion query because the results aren't immediate.
z3ro: so fglrx might do something complicated...
z3ro: looks like it's the "Double Z" thing...
z3ro: R5xx_Acceleration_v1.3.pdf page 127
MostAwesomeDude: z3ro: Doesn't look very fast...
MostAwesomeDude: But it's there.
z3ro: not much info about it.
MostAwesomeDude: Gah.
MostAwesomeDude: Oh well.
MostAwesomeDude: I'll oprofile compiz tomorrow.
airlied: MostAwesomeDude: most likely it just needs memory manager :)
MostAwesomeDude: airlied: Which? occlusion_query?
airlied: compiz..
airlied: granted compiz runs fine for me.. it may just be some bonghit plugins.
airlied: I would suspect something needing fbos
MostAwesomeDude: Ah.
MostAwesomeDude: Well, compiz is plenty fast for me, but I see no reason why it couldn't get faster.
MostAwesomeDude: I think compiz is a good optimization target because it gives the entire stack a good workout.
MostAwesomeDude: But yeah, mem manager will make everything better.
MostAwesomeDude: FBOs will work, FSAA will work, OGL apps in compiz will work, I'll get a job and a girlfriend..
MostAwesomeDude: Yeah, I mean, really, mem manager solves everything!
airlied: MostAwesomeDude: what do I get.. where's my goddam pony..
MostAwesomeDude: airlied: I thought ponies were implied.
MostAwesomeDude: Hence the name.
MostAwesomeDude: GEM -> Glittery Equine Manager
airlied: damn implied ponys..
MostAwesomeDude: airlied: Could be worse.
taiu: MostAwesomeDude: imho for stencil_twoside one should also set 0x4f00 bit 6 and backface things in 0x4fd4
airlied: hmm stencil ref mask
MostAwesomeDude: taiu: Hmm.
taiu: I tried it another day but apparently missed 4f00 bit, so it didn't work correctly
taiu: can try again if I'm at home ...
MostAwesomeDude: taiu: I'm taking a look right now.
MostAwesomeDude: airlied: How would I check to see whether DRM will let a range through?
taiu: good :)
airlied: MostAwesomeDude: r300_cmdbuf.c in the drm contains the ranges
MostAwesomeDude: airlied: Okay.
MostAwesomeDude: Let's see what happens, then. This'll be interesting.
MostAwesomeDude: As well as a good test of whether or not I actually understand the DRI as well as I think I do.
MostAwesomeDude: :3
taiu: MostAwesomeDude: i think it will send to kernel log if it doesn't like smth
airlied: MostAwesomeDude: I think the 4f00 is fine.. the 4fd4 might not be
airlied: MostAwesomeDude: actually is hould be fine.
airlied: I added some of the zb regs to r500 before.
MostAwesomeDude: airlied: Okay.
MostAwesomeDude: Um, r3xx docs don't have the backfacing regs.
airlied: r300 doesn't have them
airlied: we already knew that..
airlied: r400 is a bit wierd.
MostAwesomeDude: What's best way to
MostAwesomeDude: --
MostAwesomeDude: Nevermind.
MostAwesomeDude: spies r5xx-only code right next to current location
MostAwesomeDude: I'm being stupid again.
MostAwesomeDude: WTF, we don't have a default state for the stencils?
MostAwesomeDude: No, wait, just the refmasks.
MostAwesomeDude: Looks like it's safe to blank 'em. (If I vanish, we know why...)
quicksilver: we apologise for the lack of MostAwesomeDude this afternoon. Unfortunately he vanished when he incorrectly blanked a stencil buffer. Sadly missed.
vehemens: MostAwesomeDude: if looking for something to do, how about dri2?
MostAwesomeDude: vehemens: The only part of that where I would be remotely useful is Gallium IMO.
MostAwesomeDude: quicksilver: Well, still here somehow.
quicksilver: yay \o/
vehemens: MostAwesomeDude: bummer, i see 6 gallium versions. doesn't look like anybody has started on it yet.
MostAwesomeDude: vehemens: I started; check out my Mesa repo.
MostAwesomeDude: ...But I didn't get very far.
MostAwesomeDude: And we talked over some new things.
MostAwesomeDude: glisse and airlied suggest that we have three pipes: r1xx-r2xx, r3xx-r5xx, r6xx-r7xx?
glisse: MostAwesomeDude: i am not for r1xx-r2xx gallium driver
MostAwesomeDude: glisse: Only r3xx and forward?
glisse: even though it seems marcheu work could help for r1xx,r2xx
MostAwesomeDude: Hmm.
glisse: gallium requirement was pixel shader support
MostAwesomeDude: ...
marcheu: glisse: bla bla bla
MostAwesomeDude: Now I feel REALLY stupid.
MostAwesomeDude: Yeah, we don't have the necessary shader power before r2xx.
glisse: marcheu: ce que je dis c'est que moi j'ai pas envie de faire r1xx,r2xx :)
marcheu: les devs radeon sont des feignasses !
glisse: les devs nouveau sont des feignasses :)
airlied: well I'm trying to move radeon texture code to use regions stuff..
MostAwesomeDude: I recognize "asses". :3
airlied: feel free to work bufmgr :)
airlied: I've just made vram/gart pools..
airlied: need to get regions working, get textures working from regions..
glisse: airlied: i still think we shouldn't split gart/ram from user pov, while user should provide hint
airlied: glisse: I have to split in the bufmgr no matter what..
airlied: the higher levels shouldn't care except for hints.
glisse: why do you need to split in bufmgr ?
airlied: glisse: how can fake bufmgr work it needs to use the current lack of memory manager..
airlied: so it needs to do both gart and vram pools
glisse: i always forget about the no memory manager case :)
airlied: bbl
MostAwesomeDude: Huh. Okay, so looks like we aren't hooking the right stencil stuff. Joy.
MostAwesomeDude: Nevermind. Mesa just doesn't set ctx->Stencil.TestTwoSide if only using ATI_separate_stencil.
vehemens: MostAwesomeDude: had a look at your repo. don't think i can be of any use yet.
vehemens: do any of the gallium branches have a working radeon driver, or is it all intel?
MostAwesomeDude: vehemens: AFAIK nobody's got a working pipe.
MostAwesomeDude: Most of the Gallium stuff should be pretty simple. nha and I rewrote the shader system to be a lot more Gallium-like, and everything else can go straight over, pretty much.
MostAwesomeDude: The only question I have left is how we're handling state and state emission.
lagrimo: hi. i'm using a radeon x1330. how may i find the name of the GPU using it and when can i expect 3d/fglrx/compiz to work?
glisse: lagrimo: compiz is alreday working
glisse: with the open source driver or with the fglrx closed source driver
MostAwesomeDude: lagrimo: You have a card in the r5xx series; see Wikipedia for more information, or your Xorg log for the exact model.
MostAwesomeDude: Or lspci.
glisse: i think x1330 is r4xx
glisse: x1350 is r5xx
MostAwesomeDude: Oh, and 3D and compiz work. fglrx also works (for certain values of "works"), but we don't do fglrx here.
MostAwesomeDude: glisse: http://en.wikipedia.org/wiki/Radeon_R520 indicates it's in the RV515 family.
MostAwesomeDude: Unless it's one of those special ones.
glisse: then it's r5xx :)
MostAwesomeDude: XFD, Wikipedia is awesome. http://en.wikipedia.org/wiki/List_of_computer_games_that_require_Pixel_Shaders
lagrimo: ok. how can i proof, wich driver i'm using and if 3d works? I've got the impression, that there are already some problems
MostAwesomeDude: lagrimo: Which distro?
lagrimo: ubuntu 8.04
MostAwesomeDude: Hmm. Trying to remember if the newer Mesa and DRM have made it down there yet.
MostAwesomeDude: You may have to do the xorg-edgers repo.
MostAwesomeDude: https://wiki.ubuntu.com/XorgOnTheEdge
MostAwesomeDude: https://launchpad.net/~xorg-edgers
MostAwesomeDude: That's the "recommended" way to do it on Ubuntu.
osiris_: glisse: how is line width calculated?
mikkoc: guys, is it normal that different games have very different performance? for example, ut2004 runs very smoothly, doesn't use much cpu (the fan doesn't start), while tremulous (100 mb game) barely runs but isn't quite playable (10-20fps), uses plenty of cpu (fan keeps running)
mikkoc: and i think ut2004 is a much heavier game than tremulous
mikkoc: is this because 3d for r500 still needs to be optimized maybe?
glisse: osiris_: i don't know off hand
glisse: iirc there is a register somewhere about it
glisse: but you shouldn't have to wrroy about it proper fragment should be generated by the rasterizer
osiris_: glisse: I think stipple factor is passed as line width (for factor 1.0 it is 0x3baaaaaa)
osiris_: glisse: what's wrong with this fp: http://pastebin.com/m6af61828
osiris_: glisse: I'm trying to get r,g,b components from vertex color (slot 1 on pixel stack), and alpha from texture (tex coords on slot 0)
osiris_: glisse: but eventually I get whole red primitive
osiris_: when I get all colours from tex I can see stipples
osiris_: (red color is vertex color)
glisse: so if src color is 2 it's working ?
osiris_: glisse: partially, I get white stippled line,
osiris_: and it should be red stippled line
osiris_: glisse: I want to combine those colour sources (rgb from vertex, alpha from tex) to be able to discard the pixel with blending reg
glisse: osiris_: so if texture lookup is used in the rgb alu part it works
osiris_: yeap
glisse: but otherwise it doesn't, this sounds really strange
glisse: i have reading code over again but i don't see much, even though i haven't slep since a day...
glisse: sleep
MrCooper: mikkoc: sounds like tremulous may hit software fallbacks or run without acceleration altogether
glisse: osiris_: nothings looks suspicious too me
mikkoc: MrCooper: how can i find out?
glisse: osiris_: cmdpacket0(*, 1) might be bogus
glisse: osiris_: cmdpacket0(*, 0) might be what you need check with other cmdpacket usage
MrCooper: mikkoc: is there anything in the tremulous output about the GL renderer string, version etc. ?
mikkoc: MrCooper: i'll try, hold on
mikkoc: MrCooper: you're right
osiris_: glisse: cmdpackets are correct - the same as in original fp
mikkoc: MrCooper: http://zlin.dk/p/?ZmIyZThm
mikkoc: libGL error: reverting to (slow) indirect rendering
mikkoc: that is bad i guess
MrCooper: right
MrCooper: make sure it's picking up the right libGL.so.1 and r300_dri.so
mikkoc: uhm
mikkoc: how?
mikkoc: :)
MrCooper: for the latter set LIBGL_DEBUG=verbose
MrCooper: for the former, try strace maybe
MrCooper: (to see where it's picking them up from)
mikkoc: MrCooper: i got it.. installed tremulous for amd64, instead of 32bit binaries...
mikkoc: not the console is filled with these:
mikkoc: Mesa: User error: GL_INVALID_VALUE in glLockArraysEXT(count)
mikkoc: Mesa: User error: GL_INVALID_OPERATION in glUnlockArraysEXT(reexit)
mikkoc: is it bad?
MrCooper: not sure, try ignoring them and see how it runs :)
mikkoc: ok, yea it seems smooth, cpu usage is still very high compared to ut2004, but at least it's playable
osiris_: what's the name of variable that holds primitive type in GLcontext struct?
ponto: Hi, I am not able to correctly configure the radeon driver. For my dual head setup I have currently the following xorg.conf: http://rafb.net/p/Hq5TLi13.html The problem is that xrandr does not tell anything about the second monitor: http://rafb.net/p/qxe3rV65.html Here is the log: http://rafb.net/p/7J2ckk47.html The problems are: 1. If there is no external monitor it does not start with 1400x1050. 2. For the external monitor I need 94 DPI and for
ponto: the internal one 121 DPI. xrandr --dpi has no effect. 3. xrandr -o left does not work. Is there a solution for the problems?
osiris_: to enable blending one need to setup only RB3D_(A|C)BLENDCNTL regs, right?
mraudsepp: o boy, this was fun after upgrading to -ati-6.9 and xorg-server 1.4.99.905
mraudsepp: this being lack of any picture
mraudsepp: apparently it now thinks 1400x1050 is a valid screen for my smaller LCD
mraudsepp: so it picked that, and as the max is 1280x1024 I got video out of sync or whatever
mraudsepp: and I guess the framebuffer wasn't enough for DVI-0 (listed last in xrandr output) natural resolution of 1920x1200 to be used, when 1400 width was used up, and it didn't enable any mode at all. Had to go blind with xrandr in terminal to get something visible :)
mraudsepp: as from terminal it says "xrandr: Configure crtc 1 failed"
mraudsepp: http://pastebin.ca/1060455
mraudsepp: I think I can blame xorg-server or so
mraudsepp: as I had 6.9 actually since yesterday
mraudsepp: but seems like radeon cursor problem is still there. The cursor is sometimes flickering around (like horizontal white lines over all the width of it at random times)
agd5f: MostAwesomeDude, airlied: I can look up any r4xx two sided stencil differences
glisse: agd5f: i don't think there is any stencil difference btw r3xx,r4xx,r5xx
glisse: only r6xx can support full gl2 stencil spec iirc
BeerSerc: Hi there. I have just switched to 6.9.0. I have two issues here, and before I file bugs, I want to know if they are known or my faults:
BeerSerc: 1) glxinfo exits with a segfault
arekm: is someone still working on speeding up text in x console?
agd5f: arekm: use xserver from git
arekm: (pre1.5 xserver, latest ati driver, mesa 71 but still slooooow)
agd5f: and EXA
agd5f: console doesn't use mesa
arekm: x11perf shows ~70000
arekm: radeon x600
agd5f: arekm: x11perf for what? aa text?
BeerSerc: 2) after switching to console w/ Ctrl-Alt-F1, or back, the backlight of my thinkpad is at the darkest setting until I hit fn-up again
BeerSerc: its a mobility radeon X1400
BeerSerc: Is any of this known, or should I file a bug?
agd5f: BeerSerc: did you upgrade anything else in the process or just the driver? also, did you build from git or use a vendor package?
MrCooper: arekm: the xserver 1.5 branch doesn't have the EXA glyph cache yet, only master
BeerSerc: agd5f: kernel 2.6.26-rc8 from git and the radeon driver from the gentoo package
arekm: agd5f: yes, -aa10text
MrCooper: arekm: that should give a 5-10x speedup for text
arekm: MrCooper: easy to backport?
agd5f: arekm: try EXA and remove any migration heuristic options
arekm: agd5f: I'm using exa with no migration options
MrCooper: arekm: should be
arekm: uh, there is bunch of patches with glyph stuff in commit log
arekm: I'll try master instead
arekm: MrCooper: I guess I missed some important patch because now I have ~23000 http://carme.pld-linux.org/~arekm/xorg-xserver-server-glyph.patch
MrCooper: arekm: you need the following related commits as well
arekm: (16,16,ARGB): buffering glyph e02602bd
arekm: found entry at 282
arekm: found existing glyph at 213
arekm: or debug slows down the thing
MrCooper: arekm: probably, that was disabled in a later commit
mikkoc: guys, i got an X crash with some backtrace: http://zlin.dk/p/?NDc3YTU1
mikkoc: dunno if it's very useful tho
mikkoc: can anyone also check the rest of the log? i can't enable KDE4 desktop effects anymore... the screen turns black
mikkoc: to me it seems aiglx and composit are enabled... it always worked in the past
arekm: exaCopyDirty: Pending damage region empty!
arekm: ups, still missed something
arekm: woow, 308000
MrCooper: arekm: that message is harmless
arekm: http://carme.pld-linux.org/~arekm/xorg-xserver-server-glyph2.patch for 1.4.99.905
Aeris: hi all
Aeris: i have a problem with my GPU since xorg 7.3
Aeris: bioshotkey doesn't work
Aeris: ati radeon 7500 on a Thinkpad T42
Aeris: it works on older Xorg version, but not in this new version
MostAwesomeDude: I'm not familiar with bioshotkey. What's it for?
Aeris: i can enable or disable vga output with key shortcut fn+f7
MostAwesomeDude: Ooh.
Aeris: it catches bios event
MostAwesomeDude: Well, you could set up the event another way.
Aeris: and display osd on screen to show how display output is set
MostAwesomeDude: Enabling or disabling an output is done with xrandr.
MostAwesomeDude: You could write up a short script to toggle the output.
Aeris: yes i could
MostAwesomeDude: And then hook it up with acpid.
MostAwesomeDude: Or with your window manager's hotkeys.
Aeris: but bios hotkey is better :D
Aeris: and ibm acpid works very bad on 2.6.22 kernel
MostAwesomeDude: Well, unfortunately, I'm not familiar with how Xorg's key grab works.
MostAwesomeDude: I am certain that the BIOS key is just making an atombios call to the video card, just like xrandr. There shouldn't be any functional difference.
MostAwesomeDude: But it's not a video card issue, it's an X issue...
arekm: that glyph cache is cool 8)
agd5f: Aeris: bois hotkeys are disabled by the driver
agd5f: they mess with the video state behind the driver's back and often screw it up or lock up the system
Aeris: ok
agd5f: if you hook a script to the hotkey event you can have the script run xrandr to turn on the output
Aeris: with acpi i suposse?
agd5f: Aeris: yes
agd5f: Aeris: thinkwiki has lots of howtos and sample code to set itup
agd5f: http://www.thinkwiki.org/wiki/ThinkWiki
agd5f: Aeris: http://www.thinkwiki.org/wiki/Sample_Fn-F7_script
spreeuw: does that glyph accelerator speedup mozilla also?
adamk_: metalzelot, Read the man page for lspci. There's an option to get the PCI ID.
metalzelot: lspci -nn shows 7210... okay
metalzelot: thanks for your help :)
adamk_: metalzelot, Sorry.
adamk_: Give it another 6-9 months and hopefully you can get 3D with the open source driver.
metalzelot: ^^ You don't have to be sorry about that. Im so amazed to see all this radeonhd progress its amazing
simpson: metalzelot: 7210 is an RV515.
MostAwesomeDude: Oh, that's better.
MostAwesomeDude: radeon_chipset.h has PCI ID 7210 marked as an RV515.
MostAwesomeDude: So it should work fine.
MostAwesomeDude: I think.
metalzelot: RV515 is part of the R500 column on http://wiki.x.org/wiki/RadeonFeature ?
MostAwesomeDude: agd5f: Can we get some clarification since Mesa and DRM don't agree?
MostAwesomeDude: metalzelot: Correct.
adamk_: MostAwesomeDude, Well according to drm_pciids.txt, it's a radeon HD 2300...
metalzelot: thats cool :)
adamk_: metalzelot, Don't get too excited yet :-)
adamk_: I'd like to be wrong here.
MostAwesomeDude: adamk_: But according to Mesa it's in the r5xx family.
MostAwesomeDude: Hmm.
MostAwesomeDude: Try it and see, maybe?
metalzelot: but its better to try the radeon instead of the radeonhd driver?
MostAwesomeDude: metalzelot: If you're looking for feature-completeness, yes.
metalzelot: is there any advantage with the radeonhd driver?
agd5f: RV515
agd5f: I think they are actually RV550, but RV550 is basically RV515 with UVD
agd5f: so we treat them like RV515
MostAwesomeDude: DRM agrees: 0x1002 0x7210 CHIP_RV515|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP "ATI Mobility Radeon HD 2300"
MostAwesomeDude: So it should work just fine.
isum: Does someone have time to help me configure dual monitor with a Radeon HD?
agd5f: isum: http://wiki.debian.org/XStrikeForce/HowToRandR12
isum: Thanks, agd5f. I'll work on it an report back:)
adamk_: Ahh, I should have looked closer at that file.
adamk_: I thought all Radeon HD cards were r600 family.
MostAwesomeDude: adamk_: As did I, until now. :3
spreeuw: also r500
spreeuw: is under that drivername
spreeuw: r400 is under r300 driver
spreeuw: uh and for 2d the normal radeon
MostAwesomeDude: spreeuw: ?
agd5f: spreeuw: the r300 3D driver covers r3xx, r4xx, r5xx
isum_: I need help with xrandr: display1 is larger than display 2. Activating display 1 changes the resolution of display 2, even though I have it set lower. How can I stop that?
isum_: can anyone give help with xrandr?
spstarr: agd5f: oh?
spstarr: i thought the r4/5 were different enough
gentoofu: isum_: what's your xrandr output? (pastebin)
cbecht: Today I made an effort to upgrade X/mesa/drm. I'm running debian, and I pulled packages from the ubuntu xorg-edgers repository. I mention this because there is the possibility that I didn't upgrade all the parts correctly or that they track the latest git perfectly. Anyway, I'm seeing some horizontal lines on screen in certain situations. I thought I read about somebody else having a similar problem in here. Anybody got any ideas?
cbecht: x700 by the way.
cbecht: Wikipedia says that x700 is R410.
onox: when I set GARTsize to 2048576, I can no longer start compiz
onox: with 0.6.9
MostAwesomeDude: z3ro: Ping. Did you ever create a revenge dump for two-sided stencil?
isum: Can someone help me set up 3d?
MostAwesomeDude: isum: Sure.
MostAwesomeDude: Which card and which distro?
isum: Ok, so I've got a HD 2600 XT
isum: Had the default RadeonHD driver going, but it wasn't working out for me.
isum: So I added the www2.ati.com repos. and tried to install the latest fglrx driver.
isum: Now, I still get a negative on the 3d test, and it says my driver is "unknown" under sysinfo.
MostAwesomeDude: Well, this channel only offers support for the open-source driver.
MostAwesomeDude: You'll need to go to #ati for support for fglrx.
isum: Oh man....
isum: Why would you use one over the other?
MostAwesomeDude: Well, fglrx is the only driver that offers 3D acceleration at the moment for r6xx series cards like yours.
isum: Oh ok, well that narrows it down then, doesn't it?
MostAwesomeDude: Yeah.
isum: Thanks for the help
MostAwesomeDude: We're getting ready to start writing r6xx code, but yeah, you'll need to go to #ati for now.
MostAwesomeDude: No problem.