damentz: hey agd5f or airlied, is s3tc supported by r100 or r200?
damentz: i tried enabling texture compression in warsow and it doesn't do a thing
damentz: but when i use it on my nvidia machine, color quality is a little bit worse, showing that it works
damentz: with my radeon 9000 mobile, nothing changes and performane is still bad (lack of video ram)
airlied: damentz: you need to install libtxc_dxtn
damentz: hmm
damentz: let me see
damentz: oh wow, how did i not know about this, why would it not be in mesa?
damentz: are there any other libraries you think i would need?
airlied: patents
airlied: no jsut that one
damentz: very interesting
damentz: oh!
damentz: i read that some optimization is going into mesa, they were optimizing IR or something...
damentz: maybe that's just intel
damentz: but they claimed performance was increased dramatically from previous benchmarks
airlied: for radeon we got VBOs that might have helped
airlied: it was also just optimising shader compilers
airlied: not something games do a lot at runtime
damentz: oh i see
airlied: done once at startup usually
DanaG: wow, I never knew about that libtxc_dxtn
DanaG: Couldn't find any package whose name or description matched "libtxc_dxtn"
DanaG: =þ
damentz: just search for txc or dxt then
damentz: with your package tools or what not
DanaG: bah, no results. :(
airlied: need to package it for rpmfusion I think
damentz: hmm, libtxc didn't seem to enable anything
DanaG: is on Ubuntu Karmic.
airlied: glxinfo should have S3_s3tc extension
damentz: yes, i checked
damentz: glxinfo | grep -i s3
damentz: and glxinfo | grep -i compress
damentz: it found the extensions warsow uses
DanaG: https://bugs.launchpad.net/debian/+bug/402920
damentz: i see
damentz: i might need to get a newer version and/or rebuild the package from debian multimedia
damentz: that's really old
damentz: january 2008 is when that package was built
airlied: it doesn't change much
airlied: I think I did a bugfix to it about 3 years ago
Vash63: What's the current state of KMS on r700? Possible with anything newer than 2.6.28 yet?
airlied: Vash63: it wasn't possible with 2.6.28 ever
Vash63: Oh. Which version was it that the patches were for a while ago?
Vash63: Must be confusing something.
damentz: grr, i can't get this to work
airlied: we have a test branch that nearly works but it isn't ready for anyone else to test yet
damentz: rebuilt the package and installed it
airlied: MESA_DEBUG=verbose used to print stuff out to say if it found it
damentz: ok
damentz_: hmm ok
damentz_: running that with warsow printed out all the extensions i was using
damentz_: s3tc is definitely in there
damentz_: Mesa warning: software DXTn compression/decompression available
damentz_: that must be what you were talking about
damentz_: i wonder why warsow never actually enables the compression
damentz_: airlied, do you suppose this could be a bug in mesa?
damentz_: that might explain all the texture problems i've had with these radeon cards on the open source stack
damentz_: they seem to run out too fast
airlied: don't think so
damentz_: but i remember playing unreal tournament 2003 with full texture configuration on a radeon 7500 mobility, so something weird is going on
airlied: more like the game isn't enabling them for some other reason
damentz_: airlied, what's something i can test to see if s3tc is used on?
damentz_: oh, i'm using mesa 7.5.1 btw
damentz_: basically whatever is in debian sid
airlied: texcmp demo comes with mesa ;-0
damentz_: ok, i'll take a look at that
damentz_: hmm
damentz_: debian doesn't have the glx demos anymore
damentz_: i remember them having it
airlied: but really if glxinfo reports it its there
damentz_: but my game isn't using it!
damentz_: let me try openarena
agd5f: damentz_: how do you know it's not using it?
damentz_: agd5f, it should look worse and i shouldn't get performance issues when it views a larger scene
damentz_: if i lower texture detail, or use 16 bit textures in warsow, the problem goes away
damentz_: but setting texture compression doesn't do anything
damentz_: on my other laptop using the nvidia proprietary driver, there's a noticeable drop in quality for textures
damentz_: well, when it shades colors, it looks bad, but the game looks better than lowering texture quality
agd5f: damentz_: according to this page: http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html ut2k3 should just work
damentz_: hmm, i never tested that game in linux, i tried it in windows a long time ago
DanaG: hmm, will that s3tc work with newer cards?
damentz_: agd5f, that game is talking about precompressed textures working
damentz_: warsow uses raw textures
damentz_: and has a tunable to enable texture compression
damentz_: which i guess is done in real time, which requires the library
agd5f: damentz_: I though you were talking about ut2k
damentz_: no
damentz_: i brought that up discussing that 32mb of ram seemed to be sufficient for playing ut2k3 back in the day on a radeon 7500 with texture quality set to the max for that game
damentz: openarena seems to work
damentz: well, compressed textures look very bad on these open source drivers
damentz: i'm not even sure if this is s3tc
damentz: ya, it seems enabling compression disables texture filtering
damentz: it's all blocky like software rasterization
damentz: lame
damentz: anyway, i must go
damentz: later
airlied: agd5f, glisse : http://people.freedesktop.org/~airlied/kms/0001-r600-initial-copy-blit-code-from-non-kms.patch
airlied: on top of the wip tree is where I got to,
airlied: will try and get back to it on Monday
agd5f: airlied: I think I found a bug in the blit code. src_gpu_addr += cur_size; dst_gpu_addr += cur_size; should += cur_size * h
agd5f: should be
mmp: hello; anyone has experience with RS690-based chips and suspend to ram? I tried it today; looks like I can suspend/resume correctly as long as X is not running on current console (switching to text console and doing suspend/resume there works)
mmp: however, with X I'm getting strange freeze upon resume -- no hard drive activity, no reaction to caps lock, ...
mmp: and also no kernel panic indicated by LEDs
glisse: mmp: kms enabled ?
mmp: glisse: running 2.6.30, without patches (not mentioning tuxonice), so not...
mmp: glisse: this problem persists for a while, I think it was present also on .28 and .29 kernels
airlied: mmp: so vt switch back to X works fine after resume?
mmp: airlied: precisely
mmp: or, at least in the attempts I've made
airlied: latest git -ddx?
mmp: no, just gentoo ebuilds; let me see the versions
mmp: 6.12.2
mmp: (xf86-video-ati)
airlied: might be worth trying with latest git at some stage,
mmp: airlied: ok, I can try that
mmp: airlied: 'master' branch should be enough?
glisse: airlied: if you had to wildguess what would cause cp to hardlock when performing a cp reset if cp is off and the whole GPU report idle.
glisse: mmp: yup
mmp: going off to test it; brb
zhasha: MostAwesomeDude: how goes shatter?
suokko: glisse: My GPU hangs if you even read registers while CP is active. So if you try to use direct register access it might be some similar cause
rah: http://myrtle.6gnip.net/~rah/radeon-display-corruption.jpg
rah: what's with that?
rah: I get it all the time while scrolling web pages with the mouse wheel
airlied: glisse: microcode wrong?
airlied: or corrupted
rah: incidentally, I also get lots of errors in dmesg like so:
rah: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 26
rah: anyone
rah: have any ideas?
rah: anyone alive?
suokko: airlied: What do you think of running vi indention to all source files?
suokko: rah: Sounds like bug
hifi: whats vi indention
zhasha: suokko: what do you mean?
suokko: Open source file in vi and do gg=G
suokko: or :0=G
airlied: suokko: that might work better, depends on what the diffs end up looking like,
suokko: But the problem is what should be used for indention. Tabs or spaces? If spaces how many?
zhasha: spaces, and 4 per level /discussion
rah: suokko: do you think?
airlied: suokko: generalyl thats why I avoid the discussion
airlied: I'm leaning towards kernel coding standards
peterz: airlied: kms on r600 didn't quite work for me
peterz: I used your r600-wip drm branch
suokko: 8 spaces?
airlied: since they are one of the the few standards
airlied: peterz: the latest one? how far did it get?
zhasha: spaces, because they are uniform no matter the editor settings
zhasha: but 8 is too much
peterz: airlied: failed to start X
airlied: peterz: you need a new DDX
peterz: airlied: 1:6.12.99+git20090901.c4ab50c5-0ubuntu0tormod~jaunty
zhasha: and I like powers of 2, but 1 or 2 is too small, and 8 is too much
peterz: airlied: that not new enough?
airlied: peterz: nothing is new enough
airlied: since I haven't finished writign it yet
peterz: airlied: oh :-)
airlied: peterz: http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=r6xxcs
airlied: is closest
peterz: airlied: I'll just wait a bit more, this r600 3d stuff keeps crashing my gpu anyway
airlied: alex has one that is more cleaned up so we can merge it
peterz: I just like to try it a few times a week :-)
suokko: zhasha: tabs are winner because anyone can use wide for them what ever they wish ;)
airlied: zhasha: as I said I'm not looking for opinions ;)
zhasha: suokko: but tabs also misalign code
airlied: the other reason to lean towards kernel is I can use checkpatcl.pl ;-)
rah: *cough*gnu*coding*standard*cough*
airlied: so I can do whitespace bashing
suokko: zhasha: Only if you are perfectionist ;)
zhasha: is a prefectionist
airlied: the other option is 4 space indents
airlied: just becasue its closest to what was there before
airlied: and closest to the DDX
rah: GNU Coding Standards
airlied: when I wrote parts of re-write I mostly went with the kernel stanard
airlied: so maybe I should just sitick with it
suokko: btw, That is funny comment about that you are screwed if yo uhave more than 3 levels of indention. namepsace { class { class { function() { for only inner class function is already over that level ;)
suokko: :set et sw=8 ts=8
suokko: :0=G
airlied: will pick something next week, its the weekend for me
mmp: airlied, glisse: reproducible with current xf86-video-ati master branch
glisse: airlied: but if cp is stop i don't microcode matter
glisse: time to do massive radeondump
glisse: as sometimes it works after hardreset sometimes it doesn't
airlied: glisse: how do you know the cp is hung?
airlied: glisse: you trry and astart it again?
glisse: well i have gpu hang, i do hard reset, then i do softreset, then post video card than restart everythings
airlied: so you re-write microcode and bring it back from scratch?
glisse: thing is after the hard reset sometimes the soft reset of the cp hang the computer but all reg report idle, ie cp is stop and idle
glisse: yeah rewrite microcode and bring back from scratch
airlied: glisse: you stil ldoing the BM toggles?
glisse: i tryed doing soft reset before and after restoring bus master
glisse: doesn't change anythings
glisse: sometimes work sometimes hang
glisse: it's like it depend on what the cp was doing at hardreset time
airlied: yeah probably if it was fetching from PCI bus or something
airlied: food &
glisse: i do some radeondump see if i can find some pattern
airlied: any GART errors?
glisse: aic doesn't report any but aic is reset too
glisse: by the hardreset
glisse: anyway this is likely a bus error only way to hang computer is by bad bus activity i think
glisse: so cp must be doing somethings evil (btw i disabled all writeback like rptr or scratch reg to be sure)
suokko: glisse: Do we have any tool to monitor bus activity?
glisse: suokko: no, only dedicated hw can truely do that
glisse: but it cost quite a lot
airlied: glisse: you try pci mode (assuming you are using agp)
glisse: yeah i am in pci mode
airlied: same issue in agp?
glisse: yeah
glisse: cp reset is at fault here
glisse: i can softreset all others block without problem
airlied: glisse: can you suspend/resume 3 times?
glisse: hmmm didn't tried that
glisse: will try
glisse: funny i must have set autowakeup in my bios :)
glisse: yeah it seems so 4 suspend/resume so far
glisse: yeah definitly seems to work
airlied: does CP_STAT tell you what is hung?
glisse: before hardreset: 0x8411C100 0xC000200C
glisse: after 0x00000140 0x80000004
glisse: rrbm_status cp_stats
rah: http://myrtle.6gnip.net/~rah/radeon-display-corruption-2.jpg
airlied: wonders what an RSIU is
glisse: note that after cold boot i got same value as after hardreset
airlied: movie time &
glisse: so RSIU is always asserted busy
glisse: ok enjoy
rah: *cough*
glisse: my guess is that you get rsiu active as soon as you read a cp register
rah: pfft
glisse: rah: yup we saw the corruption
glisse: looks like small dfs corruption we are scratching our head with
glisse: try disabling download/upload from screen see man radeon
rah: glisse: at the moment?
glisse: no we were scratching our head with other things, we are lucky people we got plenty stuff to scratch our head with :)
rah: :/
suokko: glisse: I think wait for engines to be idle before transfer might help on corruption
glisse: suokko: what we really need is a simple test
glisse: somethings like radeon_test in kms kernel but to test blit
glisse: so we can play with the hw without having to hack into X or ddx
glisse: also then we know that no other process is doing funny thing with the gpu
suokko: Then you need some 3D stuff going on before to see if it can mess up the blit
glisse: well if we get thing working properly in the kernel when there is no weird interaction
glisse: then we know that some interaction is at fault
glisse: and then we need to do somethings about it
airlied: glisse: did you try inserting a delay beore restarting CP?
airlied: like 50ms or so
suokko: Maybe some reset operation has to be polled that card has really done the reset so we don't try to continue too early
glisse: airlied: i got a tons of 50ms delay
glisse: also strange thing is doing the cp reset from userspace with hacked radeontool doesn't seems to hang the hw ...
zhasha: airlied, glisse: do you know of any memory leaks in either radeon-rewrite or the r300 kernel modules?
zhasha: I seem to have made 1GB of memory disappear, accumulated over the course of a few days
zhasha: I suspect it's from opening and closing a lot of opengl rendering apps
stalkerg: thx all! 3D effects in KDE4 on 4300 normal work!
[Enrico]: wow
zhasha: I somehow doubt it's using the open drivers
simplexe: ммм грамотный отладчик в винде, ollydbg?
suokko: http://cgit.freedesktop.org/~suokko/mesa/log/?h=indent_tabs and http://cgit.freedesktop.org/~suokko/mesa/log/?h=indent
suokko: I'm leaving now for weekend trip so have fun with them ;)
MrCooper: I don't understand why everyone's suddenly so obsessed about this, I really think it causes more trouble than it's worth
jcristau: everyone loves merging across whitespace changes
jcristau: oh, no, wait, not love, the other thing.
suokko: Everyone also loves to change indention scheme for every function in the file
MrCooper: rather than re-indenting things, why not agree on a style and codify it in rules files for emacs, vim and what have you - then the problem will solve itself as the code gets modified :)
MrCooper: and without gratuitous whitespace merge failures
dileX: suokko: whats the difference between noet and et?
suokko: noet makes indention with tabs and et makes with spaces
dileX: suokko: ah OK
ahmed-araby: Hi all , I've problem with radeon or something related to it , when I open some web sites in Any browser , except for chrominum
ahmed-araby: Gnome completely freeze But When I try to ssh to my box , It responds
ahmed-araby: I tried to get that image using wget & open it locally using image viewer Nothing happened
nha: Okay guys, apparently you've been having a discussion on whitespace.
nha: *ahem*
nha: IF YOU COMMIT WHITESPACE CHANGES TO r300/compiler, I WILL HUNT YOU DOWN, WATERBOARD YOU (hey, it isn't torture, right?) AND KILL YOU.
nha: Then, for good measure, I will hunt down and kill all your relatives, just to make sure that your genes are really removed from the gene pool.
nha: Also.
nha: We live in the 21st century.
nha: When will it get into your heads that the discussions about this are over?
nha: Use tabs for indentation, spaces for alignment.
nha: When I saw that Gallium uses 4 space indentation, I literally felt physical pain.
nha: -----
nha: phew
nha: in all seriousness
nha: I can live with stupid coding styles, as painful as they may be, but never, ever do huge whitespace-change only commits
Dr_Jakob: nha: most of Gallium is 3 spaces and no tabs.
MrCooper: Dr_Jakob: run! ;)
nha: oh, that just proves how stupid spaces alignment is - because drivers/r300 uses 4 spaces
nha: but yeah, as I said, I can live with the different indentation style (I still need to figure out how to deal with them *better* with katepart, but I will get to it)
MrCooper: heh, looks like one of the IRC servers ran instead
Dr_Jakob: nha: in general I agree with you on the "Use tabs for indentation, spaces for alignment." stuff
Dr_Jakob: unforetly almost all editors does it wrong when it comes to function calls on multiple lines.
Dr_Jakob: >---my_func(int gah,
nha: Dr_Jakob: absolutely agree. Figuring out how to get it right in kate is on my "improve my tools"-todo list
Dr_Jakob: >--- int goh);
Dr_Jakob: but most editors do:
Dr_Jakob: >---my_func(int gah,
Dr_Jakob: >--->--->---- int goh);
nha: what I do as I kind of stupid workaround is:
nha: longfunctionname(
nha:
nha:
taiu: help with C, what does this do or meant to do: tmp = (cs->cdw + 1 + num) & (~num);
taiu:
nha: admittedly I'm not very consistent about using one or two tabs
Dr_Jakob: nha: heh, I'm just fight the editor until it gets it right.
nha: but it's something I learned from a rather zealous guy in Widelands who eventually convinced me that it was a viable alternative
Dr_Jakob: vim is pretty good at knowing when to not "help" you.
Dr_Jakob: Eclipse is horrible, "NO I DO NOT WANT A TAB HERE!"
nha: taiu: if num is one less than a power of two, it will do alignment
Dr_Jakob: nha: but I agree people should be able to use the tab width they want.
taiu: nha: seems so, but seems num is not always what was meant
taiu: int num = (ndw > 0x3FF) ? ndw : 0x3FF;
taiu: agd5f: it's in r600_cs_begin
nha: and ndw can be something other than 2^k - 1?
taiu: nha: yes its RADEON_BEGIN_BATCH(x)
otaylor: nha: it would be weird if it's alignment, since it would be off by one - it would be aligning cs->cdw + 1
nha: oops... that might explain why nobody tripped over it before
nha: otaylor: agree, but sometimes that's what you want
otaylor: nha: if it's really what you want, then hopefully you'd at least write tmp = ((cs->cdw + 1) + num) & ~num
MrCooper: it's really mysterious what the intention of that is
taiu: it intends to grow cs by at least 1k or ndw if that's bigger
taiu: but seems logic fails if ndw is indeed bigger than 1k
agd5f: taiu: not sure. airlied wrote that code
GyrosGeier: hi
GyrosGeier: I have a Radeon 2100, with a second monitor on DVI
GyrosGeier: that monitor is rotated
GyrosGeier: almost anything that happens on screen takes about a second
GyrosGeier: i.e. someone says something in IRC, I can see the window scrolling
GyrosGeier: and since the gfx data is rotated in video memory, this happens with a "wipe" effect from right to left
GyrosGeier: needless to say, this is very annoying
adamk_: GyrosGeier, Pastebin your /var/log/Xorg.0.log file.
GyrosGeier: is there anything I can do to make accelerated rendering on a large desktop with two monitors, one of which rotated, work?
GyrosGeier: okay
adamk_: GyrosGeier, Fast rotation requires EXA and Direct rendering enabled in the server, as I recall.
nanonyme: Which requires KMS and multihead support?
adamk_: No, just a 2.6.30 kernel with DRM enabled.
adamk_: And, of course, a new enough DDX.
adamk_: Actually, is a 2100 an r600 card or older? Not that it matters, direct rendering still needs to be enabled for hw accelerated rotate.
nanonyme: adam_: It's two separate monitors out of which one is rotated if I understood properly. Sounds like multihead to me.
adamk_: I didn't get the impression that this was separate screens, but two working together via xrandr.
GyrosGeier: http://www.psi5.com/~geier/Xorg.0.log
nanonyme: Hmm.
nanonyme: It should be r600, I think.
adamk_: Yeah, I'm not sure now. You have two screen sections, but radeon is only getting loaded once.
nanonyme: Anyway.
adamk_: GyrosGeier, How are you enabling the second monitor?
GyrosGeier: I have two graphics cards, but am using only one
GyrosGeier: because the radeon driver crashes with Xinerama
GyrosGeier: I use options "Monitor-VGA-0" and "Monitor-DVI-0" in the Device section
adamk_: So you are running X on one video card, with two monitors, and using xrandr to enable the DVI monitor?
adamk_: Gotcha.
GyrosGeier: yes
adamk_: I *think* I know what the problem is, but someone else might need to confirm this. Your GPU probably has a maximum 3D texture size of 2048, and the two monitors exceed 2048 when combined...
GyrosGeier: I'd like to get the second card running as well so I can have four monitors
adamk_: The rotated DVI is on the right?
GyrosGeier: I am not getting any 3D acceleration at all
GyrosGeier: on the left
GyrosGeier: and the driver crashes on running supertux or "xrandr --auto"
GyrosGeier: but those are preexisting conditions and I'm not supposed to play supertux at work anyway
chithead: adamk: radeon 2100 igp is rs740
glisse: what people does with 4 monitor ? :)
chithead: acceleration and rotation is a problem
GyrosGeier: my normal work setup is one for copy, one for paste, one for "watch make"
GyrosGeier: i.e. documentation, editor, compiler output
GyrosGeier: right now I have enslaved a Windows box running PuTTY
GyrosGeier: chithead, especially acceleration and partial rotation
GyrosGeier: i.e. part of the framebuffer belongs to a rotated picture, part is normal
adamk_: GyrosGeier, Well I'm still guessing that rotation is being done in software because of the texture size, but that's just based on the vague recollection of someone else with the same problem on here a while back.,
GyrosGeier: well
GyrosGeier: it appears as if rotation is done by software reading the video memory and writing it back
GyrosGeier: pre-rendering the image in RAM and writing it to the card rotated would be faster :/
GyrosGeier: but AGP card-to-host performance sucks
GyrosGeier: any idea why I'm not getting any acceleration?
GyrosGeier: (even without that monitor, and on 1680x1050)
adamk_: GyrosGeier, So with just one monitor, it's equally slow?
adamk_: Ahhh, I missed something.
adamk_: (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
adamk_: Try using EXA.
adamk_: Add Option "AccelMethod" "EXA" to the device section of your xorg.conf file.
GyrosGeier: adamk_, the other monitor is faster, but has no 3D acceleration
GyrosGeier: tries
adamk_: And see if that improves things for 2D performance anyway.
GyrosGeier: should I disable SWCursor?
adamk_: I *think* 3D acceleration is supported on the RS740 if Mesa is new enough.
GyrosGeier: I enabled it because it used to crash
adamk_: GyrosGeier, Well I would try it with hardware cursor first and see what happens.
nanonyme: One of the monitors could be running shadowfb, mind.
nanonyme: Would explain the differences.
adamk_: Can the driver run just one monitor with shadowfb when using xrandr across two monitors?
GyrosGeier: hm
GyrosGeier: it is twice as fast
GyrosGeier: but still visible
GyrosGeier: and the driver no longer crashes when starting supertux, but when stopping it
GyrosGeier: I don't get any output from supertux though
nanonyme: adamk_: Probably not, that would be the two monitor sections scenario...
adamk_: GyrosGeier, What is the output of 'glxinfo | grep -i renderer' ?
GyrosGeier: logfile updated
GyrosGeier: OpenGL renderer string: Mesa DRI R300 20060815 NO-TCL
adamk_: Well you are getting 3D acceleration...
adamk_: Perhaps your version of Mesa just doesn't support the 2100 properly...
adamk_: I know there was an issue with IGP GPUs and Mesa that was fixed in git this past summer.
nanonyme: Does it show the same output on both monitors?
GyrosGeier: "20060815" doesn't sound promising
chithead: at least the version of mesa which ubuntu 9.04 ships has serious issues with igp
GyrosGeier: nanonyme, how could it not?
adamk_: GyrosGeier, Yeah, the date is not accurate. But that one is still old.
adamk_: GyrosGeier, What version of Mesa?
GyrosGeier: nanonyme, ah, you mean video signal? no
nanonyme: GyroGeier: Easily. Try out?
nanonyme: I meant does the glxinfo grep yield same results on both monitors.
GyrosGeier: 7.5
adamk_: nanonyme, He's using xrandr. There's no logical reason for glxinfo to show different output. I don't think it's even possible.
GyrosGeier: nanonyme, how would glxinfo attach to a specific monitor?
kdekorte: GyrosGeier, did you say what kernel version you were using?
nanonyme: adamk_: Just ruling out a theory.
GyrosGeier: everything from Debian unstable
adamk_: kdekorte, According to his Xorg log file, it's running on 2.6.30-1.amd64
GyrosGeier: so 2.6.30
nanonyme: It shouldn't be that hard to run the command on the other monitor too.
GyrosGeier: the -1 is the ABI version from Debian
kdekorte: GyrosGeier, if you don't rotate the second monitor does performance get better on that display?
GyrosGeier: tries
GyrosGeier: yes
nanonyme: And now 3D works too?
kdekorte: Might be an issue with the igp chipset and copying the rotated image (bus contention)
GyrosGeier: hmm
GyrosGeier: 3D performance didn't change
GyrosGeier: still 40 fps in glxgears
GyrosGeier: starting supertux crashed the server
adamk_: That really sounds like that IGP bug from Mesa, then.
adamk_: Perhaps it didn't get fixed in Mesa in time for 7.5
kdekorte: I think Mesa 7.5.1 is coming out soon, perhaps it is fixed in there reading something about it on phoronix I think
nanonyme: GyroGeier: The glxinfo was run on the slower monitor, right?
adamk_: Actually 7.5.1 is out now.
adamk_: Yesterday, in fact.
kdekorte: 40fps is really slow, even software gets more than that usually
adamk_: GyrosGeier, You could try that version of Mesa to see if it improves 3D performance.
kdekorte: GyrosGeier, can you run 'LIBGL_ALWAYS_SOFTWARE=1 glxgears' and report back how that works?
GyrosGeier: nanonyme, no, the faster one
nanonyme: GyrosGeier: Do it in the slower one *please*.
nanonyme: The slower one could be doing CPU rendering.
GyrosGeier: kdekorte, 20 fps
kdekorte: Seriously?
kdekorte: seems awefully slow... for glxgears in software mode
nanonyme: He probably has a slow CPU...
GyrosGeier: on the slower monitor it's 1.2 fps in software mode
nanonyme: Ah. :)
nanonyme: Thank you.
nanonyme: Wait, actually, that still doesn't prove it. ;)
GyrosGeier: same without forcing software mode
kdekorte: He has a 64bit machine, so it should be faster that 1.2fps... I think my atom chip does better than that
nanonyme: Since the effect of DRI is that software rendering gets slower. The effect of DRI on one display but not the rendering display would make software rendering *even* slower.
GyrosGeier: nanonyme, Athlon 4450e with 2300 MHz
nanonyme: GyrosGeier: So. If glxinfo |grep renderer gives r300 in the slower display too, I'm satisfied and the theory is offically proven invalid. ;)
GyrosGeier: nanonyme, glxinfo is a console app
nanonyme: I know. Start up a console in the slower display and run it.
GyrosGeier: it cannot possibly know which monitor the xterm it reports to is running on
GyrosGeier: (well, it could in theory, but...)
nanonyme: If it fails to get DRI, it will fallback to software rasterizer.
nanonyme: Please prove it doesn't.
GyrosGeier: it doesn't open a window
nanonyme: (as I've been telling you to do for ages already)
nanonyme: What doesn't open aa window?
GyrosGeier: glxinfo
nanonyme: I know.
nanonyme: Why should that matter?
GyrosGeier: hence there is no graphics context that could be found incompatible with acceleration
nanonyme: Just run the damn command.
kdekorte: adamk, would DRI2 help out GyrosGeier?
GyrosGeier: nanonyme, I already did
taiu: seems r600 doesn't handle indexed primitives
nanonyme: kdekorte: If I'm right, yes, if I'm wrong, probably not.
GyrosGeier: nanonyme, glxgears is about the same speed on the slower one
nanonyme: GyrosGeier: So what did it display in the terminal that was completely in the drawing area of the slower display?
nanonyme: Ah.
GyrosGeier: OpenGL renderer string: Mesa DRI R300 20060815 NO-TCL
nanonyme: Great.
GyrosGeier: nanonyme, erm
GyrosGeier: same speed as software rendering
GyrosGeier: that is
GyrosGeier: 1.2 fps
GyrosGeier: so glxgears appears to fall back
nanonyme: Hrm. LIBGL_DEBUG=verbose glxinfo > /dev/null?
GyrosGeier: but it could also be that glxgears renders into an offscreen buffer, which is then rotated by the CPU
GyrosGeier: drmOpenDevice: open result is 4, (OK)
nanonyme: Yeah.
GyrosGeier: looks good
nanonyme: You're probably right then.
nanonyme: And no, DRI2 would probably not improve it at all given DRI works in the slower display anyway.
GyrosGeier: not sure DRI works there
GyrosGeier: it is the same speed as software rendering
GyrosGeier: so it could be falling back, or it could be hardware rendering and software rotation
nanonyme: Hmm.
nanonyme: Does playing back a movie with Xv work? :3
kdekorte: xvinfo should tell you if xv is enabled
kdekorte: GyrosGeier, do you have a virtual line in your screen section of xorg.conf?
nanonyme: Hmm, actually I'm not sure if that chip should require DRI for EXA/Xv. It has pre-r600 3D, maybe it doesn't have r600 2D either... *sigh*
GyrosGeier: kdekorte, no
kdekorte: GyrosGeier, I can send you my xorg.conf if you like.. I'm running dual head on r600
nanonyme: I'll part, apparently just creating useless traffic.
taiu: http://pastebin.ca/1554016 can play openarena on r600 quite well
kdekorte: taiu, how does etracer work with that patch?
nanonyme: taiu: So it was an alignment fix? :)
nanonyme: Erm, bug even.
GyrosGeier: kdekorte, does 3D accel work for you>
nanonyme: (wait, no, it wasn't, there's tons of other stuff too; seriously: break)
kdekorte: yes, with lots of stuff from git
GyrosGeier: oh great
GyrosGeier: $boss is already very pleased with me running Debian unstable
kdekorte: still bugs but better
kdekorte: taiu hey that patch fixes bug 23585
GyrosGeier: haha
bridgman: nanonyme; rs740 has a "real" 2D engine
bridgman: I think it should be able to do EXA/Xv without drm but agd5f may have required it for consistency
kdekorte: taiu... quake3 now runs in direct mode too... AWESOME!!!
bridgman: afaik it's only the 5xx 3D engine that we were having trouble driving without going through CP
kdekorte: agd5f, can you merge in http://pastebin.ca/1554016 seems to fix a lot of things for me on r6xx
kdekorte: etracer is so much better.. not perfect, but tons better
taiu: dont't think it can be merged as is, I don't understand most of mesa code yet :(
GyrosGeier: erm
GyrosGeier: goes WHAT?
GyrosGeier: the version of Mesa I'm running doesn't even have R600 support
kdekorte: taiu... to fix bugs like that you are well ahead of me...
kdekorte: GyrosGeier, r6xx support is really new... not surprised you don't have it
bridgman: GyrosGeier; you need mesa from mesa/mesa master + drm from ~agd5f/drm r6xx-r7xx-3d branch
taiu: bbl
kdekorte: taiu, running vdrift I see this alot... Stripping 1 verts
GyrosGeier: so just 7.5.1 isn't enough?
bridgman: nope, 7.5.1 is ancient ;)
kdekorte: GyrosGeier, I think you have to enable it to when you compile mesa
GyrosGeier: checks it out then
kdekorte: GyrosGeier, you also need the kernel modules for it as well
GyrosGeier: ow
GyrosGeier: this is my work box :/
kdekorte: yeah, I have updated libdrm, the kernel modules, mesa and the ddx all from git on my machine... so up to you how crazy you want to get
kdekorte: my work box, all stock from Fedora 11
kdekorte: GyrosGeier, you might try the Fedora 11 or 12 (snapshot) live cd and see how well the driver works in there since that is usually pretty cutting edge
adamk_: GyrosGeier, You shouldn't need r600 support in Mesa for an RS740 GPU....
adamk_: Unless I'm really wrong on this, isn't RS740 an r300-r400 generation GPU? Your glxinfo output showed the Mesa DRI renderer string.
chithead: rs740 is a die-shrunk rs690 with r500 2d and r400 3d part
GyrosGeier: adamk_, it said R300
adamk_: Right. All r300 through r500 GPUs use the same 3D driver.
adamk_: *However*, as I said, there was a bug that affected IGP GPUs in Mesa till just a few months ago.
GyrosGeier: okay
GyrosGeier: so I should get 7.5.1?
chithead: that would be a start
GyrosGeier: OpenGL version string: 1.4 Mesa 7.5.1
GyrosGeier: WTF
GyrosGeier: the Debian package version is 7.5-1
GyrosGeier: which would suggest 7.5
adamk_: lol
adamk_: Alright, well other than trying Mesa from git, which you may not want to do on a work machine, I've got nothing.
GyrosGeier: hmm
GyrosGeier: that's indeed a 7.5.1
GyrosGeier: or something inbetweenish
GyrosGeier: will go with a non-rotated left monitor for the time being
GyrosGeier: given that I also bought three monitors for myself I'll be doing some extensive testing soon anyway :/
GyrosGeier: thanks lots!
kdekorte: GyrosGeier, the slowness on the rotated monitor is probably not mesa related but drm related
kdekorte: unless you are running compiz
rnoland: agd5f: what does the blit commit in drm fix?
agd5f: GyrosGeier: rotation will be slow if the total desktop size is larger than 2048 pixels
holzmodem: Hi, I add Option "BusType" pci to my Xorg.conf. I think this fixes the random freezes with EXA. (BUG: #23660) But under load the System is not usable (horrible slow). How can I fix this?
agd5f: since that's the max texture size
agd5f: rnoland: loops with h > 1
GyrosGeier: agd5f, in any direction, or horizontal only
GyrosGeier: ?
agd5f: GyrosGeier: any rotation
rnoland: agd5f: does it fix any of the corruption issues?
GyrosGeier: hmm
agd5f: 2048x2048 is the max texture size
GyrosGeier: has 1680x1050 and 1024x768
GyrosGeier: hmm
agd5f: rnoland: not that I know of
GyrosGeier: wait
kdekorte: GyrosGeier, and it works fine in Windows?
GyrosGeier: that can work
rnoland: agd5f: sigh... ok thanks... i'll get it merged
GyrosGeier: kdekorte, I don't have Windows
kdekorte: GyrosGeier, yea!
adamk_: Yay, my theory was correct.
agd5f: kdekorte, GyrosGeier: we currently use one big surface for multi-head. we really need per output surfaces to support this better
agd5f: that's what shatter is for
agd5f: but it's not done yet
GyrosGeier: agd5f, well, ideally I'd like to use three monitors on two cards
GyrosGeier: activating Xinerama leads to an instant crash though
agd5f: GyrosGeier: you'll probably have to wait for kms for that to work with dri
agd5f: GyrosGeier: try upgrading your xserver. IIRC, there were some crashes with xinerama in older xservers
agd5f: GyrosGeier: also, multi-card with IGP + discrete likely won't work until we fix up the bios fetch for the IGP seconday case
agd5f: *secondary
GyrosGeier: IGP is primary
GyrosGeier: the other card is a Mach64
GyrosGeier: does not want that one to be primary :P
ajax: agd5f: i think we get that right now?
GyrosGeier: okay
GyrosGeier: has to leave now
agd5f: GyrosGeier: ok. at the moment multi-card is busted in most configurations unless you are using vgaarb stuff
GyrosGeier: okay
chithead: is kms even planned for mach64? efforts to get the mach64 drm into the kernel have stalled apparently
agd5f: chithead: I don't think anyone has plans to add support for those old chips
GyrosGeier: thanks
holzmodem: agd5f, I tested your suggested option "bustype" "pci" to prevent freezes when using EXA on rv350. i think the system doesnt freeze any more (2hr no freeze, earlier freeze after seconds/minutes) but the performace is horrible. (BUG: #23660) is there a solution?
agd5f: holzmodem: try different agp modes?
holzmodem: agd5f, yes 1 / 2 / 4 freeze the system too, 2/4 after seconds, 1 after few minutes
MostAwesomeDude: chithead: Adding r128 is on my list, but not mach64.
MostAwesomeDude: agd5f: Shattering per-CRTC is a ways off; I'm still sucking at basic rendering shattering. :C
kdekorte: agd5f did you see this -> can you merge in http://pastebin.ca/1554016 seems to fix a lot of things for me on r6xx
zhasha: MostAwesomeDude: bogus dude
agd5f: kdekorte: yes, I'm looking at it now
kdekorte: excellent... thank you
MostAwesomeDude: zhasha: Yeah, I know. :C
zhasha: I'm guessing that means no shatter for server 1.7
MostAwesomeDude: Oh, that was always the plan. No shatter for 1.7.
zhasha: it said shatter for 1.7 somewhere on the wiki, or maybe it was wikipedia
ajax: feature lists are always lies.
zhasha: XI2 finally made it
MostAwesomeDude: zhasha: You're thinking of old shatter, in its own layer.
MostAwesomeDude: (Which would totally be possible if we were working in a language that permitted sane layering, wrapping, etc.)
MostAwesomeDude: Heh.
agd5f: taiu: pushed thanks!
MostAwesomeDude: (cd xserver; c2python .)
zhasha: is there such a program? :P
kdekorte: agd5f, well that fixes the half texture issue in the clutter stuff... there is a alpha issue on the textures should I open another bug for that?
MostAwesomeDude: Well, there's Cython, but it'd require a lot of effort.
MostAwesomeDude: And there's no good reason to do it right now.
agd5f: kdekorte: yes please
kdekorte: will do
MostAwesomeDude: Maybe in a few years, if X12 work hasn't started, and I still hate myself enough...
zhasha: uhh... you mean a revised X protocol?
MostAwesomeDude: Yeah.
zhasha: it would be nice to remove all the legacy retardation
kdekorte: 23714 is the bug # for the alpha issue
agd5f: kdekorte: I wonder if that is related to 23657
zhasha: MostAwesomeDude: somehow I don't think rewriting X in python is a good idea
MostAwesomeDude: zhasha: s/good/AWESOME/g
MostAwesomeDude: I'm convinced already.
zhasha: MostAwesomeDude: I said NOT a good idea
zhasha: but I don't have any evidence of it
MostAwesomeDude: All we need to do is get XCB to generate server-side code too.
MostAwesomeDude: Then mod XPyB to do the same.
MostAwesomeDude: Then start filling out all the guts.
MostAwesomeDude: It'll be AWESOME.
kdekorte: agd5f, is there a way I can disable saturate in the driver? If so I'll test that here
zhasha: MostAwesomeDude: what would be awesome is to remove all the multisession handling in X and just have wayland run multiple small-load X servers
legume: Direct openarena fixed - nice
MostAwesomeDude: twitch
zhasha: MostAwesomeDude: python is sloooow with some things
MostAwesomeDude: zhasha: Slow > difficult to maintain.
agd5f: kdekorte: line 2088 in r700_assembler.c
MostAwesomeDude: It's easier to fix the former, than the latter.
zhasha: but a factor 10 slowdown is... windows vista...
kdekorte: agd5f, yeah tried 0 there and same thing, tried 1 and got a whited out screen...
MostAwesomeDude: zhasha: Oh, worse. Python's roughly 200x slower than C for mathy algos.
kdekorte: value is 0 at that point
agd5f: kdekorte: probably unrelated then
agd5f: kdekorte: might look at the blend stuff in r700_state.c
zhasha: MostAwesomeDude: a simple for loop I just tested was roughly 140x as slow as C
MostAwesomeDude: But the biggest consumer of time in X is usually waiting for the graphics card.
zhasha: MostAwesomeDude: let's keep it that way and leave room for say... OTHER processes than X
zhasha: some of us like to open and never close our applications
MostAwesomeDude: zhasha: Hey, you might be surprised.
MostAwesomeDude: PyPy's working on stuff that matches hand-written assembly in speed.
MostAwesomeDude: Code always gets faster.
zhasha: who/what is PyPy?
MostAwesomeDude: But ugly code is ugly forever.
MostAwesomeDude: PyPy is a JIT Python interpreter.
zhasha: MostAwesomeDude: llvm needs a python frontend :P
MostAwesomeDude: zhasha: The PyPy team had one for a bit.
MostAwesomeDude: But it sucked hard.
Zajec2: DAMN IT
Zajec2: openarena seems to work!
kdekorte: Zajec2, does that mean your productivity is gonna drop?
zhasha: MostAwesomeDude: wow, pypy is a python interpreter in python that can compile itself to a standalone
Zajec2: kdekorte: how did you guess? :D
Zajec2: taiu: i think it's your patch that did it!
MostAwesomeDude: zhasha: Ain't it cool? :3
zhasha: it totally is
kdekorte: Zajec2, yup that was a good patch.. fixed several things for me
Zajec2: what a nice end of day :)
zhasha: MostAwesomeDude: I still think we should let lower level stuff like X be in C
MostAwesomeDude: zhasha: There's not as much point anymore. Plenty of X is straight-up algos without HW access.
zhasha: MostAwesomeDude: but straight up algos need to be nice and fast
MostAwesomeDude: zhasha: If your only problem with Python is its speed, then I'd say that Python's the clear winner. :3
zhasha: my other beef is the annoying syntax
MostAwesomeDude: :C
MostAwesomeDude: It's so elegant though.
dazedave: exit
dazedave: oops :o, wrong term
zhasha: MostAwesomeDude: there's nothing wrong with having it in C
MostAwesomeDude: zhasha: We'll have to disagree on this for now. :3
gravity: There's already a java X server
zhasha: ew
boghog: throws up
zhasha: "X12" would essentially have to be a rewrite
MostAwesomeDude: No, it wouldn't.
MostAwesomeDude: http://www.x.org/wiki/Development/X12
zhasha: oh, already on the way
gravity: I wouldn't go that far
zhasha: why do we still have colormaps?
ajax: colormaps are a fine idea for pseudocolor
ajax: directcolor is a mistake though
zhasha: sure are, but are there any cards that actually makes use of less than truecolor?
zhasha: MostAwesomeDude: maek X12?
zhasha: can we legally introduce changes to the protocol like that by the way?
ajax: pretty much every card you can buy still has pseudocolor support
ajax: and there are enough apps written for it to make it worthwhile to keep supporting
nanonyme: Hey, is this repo broken for everyone else too? http://cgit.freedesktop.org/~airlied/xf86-video-ati/
nanonyme: Cloning fails.
nanonyme: Unless I f*cked something up.
nanonyme: Retry.
agd5f: nanonyme: don't use the http url
nanonyme: Agh, works now. :3
nanonyme: Yeah.
nanonyme: agd5f: The git address for some reason didn't end up in the clipboard. :/ Didn't notice.
_Groo_: hi/2 all
_Groo_: could any of the devs take a look at bug 23715?
MostAwesomeDude: zhasha: X12 work won't commence until enough bugs have been squashed in the current setup.
MostAwesomeDude: No point in pulling an e17.
zhasha: MostAwesomeDude: what did they do?
MostAwesomeDude: zhasha: Well, they're still working on their oh-so-cool next-gen DE that's got all these shinies.
MostAwesomeDude: And they're pulling a DNF because they never got a solid plan in place.
dileX: MostAwesomeDude: christmas gift planned
MostAwesomeDude: dileX: Hey, I'm not knocking it. I tried e17 once. It was really pretty.
MostAwesomeDude: But X12 work probably won't start for a bit.
zhasha: it looks kind of like KDE4
dileX:
dileX: MostAwesomeDude: whats X12? X11++?
MostAwesomeDude: dileX: All the things that would break wire protocol, yes.
MostAwesomeDude: dileX: If it makes you feel better, nouveau hasn't had any official releases, and Wine took forever to get a 1.0 out. :3
zhasha: nouveau doesn't work all that good
zhasha: but considering the lack of documentation, it's understandable
MostAwesomeDude: zhasha: Modesetting seems pretty solid.
zhasha: because we know every windows convertee wants modesetting and doesn't care about 3d acceleration
MostAwesomeDude: Well, they're working on that too.
zhasha: I know, but it's not exactly able to compete with the official driver just yet
MostAwesomeDude: Neither are we.
MostAwesomeDude: We won by default; fglrx is no longer the recommended consumer driver for a lot of cards.
MostAwesomeDude: And that's because AMD is a big fan of open source; it wouldn't have happened if ATI hadn't gotten bought out.
MostAwesomeDude: (Although bridgman might have more insight on the matter.)
zhasha: fglrx no longer works for many cards
rhodan: I am afraid I forgot which packages I really need for KMS. Kernel - 2.6.31_rc8-r2. Xorg-Server - 1.6.3.901. And xf86-video-ati from GIT. Is that everything? I
rhodan: was on GIT for all xorg-related things, but the evdev broke Trackpoint scrolling (again).
dileX: zhasha: that lead to radeon-driver's "success"
rhodan: i wrote this into #radion and wondered why I didn't get any answers :')
dileX: or attracted a lot of testers and maybe new devs
agd5f: MostAwesomeDude: more of an economic thing. it didn't make financial sense for ATI to fund open source. not not a big enough market. for AMD, it is.
agd5f: rhodan: you need mesa from git too for 3d
rhodan: agd5f: ok
agd5f: and libdrm_radeon from drm git master
MostAwesomeDude: agd5f: Ah.
rhodan: or is there a way to unbreak evdev?
rhodan: i can't install the old version, it doesn't compile against the newer xorg-server
rhodan: did the syntax change or anything?
rhodan: http://dpaste.com/89652 x11-trackpoint.fdi
dileX: rhodan:
rhodan: is there something i can do about the trackpoint scrolling?
rhodan: it's the only thing that would keep me on the deprecated releases
rhodan: "deprecated" from the viewpoint of an ~arch gentoo user ;)
agd5f: rhodan: new evdev? synaptic driver?
agd5f: rhodan: file a bug
rhodan: agd5f: k
rhodan: agd5f: I'll ask in #xorg first
rhodan: ok, this is actually strange. could anybody help me writing a useful bug report?
rhodan: if i click a bit randomly, emulatewheel works for a split second and firefox scrolls
kdekorte: googleearth is working quite well on r600 with today patches and starting it with "vblank_mode=0 googleearth"
kdekorte: Whoa! had neverwinter nights running!
nanonyme: With usable speeds and direct rendering? :)
kdekorte: nanonyme, yes, but it crashed when I spun the room around... I could walk around and do a few things until the front of the player character was facing the camera
kdekorte: lighting was pretty dark in general
kdekorte: I have 1.61 of nwn, so I'm gonna upgrade to 1.69 and see if that helps
masa-: what is the difference between StandbyTime, SuspendTime and OffTime with DPMS?
mjg59: masa-: The three different levels of DPMS
mjg59: Ignore all of them except Off
masa-: so Standby and Suspend won't do anything "useful" which in this case is turning off my monitor after the specified delay?
masa-: or are they all the same in that regarg?
mjg59: masa-: They're different levels of powerdown, with nominally differing amounts of latency for powerup
mjg59: So standby would traditionally have turned off the beam but kept the element warm in a CRT
mjg59: But with LCDs, the latency is identical for everything and you should just use off
masa-: ok, thanks
kdekorte: SecondLife is running on r600 (32bit) some minor defects here and there but in general not to bad
AStorm: mmmmh
airlied: wonders about that alignment, not sure where that code from
airlied: I think it was glisses code originally
agd5f: airlied: can you change the topic for r600 3d?
agd5f: since it's working pretty well for most things now
nanonyme: Yay. :)
agd5f: airlied: thanks
nanonyme: agd5f: I thought you had ops on this channel too.
agd5f: nanonyme: maybe I do. not sure
kdekorte: font in clutter apps are still a problem...
reaVer: hi...
reaVer: http://pastebin.ca/1554347 <--- what this shit?
reaVer: (I'm on a 64bit machine)
damentz: reaVer, if you read the errors, it actually tells you
damentz: looks like 13 or 14 times in a row
kdekorte: that is what happens when you run 32bit programs on 64bit machines without the 32bit dri files installed... user error
reaVer: damentz: so you're not getting it?
reaVer: it's looking for lib32 libraries
reaVer: while it's a 64bit enviroment
damentz: looks like a distribution error
damentz: usually these open source drivers work out of the box
nanonyme: agd5f: Afaik you, MrCooper, airlied and ajax have sufficient privileges from chanserv.
damentz: especially for 32bit apps on a 64bit base
kdekorte: probably a package you don't have installed
mjr: do they these days?
mjr: (one remembers a time when 32-bit apps on 64-bit drivers would use indirect glx)
damentz: reaVer, why is it even looking in /opt
reaVer: damentz: that's my question
damentz: what distro are you on?
reaVer: archlinux
kdekorte: reaVer, self compiled?
damentz: they have 32bit libraries for a lot of things
reaVer: kdekorte: the driver themselves should be yeah
reaVer: and they were working
damentz: and plus they should be able to help you in #archlinux
damentz: they recommend 64bit over 32bit
damentz: they should know what's wrong
damentz: it must be a package you're missing
kdekorte: your glxinfo binary is 32bit, so it calls 32bit mesa which tries to open 32bit dri...
reaVer: zsh/3 1003 % ls /usr/lib/xorg/modules/dri
reaVer: EGL_i915.so r300_dri.so swrast_dri.so
reaVer: the files are there
reaVer: kdekorte: it claims to be 64bits
kdekorte: you can tell file type with 'file /usr/bin/glxinfo' should say something like 32-bit in there somewhere
reaVer: it's saying 64bits
kdekorte: well it still appears to be a packaging issue...
damentz: i strongly recommend checking #archlinux
damentz: do you need me to copy and paste your errors into their chatroom?
reaVer: damentz: no, I already asked in there
reaVer: no response so far
damentz: did you search their forums?
dileX: hey damentz
damentz: hey dileX
reaVer: damentz: no
dileX: damentz: how do you do?
damentz: reaVer, do that first
damentz: http://bbs.archlinux.org/viewtopic.php?id=68053
damentz: there's your solution
reaVer: erm, no
reaVer: note the issue being resolved
damentz: yes
damentz: you need a package
damentz: lib32-ati-dri
reaVer: no
reaVer: you didn't read the problem
reaVer: he ran the 32bit version
reaVer: which gaves those errors
reaVer: I'm running the 64bit version giving those problems
damentz: why is he installing a lib32 compatability package on 32bit
DanaG: here's what I get: /usr/bin/glxinfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
reaVer: no, he runs the 32bit version of glxinfo
damentz: ok...
DanaG: file `which glxinfo`
reaVer: on 64bit linux
damentz: that's your solution btw
damentz: i can't really help you at this point
reaVer: zsh/3 1004 % file `which glxinfo`
reaVer: /usr/bin/glxinfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
DanaG: hmm. Odd.
DanaG: Possibly an environment variable screwing it up?
damentz: yes, that's covered in that forum post
reaVer: LIBGL_DRIVERS_PATH=:/opt/lib32/usr/lib/xorg/modules/dri:/opt/lib32/usr/lib/xorg/modules/dri:/opt/lib32/usr/lib/xorg/modules/dri
reaVer: who the hell put that in?
dileX: we dont know
nanonyme: Icky.
reaVer: DanaG: that one was it
DanaG: Yeah, it made no sense that the 64-bit glxinfo would be looking only in the 32-bit path.
dileX: 3 times the same path
DanaG: =þ
reaVer: wonders why his /etc/profile is executed 3 times
reaVer: DanaG: the culprit was a remainder of cataclyst
ssieb: airlied: are you around?
hifi: mmkay, now I don't have black screen with vsync and current ddx anymore
hifi: though I still have slowdowns and don't know how to force disable it
mossila: How can i enable graphic driver on ubuntu?