vehemens: this is interesting. on r600, if i place a window on the top right quadrant of glxgears, the bottom quadrants don't update.
airlied: Glebelg: so those page things on your SiS AGP board did they go away? and any ideas why
airlied: I'm seeing wierdness on an SiS/r200 AGP box I have (not the same one)
airlied: glisse: ^^^
airlied: Glebelg: stop having the same first letters nick as glisse ;-)
hax0r1337: i was wondering if kms in radeon does the same thing as nouveau's, when i have kms on and run 'mplayer -ao alsa -vo fbdev file' i get a black and white output and it is heavily interlaced, but when kms is off i get a nice color picture with progressive frames, does this has to do anything with kms?
hax0r1337: all from tty1 without xorg running
airlied: are you using vesafb?
hax0r1337: module.modeset=1 within boot line, so no vga or uvesafb
airlied: I'm not sure how with kms off mplayer can work
airlied: but I suspect we don't deal so well with fbdev conformance yet
airlied: the console is all we care about so far,
hax0r1337: airlied: with kms on, unless you misread it :)
airlied: you said it worked though with kms off
airlied: I just wondered what you used in that case
hax0r1337: oh in that case vga=0x37d
arekm: is drm for 3650 in standard drm git repo?
Zajec2: what drm?
Zajec2: drm for EXA and Xv yes
Zajec2: drm for 3D not yet
adamk_: I didn't think the DRM git repo was maintained any more except for libdrm?
arekm: exa&xv is what interests me
Zajec2: arekm: 2.6.30 is enought for that
Zajec2: you can use special branch of mesa/drm for older kernels, but this it not stable on some cards
Zajec2: stability fix for some cards gone mainaline only
warior: Hi, I have problem with my radeon 7000 it's not working with nvidia card. I've to monitors connected via nvidia and one via ati, everything I tried ends up with (EE) RADEON(1): FIFO timed out, resetting engine...
g-zu: warior: did it work before you had the nvidia card?
warior: i have nvidia before ati
nanonyme: warior: Do you or do you not have both ATi card and nVidia card in the computer and in use at the same time?
warior: i have them in computer in the same time, and I want to have 3 monitors running at the same time
nanonyme: That's a very unlikely to work use scenario, you know?
nanonyme: Even two ATi cards or two nVidia cards would be a pain to setup, mix-and-match is very likely to fail altogether.
nanonyme: Solution: use fewer monitors.
warior: two nvidia cards wouldn't be a problem :)
warior: and thats not a solution for me
warior: nowadays it's hard to find nvidia PCI card
suokko: nanonyme: I tough that support for multiple different cards was planed feature :)
nanonyme: suokko: Possibly.
warior: suokko: planned in Xorg or in radeon driver?
nanonyme: warior: Which drivers are you using with the nVidia card, btw?
warior: nanonyme: from nvidia site
suokko: But for now only solution is probably run different xservers and tell them not to use others cards
warior: hmmm :)
suokko: and nv binary driver doesn't play well with others drivers
warior: two X servers sounds good
nanonyme: suokko: It's nvidia, nv is an open driver. :3
g-zu: you need to make 2 different Xorg.conf files and disable hal support in X for that to work
adamk: Relatively open...
warior: but it should be hard to setup
warior: g-zu: ou shit :D
nanonyme: adamk: I thought it was fully open, just burdened by licenses.
adamk: MY understanding is that it's pretty obfuscated still, and really only maintained by nvidia anyway.
nanonyme: Oh, I recalled wrong.
nanonyme: Yeah, the trouble might've been related to the fact that the code came from nVidia.
nanonyme: I don't remember specifics, there was talk on some Debian newsletter about this long ago.
g-zu: by the way is there any way to make xinput work with hal and 2 xservers and I just happened to miss it?
nanonyme: It *might* still have been due to not being clear enough with the licenses and that the responsible people actually had the rights to make the code fully open.
nanonyme: But I sadly don't remember.
warior: g-zu: do I need to disable hal for both X servers?
warior: g-zu: or is there any "HOW TO" run two X servers :)
boghog: I had both an ATI and nvidia gpu working
g-zu: warior: that's been my experience so far, cause using x with hal completely took over the input devices so the second server didn't get any
boghog: of course I couldnt stretch desktop accross both, but otherwise both worked
nanonyme: boghog: Was it both opensource drivers or nVidia one closed?
g-zu: boghog: do you think you can help warrior set up his than?
boghog: nvidia was closed, ati was opensource
nanonyme: Right. Then it might work. Neat.
warior: this is the same in my situatuin
boghog: I just added two device sections in my xorg.conf and it worked
warior: nvidia closed and open source ati drivers
warior: boghog: and which one ati card do you have?
boghog: had to add BusID though
boghog: onboard one, rs780
nanonyme: boghog: Hmm, and a respective monitor section for the devices and mappings between devices and monitors?
warior: radeon 7000 is just piece of crap :D
boghog: nanonyme, yeah
warior: boghog: could you paste your xorg.conf on pastebin or somewhere?
boghog: (its commented out atm, went back to just nvidia card, I don't remember why)
g-zu: nice timing
nanonyme: boghog: It's kinda surprising, actually. I do know fglrx libGL leftovers could lead you unable to start X server with open drivers, apparently that's not the case with nvidia?
boghog: yeah I'm not sure, I was kind of surprised it worked as well
boghog: especially because I always thought I couldnt use both the onboard gpu and discrete gpu at the same time
nanonyme: Or did you have liGL from open or closed drivers?
nanonyme: libGL even.
boghog: I don't think I really tested libgl, not sure which one I had selected
boghog: the only problem with my setup was, I couldnt control the desktop I get on my other screen
boghog: but I think it's because I gave no relative positioning info for my screens in serverlayout
nanonyme: (Nouveau+radeon combination will possibly eventually lead you into a situation that you can run hardware-accelerated 3D on both monitors with no issues)
boghog: cool, because they both use mesa?
nanonyme: They diverge only for the actual Mesa driver, neither wipes any Mesa libraries.
boghog: yeah with my setup I would have to switch libgl everytime I wanted to launch a GL app on a different screen, I think
warior: i try your setup and now monitor connected to ati gives me 4 stripes :D
warior: rgb and white :)
warior: it's blinking
boghog: as long as it isn't smoking
nanonyme: Xorg log? :)
warior: and I have to reset the computer
warior: argh... need to restart into single user mode :)
warior: ok, still same problem FIFO timed out, resetting engine...
suokko: warior: HAve oyu tested that radeon 7000 works if it is alone in computer?
warior: i will try now
suokko: If it works then add nvidia cards one by one to system
warior: first i commented out nvidia screen
warior: booting information was displayed via nvidia, then ati monitor turn on and I can see only P/N 113-PC02000-05E
warior: ok I'm going to remove nvidia card
ForgeAus: how do I get Xorg to tell me what driver its using?
adamk_: ForgeAus, Check /var/log/Xorg.0.log
ForgeAus: ooohhh kay... what exactly am I looking for in there?
adamk_: Go down towards the bottom, and you'll see lines starting with '(II) RADEON' for example;
ForgeAus: I have radeon9600 AIO card and I think its using fglrx
ForgeAus: yes lots of fglrx(0) entries
adamk: Then it's using fglrx.
g-zu: which is the ati proprietary driver
g-zu: if you have problems with that #ati is the channel to talk about them
warior: so ati alone is working good
g-zu: do you have a corrent BusId option?
g-zu: you should be able to see complaints in Xorg.conf if not
warior: it's correct
g-zu: hmm, can you try to put back the nvidia card but initialize only ati in X see if that works?
warior: now I have ati running as primary card
warior: so system boots via ati
warior: looks like it is working
g-zu: go warrior
g-zu: both ati and nvidia?
warior: wait a moment
warior: yeah :D
warior: both cards are working :)
warior: OMFG :D
warior: such a big screen
warior: thank you guys
suokko: warior: So problem is that ati card can't be secondary card
warior: it has to be primary adapter
nanonyme: wouldn't be very surprised if that'd be a bug in fglrx
g-zu: suokko: can you add that info to the wiki, or maybe man file or something?
suokko: Can you make a bug report to http://bugs.freedesktop.org so it won't be forgot (and maybe fixed some day)
nanonyme: Oh, oops.
suokko: g-zu: That sounds like bug to me
nanonyme: Mixed two conversations together.
suokko: nanonyme: binary nvidia & oss ati
nanonyme: suokko: Yeah, the former guy just was talking of fglrx, got confused.
g-zu: yes, but while it's not fixed it should be documented if it's known about and causes headaches for other people
g-zu: just my opinion
warior: hmmm I've just enabled xinerama and killed X but whole system freezes :)
suokko: I don't even have x.org wiki account ;)
suokko: I think xinerama isn't supported by default in oss side
warior: so it doesn't start with xinerama 1
nanonyme: suokko: Still want me to add the cliprect debugging stuff?
nanonyme: http://paste.debian.net/42920/ as in, this
suokko: nanonyme: I think that isn't problem and agd5f was looking for problem
nanonyme: hopes it's not a matter of memcpy ending up moving different memory areas around in some cases than it should (and what the DRM code for earlier gens does)
nanonyme: As in, with tiling (if I remember the right term) and so.
suokko: There was a few reports about memory errors in memcpy call in your valgrind report. They might be related to screen corruption
nanonyme: That is, the memory wouldn't eg have to be detiled, memcpy'd, retiled.
suokko: I didn't analyze them
ForgeAus: 2D game sprites used to be done via tiling, but I'm not sure its the same one your referring to tho
suokko: And I don't think that r600+ support tiling yet
nanonyme: Ah, right.
suokko: (tiling is technique to map pixel non-linear so that most of area based image operations have better cache coherence)
suokko: and most of image operations are working in areas instead of linearly scanning
nanonyme: suokko: And with tiling you should get very weird results if you just assume it's a rectangle and copy it around, right?
suokko: (It might even be better to have all the data tiled in cpu side too if someone just wrote all the software fall backs to support tiling)
g-zu: what's the state of gallium for r300?
suokko: nanonyme: yes. Pixels would be all around the area
nanonyme: suokko: And if some memory in that area happens to belong to previously rendered programs, it gets rendered too?
nanonyme: (or might get)
suokko: If memcpy would do copy from outside of opengl back buffer to frame buffer outside of the window there might be anything what was left to vram
suokko: nanonyme: You might get gears in corruption if you decrese size of window where it is rendered ;)
nanonyme: Hmm, I managed to get the red gear to start corruption by changing the window size.
nanonyme: If glxgears window isn't a square, it corrupts.
suokko: nanonyme: Can you make video wrong how the corruption happens in screen (record-mydesktop is nice tool for that)?
nanonyme: Which way? Corruption in glxgears or corruption outside it?
suokko: or maybe not. It would be easier just to guess what might be happening under the hood when seeing the corruption happening
nanonyme: suokko: Another funny feature: if I make this the maximum size vertically, it draws a glxgears that's scaled to the maximum of the available size on horizontal side.
nanonyme: If I do it the other way around, I get *huge* gears that don't fit the window.
nanonyme: Oh, it's a glxgears feature, not a driver feature.
MostAwesomeDude: nanonyme: Yep. You could fix it by making glxgears scaled to MIN2(width, height) of the window instead.
warior: looks like i should forget about xinerama between nvidia and ati :(
warior: or maybe...
nanonyme: Wish bridgman was here. Answer to the question "can the GPU use untiled memory for rendering?" would pretty much kill out my suspicions. ;)
g-zu: can anyone tell me if gallium for r300 is in a state where it requires testing or not yet?
nanonyme: Though if answer was no, the location for the solution of the bug would be pretty evident...
glisse: nanonyme: yeah it can
nanonyme: glisse: Thanks.
nanonyme: It's also doing that by default?
suokko: nanonyme: default is not ot use tiled. Yo uhave to tell gpu to use tiled buffers
nanonyme: Then I'll forget that silly idea.
glisse: up to r5xx i think tiling is on by default in dri1 case
nanonyme: What about r6xx?
nanonyme: Conclusion stands then, the piece of trivia apparently isn't related at all. :)
suokko: glisse: Default in driver instead of default in hardware ;)
nanonyme: As long as it's off with r600 Mesa and r6xx-r7xx-3d DRM, we're fine.
nanonyme: Hmm, TILE_MODE says default 0x0.
nanonyme: (reading the register guide)
nanonyme: Dunno if that proves anything, hopefully yes.
agd5f: warior: the ddx doesn't post pre-atom cards properly at the moment, so they have to be primary. the kms code can, so it should work with kms
Sinuvoid: Hey guys, the r300 driver 'upgrade' that i compiled + installed actually made my gameplay for ut2004, worse.
suokko: Sinuvoid: What does "glxinfo |grep renderer" output?
Sinuvoid: OpenGL renderer string: Mesa DRI R300 (RV380 5B62) 20090101 x86/MMX/SSE2 TCL
nanonyme: wonders what a 8x8x1 macrotile looks like
Sinuvoid: suokko, now what :\
suokko: What is problem compared to old driver?
Sinuvoid: Well, now my FPS sucks.
Sinuvoid: it's like between 9 and 25
Sinuvoid: whenever i look at a moving model
suokko: osiris_: ping
Sinuvoid: so im screwed right
suokko: Sinuvoid: I guess there is still something missing in vbo support. osiris_ would know better if that is excepted with moving models
Sinuvoid: unless i missed coping a few files
suokko: Sinuvoid: You cna go back to use you Fedora mesa
Sinuvoid: err, i gotta redownload the files .-.
Sinuvoid: since i had to overwrite some
adamk_: osiris_ had said that ut2004 was one of the games he tested and saw an improvement on, so if you are using his vbo branch, I'm sure he'd like to know.
Sinuvoid: adamk_, well something here is going wrong :S
Sinuvoid: I'd love to talk to him if it's working better :D
nanonyme: wonders if it would be the same with DRI2
Sinuvoid: When does osiris usually pop on?
Sinuvoid: curse you ati!
boghog: that's not very nice :(
glisse: oss dev are to blame here not ati...
nanonyme: Whoa, that was kewl.
nanonyme: Wish I had managed to record that.
nanonyme: Apparently screen corruption getting to as far as glxgears affects glxgears' ability to resize.
suokko: nanonyme: Just don't paste that to phoronix ;)
nanonyme: I had previously glxgears spontaneously resizing without me doing anything.
nanonyme: suokko: Yeah, I don't think that'd be very productive anymore.
nanonyme: But yeah. Funny phenomena.
warior: so if I enable xinerama Xorg complaints about wrong device section or something like this :(
suokko: warior: That is because xinerama is disabled
agd5f: warior: you'll probably need to manually specify busid's in your xorg.conf
suokko: (build time configuration)
warior: ah :(
warior: I will post my xorg.xonf
warior: here it is http://pastebin.com/m21aff02c
nanonyme: suokko: http://koti.kapsi.fi/nanonyme/public/out.ogv You asked to see it... The funny thing is, that's not exactly the same as what I see.
warior: suokko: so how can I solve it?
warior: rebuild driver?
Sinuvoid: rebuild, WORLD
Sinuvoid: hello, WORDL
Sinuvoid: D -> <- L
nanonyme: Or even DWORD.
romeus1: I'm running Ubuntu 9.04. 3D support was working but stopped after I tried to install the older xserver and fglrx driver. I've reinstalled the new xserver and opensource driver now. Any idea how I can get 3d working again with the open source ATI driver?
nanonyme: Which card is this?
nanonyme: And yeah, you need to reinstall the dri components of Mesa.
suokko: warior: Sorry. sounds like xinerama is enabled for you so you need to just set xorg correctly.
nanonyme: At least.
nanonyme: And make sure that fglrx doesn't get loaded.
nanonyme: (as in, the kernel module)
romeus1: how do I check that?
romeus1: it's not loaded under hardware drivers
adamk_: romeus1, Are you at that machine now, logged into X?
warior: suokko: I don't know what I'm doing wrong
romeus1: I am
adamk_: romeus1, What's the output of 'lsmod | grep fglrx' ? And 'glxinfo | grep -i renderer' ?
romeus1: lemme check
romeus1: first one doesn't output anything, the second outputs Xlib: extension "GLX" missing on display ":0.0" four times
adamk_: Yeah, something's not right here, but at least you don't appear to have the fglrx kernel module loaded.
adamk_: romeus1, Go to http://pastebin.com/ and paste in your /var/log/Xorg.0.log file.
suokko: romeus1: aptitude reinstall libgl1-mesa-dri xserver-xorg-video-ati && dpkg-reconfigure -phigh xserver-xorg
suokko: That wil lreinstall radeon driver and clean your xorg.conf
romeus1: ok, sorry I'm a little slow
suokko: warior: I have never used xinerama
suokko: romeus1: you probably didn't clean xorg.conf after removing fglrx so that might be causing the problems
legume: nanonyme: FWIW my gears always corrupt like that even without a resize
suokko: nanonyme: The gears corruption is similar to what I got with r200 sometimes when there was something broken in mesa driver
adamk_: romeus1, Yeah, you'll have to reinstall libgl1-mesa-dri , though you don't need to reconfigure xserver-xorg
romeus1: thanks, doing that now
romeus1: do I need to reboot or simply restart X?
adamk_: Just restarting X should do it.
romeus1: ok thanks a lot guys, I appreciate it.... will restart X now
adamk_: And even that should only be necessary to get AIGLX working.
glisse: MrCooper: did you tested you patches on somethings else than AGP ?
MrCooper: glisse: maybe light testing with PCI GART
glisse: the pay more attention to object placement leads to massive pte corruption for me
Sinuvoid: Hey guys when does osiris_ usually pop online?
glisse: Sinuvoid: in a couple of hour i think
glisse: MrCooper: it seems pcie doesn't like being forced to uncached or wc
MrCooper: glisse: I did ask for that not going into 2.6.31...
MrCooper: but FWIW WC / uncached seems to work fine here with PCI
glisse: MrCooper: ppc ? :)
MrCooper: maybe we should just always set all caching bits there
MrCooper: let TTM figure it out :)
glisse: well i think we are just hidding a bug :(
MrCooper: glisse: it wasn't really intended for that change to make PCI(e) uncached anyway, that's an oversight
nanonyme: suokko: Don't happen to remember what that something was?
glisse: dammm i loose this Linus mail describing pte
EruditeHermit: Sarvatt: hey
boghog: mmm, i just ate pancakes :D
agd5f: glisse, MrCooper: you need to set the appropriate snoop bits in the page table depending on whether uncached/wc or not
glisse: agd5f: issue is not here, issue is somewhere ttm is getting page count messed up
glisse: well biggest issue :)
agd5f: glisse: ah ok
osiris_: suokko: pong
osiris_: Sinuvoid: I'm online usually at 18 - 22
suokko: osiris_: I just wanted point you at problem with UT2004 and vbo branch
suokko: (conversation around the ping)
osiris_: ok, thanks
suokko: nanonyme: I ca'nt remmber. I jsut remmber the image of broken gears that looked exactly same as yours
osiris_: Sinuvoid: with what mesa version did you get 25 fps on ut2004?
osiris_: Sinuvoid: do you have UseVBO option enabled in ut2004 config?
osiris_: Sinuvoid: are you using kms?
nanonyme: His renderer string said DRI instead of DRI2 so probably not.
suokko: osiris_: His distro is F11 so quite new everything.
nanonyme: 17:54 < Sinuvoid> OpenGL renderer string: Mesa DRI R300 (RV380 5B62) 20090101 x86/MMX/SSE2 TCL
osiris_: that could be everything between 7.5 and now
osiris_: anyone else has tested my vbo branch?
suokko: I would like but no hw :(
Sinuvoid: it's with the latest mesa version
Sinuvoid: (i compiled + installed)
suokko: nanonyme: It is possible that gears problem might be off-by one error in emit code ...
Sinuvoid: osiris_: how do I do UseVBO?
adamk_: osiris_, I tried to compile it on FreeBSD, but it failed :-(
osiris_: Sinuvoid: and 9 fps is with my vbo branch?
adamk_: I'm not in front of that machine now, but I'll try and compile it on this way and pastebin the error.
osiris_: Sinuvoid: search for UseVBO in ~/.ut2004/System/UT2004.ini
osiris_: adamk_: ok
adamk_: Is it still necessary to symlink those two files from the radeon directory to the r300 directory?
osiris_: adamk_: will add them in a momemt
Sinuvoid: osiris_, I only copied the files from mesa/lib to /usr/lib/dri and /usr/lib
osiris_: Sinuvoid: should be enough if your previous version is from current master
Sinuvoid: ok ill try the ut thing
Sinuvoid: osiris_, where do I put UseVBO
Sinuvoid: osiris_, I don't have a UT2004.ini
Sinuvoid: only .int
osiris_: Sinuvoid: there should be UseVBO option already, just change the value to true
Sinuvoid: There isnt :S
Sinuvoid: Could you pastebin your file for me?
osiris_: Sinuvoid: then add it to OpenGLDrv.OpenGLRenderDevice section
Sinuvoid: It's Default.ini :P
osiris_: it's in UT2004.ini here, maybe because I have demo version
Sinuvoid: Hah, funny. Because I do to XD
ferret_: It doesn't necessarily generate a UT2004.ini until you run it at least once
Sinuvoid: I've ran it like a thousand times lol...
ferret_: Well, that's weird
ferret_: Well, you can rename Default.ini and use that
ferret_: No reason that shouldn't work
Sinuvoid: I'll just change Default.ini ;P
nanonyme: osiris_: Have you done testing with Nexuiz on it, btw? Seems to be able to use VBO's.
osiris_: nanonyme: yes, I did. up to 15 fps improvement
Sinuvoid: osiris_, how do you enable editing in VI again?
suokko: Sinuvoid: http://www.wjh.harvard.edu/soc_help/viguide.htm
Sinuvoid: osiris_, anything else to optimize my performance?
osiris_: Sinuvoid: nope
Sinuvoid: time to take it for a test run 8)
Sinuvoid: osiris, crashed
osiris_: adamk_: I've pushed the symlink fixes
nanonyme: Imo there's really not that many commands in vi you need to know to be able to use it. Just have to know how to go to input mode and how to save and quit. :3
adamk_: Yep, just noticed, and downloading now.
Sinuvoid: osiris_, it crashed ut2004
Lethalman: I'm having a problem with my card (RS480 [Radeon Xpress 200G Series])
Lethalman: this is the bug I filled in for debian (already exists for ubuntu): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539162
Lethalman: the driver always worked until now
Lethalman: or better, I didn't use any 3d application since months, but I was sure they work correctly a while ago
Lethalman: I've tried with disabling low level fallback using .drirc
Lethalman: also disabled/enabled swcursor
Lethalman: but none of those workarounds have worked (maybe I'm doing something wrong...)
adamk_: osiris_, http://pastebin.com/m51618ab9
DanaG: hmm, is the issue low performance?
DanaG: oh yeah...
DanaG: reads bug report
agd5f: Lethalman: try mesa from git master
Lethalman: agd5f, so it's a mesa issue for sure?
agd5f: Lethalman: that error is coming from mesa
Lethalman: agd5f, ok thanks
suokko: adamk_ What version of libdrm you have?
adamk_: suokko, 2.4.11
suokko: I think you need newer libdrm
adamk_: Guess I should grab 2.4.12.
osiris_: Sinuvoid: could you pastebin the crash log?
osiris_: adamk_: does the master branch of main mesa repo compile for you?
adamk_: osiris_, It did as of the 15th of this month.
adamk_: So two weeks ago. Haven't tried since.
adamk_: Updating libdrm to 2.4.12 doesn't seem to have resolved it.
adamk_: Let me try a 'make clean' and start fresh, just in case.
osiris_: adamk_: try this patch http://pastebin.com/m330b50f3
suokko: adamk_ for me libdrm/radeon/radeon_bo.h defines the oepn macro with only 6 parameters
adamk_: Well, starting with a realclean after installing libdrm 2.4.12 didn't do anything.
adamk_: osiris_, I have your patch and applied it. Just resuming with 'gmake' still results in the same error, so I'll do a 'make clean' again.
adamk_: osiris_, Sorry, no luck, even after applying your patch... r300_draw.c still dies due to radeon_bo_open.
adamk_: Is it worth updating drm from git?
adamk_: Ack... I'm running late and have to sign off. My alter-ego adamk will still be idling in a screen session, if you have any other ideas.
osiris_: adamk: nope, I'll prepare new patch soon
Lethalman: agd5f, can I download the 7.6 snapshot instead of getting the git? it's the same right? or is there any branch for 7.5.1 maybe?
agd5f: Lethalman: 7.5 doesn't have the latest bits. 7.6 snapshot should be fine
Lethalman: ok thanks
osiris_: adamk: try this one http://pastebin.com/m5085b1a7
Sinuvoid: osiris_, sure
Sinuvoid: lmao, first error: Xlib: extension "XiG-SUNDRY-NONSTANDARD" missing on display ":0.0".
MostAwesomeDude: Sinuvoid: ut2004?
MostAwesomeDude: Ignore those; ut2k4 is built with support for all kinds of fancy proprietary X servers and nVidia GLX extensions that nobody supports.
nanonyme: Hilarious though. :)
nanonyme: MostAwesomeDude: There's standard ways to do all those proprietary things nowadays?
stalkerg: GLX nvidia extensions can`t emulated?
MostAwesomeDude: nanonyme: They're usually just optimized routines.
Sinuvoid: okay, I think UseVBO unenabled itself
nanonyme: So if a game *relied* on them existing, that's a bug in the game.
MostAwesomeDude: stalkerg: In this case, they're things like NV_gpu_program3 which Mesa internally decomposes into generic shaders.
Sinuvoid: osiris_, could you send me your UT2004.ini file?
osiris_: Sinuvoid: http://pastebin.com/m650897b
Sinuvoid: Here we go!
Sinuvoid: osiris_, I dont think UseVBO is staying True
Sinuvoid: Because my frame rate is 11-15 :(
Sinuvoid: also, any clues on fixing this?: open /dev/[sound/]dsp: No such file or directory
Lethalman: agd5f, sorry for bothering you, I see debian disables gallium, can that be a reason for that error to come?
agd5f: Lethalman: nothing to do with gallium
Lethalman: ok thanks
Lethalman: is compiling it the debian way
nanonyme: curses at technology
koolfy: aww, I crasshed and do not forgot what channel is used for mesa
ferret_: you mean #mesa ?
koolfy: it wasn't the one I joined…
koolfy: it's empty :p
agd5f: koolfy: #dri-devel
ferret_: That's weird, I was pretty sure that channel existed at one point.
koolfy: yeah thanks
koolfy: there autojoin fixed, thank you
Sinuvoid: osiris_, it doesn't crash anymore, but it's still at 13-15 fps
Lethalman: I get this error while compiling 7.6 snapshot: r300_context.h:47:34: error: compiler/radeon_code.h: No such file or directory
Lethalman: there's no compiler directory, and no radeon_code.h
adamk: FYI, that particular Xig Sundry error comes from the fact that the SDL library was built with support for switching to fullscreen mode with the X server from XiG. I used that server for quite a while when I had an r200 card.
agd5f: Sinuvoid: can you pastebin your xorg log?
adamk: osiris_: Both hunks failed from your latest patch...
suokko: Lethalman: I think you need use versoin from git then
adamk: osiris_: Never mind.... Forgot to remove the ^M...
Lethalman: suokko, it's the same, still requires compiler/radeon_code.h
adamk: I think there's a patch option for it. I should really remember what that is :-)
suokko: Lethalman: It was added in the latest commit to master
Lethalman: yes you're right suokko thanks
nanonyme: is starting to hate cache coherency more and more
nanonyme: Or rather, the switch.
nanonyme: I wish they manage to fix cache coherency checking by 2.6.31 so I too might start getting working kernels again...
adamk: osiris_: Success!
nanonyme: Kinda lame to have new kernels versions introduce new bugs. :)
adamk: osiris_: I'll be able to give sauerbraten a try in a little bit.
adamk: Maybe even ut2004 if I compile it on my fedora machine and copy the drivers over.
Sinuvoid: agd5f, what do you mean?
Sinuvoid: GAH, screw it
Sinuvoid: I don't think I got osiris_'s VBO branch.
terracon: Sinuvoid: are you on f11?
terracon: /dev/dsp is disabled by default (oss apps) but if you really really want it you can edit a file . . loacation. sec
terracon: in /etc/modprobe.d
terracon: dist-oss.conf is the file you want to edit
Sinuvoid: What do I do? >_>
Sinuvoid: What do I put in it
terracon: umcomment the line it says. It tells you what to do
Sinuvoid: what directory is it in
Sinuvoid: a file in a file?
stalkerg: r600 have KMS?
agd5f: stalkerg: not yet. it's in progress
stalkerg: ok. thx
stalkerg: r600 work with EFI framebuffer?
agd5f: no idea
stalkerg: agd5f: ok... i test it
Sinuvoid: terracon, same problem!: open /dev/[sound/]dsp: No such file or directory
Sinuvoid: and I uncommented the line
adamk: osiris_: Is there an easy way to check if the r300_dri.so I have now is from your branch?
adamk: Other than checking a game to see if it speeds up?
osiris_: checks glxgears
osiris_: it gives me ~200 fps extra with vbo branch
terracon: Sinuvoid: load the modules manually with the line /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss
Sinuvoid: copy+paste that into terminal?
terracon: yes as root " /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss"
adamk: osiris_: Interesting... I am seeing an increase of between 100-300 fps.
adamk: So yeah, that looks good so far.
adamk: osiris_: Does anything need to be done to the sauerbraten config to get it to use VBO (like with ut2004) or will it use them automaticallyy?
osiris_: adamk: it will use it automagically
adamk: Sorry for all these questions... Is there a way to benchmark sauerbraten? Or just get it to show the framerate?
adamk: Hmmm... The game hung.
adamk: I can kill it, but yeah, the game definitely hung with your vbo branch.
Sinuvoid: terracon: sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss: No such file or directory
terracon: you're missing a / infront of sbin, should be /sbin
Sinuvoid: terracon, they all have that
Sinuvoid: terracon, modprobe isnt in sbin
terracon: Sinuvoid: are you doing this as root?
Sinuvoid: terracon, yes
terracon: do a "whereis modprobe"
Sinuvoid: in etc
Sinuvoid: /sbin/modprobe /etc/modprobe.d /etc/modprobe.conf
terracon: it is in /sbin
Sinuvoid: bash: /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss: No such file or directory
terracon: did you su or su -
terracon: exit than su -
terracon: re run command
Sinuvoid: same error.
adamk: You might want to take this to the alsa channel :-)
terracon: simple error is tooo. Just reboot if you can't modprobe and it will be good to go and you will have sound in ut2k4
terracon: simple way to fix error that is
Sinuvoid: uh >_>
Sinuvoid: why would i want to do that
Sinuvoid: when clearly it's here
Sinuvoid: and always is there :S
Sinuvoid: terracon, ok
Sinuvoid: turns out the ""
Sinuvoid: was effecting it
Sinuvoid: Hey, how do you build mesa-vbo?
osiris_: clone the repo, checkout the vbo branch, then ./autogen --prefix=/usr --with-dri-drivers=r300,swrast --disable-gallium && make
Sinuvoid: okay i cloned the repo while ago
Sinuvoid: i downloaded the mesa-vebo
Sinuvoid: now i just run the command?
osiris_: airlied: do you think it would be possible to port the VBO code to r200 and r100 drivers?
osiris_: after you've cloned the repo do: git checkout -t origin/vbo -b vbo
airlied: osiris_: it should be, I need to take a look at migrating r300_draw.c there
osiris_: then the autogen command
Sinuvoid: fatal: Not a git repository (or any of the parent directories): .git
Sinuvoid: and must the mesa-vbo folder be in the mesa folder?
osiris_: I think you misunderstand something
osiris_: here's the walkthrough
adamk: Sinuvoid: You can always download the repo in firefox: http://cgit.freedesktop.org/~osiris/mesa/commit/?h=vbo
osiris_: git clone git://anongit.freedesktop.org/~osiris/mesa
osiris_: cd mesa
osiris_: git checkout -t origin/vbo -b vbo
Sinuvoid: Okay i got that.
adamk: Or that :-)
osiris_: ./autogen --prefix=/usr --with-dri-drivers=r300,swrast --disable-gallium && make
osiris_: and that's it
Sinuvoid: ok so now i cd into mesa
Sinuvoid: error: Untracked working tree file 'src/mesa/drivers/dri/r300/server/radeon.h' would be overwritten by merge.
osiris_: remove the file
nha: or use the --force flag
osiris_: or run git clean
Sinuvoid: osiris_, more errors
osiris_: hmm, I think you have run the make as a root, and now you're running the commands as the regular user
osiris_: run git clean as a root
osiris_: then the autogen command
Sinuvoid: osiris_, no no checkout?
Sinuvoid: git checkout -t origin/vbo -b vbo -f <- i dont do that anymore?
suokko: agd5f: It would be nice to add at least comment to magic number in your last commit
osiris_: I the log you pastebin'ed I can see that the checkout operation worked
osiris_: so no need to do it again
agd5f: suokko: that's the max value for that field
agd5f: MAX_LOD_mask already includes the shift
agd5f: so it was off
Sinuvoid: bash: ./autogen: No such file or directory
suokko: ok. But jsut as general point magic numbers are makeing it a lot harder for some one new toread the code
osiris_: oops, it's ./autogen.sh
suokko: So it might be good idea just to add small comment where did magic number come from if using them
Sinuvoid: osiris_, so i got your vbo branch when i did that check out?
Sinuvoid: i need to learn how to use this whole subversion system more efficiently. -_-
Sinuvoid: osiris_ I got an error 1
Sinuvoid: gmake: *** No rule to make target `depend', needed by `default'. Stop.
suokko: Sinuvoid: Do "git pull" to update your local copy
kdekorte: agd5f, have you looked at the projtex demo and noticed that the image is not scaled correctly?
Sinuvoid: 300_ioctl.c:r574: error: too few arguments to function ‘radeon_cs_space_check’
Sinuvoid: gmake: *** [r300_ioctl.o] Error 1
osiris_: Sinuvoid: probably you've too old libdrm
Sinuvoid: now what
osiris_: Sinuvoid: you could compile new libdrm, or ... rename /usr/lib/pkgconfig/libdrm_radeon.pc for a while, then run the autogen thing, and then you can unrename the pkgconfig file
osiris_: then make clean && make
Sinuvoid: what is the difference between old libdrm and the new
osiris_: API has changed
osiris_: mesa has a copy of the necessary functions from libdrm_radeon in case the libdrm_radeon isn't installed
osiris_: so if you'll rename the pkgconfig file it should you the own copy
Sinuvoid: so what do i rename it to
osiris_: whatever, just rename/move it for a while so that the autogen script doesn't find it
Sinuvoid: and then clean && make?
Sinuvoid: in what directory
osiris_: in the repo directory
Sinuvoid: mesa i suppose
Sinuvoid: bash: clean: command not found
Sinuvoid: osiris_, what about the error
osiris_: it should go away, if the autogen doesn't find the libdrm_radeon library
osiris_: adamk: so what are the results, do you seen any speed improvement in games?
Sinuvoid: r300_ioctl.c:574: error: too few arguments to function ‘radeon_cs_space_check’
Sinuvoid: gmake: *** [r300_ioctl.o] Error 1
osiris_: did you run autogen again after moving/renaming libdrm_radeon.pc?
osiris_: airlied: it would be great if you had bumped the libdrm_radeon version an added version check in mesa
Sinuvoid: osiris_, still doesnt work
Sinuvoid: even after moving it
osiris_: maybe you have another copy of libdrm in /usr/local prefix
osiris_: try installing new libdrm then
Sinuvoid: I hate having to drag you through this :(
Sinuvoid: But, do I compile it or download the new libdrm
suokko: Sinuvoid: http://dri.freedesktop.org/wiki/Building There is info about libdrm (and a lot more about compiling radeon driver)
osiris_: git clone git://anongit.freedesktop.org/mesa/drm
osiris_: cd drm
osiris_: ./autogen.sh --prefix=/usr --enable-radeon-experimental-api
osiris_: make install [as root]
osiris_: then rerun autogen in mesa dir
gmartyn: is there a faq page on getting kwin compositing to work with radeon(hd)?
hax0r1337: ou ou
hax0r1337: damn sister
Sinuvoid: Okay! It worked finally!
Sinuvoid: osiris_, ok compiled
Sinuvoid: now what
osiris_: compiled mesa or drm?
osiris_: ok, install mesa and run some games
Sinuvoid: install mesa by coping over the lib directory to the other lib directory?
osiris_: just run make install
Sinuvoid: oh ok
Sinuvoid: time to test >8D
osiris_: run glxgears first
Sinuvoid: I get flickering
Sinuvoid: 5298 frames in 5.0 seconds = 1058.777 FPS
Sinuvoid: 5160 frames in 5.0 seconds = 1029.837 FPS
Sinuvoid: 5552 frames in 5.0 seconds = 1106.827 FPS
osiris_: hmm, it's using indirect rendering probably. restart the X and try again
Sinuvoid: glxgears crashes X
Sinuvoid: ill try ut.
Sinuvoid: UT2004 crashes X too.
osiris_: pastebin the Xorg.log after crash
Sinuvoid: Where is that again ;_;
Sinuvoid: the .log
osiris_: got to go
osiris_: reinstall libdrm and mesa packages to recover 3d
Sinuvoid: do i paste the .old one?
Sinuvoid: make install again?
osiris_: no, use the yum installer or something to bring back original libraries
Sinuvoid: Oh my god >_>
Sinuvoid: So now I'm restarting?
suokko: Sinuvoid: just a way for you to get working system is to reinstall default libraries
osiris_: or you can leave as it is if you can stay without 3d until tomorrow
suokko: Because it seems like compiling did produce broken librariries
Sinuvoid: osiris_, why until tomorrow?
osiris_: because I've got to go
Sinuvoid: bye thanks for your help
Sinuvoid: Well I guess I'll wait until tomorrow.
airlied: osiris_: I assume people are running master of everything always until we do a release ;-)
Neo_The_User: Hi all!!! My dad just got me an MSI ATi Radeon 4650 1GB DDR2 Graphics Card and I was wondering, what is the latest absolute bleeding edge code out for the r7xx cards?
Neo_The_User: agd5f's 3d drm code, xf86-video-radeonhd master, mesa r6xx rewrite?
mjt: "absolute bleeding edge"
mjt: it's not committed yet
mjt: it's in agd5f's editor's memory... even if there and not just in mind...
Neo_The_User: ok whats the latest code out now that is accesible?
nbz: Neo_The_User: ^^
Neo_The_User: nbz: what?
legume: Neo_The_User: mesa master now
Neo_The_User: oh nice :) it was merged
Neo_The_User: what DDX is better for r7xx cards? -radeonhd or -ati?
nbz: Neo_The_User: you can use radeonhd or ati - this channel has more ati/radeon driver.
nbz: Neo_The_User: both, either depending on which works better for you.
Neo_The_User: well as long as they have the PCI IDs and register support for it and all that good accel stuff... kewl!
Neo_The_User: oh one more thing. any special kernel that I need?
suokko: 2.6.28 is the best
suokko: There is batches to make it work with newer kernels but they aren't in agd5f's tree
Sinuvoid: anyone got the vbo branch to work?
Neo_The_User: What version of OpenGL does mesa master have for the r7xx?
nbz: Neo_The_User: barely-working-version I doubt that question is useful yet - I hear it is too slow for most stuff until the copying speed gets fixed.
Neo_The_User: thinks about installing windows 7 64-bit editon
suokko: Neo_The_User: It will be 1.4 when classic mesa driver is ready
suokko: Current version is WIP :)
kdekorte: Neo_The_User, yeah probably at least a month until something useful for r7xx... I have the latest stuff on r6xx and while some demos work, there is a bunch more to do
Neo_The_User: oh ok. ill run windows 7 64 for a month until its at a relativley working state :)
Sinuvoid: anyone got the vbo branch to work?
kdekorte: only works for r3xx chips
nanonyme: kdekorte: Did you mean r300 driver?
Sinuvoid: nanonyme, are you working with the vbo branch?
nanonyme: Nope, I don't atm have the hardware. Should reinstall my laptop, it got sorta borked...
nanonyme: And now, I'm not participating in the development either if you meant that.
nanonyme: But yeah, afaik it should be r300 driver as in r3xx-r5xx that the vbo stuff is for.
Sinuvoid: osiris_: I think it worked! I reinstalled the fedora GL,GLU and DRI and it works even better than before
adamk: osiris_: I've discovered that sauerbraten isn't actually locking up. The game continues, as I can hear music, and if it was in windowed mode, I can continue using my desktop like nothing has happened. But the game just stops displaying anything/everything :-)
adamk: osiris_: If I run the game in gdb, and hit control-c when this is going on, this is the backtrace I am left with, though I don't know if it tells you anything: http://pastebin.com/m3746debc
adamk: Various references to radeon_bo_legacy.c
adamk: I'm going to try updating my libdrm... This is a different machine than the one I updated it on this morning.
adamk: s/this morning/earlier this afternoon/
adamk: osiris_: Alright, I updated libdrm to 2.4.12 on the same machine I'm running sauerbraten on, recompiled your vbo branch, just in case, and still get the same problem with sauerbraten. Slightly different backtrace: http://pastebin.com/m5a3bdf5c
adamk: DRM module is at 1.29.0, if it matters.
adamk: Hmmm... And the vbo branch doesn't seem to compile in F11, at least for me.
adamk: COmplaints about too few arguments to function radeon_cs_space_check in r300_ioctl.c
adamk: Oh well, time to hit the road.
nanonyme: adamk: Your libdrm_radeon sounds too old.
adamk: Hmmm... I just pull the drm git repo, configured, and made it, but it didn't generate a libdrm_radeon library
adamk: But, anyway, I am off...
nanonyme: adamk: libdrm_radeon implies the new KMS API. F11 comes with it, just with an older version.
nanonyme: Older and in this case deprecated since the API went through changes.
nanonyme: If you'd have compiled your libdrm with --enable-radeon-experimental-api, the Mesa would likely have compiled just fine.
adamk: Hmmm... osiris_ had said that KMS wasn't required for his vbo branch.
nanonyme: It's not.
nanonyme: But your libdrm claims it's KMS-compliant.
adamk: Ahhhh, I see.
nanonyme: So either you make to stop it from doing so by removing the pkgconfig file or update your libdrm_radeon.
adamk: That's sounds like a possibility, but is really annoying :-)
adamk: And where does one update libdrm_radeon from? :-)
nanonyme: It's in drm master.
nanonyme: Just have to set --enable-radeon-experimental-api.
adamk: D'oh, you already said that.
adamk: Sorry, I'm too tired to be doing this :-)
adamk: Alright, that's updated.
adamk: One last attempt at building his vbo branch on F11 before I call it a night.
nanonyme: adamk: Btw, as the API is experimental, there's no guarantees it won't change again. If you remove the pkgconfig file, you pretty much guarantee Mesa will keep compiling properly for you.
adamk: loves nanonyme.
nanonyme: (except when you have the next libdrm update in Fedora)
nanonyme: Meep. ^^
airlied: f12 libdrm is compatible
airlied: I just haven't backported to f11 as it would break stuff I don't have time to fix
adamk: Updating libdrm with that option let osiris_' vbo branch compile.
adamk: And now ut2004 hangs when on FreeBSD when using those newly compiled libraries in the linux compat tree.
adamk: Same symptoms as Sauerbraten.
adamk: I'll try and hunt down osiris_ tomorrow, I guess. He seems to have gone for the day, as I keep planning on doing :-)
nanonyme: airlied: Can I interpret that as in you're not planning any bigger changes in the API anymore?
airlied: nanonyme: not unless we find some more stupid
airlied: I'm not 100% sure the current API isn't wrong in a few places
airlied: I need to do somoe more testing
nanonyme: Btw, you didn't comment on that chipset info (for version string and so) to Mesa from kernel (since the pci id's are stored there anyway) idea. Was it seriously that bad? ;)
airlied: well it doesn't really help, since if you don't use pciids, you still need another translation method
nanonyme: Hmm, right.
airlied: we end up exporting chip families to userspace
airlied: but even then we need workaround for specific pci ids
nanonyme: Is Mesa still the right place to store the infor though? (instead of eg libdrm)
airlied: it is unless we need to use it in the DDX for example
nanonyme: Which you apparently don't. :)
spstarr: status check, how is KMS for r6xx PCIe and % pass of 3D tests?
airlied: 0 and 0
nanonyme: spstarr: The 3D code is in public repos, go try out. ;)
spstarr: nanonyme: yeah but im on F11 right now
nanonyme: spstarr: So am I.
spstarr: i could get some of F12 bits selectively
spstarr: nanonyme: you just picking RPMs from koji?
nanonyme: Nope, straight from git.
nanonyme: You were talking of r6xx 3D, right?
nanonyme: Well, then it's likely a trip for git anyway.
nanonyme: I doubt F12 is of any use for you there.
nanonyme: airlied: Using binary values for estimates? :) (as in, "is not done" -> 0, "is done" -> 1)
spstarr: rawhide burnt me once too many this time, destroying _2_ computers :D
spstarr: well, destroying as in the OS
spstarr: not hardware
nanonyme: I haven't told you even once to use Rawhide?
spstarr: no :)
spstarr: I did prior
spstarr: F10->F11 was ok
spstarr: even F9- F10 rawhide was ok
nanonyme: It depends on when you try Rawhide.
spstarr: 'when' is key
spstarr: I thought I'd try very early...
nanonyme: Some devs claim to intentionally break Rawhide from time to time to make sure people don't use it for everyday use.
nanonyme: Don't know how true that is.
spstarr: i dont think it's true, but i do believe invasive changes just break things
spstarr: rawhide != debian sid
spstarr: even if I wish it was
nanonyme: The thing is though, you should *not* be using it on a system you care about. If you are going for Rawhide, you should be emotionally prepared for having to format the partitions after a full filesystem vaporisation.
spstarr: rawhide == debian experimental 'repository'
spstarr: i will only use rawhide in a VM now
spstarr: until airlied and others switch to it
nanonyme: That's what most people do, I think.
mjg59: spstarr: No, that's not a correct approximation
nanonyme: I've been content to just replacing enough of F11 to be able to test the new stuff and switch to F12 when it's ready.
spstarr: mjg59: thats as close as I can think ;p
mjg59: spstarr: "close" != ==
spstarr: fine ~=
mjg59: Well, no
spstarr: ~ then
mjg59: Rawhide is a development branch
mjg59: Experimental isn't even vaguely a distribution
nanonyme: a ~= b is a = a ~ b though. :)
spstarr: mjg59: Debian experimental was just some packages
spstarr: mjg59: but Rawhide is not close to debian sid
mjg59: Yeah, it's difficult to find a mammal that closely resembles a peacock
spstarr: i could use debian sid for my machines and rarely would it blow up, more less due to a a package dep error or so
mjg59: Debian does very little upstream development, comparatively
mjg59: Comparing these things is not a useful way to discuss the problems that exist in rawhide
spstarr: did that new repo structure f13 proposed get approved?
soreau: gentoo isn't too terrible with it's overlays and -9999 ebuilds, just a bit time consuming. It kinda forces you to pay attention to what it is you're doing
Neo_The_User: if i put my 4650 in with my 945GM, will that cause any problems in terms of hardware?
nanonyme: soreau: That's true, I'm not sure other distros have implemented that easy git snapshotting systems.
soreau: Neo_The_User: The intel card will probably become automatically disabled
Neo_The_User: and if its not?
soreau: Disable it in the bios
Neo_The_User: oh it will be in there?
soreau: I'm assuming the 4650 is pci-e, you shouldn't have any problems with the hw being recognized
soreau: Neo_The_User: Curious, why do you ask?
mekius: Neo_The_User: You could just try it first...
Neo_The_User: k. 1 more question
Neo_The_User: if I use drm git master, mesa master, xf86-video-radeonhd master and linus kernel git tree master, will that work? or do I need the 2.6.28 kernel still regardless of wheather or not im using agd5f's drm 3d code?
soreau: nanonyme: Don't get me wrong, it has it's flaws like every other distro, but I've never had it blow up on me to the point I needed to reinstall. chroot, simple steps to protect the system and chithead are your friend ;)
soreau: I've probably had the gentoo partition around for 3
Neo_The_User: slackware has no flaws. neither does linux from scratch :)
soreau: ~3 years
nanonyme: soreau: Actually I suspect it's possible to do something like the -9999 packages with srpm's in RH-based systems.
Neo_The_User: reason why: you build it
soreau: nanonyme: Anything's possible but the likely hood of a binary based distro falling apart at the seems or exploding outrightly is more likely than source based I guess
soreau: Maybe it's because the user is forced in a way to understand what it is they're doing
Neo_The_User: i use LFS and slack but my HDD was detroyed due to ext4
nanonyme: soreau: Yeah, source-based distros don't tend to break often and when they do, they do it with style. ;)
Neo_The_User: ext4 is great though if you are all about speed
DanaG: HDD actually destroyed? Whaddaya mean?
soreau: I'm waiting for the ext4 horror stories to be replaced with decent ones before I try it
soreau: nanonyme: heh
Neo_The_User: i also compiled e2fsprogs with -funroll-loops which is why i messed it up within 6 months
nanonyme: (as in, you end up getting system-wide ABI failures and are incapable of updating anything)
Neo_The_User: -O3 as well
DanaG: that'd be a funny cereal name.
DanaG: or a space before "Loops".
DanaG: FunRoll Loops.
DanaG: nah, better without the space.
nanonyme: Neo_The_User: You probably *have* also been told that -funroll-loops and -O3 slow down execution depending on use case? You need to do profiling to find out proper optimization flags.
soreau: I for one am very pleased with my dri2 install here on gentoo. It's a lowly radeon 9600 rv350 and I've never seen it run so good and smoothly on linux in the past 5 years I've owned it. And I've tested a *lot* of different drivers/versions on it
soreau: Not to mention distros on this machine
nanonyme: Proper optimization flags are program by program.
nanonyme: Not distro-wide.
Neo_The_User: nanoyme: i have heard literally every single response for the choices i make
nanonyme: (actually might even be source file by source file but that's nit-picking)
Neo_The_User: oh yay! a ricer!
nanonyme: Neo_The_User: I'm just saying it makes no sense to use those flags unless you really get speed benefits out of them. ;)
Neo_The_User: i notice udev load 3x faster when i compile my kernel with those flags
nanonyme: Don't use them unless you *know* how to use them.
nanonyme: And knowing how to use them means you know how to do profiling.
nanonyme: (and actually do it)
Neo_The_User: nah i dont do it. i just type random CFLAGS with the word "faster" in the discription in the GCC manual
Neo_The_User: works quite well actually :)
Neo_The_User: except when it comes to compiling ext4 partioning tools or whatever
nanonyme: Actually man gcc says -funroll-loops "makes code larger, and may or may not make it faster."
soreau: Sounds funroll. I should try some random optimization sometime
Neo_The_User: well its faster for me
nanonyme: You mostly end up with larger executables which might in some cases be slower.
soreau: funrolls eyes
Neo_The_User: not for me
nanonyme: In some cases faster, some cases as fast.
nanonyme: Neo_The_User: Do your profiling. Otherwise you don't know if you benefited at all.
nanonyme: Right, if you don't know what that means, don't even bother reading the optimization flags...
Neo_The_User: or else what?
soreau: or else you end up trolling :P
nanonyme: I'm off to bed.
soreau: nite nanonyme
Neo_The_User: my flags have nothing to do with trolling
Neo_The_User: nite nanonyme
DanaG: rolling, rolling, rolling.... (that song I don't remember well at all).
DanaG: that'd ba funny variant.
Neo_The_User: DanaG: you're thinking of limp bizkut or whatever
Neo_The_User: does mesa utilize the shader model in the GPU?
Neo_The_User: or drm or the DDX?
Neo_The_User: because I'm going to be playing GRID and Americas Army which require that
Neo_The_User: (shader model 4.1)
mekius: 4650 has 0 3D support atm afaik heh
mekius: well it's in the works, but still very primative atm
mekius: primitive evn
Neo_The_User: I have a question. http://www.amd.com/us/products/desktop/graphics/ati-radeon-hd-4000/hd-4600/Pages/ati-radeon-hd-4600-specifications.aspx says the 4600 has OpenGL 3.1 support but http://ati.amd.com/products/Radeonhd4600/specs.html says it only has OpenGL 2.0 support. which one do I believe?
airlied: believe the driver
DanaG: Anyway, the question is about the hardware, not about 'radeon' or 'fglrx', right?
Neo_The_User: ya got me. sry
Neo_The_User: just hoping to get lucky
DanaG: I'm now curious, also. Odd that the site contradicts itself.
Neo_The_User: meh ill call them on friday during their hours
DanaG: hmm, they have a GPU info thingy here,
DanaG: hmm, random question, that that gpu comparison reminded me of:
DanaG: Was there ever any support for that Rage Fury Maxx in Linux?