airlied: EruditeHermit: still some optimisations not gone in, mainly the page allocator
EruditeHermit: airlied: is that a significant speed boost?
EruditeHermit: airlied: I remember I had one kernel running at about 40% faster than what I have now
EruditeHermit: 40% better FPS in some simple games
EruditeHermit: but I can't remember what stuff it was compiled with
zhasha: MostAwesomeDude: I was bored so I updated my extraction script and it should be pretty good now: www.zhasha.com/stuff/r300regs.xml
MostAwesomeDude: zhasha: Morning. :3
MostAwesomeDude: Lemme take a look.
zhasha: it still needs human intervention
MostAwesomeDude: Hm.
zhasha: anywho, we can use it along with rulesng to generate a r300_reg.h header
MostAwesomeDude: But getting there.
MostAwesomeDude: Yeah, this'll be AWESOME. :3
zhasha: well, we can generate anything really :P
MostAwesomeDude: But still. This is such a massive improvement from before. Really.
zhasha: I rewrote most of the script
zhasha: should be usable with little modification for r600 as well
MostAwesomeDude: Sweety.
MostAwesomeDude: *Sweet, even.
zhasha: www.zhasha.com/stuff/radeonreg.py
MostAwesomeDude: And rulesng can turn this into r300_reg.h more or less?
zhasha: yep
MostAwesomeDude: o/
zhasha: MostAwesomeDude: I'll likely make it output in the form of REG_NAME_ARG_NAME(x)
MostAwesomeDude: Sounds fine.
MostAwesomeDude: I'm not so sure that I like the unions in r600. They're very explicit, but I feel like they'll be a speed bump down the road.
zhasha: unions in r600?
MostAwesomeDude: Yeah, they're using unions to store regs.
MostAwesomeDude: Check it out.
zhasha: MostAwesomeDude: in the driver or the specs?
MostAwesomeDude: In the driver.
zhasha: MostAwesomeDude: I only see enums
zhasha: I'm assuming that's what you meant
taiu1: nha: you may need for kernel - drm/radeon: fix support for vline relocations.
airlied: taiu1: thats upstream now
taiu1: yep, I dont know if his kernel's was new enough
nha: k, I'll see about getting a more recent kernel
nha: it's just always such a big hassle to recompile a kernel using the debian-style tools
nha: and without the debian-style tools it's a mess to figure out the exact initrd settings
chithead: if you compile the kernel yourself, why do you need an initrd?
airlied: nha: make install doesn't work?
nha: last time I tried without, things went horribly wrong
nha: airlied: in order to keep my sanity in the face of system lockups, development machine != testing machine
airlied: nha: ah, I develop over ssh ;-)
airlied: though sometimes I wish I was smarter, some of my test machines are seriously slow
nha: well, I like my graphical editors, and I like them not to crash ;)
vehemens: how does one flag r600 problems/patches. bugzilla?
nha: I've considered going via NFS or something, but so far I haven't
airlied: nha: I use xemacs over ssh
airlied: sometimes I use xemacs locally and use ssh to read files
airlied: I think anholt tried using sshfs for a while not sure how thatwent
airlied: easier to setup than nfs
airlied: hopefully we'll be finished the kernel soon!!
amarsh04: nha, I just use kernel-package, bzip2 -dc name-of-kernel.tar.bz2|tar -xf /dev/fd/0;cd linux-source-name-of-kernel; time MAKEFLAGS="HOSTCC=gcc-4.4 CC=gcc-4.4" CONCURRENCY_LEVEL=32 make-kpkg --config menuconfig --initrd linux-image
nha: amarsh04: how do you recompile after making small changes?
airlied: amarsh04: tar -jxvf works ;-)
amarsh04: I haven't been doing that nha... usually I'm downloading an entire new kernel
vehemens: airlied: code in any form is never "finished"
nha: amarsh04: yeah, getting an entirely new kernel and working with that is fine for me; it's the incremental hacking that's unbearable to me because I can never quite get it to work right
amarsh04: tar -xf /dev/fd/0 worked across UnixWare 1.X, Solaris 7/8/9 and linux so I saw no reason to change (-:
MostAwesomeDude: "A program is perfect not when there is nothing left to add, but when there is nothing left to take away."
MostAwesomeDude: So, just finish adding all the GL extensions, then take away everything else (e.g. teh suck) and we're finished. :3
amarsh04: I compile both for amd64 and for i386 on my amd64 machine, so I do make-kpkg clean in between
airlied: vehemens: once mesa can read email I think its finished ;-)
dileX: amarsh04: CONCURRENCY_LEVEL=32. whats that for a fuckin fast machine :-)?
amarsh04: no, only have 2 cores, but with 4 GiB RAM, why not put it all to use? (-:
vehemens: i'm waiting for mesa to be a kernel module
nha: amarsh04: I'd like to throw away as little already-compiled stuff as possible
amarsh04: understood, nha
amarsh04: I couldn't get mesa to compile earlier today
airlied: nha: oh also ccache
nha: airlied: already set up :)
amarsh04: r600_cmdbuf.c: In function ‘r600_cs_emit’:
amarsh04: r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known
vehemens: amarsh04: sounds like a header problem
amarsh04: kernel header not found?
nha: aha! removing the debian/stamps directory seems to do the trick
amarsh04: yes, that rings a bell nha
nha: the worst part, however, is making sure that one removes as many configuration options as possible, but without removing *too* many of them
nha: that's not exactly user-friendly
amarsh04: I had that fun doing a git-bisect on the kernel on this pii-266
nha: ouch, the pain
osiris_: nha: I've just pushed updated vbo branch - sauerbraten leak is fixed
osiris_: glxgears segfaults with current master
nha: osiris_: have you tried make clean && make
osiris_: will try
nha: there was a libdrm change, and the Mesa makefiles don't always pick up on stuff like that
osiris_: yeah, clean build fixed it
nha: hooray, installing .31-rc5 fixed my troubles
nha: airlied: that rv515fix against .31-rc5 seems to make no visible difference for me on an RV530 (PCI ID is 71c1)
nha: both with and without, things seem to be working only with radeon.agpmode=-1
nha: mainboard says:
nha: 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
nha: 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
osiris_: debugging an app using a cell phone without qwerty keyboard is slooow :/
osiris_: nha: do you have ut2004 game?
nha: osiris_: no
nha: I tried half-life 2 yesterday via Wine, and it spends about 50% of CPU time in the X server servicing GetImage requests
osiris_: are you willing to download a demo? I don't have second machine to debug a deadlock :(
osiris_: the game locks only without kms
nha: what deadlocks?
MrCooper: nha: what does 'dmesg|grep -e GTT -e VRAM' say?
nha: :/
MrCooper: nha: (without agpmode=-1)
osiris_: nha: what wine version do you have?
nha: osiris_: the one from ubuntu 9.04
nha: MrCooper: I'll report back to you as soon as I can reboot
osiris_: nha: try some newer one. newer versions use fbos (if available) for offscreen rendering
MrCooper: nha: no hurry
nha: tbh, deadlocks are about the nastiest thing to debug, and the thought of trying to figure out a deadlock in a soon-to-be-pretty-outdated codepaths is not what I imagine a perfect Sunday to be like ;)
MrCooper: nha: the code which places the VRAM and AGP apertures in the card's address space needs some work still
MrCooper: osiris_: it can't use FBOs without KMS though
nha: MrCooper: oh, the error I got was something about CP writeback failure, and it all went downhill from there
MrCooper: nha: yeah the GPU can lock up if the apertures aren't aligned properly
MrCooper: of course it could just be an AGP bridge/driver issue
nha: very possibly; this VIA AGP bridge has caused me grief from the day I first got it
MrCooper: and there may well also still be other AGP related bugs in the radeon KMS code, e.g. it only works for me with 1x whereas 4x is rock solid without KMS
nha: on the other hand, I believe it used to work on non-KMS setups
nha: when I try to set agpmode=1, I get complaints that only 4 and 8 are valid modes
MrCooper: with KMS we're exercising the AGP driver/hardware much more dynamically than without, so we're more likely to trigger issues there
MrCooper: right, AGPv3 only supports 4 and 8
MrCooper: though I don't think there should be that much difference up until KMS initialization...
osiris_: MrCooper: any comments on my vbo branch?
MrCooper: osiris_: haven't tried the current version yet, but the one from a couple of days ago (when you announced it on IRC) works here with some minor endianness fixups
nha: MrCooper: http://radeon.pastebin.com/m5d65f379 <-- this is without any radeon.agpmode setting
MrCooper: nha: so the AGP aperture is aligned to 512M, I think that should be enough :}
nha: with radeon.agpmode=-1, the GTT is mapped directly after VRAM
MrCooper: yeah, well the problem in my case was actually that the AGP aperture is at 0 and VRAM immediately afterwards, so VRAM wasn't aligned properly if I tried with too small an AGP aperture
papillon81: MrCooper: here I am :-)
osiris_: nha: I think that during context destroy/creation (when a game changes display resolution)
nha: can you give an example of where it happens?
nha: my changes work by giving a fake backing store to a fake texture, where the fake backing store is taken from the framebuffer itself
nha: this should work unless the framebuffer has size 0
papillon81: MrCooper: that's very strange. with agp disabled (via kernel commandline), the machine does not even boot up. problem is I can't see what's going on
MrCooper: papillon81: you could build radeon as a module, boot without it loaded, then load it from an SSH login
papillon81: MrCooper: that sounds good :-)
papillon81: and the agpgart driver as well, i guess?
nha: osiris_: ahhh wait, you're using non-KMS, right?
MrCooper: shouldn't matter
osiris_: nha: yes
nha: osiris_: can you please try whether the following fixes your problem: git://anongit.freedesktop.org/~nh/mesa bugfixing-non-kms
osiris_: nha: sure
osiris_: nha: the patch fixes the problem, although I didn't check if it doesn't cause any regressions elsewhere
nha: osiris_: it shouldn't; it just reverts to the previous behaviour on non-KMS
nha: but please report back if you find some other regressions, and I'll push the patch later, just in case something comes up in the meantime
osiris_: ok
papillon81: MrCooper: modprobe radeon agpmode=-1" crashes the whole machine
papillon81: i'll try to get some debug
papillon81: MrCooper: http://pastebin.com/d37c8fdd9
papillon81: MrCooper: bbl
taiu: demos/shadowtex depth texture seems garbage
nanonyme: Which card?
taiu: r500 kms
nanonyme: notices about all stdin commands are capable of breaking output of texenv on r600
nanonyme: taiu: And yeah, no idea, I don't have the relevant hardware nor am I experienced with the driver.
nha: taiu: and silly me though depth textures would work on R500
taiu: :)
nha: taiu: I was chasing a depth texture bug on R300 to no avail, and it really confused me that it seemed to work correctly on R500
nha: it still confuses me somewhat that the piglit depth texture test works out fine
nha: that still doesn't make sense, even after this news
nha: but yeah, it seems like the texture format setup changed in some KMS-related changes, and now it's no longer correct
nha: MostAwesomeDude: seems like recent kernel / libdrm changes made gallium fail
MrCooper: fail how?
ati: EXA acceleration causes out of range
nha: [ 9631.667335] [drm:r300_packet0_check] *ERROR* No reloc for ib[175]=0x4E38
nha: and stuff like that in dmesg
MrCooper: nha: probably tiling support? You may need the corresponding kernel support
nha: ah maybe
nha: though it has to be gallium which is at fault here, because everything else (kernel, ddx) is recent
MrCooper: or maybe the Gallium driver needs to grow COLORPITCH relocs
zhasha: nha: if it's using index buffer render, then that's the cause of fail
zhasha: it's broken and was never looked at nor tested
nha: (btw, this is glxgears on R500)
nha: zhasha: and 4E38 is indeed COLORPITCH, so MrCooper is right
zhasha: nha: I don't understand the error message then
nha: well, clearly the kernel started to require reloc info for the COLORPITCH register, and gallium doesn't write it
nha: and I just got an invalid command stream in openarena when going to Setup -> Controls
nha: and it seems reproducible, too
nha: there's also a misrendering in sauerbraten, which could really be pretty much anything related to vertex programs and vertex handling
nha: osiris_: btw, I pushed that non-kms bugfix
osiris_: ok
papillon81: MrCooper: ping
MrCooper: papillon81: it detects an iBook, is that correct? Also is that certainly the last output, or could some of it have been lost?
MrCooper: anyway afk for a bit, bbl
papillon81: MrCooper: ibook is allright. output can be lost, of course. I had to restart and read the logfile afterwards so it is probably not complete
mpyne: airlied: ping? I have a Linux radeon KMS failure that seems to be caused by a commit adding a workaround for vram sizing on r100 chips
mpyne: commit 7a50f01a. (I also had to revert ed8f0d9e since it depends on this commit)
mpyne: I'd let you know if X11 actually worked after reverting (radeonfb is fine) but the rest of the 2.6.31 kernel is apparently going to hate me since it freezes later in bootup
papillon81: mpyne: something with "radeon 0000:00:10.0: Invalid ROM contents"?
mpyne: papillon81: I don't know, I can't see the screen. :(
papillon81: oh yeah. that sounds familiar
mpyne: I tried without modeset and with modeset=0 but I couldn't seem to stop KMS either time
mpyne: probably due to radeonfb
papillon81: mpyne: modeset=-1?
mpyne: haven't tried that, no
nanonyme: yays at Fedora now making working kernels for Mac's again
nanonyme: (they made PPC kernels for a time that didn't boot with Mac computers)
suokko: agd5f: Sorry. I forgot to do git add before commit --amend :(
dileX: mpyne: is that a rv515?
mpyne: rv505 CE
mpyne: lemme get the exact lspci
mpyne: 01:00.0 VGA compatible controller: ATI Technologies Inc RV505 CE [Radeon X1550 64-bit]
mpyne: [1002:715f] <-- pci vendor/id
suokko: mpyne: Do you have fbcon loaded?
suokko: and you shouldn't use radeonfb with kms
dmb: that would be a very evil thing to do
dileX:
mpyne: suokko: I think I have it compiled in. And I'll try without radeonfb (but then what resolution do I get for console?)
suokko: mpyne: You should get native resolution for your monitor
dileX: mpyne: might be the broken rv515 (vram) init (if its the same chip-family)
suokko: That why there is kms
suokko: dileX: I think there was simple patch to fix that r500 vram init
mpyne: anyone know the .config option for fbcon? :)
suokko: there was missing call to checking vram size in r500 code path
dileX: mpyne: try this fix
mpyne: ok
dileX: mpyne: check your /var/log/messages for "VRAM" and "0"
mpyne: Well when I have a "Aug 2 11:21:06 midna [drm] radeon: VRAM 256M" from my KMS boot this morning
mpyne: s/when I/I/
mpyne: and also "Aug 2 11:21:06 midna [drm] radeon: 256M of VRAM memory ready"
mpyne: brb, baby
nanonyme: Hey, how often are the development boot.iso's regenerated?
nanonyme: I'm apparently going to be needing one that has kernel 2.6.31-0.118.rc5 for ppc.
marvin24: I'm still getting "screen all black" while running redbook/hello on rs780
marvin24: is it only me?
Nightwulf: hi
glisse: marvin24: i don't think any dev used a r780 yet
glisse: as IGP are often slightly different you might be hitting somethings that was forgotten
marvin24: the funny thing is, that glxgears works fine
marvin24: but ok
Nightwulf: but only in software rendering mode!
marvin24: Nightwulf
marvin24: no
marvin24: with direct rendering
Nightwulf: you mix up dri and gl acceleration
suokko: Does redbook/hello use single ubffered visual?
marvin24: suokko: how to find out?
suokko: yes. It does
Nightwulf: marvin24: just start glxinfo and search a line beginning with "OpenGL renderer string" and tell me, what you read behind it please
mpyne: Before I upgraded my kernel I'd get a screen all black with Mesa
suokko: marvin24: the problem with hello is that focsed window with direct color visual causes black screen
nanonyme: Nightwulf: glxgears works just fine on the r600 driver.
mpyne: indirect, direct rendering
mpyne: even sw rendering
mpyne: it all didn't matter
Nightwulf: nanonyme: yes but without 3d acceleration which is, what i mean
nanonyme: Nightwulf: That's crap.
Nightwulf: lol...as you think
nanonyme: Nightwulf: Using r600 Mesa driver implies GPU rendering.
suokko: And I did check the code that redbook/hello is hitting the direct color visual bug
marvin24: suokko: and what does glxgears use?
suokko: double buffered true color visual
mpyne: glxgears worked fine for me but gliv and kwin did not
Nightwulf: nanonyme: which isn't out until now...there exist mesa branches which support parts of the implementation
nanonyme: Nightwulf: Actually it's in master.
nanonyme: Well, the Mesa part is.
suokko: marvin24: you can alt tab to another window and move it so that you see the hello window
Nightwulf: nanonyme: but not completed yet...parts work, parts do not
nanonyme: Nightwulf: True but it does run glxgears just fine.
nanonyme: Which was my point.
Nightwulf: nanonyme: may be...but that's not hell of a complex 3d app :P
nanonyme: Nightwulf: We were not talking of complex 3D apps but glxgears to begin with.
marvin24: suokko: thanks - that really works
nanonyme: Nightwulf: You're just pulling in random stuff to the conversation since you being wrong is too obvious.
Nightwulf: nanonyme: don't get me wrong, I'm very amazed of the work and it's progress both teams do...but it's nothig for the unexperienced user yet
nanonyme: 21:18 < marvin24> the funny thing is, that glxgears works fine
nanonyme: 21:18 < Nightwulf> but only in software rendering mode!
nanonyme: That was a false claim.
Nightwulf: nanonyme: as you mean
marvin24: Nightwulf: maybe you meant, that it feels like software rendering (only 10 times slower) :-)
Nightwulf: marvin24: no, what i ment was, that with *realeased* versions of kernel drm/mesa and radeon/radeonhd drivers you will only get software rendering...not more and not less
yangman: Nightwulf: look, this conversation isn't going anywhere. you jumped into a discussion with no context and started making irrelevant claims
suokko: lshw claims that CPU version is "Engineering Sample" :)
Nightwulf: yangman: no...but you could take into consideration, that I didn't express myself exactly enough...anyway, if there was a misunderstanding on my side, which is of course possible, that one could have just told me and not starting to throw accusations into the channel...I don't know what this type of conversation should lead to but I don't like it
suokko: Does anyone use thunderbird with git master without kms? I just saw with r500 card problems that thunderbird doesn't render all texts (some of folder names and mail subjects are missing if not clicking them and forcing redraw)
mikkoc: works fine here
mikkoc: tb 2.0.0.22
mpyne: suokko, airlied: The rv515-fix patch seems to have fixed my bootup issue, thanks.
mpyne: well, either that or ensuring fbcon was disabled, since I did both.
glisse: mpyne: fbcon should be fine
mpyne: apparently mesa likes hanging the kernel or something though :-/
Zajec2: has broken glxgears in mesa git
Zajec2: is that known?
Zajec2: should i bisect?
Zajec2: r67x
DanaG: interesting: http://anandtech.com/weblog/showpost.aspx?i=628
Zajec2: agd5f: you broke my glxgears ;) http://bugs.freedesktop.org/show_bug.cgi?id=23095
nanonyme: Zajec: Remembered to update your DRM?
nanonyme: Apparently yeah...
nanonyme: Strange.
airlied: glisse: won't you need to CS passes in the kernel to do this?
airlied: one to figure out the placemtns from the use case, then do placement, then a second pass to relocate the offsets
glisse: well depending on how fine grained you want to be that could be solution to have better hint in kernel space
glisse: but for time being i think userspace provided hint is good enough
glisse: i thought memory move was a culprit but it seems that we keep deleting/creating bo :(
airlied: yes thats why I spent time write page allocators ;-)
airlied: we need to add back the clear optimisation to ttm as wel
glisse: well it's odd usage pattern
airlied: its normal X usage
airlied: create a pixmap, render stuff to it, copy that to the window, destroy pixmap
glisse: also there is a very odd perf decrease with time
airlied: yeah someone mentioned after running for a day or so
airlied: probably TTM fragments
glisse: i cold boot q3 demo1 fps is 33.6, i rerun q3 demo1 and it keeps degrading util it stabilize at some lower level
glisse: but object are destructed
glisse: so fragmentation should play here
airlied: try restarting X
glisse: or the drm_ stuff used in the allocator is buggy
airlied: since that should clear out all the buffers
glisse: restarting X doesn't play
airlied: the drm_mm stuff is used in GEM as well
glisse: removing kernel and reposting neither
airlied: so its well tested
airlied: oh that is wierd
MrCooper: if it is fragmentation, it should show up in profiles
airlied: it might be CPU pages either
glisse: only reboot helps
airlied: getting pages can take longer
airlied: which is why I had page allocator for all pages
airlied: but you removed that ;-)
glisse: readding normal page is easy that reminds me that i have half finished rework pool allocator waiting, using the global alloc stuff to avoid static things
glisse: hhhmmm this perf stuff is heratic
airlied: but you should be able to see those things in sysprof
glisse: reposting twice and i am nearly back to cold boot perf
glisse: this is likely memory related
glisse: i will try after find /
airlied: I was going to add debugfs dumping of the mm structs at some point
airlied: so we could see vram/gtt snapshots
glisse: yeah might be usefull for when we want to address fragmentation issue
airlied: I'd like to know how much impact a two pass CS will be
airlied: or if we need a CS redesign
glisse: i am benchmarking the cs and its looking bad
airlied: and if we do, when will we be happy.
glisse: i think i will take best fps after cold reboot after ref
glisse: rather than trying to find out why it's degrading now
airlied: I used to do the offset calcs at the reloc processing time, instead of separate
airlied: the locking overhead sshot up
airlied: since it had to do bo lookups by handle at every reloc point
MrCooper: I'm off for tonight, bbl
airlied: MrCooper: having user buffer access might help a lot for DFS
glisse: btw DropMaster should not be call in CloseScreen in ddx right ?
airlied: I need to expose those somehow I supose
airlied: glisse: it sholdn't be necessary
MrCooper: airlied: yeah
airlied: since we close the device
airlied: though it might help avoid a race
MrCooper: it is necessary
MrCooper: didn't I explain it in the commit log?
glisse: airlied: well if you run Xorg -retro without anythings than you can't run gl app such as q3
airlied: glisse: you need a wm
airlied: hmm screen recylcing ftl
glisse: X closescreen drop master and reinitscreen but reinitscreen doesn't call setmaster
airlied: since you don't get msater back
airlied: office &
glisse: ok i guess i will have some sleep now :)
vehemens: glisse: does your r600 kms/cs work provide support for dri2 as well?
MrCooper: glisse: so add a SetMaster call to ScreenInit
glisse: catchup with ouy in the morning
glisse: vehemens: now, piece are missing
glisse: no
airlied: glisse: the reason I kept the domains separate was an extra hint to the kernel
airlied: since writing to GTT might not work on some hw
MostAwesomeDude: nha: You...oh. You aren't around.
MostAwesomeDude: Gonna merge the tgsi-to-rc stuff now.
spstarr: watches mjg59's talk from GCDS
spstarr: mjg59: so for you it's killing polar bears, and airlied is killing kittens ;)
spstarr: its
fr33mind: Hi, i have a Ati X1950pro and i can't get it work with radeonhd...i've followed this tutorial: https://help.ubuntu.com/community/RadeonHD and nothing. The monitor simply suspends and /var/log/Xorg.0.log is empty
Zarin: Is the invisible bridgman around?
bridgman: Zarin; you rang ?
Zarin: bridgman, :)
bridgman: fr33mind; still around ? If so, which distro ?
bridgman: you might want to hop across to #radeonhd for radeonhd questions
Zarin: Just trying to work out this resizing thing
Zarin: Jason is in #kde-devel
bridgman: hold on, were you using radeon or radeonhd ? you said "radeon" wasn't working but you linked to a radeonhd page
fr33mind: bridgman, hi
fr33mind: Trisquel (ubuntu based)
fr33mind: bridgman, i tried radeonhd
fr33mind: and i said radeonhd :P
bridgman: ok; did the distro come with radeon, as ubuntu does, and what happened with radeon ?
fr33mind: came with radeon i think (not radeonhd)
fr33mind: bridgman, why?
fr33mind: any idea?
bridgman: so did it work with radeon ?
fr33mind: bridgman, with radeon says: "[drm] failed to load kernel module "radeon""
fr33mind: but i still have a GUI
fr33mind: so i must be using vesa
bridgman: nope, you have 2D but without acceleration
fr33mind: hmn
bridgman: you probably were running radeon not vesa; what did the log say ?
fr33mind: if i do "grep radeon /var/log/Xorg.0.log" it gives me that message i told you
fr33mind: you want the whole log?
fr33mind: :P
bridgman: sure, but that is just radeon saying "I tried to initialize the drm driver and it didn't work"
bridgman: so we need to look at your drm driver
fr33mind: ahm
fr33mind: ok
bridgman: does your distro use the same kernel as Ubuntu, and if so which version of U does it match ?
fr33mind: it uses Linux-libre
fr33mind: you know?
fr33mind: the version is...2.6.28-14-generic
agd5f: fr33mind: you likely need the firmware-linux package
fr33mind: i'm guessing it's proprietary?
bridgman: yep
fr33mind: but why do i need it?
bridgman: because it makes the acceleration work
bridgman: some vendors burn the firmware into the chip, others load it from a file
bridgman: we happen to load it from a file
fr33mind: hmn...ok
simplexe: hi all
bridgman: ;)
fr33mind: anyway thanks for you help ;)
bridgman: no problem. Note that you should be able to get basic 2D acceleration without the firmware; it's just the 3D engine that can't work without it
fr33mind: yea i can, but the 2D it's a bit slow
agd5f: fr33mind: you really need 3d for most of the eye candy
fr33mind: i'm not interested in the eye candy ;)
fr33mind: it's just, for example, switching between tabs it has a small delay
agd5f: fr33mind: most of the advanced "2D" accel uses the 3d engine
agd5f: same for the video accel
fr33mind: hmn
fr33mind: i see