_Groo_: seeya all later... bed time
MarcOChapeau: glisse: hi. is that you maintaining the kms stuff ?
MarcOChapeau: I've got an ugly kernel fuckup you might be interested in : http://rafb.net/p/Tias3k98.html
MarcOChapeau: glisse: ping me if you need any other info. I'd be glad to help. brb
hifi: hmm, my X hard locked
hifi: was changing a desktop on my second head while playing quake on other
nanonyme: Yays, the keyboard lock light problems seem to no longer be present with newest Fedora kernel and r6xx-r7xx-3d DRM.
nanonyme: Hmm, is it going to still be "#define DRI_CONF_FP_OPTIMIZATION_SPEED 0" for r6xx-r7xx-3d like it was for r300?
nanonyme: r600-rewrite seems to lack the definition.
nanonyme: Well, going to try.
nanonyme: Hrm.
hifi: nanonyme: how mature is the 3D support?
nanonyme: hifi: None at all? :p
hifi: yay \o/
MarcOChapeau: :)
hifi: but it can draw glxgears? :p
nanonyme: I was just wondering if I could poke around enough to get glxinfo to run.
nanonyme: Currently it doesn't run either with the r600-rewrite code due to DRI_CONF_FP_OPTIMIZATION_SPEED issues. (and possibly more issues that the macro is currently hiding)
nanonyme: Or the lack of the macro even.
nanonyme: hifi: The r6xx-r7xx-support Mesa could *start* glxgears but it rendered it very wrong and could cause lockups. I think the effort is on r600-rewrite anyway atm - and I'm no dev. (r600-rewrite atm seems to be lacking so much that as I said, you can't even yet run glxinfo)
hifi: postponing R600/R700 purchase until it's on par with R500
p4ddY`: simply use the propritary driver if you depend on 3d :/
hifi: it's not "simply"
hifi: the propietary driver sucks period
nanonyme: Except it's faster. :o
p4ddY`: only @ 3d though
hifi: I don't need speed :/
hifi: well, after quake runs fine
hifi: until then moar fps!
nanonyme: hifi: Which Quake? :p
hifi: 2
nanonyme: Does it run fine with r500? :)
hifi: yes!
nanonyme: Why buy a new card at all then? ;)
hifi: for my wife
hifi: she's going to buy sims 3
nanonyme: :P
nanonyme: Sounds like she's going to be using Windows and closed drivers then. ,)
hifi: but she uses windows only for sims, quake and linux mostly
MarcOChapeau: hifi: why not wine ?
ikaiyu: RV630 sux :(
nanonyme: MarcOChapeau: Sims 3? Are you kidding?
hifi: new game, wine and open drivers... not a good combinatio
nanonyme: MarcOChapeau: They even list compatibility with Sims 2 as garbage.
MarcOChapeau: well, someday... :)
nanonyme: Yeah, maybe by the time Sims 7 will be coming out. :P
MarcOChapeau: nanonyme: I wouldn't take what users say about compatibility as granted
nanonyme: MarcOChapeau: It's in 99/100 cases the other way around though.
MarcOChapeau: most wine users are just poor lamers who don't understand anything...
MarcOChapeau: have you ever read a wine bug report on their bugzilla ?
nanonyme: MarcOChapeau: Users rate too high compatibility usually. If it's listed as garbage, it probably really doesn't even start or install.
MarcOChapeau: it's actually really funny
nanonyme: They don't really give too low, ever.
hifi: I think even Sims 1 isnt working
MarcOChapeau: nanonyme: it depends. some users list stuff as garbage because of an issue external to wine (using vesa driver for instance...)
hifi: maybe some, but when 10 users report garbage, are all of them wrong?
MarcOChapeau: ok, 10 is a lot :p
nanonyme: would probably run a VM for games if he had CPU virtualization extensions
MarcOChapeau: I wish I could just run nexuiz or spring...
nanonyme: ponders whether Qemu state tracker for Gallium would make any sense
honk: who's using qemu anyway?
phoenix64: would be interesting for kvm really
phoenix64: though that would be more of a complete driver, wouldn't it?
nanonyme: phoenix64: Well, I actually don't think so, Gallium-wise.
nanonyme: Erm, unsure though. Might actually need userspace driver.
phoenix64: well, depends what you want to do, for the usual use (OpenGL in a qemu window) you need a translator for the host system
phoenix64: which would be a complete driver
phoenix64: well, maybe this could just be some pipe to the host gallium3d driver though, would be quite fast probably
nanonyme: Myeah.
phoenix64: if you wanted full-screen qemu, the solution would be PCI forwarding, that would be simpler but wouldn't need gallium actually :D
nanonyme: phoenix64: Meh, I'd prefer a solution that used KMS + memory manager, personally. ^^
phoenix64: hm, yeah, that would work as well
nanonyme: Would make less of a mess.
phoenix64: but that again would need a different implementation for every driver
phoenix64: as far as I understood it
phoenix64: aynways, I am again talking about things I don't know how they work :D
nanonyme: Kinda why I hoped you could do it with a state tracker. Would enable you not to care of the underlying hardware/driver implementations.
phoenix64: you could just forward the memory manager interface to the client, but that would be a solution which only worked with some host drivers
phoenix64: just had a crazy though about gallium on the client with a direct connection to gallium on the host with an opengl backend *g*
nanonyme: Why OpenGL?
phoenix64: because it then even works with other OpenGL 2.0 drivers?
phoenix64: (OpenGL -> gallium(client) -> gallium(host) -> OpenGL -> host driver, wasn't meant seriously :D)
nanonyme: phoenix64: I meant, OpenGL is just a state tracker in Gallium. Why mix it up in all of this?
phoenix64: well, you could replace the first opengl in that line with anything else, sure
glisse: MarcOChapeau: is this with lastest drm bits ?
honk: nanonyme: if you want opengl in a vm.. just use virtualbox ;P
MarcOChapeau: glisse: from last night
rah: I have an iceweasel that doesn't crash
rah: and a screensaver that doesn't whiten or blacken everything on screen
rah: I may just continue using the radeon driver :)
rah: hmm
rah: not sure what to do with myself now everything's working :)
vital: delete some random files in /usr/bin? ;)
rah: why is the display on my VGA-connected panel not as sharp under radeon as under fglrx?
rah: I DEMAND TO KNOW!
dileX: (dont shout)
dileX: If you had a look on my current screen (corruptions), you would cry
stikonas: rah: are you using native resolution?
rah: stikonas: yup
nanonyme: honk: I don't want OpenGL in a VM.
nanonyme: You completely and utterly misunderstood my point.
nanonyme: I'd want the VM to be capable of handling things on a lower level.
nanonyme: VM + OpenGL mostly sucks because you have to do DX -> OGL translations then and it's slower.
max_r: hi all. I have a question: I saw that you are developing new serialization format to replace XML called RIO. Why aren't you using something already implemented/stable/fast like google protocol buffers?
max_r: oops
max_r: wrong channel
agd5f: Looks like I missed _Groo_ again, but as I've said over and over, reverting 48156758ec2c406c28b52b3cd65e77f29d98f79b will and does fix Xv
agd5f: for kms
agd5f: or rather 8338385cd94b35f54b25cf2576890159f8dd9f71 in glisse' ddx tree
egore: agd5f, could you define "fix Xv"? is he having scaling issues like me?
agd5f: egore: yes wit kms
agd5f: *with
egore: agd5f, at least in glisses tree reverting that does sadly not fix the scaling issues. no idea about master
agd5f: egore: master is fine. it's only the kms ddxes
egore: agd5f, I'm running glisses kms stuff right now. the exact way he described in his blog
agd5f: egore: fixes it here on all the systems I tested
egore: agd5f, hmm, strange. need to verify that here
agd5f: here's a patch that does the same thing: http://www.botchco.com/alex/xorg/groo.diff
egore: agd5f, I tested it a few days ago
egore: agd5f, ok. thats exactly what "git diff HEAD~1" gives me
egore: after "git revert 8338385"
agd5f: egore: what chip are you using?
egore: agd5f, RV535
stikonas: agd5f: scaling issues also remain with RS480
agd5f: stikonas: did you try reverting that commit?
egore: agd5f, sigh, found it! I installed them to /usr/local instead of /usr
stikonas: agd5f: yes, and I did cold reboot
stikonas: I'm also using glisse's tree
egore: brb
egore: agd5f, you're right 8338385cd94b35f54b25cf2576890159f8dd9f71 fixes the scaling issues
agd5f: stikonas: are you sure you installed properly?
stikonas: agd5f: /usr/lib/xorg/modules/drivers/[ati,radeon]_drv.so have correct time
stikonas: so it should be installed correctly and I've been installing glisse's driver lots of times, and it always worked
stikonas: agd5f: can IGP chipset be the cause?
agd5f: stikonas: doubtful, they use the same Xv command stream
agd5f: as the discrete chips
stikonas: I'll try to recompile and reinstall, maybe it will help
stikonas: agd5f: still no luck :(
agd5f: stikonas: weird. maybe it is igp related
agd5f: I guess _Groo_ has an rs480 as well
stikonas: agd5f: I compared two videos, it looks much better when I revert that commit. Maybe there is another problem on IGP chipsest
stikonas: when Video is maximized, it is just cropped at about 25% from bottom and right
stikonas: but has correct scale
stikonas: agd5f: http://imagebin.org/49335
xconspirisist: hey folks, I am trying to get a 9800 working using svideo on debian 5. The xserver starts but it's just a black screen. Can't seem to see anything in /var/log/Xorg.0.log
xconspirisist: Here is my Xorg.0.log: http://paste.debian.net/36413/
agd5f: stikonas: ah, bad clipping. glisse didn't update the clip offsets when he switched to 1/12 mode. http://www.botchco.com/alex/xorg/kms_fix_clipping.diff
stikonas: agd5f: thanks
agd5f: or a full patch with the clampping fix as well: http://www.botchco.com/alex/xorg/kms_fix_xv.diff
stikonas: the second patch doesn't apply cleanly
stikonas: the 1st one does
stikonas: agd5f: it works now
agd5f: stikonas: the second patch is just a combination of the two patches I posted
MrKeuner: my system, thinkpad r52 with ati X300 using radeon driver is having trouble every now and then. When I use the user switcher tool in Ubuntu jaunty the screen freezes and the colors on screen changes into white slowly thorugh other colors. How can I make sure what the problem is?
bridgman: MrKeuner; are you able to get a log from when that happens ? Don't cause it to happen just to get a log, but if it does happen again try to get one
bridgman: this is on the laptop panel, right ?
MrKeuner: bridgman, yes laptop screen
MrKeuner: bridgman, for error should i be looking at Xorg.log or someother as well
bridgman: xorg log, I think; IIRC the symptoms indicate that the GPU isn't driving the panel any more but don't know what the current thinking is re: what might cause it
bridgman: maybe some interaction between driver & BIOS, not sure
bridgman: agd5f, was there ever an option to block the BIOS from messing around behind the driver, or was that just code ?
bridgman: seems I remember someone letting the BIOS play, maybe to enable backlight controls or something, but that might have been in radeonhd not radeon
bridgman: this is all guessing though
glisse: agd5f: i want to merge master in my tree soon this is why i didn't fixed xv
glisse: i hate ot have conflict in texturev* files ;)
MrKeuner: bridgman, there is no re: I am clueless
MrKeuner: but if it's not driving the panel anymore, why would the colors change?
MrKeuner: it's similar to the color change when a magnetic source is put next to the crt monitor
MrKeuner: but stabilizes when it reaches white
glisse: bridgman: there is a bit in bios reg 7 which i think we need to enable
glisse: iirc it's commented out in ddx
glisse: bit telling the bios that a video driver is loaded and that it shouldn't mess but i guess some gpu bios might silently ignore this bit
glisse: MrKeuner: is there issues when you switch to console ?
MrKeuner: glisse, I think I tried that and it did not work, but I am not sure
glisse: MrKeuner: could be helpfull if you could try that too
glisse: i don't know what the ubuntu tools does on user switching
glisse: but i think it's a bit like switching to console
bridgman: MrKeuner; my guess is that the panel loses drive so the liquid crystals randomly reorient themselves, but I don't know much about modern LCD internals
MrKeuner: what keyword should I be looking in the error logs, besides "| grep -i error"?
bridgman: we don't know, that's why the logs are so important ;)
bridgman: can you use pastebin and post a link ?
nanonyme: Hey.
bridgman: Ho
MrKeuner: :) OK. I'll get the error log after a freeze
MrKeuner: there was a recent freeze do you think it may still be in my logs?
bridgman: every time you restart X the log starts from zero
bridgman: I think the previous log is saved with a different name, not sure though
rah: /var/log/Xorg.0.log.old
bridgman: tx
nanonyme: bridgman: Wouldn't happen to have a clue of what the keyboard lock light issue might be related to I was having with r6xx-r7xx-3d? ^^ (or have any means of reproducing it since I'm a bit wtf with it atm)
nanonyme: That is, with the r6xx-r7xx-3d drm keyboard lights go spontaneously on and off. I'm pretty sure this should not happen and I can't immediately even understand why it's possible. ;)
rah: np
rah: nanonyme: some kernels will flash the keyboard LEDs if there's a panic
nanonyme: is fairly certain DRM shouldn't affect such things, yet it seems confusingly much like it does
nanonyme: rah: No, it's not that.
bridgman: nanonyme; someone mentioned that certain kernel problems flash the...
nanonyme: There's no panic and system works properly.
bridgman: yeah, rah beat me to it
MrKeuner: 0.log.old -> http://pastebin.com/d14b0a50f
rah: :)
MrKeuner: 20.log.old -> http://pastebin.com/m5ea4c809
rah: nanonyme: no idea then
nanonyme: bridgman: Well, that'd be a hardlock and all lights continously going on and off, I think.
nanonyme: This isn't the Christmas tree effect, this is mostly random.
bridgman: maybe there's no panic but the kernel is nervous ;)
nanonyme: But only happens with r6xx-r7xx-3d.
bridgman: seriously, no idea what would make the lights flash
MrKeuner: 20.old.log and 0.old.log modification dates are very close. 1 sec. and system froze when I switching over
bridgman: that hardware is so far away from anything the drm touches
bridgman: note to self; when pastebin is slow you still get the entire page but only a fraction of the contents
bridgman: then the contents fill in with time
nanonyme: bridgman: This might be strictly related to Fedora 11 kernels (with their KMS) though. I just don't have another machine to try to duplicate the issue with.
bridgman: I was about to post "the first log is very short" p)\
bridgman: ;)
bridgman: maybe glisse is messing with you
glisse: not newttm in f11 :)
nanonyme: Indeed.
nanonyme: Is it possible some funky stuff happens through the i2c?
glisse: don't think it's i2c
glisse: more likely we are writting to memory we shouldn't
bridgman: the last line in the second log (20.old.log) is "ddxSigGiveUp: Closing log" after unloading a bunch of modules
nanonyme: Hrm, right.
bridgman: maybe that is normal termination but I don't think I've seen it before
glisse: really hard to guess, so if you manage to avoid f11 to load radeon module it doesn't happen right ?
glisse: or with nomodeset
nanonyme: Well, I couldn't get r6xx-r7xx-3d drm to load at all unless I put nomodeset.
glisse: bridgman: not normal ending, somethings want wrong at some point
nanonyme: glisse: Got any good tips on how to produce some debugging information to find out what's happening? dmesg is perfectly clean.
glisse: i don't know how recent is the r6xxr7xx drm bits in f11
nanonyme: Well, the r6xx-r7xx-3d is self-compiled.
nanonyme: Which would cover drm.ko and radeon.ko getting recompiled.
nanonyme: (I know this shouldn't yet do anything useful but having it randomly flashing keyboard lights isn't what I'd call expected behaviour :)
MrKeuner: I can try to recreate the problem, if you think that would help
glisse: nanonyme: well i think you should wait a lot is happening on this side
glisse: just keep monitoring
nanonyme: That I will. :)
glisse: it might be fixed soon out of nowhere due to fixing somethings
nanonyme: Yeah... Then again, might be a thinko somewhere and those could be very hard to spot.
bridgman: MrKeuner, until we know what is happening I wouldn't go out of your way to recreate it
spstarr: glisse: i cant test your new stuff cause I need new X server
glisse: spstarr: yes
glisse: well it should work with older xserver but you won't have the front buffer rendering stuff
spstarr: glisse: im hoping F12 will merge this all in for when rawhide cuts off (soon)
glisse: that's the plan i think
spstarr: I hope so
bridgman: MrKeuner; unless anyone here is aware of a similar bugzilla ticket already existing it would probably be good to open a ticket
spstarr: then I can cherry pick RPMs
bridgman: attach the 20.log
MrKeuner: bridgman, OK, I'll do but not sure where to bug
DanaG: Something interesting: my 1920x1200 matte LCD somehow gives a subjective feel that's almost like paper, somehow.
nanonyme: Ahh, right.
bridgman: check the home page at www.x.org, that has info
bridgman: you'll want to register so that you'll get email when the bug is updated
nanonyme: ponders whether definitions for DRI_CONF_FP_OPTIMIZATION_SPEED and DRI_CONF_FP_OPTIMIZATION_QUALITY for r700 will be ported over from r300 next week ^^
bridgman: nanonyme; depends on whether their absence causes problems when Richard builds; if yes, then yes, if no, then no ;)
nanonyme: bridgman: It only causes problems if you actually try to run anything with the Mesa. ;)
MrKeuner: bridgman, how do you know if this is a Xorg bug or a radeon bug?
bridgman: we don't really, there's a certain amount of "best guess"
bridgman: I would file it against radeon for now
nanonyme: bridgman: It would *likely* be safe just to copy the define lines over as they as far as I read from the other r700 source files. The definitions seem to be same. (0 for speed, 1 for quality)
bridgman: and if one of the devs tells you otherwise, do what they say ;)
bridgman: s/build/build or run/
nanonyme: bridgman: I tracked that http://www.phoronix.com/forums/showpost.php?p=73584&postcount=31 to the possible absence of those definitions.
nanonyme: Will be trying out whether it makes a difference in a few minutes.
MrKeuner: bridgman, and both are reported the same place?
bridgman: nanonyme; sounds good
bridgman: MrKeuner; yeah, that bugzilla covers pretty much the whole stack AFAIK; xorg, drivers, utilities etc..
agd5f: bridgman: we stop the bios from messing around by default. I suspect MrKeuner's problem is related to starting a second instance of X
MrKeuner: agd5f, it also happens if I try to run googleearth
MrKeuner: agd5f, I should say most of the time I run googleearth, sometimes it works
agd5f: nanonyme: the DRI_CONF stuff is just a remnant of the old r300 code that the r6xx-rewrite branch is based on
agd5f: there is no r700_driconf.c so they are missing
agd5f: glisse: Ah, I figured.
agd5f: glisse: btw, did you see my drm patches? http://www.botchco.com/alex/xorg/for_glisse/
nanonyme: agd5f: Oh, right. What's the correct fix to the thing then? ;)
nanonyme: Removing the conf altogether?
glisse: agd5f: i think i pushed this patches
glisse: oups forget to push upstream
nanonyme: Egh.
nanonyme: goes read more
agd5f: nanonyme: probably just include r300_driconf.c in radeon_screen.c or where it gets pulled in for now
agd5f: or copy r300_driconf.c to r700_driconf.c
nanonyme: Right right...
agd5f: nanonyme: have you tried r6xx-r7xx-3d branch against a kernel other than f11? it may be due to bits in that kernel
nanonyme: agd5f: Sadly I haven't gotten this Fedora to boot with any other kernel, uncertain exactly why that is. I *could* always install another distro on the dual-boot.
bridgman: agd5f may be asking about whether you have tried on a "normal" kernel, ie one without all the KMS/GEM/TTM stuff
bridgman: ie a more mainstream distro than F11
bridgman: maybe "less aggressive" is better than "more mainstream"
agd5f: exactly
nanonyme: bridgman: Yeah, that's kinda what I tried too and failed to get this to boot at all... Booting Fedora with a stock kernel.
bridgman: not Fedora with a stock kernel... a distro that comes standard with a stock kernel
nanonyme: Heh.
nanonyme: Right, that would work with the dual-boot.
bridgman: maybe the 'U-word" or something like that ;)
nanonyme: Or hmm, maybe a LiveCD could do the trick too.
nanonyme: (Assuming I get it to boot on init level 3)
agd5f: nanonyme: booting fedora with a stock kernel woudl work too
nanonyme: Right, I'll work on that then. *Should* be less effort. (I hope)
_Groo_: hi/2 all :)
_Groo_: is alex around?
nanonyme: Was a few minutes ago.
nanonyme: wonders if he has his name on highlight
MostAwesomeDude: _Groo_: You might have to ping him directly...
_Groo_: nanonyme: damn, he sent me a patch that was suposed to fix xv on radeon-rewrite, but it didnt :P
stikonas: _Groo_: you need one more patch
stikonas: read logs
_Groo_: stikonas: which one?
_Groo_: MostAwesomeDude: which one is alex? agd5f?
MostAwesomeDude: _Groo_: Yep.
_Groo_: MostAwesomeDude: thanks :) btw, with the new pcie pipes and clock gating, powersave should work now with kms/dri2, correct?
stikonas: _Groo_: http://www.botchco.com/alex/xorg/kms_fix_clipping.diff
MostAwesomeDude: _Groo_: Probably, but I don't know anything about that.
_Groo_: stikonas: thats he one he sent me.. no lucj
spstarr: _Groo_: the AMD crew resides here (most of it)
stikonas: you need to revert 8338385cd94b35f54b25cf2576890159f8dd9f71 as well
_Groo_: stikonas: whit...
stikonas: that's from glisse' tree
stikonas: revert: radeon: rs690 texture fetch unit seems insane.
stikonas: _Groo_: ^^
_Groo_: stikonas: ok stikonas, thanks, im compiling, gonna report to you guys in a few minutes
_Groo_: ok compiled, restarting X, brb
_Groo_: ok, who fixed xv? so i can send my wife to bare your children :D
stikonas: _Groo_: Alex
_Groo_: stikonas: thanks to the patch you pointed me and the ones he sent me, xv is now very good :)
stikonas: _Groo_: you are using KMS?
agd5f: _Groo_: the power save stuff is not hook up yet in kms. I just added the hooks
_Groo_: stikonas: yep, for at least 3 weeks now
stikonas: _Groo_: does plymouth work for you?
_Groo_: agd5f: ahh, ok, so im gonna wait for the remaining pack
stikonas: or fbv
_Groo_: stikonas: im using kubuntu, so no plymouth so far BUT on fedora 11 rawhide, plymouth worked very well
stikonas: _Groo_: I'm also using kubuntu, and installed plymouth from PPA, it worked earlier, but now doesn't
_Groo_: stikonas: ppa please
stikonas: _Groo_: https://launchpad.net/~plymouth-dev/+archive/ppa
_Groo_: agd5f: are you guys aware of the rgb color problems with kde4/gtk and compiz?
stikonas: fbv (http://s-tech.elsat.net.pl/fbv/) seems to have the same issue. I've never used fbv.
_Groo_: stikonas: thanks
stikonas: but it seems to have the same issue
stikonas: and is easier to test
agd5f: _Groo_: yes, you've mentioned it :)
agd5f: bbl
_Groo_: stikonas: what issue are you having?
_Groo_: agd5f: did you had the time to see the regs i sent to garbled screen bug?
stikonas: the screen is not updated until I press Esc which turns plymouth off
_Groo_: stikonas: im having a similar issue when i restart X... i need to explicitly restart X with alt -e in order for him to appear. if not, the screen remains black (mouse works though)
stikonas: _Groo_: I noticed that too...
_Groo_: stikonas: probably its related
DanaG: I tried Plymouth... and it didn't even try to work, even on Rawhide.
DanaG: It just loaded details.so, instead of the default solar.
_Groo_: btw did anyone tested cairo 2.0 with dri2? im having crashes and rendering errors.. probably shader related
Neo_The_User: _Groo_ not me. sorry
otaylor: _Groo_: cairo 2.0?
Neo_The_User: rnoland_ Does freebsd come with dri2 and kms for radeon?
_Groo_: otaylor: cairo dock 2.0
otaylor: _Groo_: ah
_Groo_: otaylor: want the ppa?
otaylor: _Groo_: Fedora.
_Groo_: otaylor: oh... well, he must bem yumable somewhere
otaylor: _Groo_: cairo-dock is certainly part of Fedora. No idea about versions offhand.
_Groo_: otaylor: new version is completely opengl based, if you can do a cairo -o and see if it breaks with radeon would be nice
otaylor: _Groo_: dri2 is unlikely to be the problem (whatever the problem is) itself... it's more likely the mesa version you are using
_Groo_: otaylor: mesa from master
otaylor: _Groo_: Completely GL based? They should rename then...
_Groo_: otaylor: with glisse radeon-rewrite branch
otaylor: _Groo_: mesa from master? Does that even work with dri2?
otaylor: _Groo_: has to be one or the other :-) - master or radeon-rewrite.
_Groo_: http://jglisse.livejournal.com/1822.html
otaylor: _Groo_: Crashes for me with a compositin gmangaer enabled
otaylor: CS section size missmatch start at (r300_cmdbuf.c,emit_tex_offsets,186) 4 vs 2
_Groo_: otaylor: exactly
_Groo_: try now with cairo -i
_Groo_: it uses indirect rendering.. show work but with black backround
_Groo_: background
_Groo_: should work.. damn fingers, shopped you go!
otaylor: tries to not get annoyed by 'cairo' rather than 'cairo-dock'
otaylor: _Groo_: I saw some misrendering when I ran without a compositing manager.
_Groo_: otaylor: yeah might confuse ppl with the rendering cairo
otaylor: The crash is probably really easy to track down, if you get someone interested.
otaylor: _Groo_: cairo is the name of a rendering library. cairo-dock is a bit of a stupid name (people should name their apps by what they do not how they are implemented), but sure, whatever. But it can't be abbreviated to cairo.
_Groo_: otaylor: yes, but i believe this kind of apps bugs are inherent to the imaturity of the implementation, we dont even have fbos or vertex shaders up to speed.
_Groo_: otaylor: so i can wait till a final release. IF after a final release we still get crashes, then you get a legitimate bug.
otaylor: _Groo_: I'd would advise filing the bug in freedesktop bugzilla. bugzilla is certainly not watched all that closely, but if you don't report the bug at all, then you deserve what you get when it's still there in the final release
_Groo_: otaylor: im not saying that :D im saying i know that fundamental parts of the arquitecture are missing.. i compile dri2/kms almost on a daily basis and i have a few tests i run every day, cairo is one of them... if i see the code is there and the bug doesnt go away, then i report it
_Groo_: devs are going to ignore me if i report early without fundament anyway
otaylor: Trust me, this bug doesn't have anything to do with missing fbo's
otaylor: "CS section size mismatch" means that there's some mistake (probably a typo) in the way that gpu instructions are being emitted
_Groo_: cairo-dock: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed.
onox: agd5f: when I try to run opengl apps, the painting looks quite fubar, any idea why?
tormod: otaylor: didn't follow the whole conversation, but I got that error until I reverted 76a64958a4ca38ec27b63a909979c493c507b952
otaylor: tormod: I'm actually reproducing it with a version of mesa that predates 76a649
otaylor: tormod: so it's likely a different bug that ends up with the same assertion
tormod: otaylor: ok (my issue is bug 21776)
otaylor: (my memory is that you get that assertion when you say "I'm now going to emit X bytes of register writes" and then you emit Y bytes instead
onox: how can I get indirect direct rendering with radeon driver?
otaylor: onox: get what?
onox: I want to run opengl apps inside an opengl compositor
otaylor: onox: Ah, "redirected direct rendering"
otaylor: (Yeah, all the terminology is similar and confusing. "redirect" is refering to something different from direct/indirect, as it happens)
_Groo_: onox: follow this http://jglisse.livejournal.com/1822.html
Netzpython: hehe that looks not too stable yet ;D
Netzpython: at least on r300 based chips that will work just outofthebox mit compiz
Netzpython: *with
nanonyme: otaylor: Which is exactly why it's nice to just drop as much of the terminology as possible and try to describe what you want in the first place. ;)
Netzpython: e.g. running quake3 ontop of compiz?
nanonyme: Yeah, exactly. ^^
osiris__: MostAwesomeDude: antialiased points can be done by in fragment shader by conditional killing samples
onox: hehe, I don't quite feel adventurous yet :p
osiris__: MostAwesomeDude: take a look at mesa/progs/glsl/points.c
MostAwesomeDude: osiris__: That sounds, um, unfun.
MostAwesomeDude: But that only does the smoothing, it doesn't actually multi-sample them.
stikonas: MosAwesomeDude: do you know why r300-gallium prints lots of strange Pkt0 at 256 (8 dwords). This is debugging code or something is wrong?
MostAwesomeDude: stikonas: If it does this, then at the top of the dump, you should see "Bad CS, dumping."
MostAwesomeDude: It means that something went horribly wrong. You should pastebin the *entire* log, and also the tail of your dmesg.
MostAwesomeDude: Also tell me what you did. :3
stikonas: I can't see Bad CS but dmesg gives some info
MostAwesomeDude: Hm. You probably need to dump your stderr and stdout to a file, rather than using scrollback.
MostAwesomeDude: dmesg should say something about bad reloc or bad register, could you pastebin it?
stikonas: MostAwesomeDude: glxinfo: http://pastebin.ca/1425699, dmesg: http://pastebin.ca/1425702
MostAwesomeDude: glisse: ^^ MSPOS[01] are forbidden now?
MostAwesomeDude: Lemme make sure that 0x4010 is the right reg.
MostAwesomeDude: Nope, it's definitely the right reg.
glisse: MostAwesomeDude: MSPOS01 are closely related to 1/12 1/16 in gb_tile_config and i don't userspace to mess with gb_tile_config
glisse: but we could let userspace write mspos01 and add a info about 1/12 or 1/16 config
MostAwesomeDude: glisse: Oh, so GB_TILE_CONFIG is off-limits too?
MostAwesomeDude: That seems *really* painful to have to guess. If I guess wrong, either I get bad CS emits, or I get lockups.
MostAwesomeDude: (Bad CS if I can't write it but I try, and lockups if I need to write GB_TILE_CONFIG but I don't.)
MostAwesomeDude: Why don't we just agree to stick to 1/12 config for good? We don't need 1/16, I think.
glisse: MostAwesomeDude: it shouldn't lockup, my kernel will just refuse to execute cs
glisse: and you will see in dmesg which regs was forbidden
glisse: i got a list actually
glisse: i need to push the tools i use to build the table
mcgreg: hell, every day I am thinking about testing current git radeon drivers ;)
mcgreg: is xserver 1.6.1.901 current enough
mcgreg: +?
MostAwesomeDude: glisse: No, if GB_TILE_CONFIG is missing, and the kernel doesn't set it, bad things happen.
MostAwesomeDude: We found this out the hard way a few months ago.
MostAwesomeDude: Moreover, it doesn't seem right to not permit userspace to reach most of those registers.
MostAwesomeDude: First you take my antialiasing, then you take my RS, then you take my shaders. :3
MostAwesomeDude: And then we only have RADEON_INFO_DO_GLXINFO and RADEON_INFO_DO_GLXGEARS left. :3
_Groo_: lol
MostAwesomeDude: Now, to be fair, some of it, like GA_ENHANCE, makes sense. After all, the kernel can auto-setup those registers really easily.
MostAwesomeDude: And their contents never change.
MostAwesomeDude: But if you do that with the MSPOS, which I intend to wire up very soon, then stuff sucks.
MostAwesomeDude: glisse: I should note that r300_state_invariant.c is a good list of possible regs like that.
mattst88: mcgreg, yes, it should be
mcgreg: http://rafb.net/p/ejvfXx70.html problem during autoget.sh
mcgreg: oh looks like I was misisng somehting
mcgreg: yeah sry
osiris__: MostAwesomeDude: for depth writes to work you need to properly set up FG_DEPTH_SRC, ZB_ZTOP and US_W_FMT
MostAwesomeDude: osiris__: Yeah, I know.
MostAwesomeDude: I was mostly just trying to get the fragment shader part out of the way.
davidjheinrich: hi all, quick question: if switching from using radeonhd to ati/radeon driver, do I need to change anything in my xorg.conf other than replacing 'Driver "radeonhd"' with 'Driver "ati"'?
MostAwesomeDude: Nope.
edwin: btw does new development happen only on radeon, or changes are committed to both (radeon and radeonhd)?
otaylor: _Groo_: so, the problem is that cairo-dock is using a texture from one gl X context in another
MrKeuner: is there a new driver coming up for x300? (or a radical change in radeon?)
MostAwesomeDude: edwin: Depends. Some of us only commit to radeon, some only to radeonhd, some to both.
MostAwesomeDude: MrKeuner: There's a handful of them.
MostAwesomeDude: The 3D driver is getting a rewrite. radeon is getting KMS. There's a Gallium driver being written.
nanonyme: MostAwesomeDude: Some to neither? :p
MostAwesomeDude: davidjheinrich: IIRC all EXA ops are vsynced, so you shouldn't see tearing with text.
nanonyme: (As in, bound to be some who only do the Mesa driver stuff)
MostAwesomeDude: nanonyme: :3
otaylor: (Hmm, confusing. How would that be possible to do. It's definitely two different bo managers being mixed together)
MrKeuner: ah, Ok I heard about Gallium. Can I expect a lot from Gallium? I feel very bad about my video card currently.
MostAwesomeDude: nanonyme: I can't really think of any. I think everybody who has worked on r300 Mesa has done at least something for radeon.
MostAwesomeDude: MrKeuner: Sure, when I'm done. It'll be a bit. :3
chithead: MrKeuner: can you be more specific about which issues you experience? gallium will help for 3d and maybe video decoding
MrKeuner: chithead, I have x300 and used fglrx before and googleearth did not work when I enabled compiz. when disabled compiz it worked. Now I use radeon and i get freeze some of the times, also i cannot run googleearth.
MrKeuner: I was thinking that I got the shittiest of cards
glisse: MostAwesomeDude: kernel program GB_TILE_CONFIG once and it's enough
MostAwesomeDude: glisse: 'k. Can I has my MSPOS back then?
adamk: MrKeuner, googleearth should definitely run on radeon, but will still have problems under compiz till the DRI2 driver is completed.
MrKeuner: adamk, I don't care about compiz at the moment. I cannot run googleearth with radeon at all. it freezes the system/Or X
_Groo_: otaylor: and whats the fix?
otaylor: _Groo_: Still trying to understand what's going on. My initial explanation isn't quite right
glisse: MostAwesomeDude: given that kernel program them too it's not really needed
adamk: MrKeuner, What distribution are you using? Do you know the version of the drivers?
glisse: but i could allow them
_Groo_: otaylor: ok :)
MostAwesomeDude: glisse: Right, but at some point we might actually want to do multisampling.
MostAwesomeDude: And I don't want to have to ask the kernel for permission in order to multisample.
MrKeuner: adamk, using Ubuntu 9.04, radeon src version: 7A6B38CD8F63B2BBC872D5F
MostAwesomeDude: That's all. I'm okay with letting the kernel have registers that I never ever ever need to touch.
nanonyme: Hey, yay. I finally got a stock 2.6.29.3 to work. :3
nanonyme: Oh, for the love of...
MrKeuner: adamk, filename: /lib/modules/2.6.28-11-generic/kernel/drivers/gpu/drm/radeon/radeon.ko
nanonyme: Seems slub is failing *hard* on my kernel. *chuckle*
tormod: MrKeuner: you could try the mesa radeon-rewrite but don't have high expectations at this point
tormod: MrKeuner: https://launchpad.net/~xorg-edgers/+archive/radeon
MrKeuner: tormod, so all i am experiencing is something that is known and being tried to be fixed?
MrKeuner: can i expect Gallium to fix those things?
adamk: I'm fairly certain that lockups when running googleearth are not known.
bridgman: I think we actually expect GoogleEarth to run OK, but it keeps changing
bridgman: so it's possible that the latest version of GE has problems
adamk: It does?
bridgman: keep changing ? yeah
tormod: I have reported googleearth lockups several times
adamk: bridgman, Sorry, I read "keeps changing" as "keeps crashing"
adamk: I guess I'm just lucky that I haven't had any GE related lockups in well over a year.
bridgman: adamk; keeps changing and keeps crashing frequently go together ;) ;)
MostAwesomeDude: agd5f: IIUC the vert shader for passing through colors should be the same as the vert shader for passing through texcoords?
MostAwesomeDude: Only the RS differs?
tormod: adamk: do you use DRI ;) seriously, you use suspend to ram also?
spstarr: I think tonight will be sunny side up eggs and english muffins :)
adamk: tormod, I do use DRI, frequently.
tormod: MrKeuner: it depends a bit on what card you have
spstarr: Omega-3 Eggs of course
adamk: tormod, I only suspend to ram on my laptop which is intel.
spstarr: bridgman: its going to be interesting to see fireworks around the neighbourhoods from 15 stores up
spstarr: i have such a wide view and should see a nice light show scattered around
tormod: adamk: I suspend to ram without problem on my desktop (RV515) but on my laptop it is not so reliable (M26)
spstarr: im glad airlied is having a nice time off, he deserves every minute of that
tormod: anyway I can make GE lockup the laptop in a few minutes
otaylor: glisse: has any thought been given to sharing of textures between contexts? (shareList argument to glXCreateContext) - seems that the bo manager needs to be shared as well for that
tormod: MrKeuner: don't expect much from gallium in the near future, radeon-rewrite is your only hope :)
bridgman: spstarr; good point, I forgot about the fireworks
spstarr: :-)
bridgman: it sounded like they let off firewroks over at Mosport yesterday but that was around 10am
spstarr: odd
stikonas: MostAwesomDude: I still get "Forbidden register 0x4010 in cs at 3"
MostAwesomeDude: stikonas: I know.
MostAwesomeDude: That's the MSPOS.
MostAwesomeDude: Either comment it out in r300_state_invariant.c or wait until glisse changes kernel again.
spstarr: MostAwesomeDude: I wanna play Gallium...so i just build the driver with existing rawhide bits and try stuff out? :)
MostAwesomeDude: spstarr: Builds and runs on current Rawhide.
spstarr: MostAwesomeDude: so just grab mesa master bzip2 it and turn it into an RPM
stikonas: spstarr: you won't see anything more than triangles
stikonas: or lines
spstarr: stikonas: i can at least test it.. as long as it doesn't always wedge GPU :)
MostAwesomeDude: spstarr: You won't be gettin' much out of it. progs/trivial shouldn't wedge, and most of it draws correctly.
MostAwesomeDude: progs/demos has some working, some assert-dying, and some, like copypix, might lockup.
spstarr: so you have it just drawing primatives?
stikonas: MostAwesomeDude: tri/clear is not working?
MostAwesomeDude: stikonas: progs/trivial/clear works fine, provided that you comment out the offending state in r300_state_invariant.
MostAwesomeDude: I can't make something work with glisse's latest kernels without breaking hybrid kernels (like Rawhide's).
stikonas: that's understandable
MostAwesomeDude: And TBH I'd rather keep developing against Rawhide's relatively stable API than keep chasing glisse. I'm trying to accomodate him where possible though.
MostAwesomeDude: And eventually, when his stuff moves into Rawhide and staging, I'll gladly change everything in an instant. I just want a measure of stability.
MostAwesomeDude: Gallium, to me, is an opportunity to say, "Fuck backwards compatibility." So I'm really not wanting to do any compat chasing.
glisse: otaylor: you could share bo through kernel
glisse: it's the flink stuff
glisse: at least this was the name last time i used it :)
spstarr: MostAwesomeDude: hopefully as soon as f12-devel branch switch to rawhide, newttm can go merged in
MostAwesomeDude: spstarr: Yep.
MostAwesomeDude: glisse: flink works in newttm? Yay.
spstarr: i dont think there will be a problem with that happening though, airlied mentioned this was the goal
spstarr: so, sooner the better
MrKeuner: tormod, ati x300
glisse: MostAwesomeDude: it should it's core gem stuff
spstarr: glisse: why not merge your stuff into the f12-devel branch now when airlied gets back? or ask ajax?
spstarr: glisse: there are F12 kernels based of 2.6.31-rcs i believe
otaylor: glisse: well, if you were sharing through the kernel, you'd have to be able to write relocatoins for different buffer managers into the same cs
spstarr: kernel-2.6.30-0.81.rc5.git1.fc12
spstarr: not 31..
spstarr: 30. i thought 30 was close to release ;p
otaylor: glisse: seems simpler to share the buffer manager
otaylor: (Not sure why more than one buffer manager is used for the same process space to begin with)
glisse: otaylor: sharing is through global id
glisse: it's really easy
otaylor: glisse: but id's are local to the buffer manager
glisse: apps which create the bo ask for a global id if it wants to share bo
glisse: then it communicate to the others apps (we are not aware how and don't care) this idea and the other app could open the bo with the global id and get an app local id for it
otaylor: glisse: but you don't know that you are sharing buffers untli you create the *second* context
glisse: otaylor: dri2 is using this mecanism
glisse: otaylor: first app which create the bo as to know that it will share it
otaylor: glisse: Sure, you could share buffers at that level, but mesa isn't set up that way - if you have two contexts that are sharing textures, they share the mesa texture objects
glisse: otaylor: i guess we will need to hack into mesa for that but best things seems to use flink as it will works for intel too
otaylor: glisse: why don't you think it would work to just share a buffer manager?
otaylor: glisse: the way it work now, is that all context for the same X screen share a buffer manager
otaylor: glisse: the reason that cairo-dock is breaking is that it opens two X displays
glisse: otaylor: it would work too, i would just be heading to the easiest thing and you likely right that sharing the bufmgr might be the easiest
otaylor: (it looks like that probably breaks with intel dri2 as well)
MostAwesomeDude: otaylor: Wait, so cairo-dock is sharing a tfp texture between two GL contexts?
glisse: thing is in kernel id are associated with drm file holder iirc
MostAwesomeDude: Or what exactly was it that was breaking?
otaylor: MostAwesomeDude:no, just a normal texture
MostAwesomeDude: Is sharing a texture between contexts legal? It sounds like one of those things that shouldn't work but did anyway.
otaylor: MostAwesomeDude: the breakage is that according to the glx spec that you can use the "shareList" facility of glXCreateContext to share textures between any two dircet contexts in the same process, even for different displays
otaylor: MostAwesomeDude: but the dri buffer manager is bound to the X screen
otaylor: MostAwesomeDude: So,once you use the sharelist, mesa starts passing a buffer from one buffer manager, to code that's using the other buffer manager
MostAwesomeDude: otaylor: Shouldn't be a problem, just force the BO manager to get global handles on the textures.
MostAwesomeDude: That was one of the entire points of global BO...
bnijk: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE)
otaylor: MostAwesomeDude: and things get confused - the particular breakage was that the relocation code was saying "hey, there are relocations to use this buffer for both read and write in the same command stream" - but it was actually two buffers that had the same id but different buffer managers
bnijk: this supported?
MostAwesomeDude: bnijk: Yes.
bnijk: ok
bnijk: can i swap out the drivers from catalyst while it's running ;)
otaylor: MostAwesomeDude: as I was saying to glisse, that's possible, but then you'd have to have to havea *list* of bo's for the mesa texture, one for each bom it is used in
MostAwesomeDude: otaylor: Ah, so the BO handling code in userspace needs to be more robust.
bridgman: depends, do you like spectacular hangs ?
MostAwesomeDude: bnijk: No.
bridgman: seriously, you need to fully uninstall the Catalyst driver first
MostAwesomeDude: otaylor: I wonder if it's possible to just always have a strongly unique serial number for each BO.
bridgman: or you'll have problems running the open source drivers
bnijk: this is xf86-video-ati or xf86-video-radeonhd?
bridgman: the Catalyst install plants a kernel driver and also overwrites a couple of other files
bridgman: you need to back those changes out first
bnijk: no kidding
bnijk: how's the 3d support on the radeon drivers for my card
bnijk: i want to play assaultcube :(
bridgman: it's getting there; the Xpress200 doesn't have vertex shader hardware so it'll be slow in anything that makes heavy use of vertex shaders
MostAwesomeDude: glisse, otaylor : Seriously, why not make BO numbers more global, regardless of whether they're supposed to be local or global?
bridgman: GL support is around 1.3-1.4
bnijk: how common is that
bridgman: not sure what assaultcube needs
bridgman: not that common
bridgman: yet
bnijk: is there any progress on getting them to open the catalyst code
bnijk: is that possible
MostAwesomeDude: bnijk: We don't want the Catalyst code. It's full of suck and fail.
bridgman: not likely; it's also huge
bnijk: surely it would help fix the problems with the open source code
bnijk: the spec is closed, right?
bridgman: the open drivers have maybe 100k lines of hw-specific code, Catalyst has maybe 10M
bridgman: that's why it goes faster but it needs a lot more people to maintain
bnijk: wow
MostAwesomeDude: bnijk: Nope, the hardware documentation is open now.
bnijk: nifty
bnijk: how long until this vertex shading stuff is completed
bridgman: it's your chip that doesn't have vertex shader hardware
bridgman: that won't change
bnijk: oh ok
otaylor: bnijk: yes, being able to look at the catalyst code would be a huge help> On the other hand, considering the consierations about drm in particular, and other parties ip in general, I would believe bridgeman that it's unlikely to happen
bridgman: so vertex shaders run on the CPU, but I think there's a lot of room for improvement there
MostAwesomeDude: bridgman: Less than you might think. Mesa already does runtime vert shader MMX, SSE, SSE2, etc. :3
bridgman: we do have people looking through the code to help answer questions for open source devs though
bridgman: is it JIT-compiled code already ? If so then yeah, not much more to be gained
bnijk: you mean like, corporate moles?
bridgman: I had been told that SWTCL on fglrx was a lot faster than Mesa but that's just anecdotal
MostAwesomeDude: $ mplayer -ao:hands -ss gig piano.music
bridgman: yeah, corporate moles ;)
bridgman: some of the devs work for AMD
bridgman: the rest ask agd5f and then he asks around internally
bridgman: sometimes they ask me but I think they trust agd5f more ;)
bnijk: don't they have to sign NDAs?
bridgman: the AMD devs ? sure
otaylor: MostAwesomeDude: don't really know what the implications would be. I'll ask krh about it tomorrow if I think of it
bridgman: there are also a number of devs working under NDA who get early access to the info, but we try to push everything we can out public without NDA
bridgman: we don't want NDA stuff going in the code anyways, it's just to help understand the hw better
bnijk: there has to be a better system than this darkroom spec crap
bnijk: what a world
bridgman: I'm open to suggestions
otaylor: bnijk: the problem basically is that great specs dont' exist
bnijk: anarchy! \m/
bnijk: then how do they produce the hardware ;)
bridgman: sure, and the rioting mob is going to think "hey, we should all sit down and develop billion transistor GPUs"
bridgman: right after we knock over this liquor store
otaylor: bnijk: so amd put a lot of effort into cleaning up their specs for release, but they don't cover everything, and are pretty cryptic
bnijk: we have different ideas about what will happen bridgman
bridgman: the issue is that we have tons of design documentation for the hardware internals and software internals, but since we design the hw and sw together with colocated teams our design process doesn't need to generate formal programming guides
bridgman: what do you see happening ?
otaylor: bnijk: the driver people go talk to the hardware people as necessary, there's a lot of knowledge in people's heads, in comments in the catalyst source code etc. (I'm assuming, from a completely external position, based on every other project I've worked on.)
bnijk: cryptoanarchy
bnijk: the development of a private financial sector
bnijk: literally private
bridgman: we already have that, don't wek ?
bnijk: nope
bnijk: that's why we have black markets, and IP regulations, etc
bridgman: I'm not following; IP regulations are how value is kept within the private market
bnijk: information no longer has value
bnijk: it's entirety artificial
MostAwesomeDude: bnijk: If you want crazy rebel-against-the-machine stuff, #nouveau is reverse-engineering nVidia cards.
bridgman: black markets spring up when public markets are forced out of whack
bnijk: price is the equilibrium of supply and demand, remember
bnijk: the supply is now infinite
bnijk: or practically infinite
bridgman: supply of what ?
bnijk: information!
bridgman: it always has been; turning the information into something specific and tangible has always been the hard part
bnijk: this is more like if you're talking about DRM'd mp3s than technological patents
bnijk: but those are artificial nonetheless
MostAwesomeDude: Spoken like a pirate.
bridgman: arr
MostAwesomeDude: But seriously, just RE whatever you don't have docs for.
bnijk: heh
bnijk: well remember the legal front against REing
MostAwesomeDude: Only the truly evil guys (Apple) will sue you for RE. Even nV, MS, etc. are okay with it.
bnijk: people like apple a lot less than they used to ;)
bridgman: honestly the biggest barrier to REing is that it's really hard, and the few people who can do it would rather be doing something else
bnijk: did they crush the apple second party hardware market under jobs or that other guy
MostAwesomeDude: really has to go now
bnijk: waves
bridgman: other guy; I was part of the second party hardware market making graphics cards ;(
bridgman: the guy from pepsi, hold on I'll remember his name
glisse: MAD|music: security
DanaG: oh yeah, random: reallyslickscreensavers has cool fireworks.
bnijk: from pepsi?
rehabdoll: i just realized that radeon names the first xrandr primary output DVI-1 and the secondary DVI-0. confusing
rehabdoll: *grumble*
bridgman: john sculley
bridgman: rehabdoll; I think the naming is less predictable than that; connector closest to the bottom of the card gets the lowest number or something like that
soreau: rehabdoll: You either have your connectors switched up or your monitors, whichever ;)
DanaG: hmm, other parties' IP... I'm curious... are you even allowed to say whose IP you have that there are issues with?
bridgman: if you're asking me, generally no
bridgman: if the agreement allows us to discuss, then yes
rehabdoll: :>
bridgman: but for the 3d stack it's more competitive issues than 3rd party IP
bridgman: but anything related to multimedia has both third party IP and DRM agreements
bnijk: blinks
DanaG: frankly, if those drm-pushers would suddenly cease to exist.... that would be a win.
bnijk: DanaG: as long as it's profitable, they'll do it
bnijk: so the trick is to make it unprofitable ;)
DanaG: Things like that CableCard.... I don't so much take issue with the "Vista Only" as I do with the "Must be one of 5 approved systems in the whole world".
DanaG: er, 5 types of systems. Probably more like 10 or 15... but you get the point.
bridgman: it's not so much a "vista thing" as "OS which has implemented a suitable environment to run protected DRM code", where protection includes protection from the system owner not just outsiders
DanaG: well, the thing with cablecard was that CableLabs didn't just say Vista Only; they also had to have a specific seal of approval in the BIOS. So, it's anticompetitive.
bnijk: lol
bridgman: bnijk; the trick is to stop scaring the copyright owners by insisting their property should be free; focus on the impediments to legitimate users and convince the copyright owners that they can make as much or more money without DRM
bnijk: that's not the trick
bnijk: their 'property' is already free ;)
bridgman: I don't follow
bnijk: imagine a guy trying to sell you air in a tank
bnijk: normal air
bnijk: and then he pays the government to pollute the rest of the world's air
otaylor: bnijk: so, what do you do for a living?
bridgman: sure, don't you pay to get SCUBA cylinders refilled ?
bnijk: whatever i can
bridgman: or do you take a compressor on vacation ?
bnijk: that's paying for the use of the compressor
bnijk: not the air itself
bnijk: well, i hope so
bridgman: you've pretty much described the bottled water market ;)
bnijk: i'm going to start distilling my own water
bridgman: and I live in the place where it seems like most of the bottled water comes from
bnijk: i don't want flouride or asbestos, and i don't want to pay 8 dollars per gallon
bridgman: you can probably just filter, it's cheaper and gets most of the stuff you'd worry about
bridgman: why not flouride ?
bridgman: I'm with you on the asbestos though ;)
bnijk: look it up for yourself
bnijk: this is quite a divergence from talking about hardware specs ;)
bridgman: don't need to look it up, I saw Dr. Strangelove ;()
bnijk: oh don't give me that
bnijk: i'm no turgidson
bnijk: er, jack d ripper
bridgman: I'm kidding, just happened to watch the movie recently
bridgman: I do agree that fluoridation may no longer be necessary in a lot of areas
bridgman: but there seems to be a bit of a circular argument against it
bridgman: people are opposed because they feel that some other people might not want it
bridgman: and it's unfair to force it on those people
MarcOChapeau: glisse: so, did you find anything interesting in the backtrace I sent ?
glisse: MarcOChapeau: haven't had time to look at that but it looks strange, it shouldn't oups anymore
glisse: MarcOChapeau: what where you doing when it happened ?
bnijk: that's circular
MarcOChapeau: glisse: I was simply booting. it seems it locked up after x started
bnijk: but the real reasons for the opposition to it are things like uh
bnijk: is flouride toxic
bridgman: yeah, exactly
bnijk: does flouride cause tooth decay in large doses
bnijk: is it carcinogenic...
bridgman: haven't heard that one; there does seem to be a general concern that current dosage might be too high
MarcOChapeau: glisse: could it be that I missed one of your updates ?
bridgman: which almost definitely means that it is; our concept of safe threshold goes down by about 50% every 10 years for pretty much everything
DanaG: oh yeah, 1920x1200 framebuffer console == tiny text.
DanaG: Now we'll start needing DPI scaling on the console. =þ
bnijk: http://www.nofluoride.com/fear_of_fluoride.htm
glisse: MarcOChapeau: what is the last commit id on your tree ?
bridgman: anyways, this should probably go to #flouride or something
bridgman: #fluoride
bnijk: lol
bnijk: 16:45 -ChanServ(ChanServ@services.)- #fluoride is now registered to bnijk.
MarcOChapeau: is gonna feel stupid...
MarcOChapeau: glisse: command ? (I'm not yet git fluent :p )
rah: MarcOChapeau: git log
rah: speaks basic git :)
MarcOChapeau: :)
MarcOChapeau: glisse: weird... commit 10439f0c5f782ea9e77212be1f8a6e384527693d from jan 22 2009
glisse: git log |head | grep commit
MarcOChapeau: oh no....
MarcOChapeau: I might know what happened there
MarcOChapeau: I'm really not git fluent it seems. I'm using the master branch
MarcOChapeau: glisse: spank me... hard
rah: O_o
MarcOChapeau: I didn't go through your whole tutorial it seems
osiris__: MAD|music: bridgman is right. classic mesa shader program executor is slow as hell, but gallium is completely different story (RTASM module is used there for creating assembly code from shader programs)
terminatorul: Hello
terminatorul: I have an Radeon 9250 card
terminatorul: And it is so slow ...
terminatorul: Are there some driver options to improve the fps ?
terminatorul: Is "AGPFastWrites" going to cause instability, as the manual page says ?
adamk: terminatorul, It might.
adamk: Are you sure that 3D acceleration is enabled?
da1l6_: terminatorul: what does glxinfo | grep renderer output?
terminatorul: OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x x86/MMX+/3DNow!+/SSE TCL
adamk: Well, 3D acceleration is working.
adamk: You can certainly try some of those options in the man page, but I'm doubting it will ever run WoW well under wine.l
terminatorul: WoW does not run well under wine ?
adamk: On that particular GPU? I doubt it very much.
terminatorul: I saw the CPU is also loaded as sound playback is interrupted often
da1l6_: terminatorul: do you run it in opengl mode?
adamk: I've never tried it on any system with wine, personally, but that's rather old GPU.
da1l6_: its a damn old gpu actually ;)
terminatorul: Oh ... I guess not
terminatorul: How do I do that ?
terminatorul: In-game video settings ?
da1l6_: not sure, never played wow. just thinking i read that there is some cmdline switch for it. do a websearch
terminatorul: :(
terminatorul: I thought I could play at least WoW, as I know it does not require performant GPUs :(
terminatorul: One question: can you please tell me how can I see how much video memory the driver sees on my video card ?
terminatorul: Also, is "AccelMethod" "EXA" still not well-tested ?
da1l6_: i am pretty sure it is
da1l6_: should be the default
chithead: look at Xorg.0.log
terminatorul: The default is the stable XAA
chithead: EXA is default for r600+
terminatorul: By the radeon man page
terminatorul: /var/log/Xorg.0.log ?
bridgman: I think the change to make EXA default only happened in the last week or two
bridgman: man page might not be updated
terminatorul: Well I installed radeon driver from source last week :)
terminatorul: Ok
bridgman: you can look in the log and it will tell you many things
bridgman: and if you pastebin the log we can tell you where to look
terminatorul: Anyway I have an R200, so does this mean the default is still XAA for me ?
da1l6_: radeon manpage here says "The default is EXA"
bridgman: don't know; I think it defaults to EXA for you as well
bridgman: it wasn't so much the driver's EXA code becoming more stable, but the X server EXA code becoming more efficient
terminatorul: Well, installing from source often does not install man pages :(
terminatorul: I do not know why
terminatorul: Ok, so I gues I could set AccelMethod to EXA, since it seems it is supported
terminatorul: I mean well supported
da1l6_: it will not increase 3D performance, though.
terminatorul: Because it is likely it was already the default ?
da1l6_: no, because EXA is for 2D acceleration.
bridgman: terminatorul, what 3D programs are you trying to run ?
terminatorul: "better performance for the render and composite extensions"
terminatorul: Is that for 2D ?
terminatorul: I want to play World of Warcraft
terminatorul: I saw with google it has (or had) an -opengl option
terminatorul: Maybe that will help
terminatorul: Also, If I play Heroes III, which is 2D, will I get 2D acceleration ?
terminatorul: I tried with Age of Empires, also 2D, and it works very slow. But I am not sure it is because of the graphics, maybe AoE has something with wine
spstarr: those were some good eggs :-)
spstarr: loves sunnyside up eggs
spstarr: flip 'em for 6-10 seconds and serve once the white side is cooked with slight golden brown
bridgman: Render and Composite extensions are more related to 2D; that's where EXA will help
bridgman: Render uses the 3D engine but it's a 2D API
bridgman: 2D games on Wine tend to be generally bad AFAIK
bridgman: there isn't a good mapping between the Windows 2D API and the ones in Linux
bridgman: are there any native Linux apps you're trying to run ?
spstarr: bridgman: I'd love to have OpenGL Sunnyside up eggs in 3D :)
bridgman: I'm sure there's a fried egg screensaver
spstarr: although the texturing of the egg shape might be a problem
spstarr: :)
valgaav: from my experience if I had a 2d game it was "hmmm this should work with wine"
valgaav: but with 3d it's more like "hmmm it probably will not work why should I even try it ?"
DanaG: Wine can't do surround sound. :(
spstarr: bridgman: might need freeglut no?
bridgman: don't really know
bridgman: anyways, terminatorul if you were running with XAA before then you should see a useful improvement with XAA
bridgman: if you look in your log you should be able to tell which accel method is being used
bridgman: or pastebin it and we'll tell you
da1l6_: he is alreay gone
bridgman: huh, you're right... I kinda felt like I was talking to myself ;)
MostAwesomeDude: glisse: Man, are you just not sleeping now? :3
MostAwesomeDude: I agree on security concerns, but at the same time I really don't want to end up with registers that are locked up and unusable when I need them.
MostAwesomeDude: I thought about it, and GB_TILE_CONFIG can belong to kernel as long as kernel also decides on tiling.
MostAwesomeDude: If I can't change tiling settings, I don't want to have to have tiling code. :3
zhasha: MostAwesomeDude, the idea was to have tiling implemented transparently in the kernel and exposing linearly to userspace IIRC
MostAwesomeDude: zhasha: I think that's a terrific idea. I've never heard it mentioned before, but I think that's awesome.
zhasha: airlied mentioned it
MostAwesomeDude: Hm.
MostAwesomeDude: Looks like not using GB_TILE_CONFIG does not hurt here.
MostAwesomeDude: So I'm gonna go ahead and nuke it. If it breaks anybody, they'd better speak up. :3
zhasha: should probably add some query so we can know whether tiling is enabled on the card or not (you know, since we do at least need to know in some cases)
MostAwesomeDude: zhasha: Maybe I'm too tired, but could you give me an example case?
MostAwesomeDude: Only thing I can think of is that we might not be able to render/scanout from all kinds of tiles, but IIRC that's not a problem on Radeons.
zhasha: remember when we couldn't figure out why weirdness occurred in trivial/clear, and it turned out there was no tiling support in kernel?
zhasha: we emitted some tiling flags in a few places
MostAwesomeDude: zhasha: Well, at that time, is was because there was no gb_pipes being magically added by the kernel anymore.
MostAwesomeDude: I'll reboot the comp, clearing the 3D engine, and then I'll test again.
MostAwesomeDude: In theory, if GB_TILE_CONFIG isn't being written by kernel, then I'll get a lockup after three frames of clear.
zhasha: MostAwesomeDude, are you using glisse's kernel now?
MostAwesomeDude: zhasha: No, Rawhide. (airlied's, basically.)
zhasha: but it has glisse's latest security patch?
MostAwesomeDude: zhasha: Nope.
MostAwesomeDude: Which is why my MSPOS still works. :3
zhasha: I'm gonna pull the latest kernel from ~glisse/drm-next drm-next-radeon then, and have a look
zhasha: shouldn't mspos be set by the kernel?
MostAwesomeDude: zhasha: Why? Kernel shouldn't be managing multisampling.
MostAwesomeDude: Also, looks like Rawhide is okay with userspace not providing GB_TILE_CONFIG. Gonna commit a few things and push.
zhasha: sorry, read it wrong. I thought it was something strictly frontbuffer related
zhasha: compiling the kernel now
MostAwesomeDude: zhasha: Nope, it's subpixel positions for multisample antialiasing.
zhasha: MostAwesomeDude, do you think this driver will at some point become feature complete?
MostAwesomeDude: zhasha: This is the *only* driver that I think will ever become feature-complete for these chipsets.
zhasha: considering you're the only one really developing it, I wonder if it will get some interest from the outside world :/
MostAwesomeDude: I admire osiris' efforts on classic Mesa, but I really honestly think that this driver will surpass it.
MostAwesomeDude: Not because of me. Just because Gallium makes driver development so much easier.
zhasha: how are we on the shader end of r500 by the way?
MostAwesomeDude: Frag shaders are great, vert shaders are shaky.
zhasha: I skimmed the TGSI ops doc. did you really implement them all?
MostAwesomeDude: None of the shader assemblers are feature-complete or optimized.
spstarr: MostAwesomeDude: as long as you can use them with.. fog ;-)
MostAwesomeDude: spstarr: Gallium doesn't use dedicated fog blocks. :3
spstarr: fog. roawr.
spstarr: MostAwesomeDude: oh good :)
zhasha: spstarr, fog is no longer a nemesis of his, gallium -> awesomeness
zhasha: fog in gallium as far as I can tell is just a shader
DanaG: Didn't the really old cards still have some sort of (non-DX-compliant) shaders?
zhasha: MostAwesomeDude, what do you mean by "shader assemblers", the ones in mesa, or the ones in the driver?
MostAwesomeDude: DanaG: r200 have semi-programmable pipelines. They are not full arb_v_p or arb_f_p though.
MostAwesomeDude: zhasha: The ones in the driver.
MostAwesomeDude: I call them assemblers because they don't really optimize much.
MostAwesomeDude: I leave it as an exercise for somebody else to optimize them further. :3
bridgman: yeah, I guess there are really three categories; assembler, translator, compiler
bridgman: nobody uses translator though AFAIK
bridgman: but that's kinda what we're talking about here
MostAwesomeDude: bridgman: Kinda. There's a lot of non-native insts that have to be re-legalized though.
MostAwesomeDude: is still not looking forward to r300 frag shaders
bridgman: I can solve all your problems at once; give up on Mesa and join the drm overlords
spstarr: heh
bridgman: the ";)" is silent but implicit
spstarr: MostAwesomeDude: become a TTM expert
bridgman: jump !! jump !!
MostAwesomeDude: But somebody's gotta finish the Gallium driver. :C
bridgman: yeah, I know. We're not serious
spstarr: bridgman: but then you're going to make him feel sad and hurt with AGP.. maybe fog is better :D
zhasha: DanaG, the ATI_fragment_program and the like?
zhasha: there are some really old shader specs out there yes
zhasha: card dependent, have to be written in an assembly-like language
bridgman: AGP makes everyone feel sad and hurt
zhasha: hmm, no ATI_fragment_program wasn't the one I was thinking about. I remember the r200 could do a few shader things under DX
spstarr: well, i was sad, but im less hurt now
MostAwesomeDude: zhasha: ATI_f_p is right.
spstarr: bridgman: except firefox wedging GPU :( issue...
zhasha: ATI_f_p, google said was the Pixel Shader 2.0 extension
zhasha: oh come on, AGP was needed
bridgman: AGP was great, so was 2x
bridgman: 4x was starting to push single-ended signalling too far, and one could argue that 8x was just not a good idea
zhasha: I still have an MB with an AGP x4 bus :P
bridgman: then again the same can be said about many standards and trends
zhasha: does mesa have support for voodoo? :P
bridgman: probably; mesa probably has a driver for your coffee maker
zhasha: bridgman, you're confusing mesa and emacs
bridgman: hold on, I'm looking in the driver tree now
DanaG: voodoo as in voodoo1, voodoo2, or later?
MostAwesomeDude: Yes, there's a Glide driver.
DanaG: I have a PCI voodoo3 around here somewhere. What would that be able to do nowadays?
bridgman: yep... there's a Gli... oh never mind ;)
MostAwesomeDude: DanaG: Probably GL 1.2 IIRC.
MostAwesomeDude: bridgman: Some of those drivers are classic and hilarious. dos, for example.
bridgman: there's also a dri/tdfx driver
DanaG: dos? is that missing caps, or what?
MostAwesomeDude: DanaG: The folder is src/mesa/drivers/dos
DanaG: MESA on DOS?
MostAwesomeDude: bridgman: Yeah,
kig: how many different ati x/linux drivers are you writing?
MostAwesomeDude: I'm really hoping somebody with spare cash will say, "Here's cash, so KMS my tdfx plz"
bridgman: seriously, if it has a screen it probably has a mesa driver
MostAwesomeDude: kig: Me?
DanaG: How about a STB LightSpeed PCI? Probably just VESA.
bridgman: kig; there are three active projects right now, I guess :
DanaG: er, ISA, rather.
bridgman: 1. classic mesa for 6xx/7xx
bridgman: 2. gallium3d for 3xx/4xx/5xx
bridgman: 3. rewrite of the classic mesa drivers for 1xx-5xx
zhasha: bridgman, if you look at radeon that is
soreau: DanaG: What were those screen savers you were raving about earlier. are they for linux or what?
DanaG: rss-glx is the package name in Ubuntu.
DanaG: reallyslickscreensavers is the original web site.
bridgman: zhasha; is there anything going on for older ati chips ?
zhasha: really slick screensavers port to glx
zhasha: don't think so
bridgman: hey, look at the registers in the s3v driver
DanaG: It's already OpenGL in Windows; it's just been ported to XScreensaver.
zhasha: I should have said ATI
bridgman: don't you wish GPUs were still that simple ?
bridgman: the question was ati though, wasn't it ?
bridgman: I agree there's lots of other stuff going on
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/s3v/s3v_regs.h
MostAwesomeDude: bridgman: marcheu has suggested that r100 and r200 could be done in Gallium, with some shader hax.
MostAwesomeDude: Personally, I took that to mean "painful softpipe fallbacks for anything not fitting into their pipelines."
bridgman: that would be neat
zhasha: haha, that is awesome
MostAwesomeDude: But it'd be a good use of the failover.
MostAwesomeDude: Just don't make me do it. :3
MostAwesomeDude: (For free. :3 )
zhasha: let marcheu do it
bridgman: I understand why marcheau is thinking about it... for all the cool things you can do with shaders, a lot of apps still draw coloured triangles
MostAwesomeDude: bridgman: Bingo.
MostAwesomeDude: Moreover, it'd be very nice to not force people still using those ancient cards to use classic.
bridgman: and it should be possible to sniff out "do nothing" and "standard ogl tcl" shaders and make r1xx/2xx hardware do something equivalent
MostAwesomeDude: Although TBF r100 was just after DNF was announced...
zhasha: DNF?
MostAwesomeDude: Duke Nukem Forever.
zhasha: it's coming!
bridgman: we missed it !
MostAwesomeDude: Every single Radeon except the rv770 was developed and released during DNF's development. :3
zhasha: meanwhile please enjoy this comic video http://www.youtube.com/watch?v=IE3KdcTgrno
DanaG: Might be handy to be able to run compiz, at least, on the old cards -- even without the wavy stuff, and such.
MostAwesomeDude: Pushed GB_TILE_CONFIG nuke.
zhasha: DanaG, the wobbly windows doesn't use shaders :)
MostAwesomeDude: DanaG: Already works on r100 in radeon-rewrite.
DanaG: wavy -> water, I meant. =þ
zhasha: MostAwesomeDude, we don't care about how many gb_pipes we have?
MostAwesomeDude: zhasha: Kernel's problem now.
MostAwesomeDude: Not ours. :3
zhasha: :P
MostAwesomeDude: It's only set in that one place.
zhasha: fair enough, does it work on rawhide?
zhasha: what's the word on getting radeon kms into linus' tree?
MostAwesomeDude: 2.6.31 is still the target, I believe.
zhasha: sweet, and nouveau?
MostAwesomeDude: Not a clue.
MostAwesomeDude: Nouveau's KMS is still very experimental AFAIK.
MostAwesomeDude: Would have to ask darktama.
zhasha: it's in F11 though :/
MostAwesomeDude: zhasha: Only for NV50 IIRC.
MostAwesomeDude: Unless the F11 feature page is out-of-date, it's only for NV50, and disabled by default.
zhasha: anywho, does your gb nuke work in rawhide?
MostAwesomeDude: Yes.
MostAwesomeDude: From cold boot, I can turn it on, and go immediately into Gallium tests, and it works.
zhasha: what about glxgears by the way?
MostAwesomeDude: No change. Microgears on SW TCL, nothing + assert on HW TCL.
zhasha: why do you suppose microgears happens?
MostAwesomeDude: Bad viewport transform, somehow.
zhasha: MostAwesomeDude, what do we do about RB3D_ABLENDCNTL? (SRCBLEND/DSTBLEND)
spstarr_desk: AMD doesn't make cards with TV tuners anymore or are they HD tuners now
zhasha: there appears to be a problem with the newest drm-next-radeon from glisse's repo
zhasha: http://imagebin.org/49385
zhasha: this wouldn't happen to be related to subpixel precision would it?
MostAwesomeDude: zhasha: ABLENDCNTL? The separate alpha?
zhasha: MostAwesomeDude, the blend function stuff
zhasha: It seems to have API specific parameters
MostAwesomeDude: goes to look
MostAwesomeDude: Hm. You're right.
MostAwesomeDude: DX and GL must have different rules for separate alpha.
zhasha: if we're supposed to be API independent, that one's a blocker
terminatorul: Hello
terminatorul: Can you please help me find out why I no longer have direct rendering ?
soreau: Can you pastebin your X log file?
terminatorul: How do I do that ?
soreau: Open /var/log/Xorg.0.log in your text editor, then submit it to pastebin.com and post the link back here
terminatorul: Ok
terminatorul: http://pastebin.com/d37f6bcfe
soreau: What does 'glxinfo|grep renderer' say?
terminatorul: OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x x86/MMX+/3DNow!+/SSE TCL
soreau: That means you have hw accel working already
terminatorul: Still direct rendering is No
terminatorul: It was yes a few days ago
soreau: Did you turn it off in driconf?
terminatorul: Since then I tried to improve my fps
terminatorul: Were is driconf ?
terminatorul: I must have done something, do not know what, to turn it off
soreau: Can you pastebin the complete output of 'LIBGL_DEBUG=verbose glxinfo'?
terminatorul: Ok ...
terminatorul: Oh .. I see some error messages not redirected with >glxinfo.txt
terminatorul: libGL: XF86DRIGetClientDriverName: 5.3.0 r200 (screen 0)
terminatorul: libGL: OpenDriver: trying /usr/local/lib/dri/r200_dri.so
terminatorul: libGL error: dlopen /usr/local/lib/dri/r200_dri.so failed (/usr/local/lib/dri/r200_dri.so: cannot open shared object file: No such file or directory)
terminatorul: libGL error: unable to load driver: r200_dri.so
terminatorul: libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so
terminatorul: libGL error: dlopen /usr/local/lib/dri/swrast_dri.so failed (/usr/local/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
terminatorul: libGL error: unable to load driver: swrast_dri.so
terminatorul: libGL error: reverting to indirect rendering
terminatorul: libGL is looking for trivers in /usr/local/lib
terminatorul: Do not know why
DanaG: ah, it's looking in /usr/local.... odd.
terminatorul: I just compiled mesa
MostAwesomeDude: You compiled your own libGL without --prefix and didn't put your DRI drivers in /usr/local/lib/dri.
terminatorul: And glxinfo still says v 20060602
terminatorul: Souldn't it say some newer date after I compiled mesa ?
terminatorul: What should the --prefix be ?
MostAwesomeDude: --prefix=/usr if you want it in /usr/lib...
MostAwesomeDude: Or you forgot to tell Mesa to build and install the DRI drivers.
soreau: Should be the same as wherever all the other components installed
terminatorul: I am confused ... mesa/autgen.sh said to just run gmake
terminatorul: I never configured ...
terminatorul: Oh ... and it takes 20min to compile !
terminatorul: Is it ok if I just copy the drivers to /usr/lib =
terminatorul: Is it ok if I just copy the drivers to /usr/lib ?
MostAwesomeDude: terminatorul: Did you enable DRI when you configured your Mesa?
terminatorul: Sorry I never configured mesa
terminatorul: I just run autogen.sh
terminatorul: So I guess the answer is no
MostAwesomeDude: Okay. You don't need to copy anything.
MostAwesomeDude: I guess you didn't look at the output from the autogen...
MostAwesomeDude: You need to run it with --with-dri-drivers=r200
terminatorul: I need to run autogen.sh --with-dri-drivers=r200 ?
soreau: Try it, and this time read the output ;)
terminatorul: Oh ...
terminatorul: Thank you
terminatorul: Ok
terminatorul: The last lines of the output said to run gmake and I never read the rest ... :)
DanaG: why "gmake", and not just "make"? What's a gmake, anyway?
DanaG: =þ
MostAwesomeDude: Mesa was created in a time when GNU make was not prevalent. :3
DanaG: Xilinx tools explicitly call gmake... so I had to symlink make to gmake.
soreau: agd5f: I set a compiz rule for brightness to be set to 98(/100) for all windows and it completely fixes the white noise for tv-out
soreau: s/fixes/eliminates
Neo_The_User: soreau: I'm happy for you :)
Neo_The_User: My dad wants to use HDMI for his radeon 2400 or 2600 PRO PCI Express card. Would he be able to do that using the xf86-video-ati driver?
agd5f: MostAwesomeDude: the vertex shader and vap setup will need to pass through however many verts you need for pos and textures, etc.
agd5f: Neo_The_User: hdmi should work fine for video on xf86-video-ati
Neo_The_User: Thank you agd5f
soreau: agd5f: When do the audio bits get added in?
agd5f: soreau: when someone has time :)
DanaG: oh yeah, I see in xrandr:
DanaG: Panning: 0x0+0+0 Tracking: 0x0+0+0 Border: 0/0/0/0
DanaG: What are each of those? Panning... is going to be either the outer real dimension or the inner virtual dimension... but what are the others?
Neo_The_User: What would happen if I ran radeonhd on my 9800 PRO?
Neo_The_User: specifically and technically speaking
Neo_The_User: ...if anybody knows
myalltimelow: hi
myalltimelow: man i used to have a radeon
myalltimelow: it sucked
myalltimelow: nvidia > ati
Neo_The_User: stop trolling or leave
Neo_The_User: or you'll just get kicked
myalltimelow: oh boohoo ill get kicked for expressing my opinion
myalltimelow: yeah thats right
Neo_The_User: agd5f: ping
myalltimelow: DINGO
soreau: myalltimelow: Did you have a question about the radeon drivers?
myalltimelow: yes
myalltimelow: why do they have to take so long to install
soreau: blinks
myalltimelow: congradulations
soreau: The radeon drivers are already installed by default on most recent distos
Neo_The_User: myalltimelow: if you like trolling, go to #ati
Neo_The_User: they love trolls
soreau: indeed :p
myalltimelow: oh boohoo i was labeled a troll
Neo_The_User: does anybody here have op? ajax?
myalltimelow: no
myalltimelow: im a dude
myalltimelow: yeah im a dude
myalltimelow: 180 degree dude
myalltimelow: thats right, im straight
myalltimelow: (DINGO)
MostAwesomeDude: I'm a dude.
soreau: Where the hell is airlied anyway?
Neo_The_User: holiday @ soreau
Neo_The_User: i hope hes not the only one with op. this guy could be here for a whole month
MostAwesomeDude: Oh, no, there's others with ops.
soreau: Oh well. I can still enjoy 3D graphics without irc :)
MostAwesomeDude: XD
myalltimelow: ex dee?
MostAwesomeDude: Yes, ecks dee.
Neo_The_User: hahaha
myalltimelow: what does that mean
DanaG: XÞ
DanaG: =þ
MostAwesomeDude: It means that I grinned, mostly. It's an emoticon.
myalltimelow: ee-mote-icon
myalltimelow: whats that
MostAwesomeDude: Y'know, a smiley.
Neo_The_User: myalltimelow: this is for end user support and development of radeon drivers
soreau: MostAwesomeDude: Same goes for you too xD
myalltimelow: oh i didnt know that
myalltimelow: whats the chatroom for nvidia support?
myalltimelow: because im an nvidia fan and stuff, you know
Neo_The_User: #nvidia
MostAwesomeDude: I would imagine that #nvidia is for the binary drivers, and #nouveau is for the open-source drivers.
MostAwesomeDude: But I've never actually looked inside #nvidia, Freenode might not have one.
Neo_The_User: He doesn't seem like the open source kind of guy
soreau: It does. It's just as welcoming as #ati I'm sure
myalltimelow: man i like that
MostAwesomeDude: agd5f: I meant more WRT the proper passthrough slots. If I have pos & color, it's 0 & 1, same as pos & texcoord.
myalltimelow: yeah ok
myalltimelow: but where are all the nvidia people
MostAwesomeDude: Just asking if the same passthrough shader could be used in both spots.
MostAwesomeDude: myalltimelow: aaronp is nvidia, and he's never in this channel. marcheu and darktama are nouveau, and they're usually not in here.
Neo_The_User: I just love the /ignore feature!
soreau: MostAwesomeDude: *is*? *are*? Such strong words :)
myalltimelow: you dont understand
myalltimelow: nvidia rules and stuff
myalltimelow: yeah, ill get a tattoo on my face that says NVIDIA
DanaG: Good luck finding a job, or a date, then.
soreau: myalltimelow: We get it. You're in the wrong channel
MostAwesomeDude: myalltimelow: I get it. You're a bored 15-year-old with nothing to do.
soreau: Also, you are trolling which no one appreciates
myalltimelow: no, see thats where you're wrong
soreau: DanaG: no shit
myalltimelow: im 18 and i finished studying for finals
myalltimelow: yeah, still bored though
MostAwesomeDude: Well, okay, here's the thing.
DanaG: Hmm, check the time zone in your area... and consider getting sleep. That definitely helps for tests.
myalltimelow: DanaG
myalltimelow: did i ASK for your advice?
MostAwesomeDude: When I was 18, I was writing code. It wasn't the best code, and I wasn't getting paid for it, but I was writing code because I was bored.
myalltimelow: UM, NO
MostAwesomeDude: And now I'm here getting paid for writing code.
MostAwesomeDude: Lesson: Go out and do shit, and if you're good, somebody will start throwing cash at you.
MostAwesomeDude: Oh, and I'm only 21. Lots will happen in the next few years for you. Don't fuck up, and life will be good. Even if you use nVidia cards.
myalltimelow: no, see thats where you're wrong
myalltimelow: nvidia cards are good!
MostAwesomeDude: I didn't say they weren't. I've got one sitting next to me right now.
myalltimelow: what one is it
MostAwesomeDude: I just don't get paid to work on them, that's all.
DanaG: now... what IS bad.... is Creative. =þ
MostAwesomeDude: NV19. Old FireGL PCI card, can't remember the exact number.
MostAwesomeDude: *Quadro, not FireGL.
Neo_The_User: maybe if you just stop talking to him, he'll get bored and leave
MostAwesomeDude: Neo_The_User: He's already bored. Might as well not bite the newbie.
MostAwesomeDude: 'Sides, I remember being young and trollish. Hell, I'm *still* young and trollish. :3
DanaG: I tend to be just ... random.
soreau: uses DanaG as his random generator
myalltimelow: hey whoa
myalltimelow: im not a troll
myalltimelow: my name is brian
myalltimelow: im a guy
MostAwesomeDude: 'k.
MostAwesomeDude: My name's Corbin. I'm also a guy.
Neo_The_User: My name is Alec. I am a male as well.
myalltimelow: im straight..
myalltimelow: 180 degree guy, i am
MostAwesomeDude: I don't disclose my sexuality so that I can make people feel bad about insulting gays.
Neo_The_User: Agreed. Nothing wrong with being homosexual at all.
Neo_The_User: ...why am I talking off topic?
Neo_The_User: I'm out. ping me in #unichrome when he leaves
myalltimelow: youre right
myalltimelow: nothings wrong with homosexuality
myalltimelow: but i prefer women..