vldmr: can someone help me ?
spstarr: aha
spstarr: DanaG: n/m
spstarr: it looks like the screensaver is causing GPU lockup in a different way
spstarr: i will disregard for now glisse thinks he knows what is causing it
spstarr: im gonna get some sleep so I can be up when glisse is in terms of tz diff
vldmr: spstarr: plese, can you past the link for download open source driver ?
soreau: vldmr: Which distro are you using?
vldmr: slackware current
vldmr: xorg 7.5 kernel 2.6.33
soreau: You might want to review the wiki, link in the topic here
vldmr: ok... thanks
vldmr: I will see it
dileX: ask himself why ppl dont read topic/wiki
DanaG: argh, radeon took like 15 seconds to resume from suspend.
DanaG: Or rather, the whole system did.
dileX: DanaG: for me-myself-and-I it take hrs to "resume" from sleep :-)
dileX: (try with strong coffee)
DanaG: fglrx used to take like 5 minutes, if it decided like working. =þ
DanaG: 5 minutes of system having really-fast "heartbeat" (yay heartbeat LED).
DanaG: [107199.807990] PM: resume devices took 14.810 seconds
DanaG: on my netbook, it's more like 1.5 seconds, tops.
airlied: I think pm and suspend have some interaction issue
Nightwulf|work: hi all
gnu_d: Hi, how to overclock my GPU ?
MostAwesomeDude: gnu_d: No.
gnu_d: I have nothing to lose :D
MostAwesomeDude: Sure you do.
MostAwesomeDude: For starters, we don't support overclocking and our driver doesn't do it.
MostAwesomeDude: So if you overclock, or do any other vbios mods, we can't help you if your card doesn't work.
MostAwesomeDude: In addition, you probably don't want to overclock.
MostAwesomeDude: You want a better GPU but you're not willing to spend money.
MostAwesomeDude: And you haven't considered the cost of a new GPU if you slag your current one.
gnu_d: no, I'm willing to spend money for a better GPU, but there is only one problem, I don't have them:D.
MostAwesomeDude: Moreover, overclocking doesn't increase performance much.
MostAwesomeDude: The big performance jumps come from going to a newer GPU when it comes to Radeons.
MostAwesomeDude: Unlike GeForces, which are often sold with disabled lanes or underclocked cores, Radeons are usually sold at top speed.
CompuHacker: you know, I'm not sure whether "freenode" means either "open source" or "alternative topics", but a better name for this channel would be #openradeon or something other than the name of the line of cards
DanaG: well, "radeon" is the driver itself.
CompuHacker: oh jeeze.
CompuHacker: well, I guess that's what I get for not being on IRC for a few months, then rushing on to see what's changed and making fun of random channels.
MostAwesomeDude: CompuHacker: Freenode *is* expressly for open source projects.
CompuHacker: Oh man I'm stupid. I always thought it was like a central hub for IRC. I guess I should have realized why the top... 50 or so channels are all open source projects.
MostAwesomeDude: Nope.
yangman: it's sentence 2 of the main website, even ;)
MostAwesomeDude: There are some offtopic channels; look for channels with "offtopic" in the name.
chithead: like ##otw but you get banned there for lurking
Tommeh: So how the hell did #cisco get a channel?
chithead: there is also a ##windows channel. so? it is not that closed source is banned
Tommeh: "Freenode *is* expressly for open source projects"
Tommeh: I was listening to him :)
Tommeh: (As he is Most Awesome)
MostAwesomeDude: There are open-source thingies on Windows, y'know.
MostAwesomeDude: Hm. #cisco should probably be ##cisco, if I remember the rules correctly.
MostAwesomeDude: But whatever. There are channels that have nothing to do with Freenode.
MostAwesomeDude: For example, my bosses run about three of the Freenode servers, plus their web server, so we get to make channels when we like.
dileX: while looking at
zhasha: --with-state-trackers="dri"
dileX: which *_dri.so is this?
dileX: if I use ddx with renamed radeong_dri.so to r300_dri.so thats still r300g st/dri?
zhasha: oh you want to use st/xorg?
dileX: IIRC r300g st/xorg is radeong_drv.so (ddx) with radeong_dri.so (mesa)
dileX: (and black screen :-))
zhasha: I'm not sure what you're trying to accomplish
dileX: whats "r300g st/mesa"?
dileX: hmm
dileX: src/mesa/state_tracker
zhasha: that's OpenGL
dileX: src/gallium/state_trackers
dileX: OK, its different paths
zhasha: clarify please. st/mesa is in src/mesa/state_tracker because mesa still has loads of legacy drivers
dileX: I thought --with-state-trackers is only in combination with --enable-gallium-*
zhasha: it is
zhasha: lest gallium is still enabled by default
dileX: I cant imagine if src/mesa/state_tracker is the dir for st/mesa you have to use --with-state-trackers configure option
zhasha: st/mesa needs a co-state tracker (dri or glx) to actually do anything
zhasha: ./autogen.sh --enable-gallium-radeon --with-dri-drivers="" --with-state-trackers=dri
zhasha: make
dileX: do I need --enable-gallium-radeon for st/mesa - I think no
dileX: If I look here in my autogen.sh line and the resulting config.status log
dileX: Gallium/Trackers dirs
dileX: why the hell is svga i915 i965 built? (Gallium-section Driver dirs:)
MrCooper: the goal is to build as much as possible by default to catch regressions early
dileX: so whats the autogen.sh/configure line to get st/mesa? which ddx and mesa-dri drivers to use?
dileX: (maybe its simply "r300 classic" :-)?)
MrCooper: dileX: what exactly do you want when you say 'st/mesa'?
CompuHacker: Obviously you want a street in Mesa, Arizona.
CompuHacker: But don't take it from me. Take it from him.
dileX: I was wondering what it is while gasping on marek's mesa repo
MrCooper: it refers to the Gallium OpenGL state tracker
[Enrico]: mhm is the PM patch merged in drm-linus or drm-next actaully? (iirc it is merged in drm-radeon-testing but that is still .32 eheheh )
hagabaka: does using radeon.agpmode=-1 affect performance?
evil_core: hi all
BioTube: hagabaka: it restricts your card to PCI speed, so yes
hagabaka: oh
BioTube: hagabaka: what gives AGP its speed is also what makes it buggy
hagabaka: starting with 2.6.33 rc7 kernel, I get a backtrace when booting, unless I set agpmode=-1. one of the lines says "radeon_agp_init+0x14/0x360 [radeon] SS:ESP 0068:f68f7cf0"
BioTube: you should probably file a bug
hagabaka: where should I file it?
BioTube: http://bugzilla.kernel.org/
hagabaka: ok
glisse: BioTube: pcie is faster than agp, well pcie with big number of lane :)
glisse: link
[Enrico]: mhm i get a small blue noise effect with kernel .33 vanilla with kms enabled on my hd 3470..... is this a known bug or i have done something wrong? this noise shows up as soon as radeon is loaded, so it is a drm thing i guess.....
Wizzup: http://www.fsf.org/photos/rms-sign.jpg Wonder when that was taken
Tanktalus: Wizzup: I'm just not sure what video card RMS must use. Aren't they all "enem[ies] of your freedom"? :-)
Tommeh: Do Intel require any form of closed source code?
edwin: I wonder why it says ATI and not NVidia
mazzachre: Tommeh, No
Tommeh: edwin: it's probably quite old.
Tommeh: But yes, I do wonder.
Dr_Jakob: because ATI was at the Uni where RMS works/lives and had a talk.
mjg59: edwin: It was at an ATI presentation
edwin: ok that makes sense
mazzachre: [Enrico], what noise effect?
[Enrico]: mazzachre: well i have really small blue lines going around of my screen
edwin: hmm, apr 18 2008
edwin: did ati have free drivers at the time?
amarsh04: mazzachre - intel don't provide all details of the graphics in the 945G polsboro (sp) chipsets
[Enrico]: mazzachre: to be precise only horizontal lines
amarsh04: that's what puts me of buying a netbook that claims linux support - if it requires non-free graphics (or wlan) drivers I would feel cheated
mjg59: amarsh04: No, there are full details for 945
amarsh04: s/of/off/
mjg59: amarsh04: You mean GMA500
[Enrico]: mazzachre: the fun thing is that i can't screenshot them! in the screenshot they do not appear!!
amarsh04: thanks mjg59
mazzachre: [Enrico], That sounds strange..
[Enrico]: mazzachre: yeah it is..... but if i boot without kms (so with ums) it works great
mazzachre: amarsh04, No, but they don't provide closed sources either... so you are just fucked...
[Enrico]: mazzachre: well may be those blue lines are so thin that the screenshot program delete them
mazzachre: [Enrico], ok... then it must be in the kms... what kernel and drivers?
[Enrico]: mazzachre: .33 kernel video-ati libdrm and mesa from git master
mazzachre: [Enrico], Hmm. same as here.. I don't have any of those errors...
[Enrico]: mazzachre: the issue start as soon ad radeon is loaded (it is builtin so very early, even before init!) and persist even when X starts
Shuren: now, i have tried out prey demo, just curious... but i have a lot of "WARNING: Couldn't load image" in terminal... anyone tried it out with success? is it a radeon releated problem? i have hd4670 with 2.6.33 latest video-ati e mesa git
mazzachre: [Enrico], And it does not occur without kms? And not in windows or other? (have you tried other monitor?)
[Enrico]: mazzachre: well this it is a laptop, so the video card is an asus dedicated card i guess..... may be this is the point
[Enrico]: mazzachre: with UMS it is all ok, nothing wrong at all, i didn't tried another monitor, but i can of course if you wish
mazzachre: [Enrico], It just sounds like something is amiss with the kms and drm...
[Enrico]: mazzachre: yeah i thought the same, but i have no idea what/where :)
mazzachre: [Enrico], take hold of airlied and ask him about debugging it...
[Enrico]: mazzachre: wow ok :)
[Enrico]: mazzachre: thank you very much for your time :)
mazzachre: [Enrico], no problem (did not help that much.. only confirm where you already thought the problem is...) :D
[Enrico]: mazzachre: well you pointed me to a direction at least, it a lot better then nothing :)
[Enrico]: it's *
mazzachre: :)
evil_core: I got Xorg crash when running Dethkarz Zenehack glide wrapper
evil_core: anybody can help me?
evil_core: http://pld.pastebin.com/jxdSwbJx
evil_core: its xorg.log
diverse_izzue: test-post
evil_core: need I simply ro recompile xorg server?
evil_core: diverse_izzue: ?
diverse_izzue: evil_core, had trouble writing to this channel before, apparently works now
diverse_izzue: so since kernel 2.6.33 i have trouble with external screens, in that i have a horrible jitter on them when using KMS, is that a known issue? how to debug?
evil_core: yes, you got patrches to fix analog output and got broken dvi
evil_core: you have choice ;)
diverse_izzue: oh... i'm using analog output
diverse_izzue: but, leaving the irony aside, is there improvement in sight?
evil_core: dunno, I know there were patch fixing analog and breaking digital
diverse_izzue: evil_core, do you know who to bother with that?
evil_core: no, I can find that patch if you need it
evil_core: hmm..not sure which it patch ;)
evil_core: I can guess than one for spread spectrum
evil_core: or maybe pll code
diverse_izzue: evil_core, i'm running into that on ubuntu lucid, i doubt the devs will be happy about a patch which fixes one output and breaks another
evil_core: why only one screen is DRI capable?
Terman: Problem with x1400 mobility (thinkpad 2007-63G), kernel 2.6.33, drm,ati,mesa from yesterday's git master: with kms enabled, I can see an externally connected projector via xrandr -q, but I can't get the projector to display an image (projector doesn't detect my laptop). with kms disabled, this works
Terman: I know that there was a problem with something like that earlier, but I thought this was fixed already
Terman: anyone here able/willing to help me while I still have access to an external device - otherwise it's hotel for now and next debug window would be in about 24 hours
adamk: While I certainly can't help, I would recommend opening up a bug report with the appropriate information... dmesg, /var/log/Xorg.0.log, xrandr --verbose, etc.
glisse: also boot with drm.debug=15 and attach dmesg
Terman: thanks, will do that immediately. Should I add the non-kms info as well?
glisse: yes please
Terman: good
edwin: glisse: your command stream checker in your drm tree has caught a bug! see bug #26962 (b.f.o)
glisse: better than corruptiing memory or lockup :)
edwin: glisse: with 2.6.33 that piglit test passed, but yeah better not corrupt memory
spstarr: glisse: ping
glisse: pong
spstarr: any stuff for me to test?
glisse: spstarr: when i have stuff ready i send them to the ml :)
spstarr: not your git tree?
glisse: well i update my git tree too
glisse: but i won't update WIP in my git tree
spstarr: ok
spstarr: the GPU softlocks are so annoying, i have to use firefox in virtualbox to stop it resetting so much ;/
glisse: btw do you have gnome installed too to test from time to time if it works better there ?
glisse: i am just puzzle on what qt is doing differently
glisse: s/qt/kde
glisse: as firefox isn't using qt for rendering afaik
edwin: spstarr: what gpu?
spstarr: can go to gnome, yes
spstarr: un moment
Terman: adamk, glisse: thanks to your infos, I found out that my bug description was incorrect - will do some more experiments first ;-)
twnqx: i don't have any kde, but gtk causes the softlocks here
twnqx: at least in filezilla and thunderbird, right at startup :P
spstarr: ok in gnome
glisse: weird, did you try to play with kde compositing option to see if one of them is less prone to lockup ?
spstarr: glisse: in GNOME firefox is not causing GPU lockup
spstarr: composite is off
twnqx: spstarr: do you have enlightenment dr17 as well? :P
glisse: twnqx: maybe it's a sign to not use thunderbird ? ;)
twnqx: glisse: non-gnome/non-kde emailprograms are sadly pretty rare
spstarr: it did lockup
twnqx: and i refuse any and all desktop systems
glisse: twnqx: mutt ! ;)
spstarr: glisse: it just faded to white/purple screen
spstarr: glisse: no GPU reset worked this time
twnqx: glisse: too crappy :P
twnqx:
spstarr: glisse: i have logged in!
spstarr: X is dead
spstarr: the screen is crashed but i can ssh into laptop
spstarr: no CPU usage
spstarr: it attempted a GPU Reset
glisse: spstarr: likely the dead lock
spstarr: [ 917.028315] radeon 0000:01:00.0: GPU reset succeed
glisse: pastebin full reset message
spstarr: well, i can still ssh into laptop
glisse: and around
spstarr: er im in console..
spstarr: i'll dump it
spstarr: [ 916.993223] radeon 0000:01:00.0: GPU lockup CP stall for more than 1774msec
glisse: yeah deadlock don't screw the computer just an infinite loop in the kernel
spstarr: [ 916.993226] radeon 0000:01:00.0: GPU lockup (last fence id 0x0002059C)
spstarr: [ 916.993233] [drm] Disabling audio support
glisse: pastebin
spstarr: http://pastebin.ca/1828785
spstarr: there isn't much else other than the GPU reset info
glisse: yeah deadlock in ibtest
glisse: reboot
spstarr: yep.. in KDE it doesn't cause display to die though
glisse: the deadlock is timing issue it will happen only if reset is triggered from some path
spstarr: in KDE now
glisse: play with composite option in kde and let me know if any is more stable than others
spstarr: [6~[6~[6~[6~[5~deeedwqoikokfpwqkfpoqwkpokpkpeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeebaa
spstarr: [6~[6~[6~[6~
spstarr: ouch
spstarr: my screen session got fuzzled
spstarr: glisse: ok, let me try with KDE + composite
spstarr: composite on
spstarr: loading firefox
spstarr: GPU softlock
spstarr: pastebin coming
spstarr: glisse: http://pastebin.ca/1828814
spstarr: with composite on glisse , im hitting it even more
spstarr: now even in a konsole on scrolling with mouse
spstarr: no, only if firefox is open does it do it
Terman: ok, the problem has nothing to do with kms vs non-kms and is either a user bug (incorrect usage of xrandr) or a projector bug (incorrect modeline) - will experiment some more
spstarr: glisse: text glyph corruption
spstarr: if i minimize firefox multiple times and restore it, some text is corrupted
spstarr: but probably casading bug
spstarr: cascading
twnqx: maybe a ffox bug
twnqx: i regular have bugs on pango/cairo apps
spstarr: no its driver ;)
twnqx: hm ok...
Terman: ok, the projector doesn't like the modeline it is reporting (non-preferred case). It seems to only like it's preferred mode modeline. And it's a user bug, because I seem to have changed two parameters in the same test (kms->non-kms + different mode)
evil_core: hi Ralesk
edwin: spstarr: which cairo version? I had to downgrade it to 1.8.10, because 1.9.6 was crashing randomly when closing tabs
spstarr: its driver :)
spstarr: if anything breaks the GPU it is driver fault in the end
spstarr: dont care if firefox, kde, cairo cause GPU to softlock
spstarr: it is driver's responsibility
edwin: sure
edwin: but it would explain why I am not seeing the bug
edwin: if I'm using older cairo, and you're using newer
shadowmaster: [TTM] Zone kernel: Available graphics memory: 898708 kiB.
shadowmaster: found this in the logs of a 2.6.33 kernel with KMS. Is this supposed to mean that I have ~900 MB of video memory?
Enverex: I know glxgears isn't a benchmark but for some reason, on my old Radeon X1700 Mobility, the FPS just jumped from 2500 to 13000... which is a tad weird
Wizzup: Is KMS 2d much slower than UMS 2d? It certainly feels like it
shadowmaster: it felt like that for me in a RS780 but I seem to be having issues with the firmware
shadowmaster: "disabling GPU acceleration" indeed
edwin: shadowmaster: you need the R{6,7}00_rlc.bin firmwares
shadowmaster: yeah, and someone's just telling me that it cannot be shipped with th ekernel
edwin: it can't
edwin: it is in the firmware repository
edwin: its already in Debian, if you're using that
edwin: there is a firmware-linux package, (or use the firmware repository)
edwin: if you build radeon as a module it will load it from /lib/firmware/radeon
edwin: or you can download the firmware yourself, and build it into the kernel yourself
edwin: see the wiki
edwin: it'd be nice if the license could be changed so that it can be included in the kernel itself :)
edwin: but even then it probably wouldn't be good enough for Debian...
shadowmaster: is that repo large? ;)
edwin: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=d9076a54d74e371a11e1206b4a26e2e428045b9e
edwin: the .bin files are like ~4k
shadowmaster: yes, but I tend to like to have clones of repos if I can afford downloading everything
edwin: Debian's /lib/firmware is 2.7M
edwin: don't know how big the upstream repo is
edwin: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
edwin: try cloning it
shadowmaster: ah, it's tiny
shadowmaster: well, sort of. Thanks anyway ;)
DanaG: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/534677 -- new bug report by me.
mjg59: DanaG: Why have you filed that against gnome-power-manager?
DanaG: er, good point... I should add the DDX.
DanaG: anyway, part of is that something in g-p-m changed so that even the old HAL method no longer works.
DanaG: ah, added ddx.
Obscene_CNN: In the file r600_exa.c in the function R600DownloadFromScreen it looks like the desired effect we are trying to achieve is to have the GPU bitblt from vram to a portion scratch memory while the CPU does a memcpy from another section of scratch memory.
DanaG: Added a comment: "To clarify, there are two interacting bugs here: One is that Radeon doesn't support BACKLIGHT, and the other is that the old HAL-based way no longer works. The preferred action would be to fix the former, rather than the latter."
DanaG: er, gotta' go now.
Obscene_CNN: unfortunately the way its written prevents this from happening because the RADEONWaitForIdleCP(pScrn) call would have to go before the if(hpass) statement. Is there a reason for this?
agd5f: Obscene_CNN: bug I guess. the code for the older asics in radeon_exa_funcs.c does the same thing
Obscene_CNN: well I'm going to try changing it to see if it explodes on me ;)
Obscene_CNN: so far so good :D
Obscene_CNN: hmmmm..... helps on some gtkperf benchmarks but hurts on others
Obscene_CNN: net loss of about a second for 1000 reps on my machine
Obscene_CNN: no change on glxgears
agd5f: Obscene_CNN: shouldn't affect 3D
Obscene_CNN: duh! thanks
fredrikh: agd5f: 3594bf23 (in mesa) causes a regression for me in the r600 driver
fredrikh: do_copy_texsubimage gets called with a MESA_FORMAT_S8_Z24 texture, which r600_check_blit doesn't like
fredrikh: so it substitutes it with MESA_FORMAT_ARGB8888, and that results in some unhappiness
fredrikh: if it doesn't change the format it seems to work fine
agd5f: fredrikh: pushed a fix to the 7.8 branch
airlied: mcencora: so keith/brian think the avoid mapping textures approach is okay
airlied: so is gen-texsubimage the only other problem?
fredrikh: agd5f: thanks
spstarr: builds mesa trunk/ddx
agd5f: airlied: does that patch on this bug break atom on ppc? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572311
agd5f: it's a fix for alpha
agd5f: if you get a chance
agd5f: ums
airlied: at first look most definitely
airlied: let me lookup ldw_u for ppc
airlied: I've a funny feeling it'll even berak the build
airlied: since I don't think we define ldw_u on ppc at all
spstarr: airlied: any reason CS checker isn't done inside libdrm vs kernel code? or it is done in libdrm ?
Obscene_CNN: oops, i was wrong about the 1 second loss on gtkperf. I had a gtk upgrade. it now looks like moving RADEONWaitForIdleCP(pScrn) call before the if(hpass) is a 0.2 second win on gtkperf doing 1000 reps
spstarr: i thought everything has to pass though libdrm -> kernel drm
spstarr: hello bridgman
bridgman: hi spstarr
bridgman: I think the answer is that everything *should* pass through libdrm but *must* pass through drm
spstarr: so then, why not do the CS checking in libdrm?
MostAwesomeDude: Because the CS checker isn't optional.
spstarr: you don't need to make optional in libdrm?
MostAwesomeDude: One could bypass libdrm.
spstarr: there's no measure to block that from happening?
MostAwesomeDude: It is impossible by definition.
spstarr: and what does windows drivers do?
MostAwesomeDude: No idea.
spstarr: if they don't have a checker, why should we?
airlied: spstarr: run under a different OS
spstarr: we should assume same risk?
spstarr: hmm
MostAwesomeDude: It's not an assumption. The attacks on DMA have been demonstrated.
Obscene_CNN: does not want his desktop crashing as often as windows
airlied: we should demonstrate them more clearly ;-)
spstarr: hmm
spstarr: but wouldn't it be possible to devise a way to protect the drm from attacks vs a CS checker which does add some overhead?
MostAwesomeDude: It's not the kernel that's under attack.
airlied: spstarr: look you <---------> clue
MostAwesomeDude: It's all of main memory.
Obscene_CNN: what does doing the checking in libdrm get us?
airlied: its like asking why we have file premissions
MostAwesomeDude: It's possible to maliciously obtain *anything* in main memory, if you can send arbitrary things to the card.
airlied: when surely the apps could just check them
airlied: likewhy doesn't glibc stop me eding /etc/shadow instead of silly file permisissions
spstarr: but you have userspace/root | kernelspace boundaries
MostAwesomeDude: Haha, no. The card's DMA engine cares not.
MostAwesomeDude: It can and will stomp or snoop anything in main memory.
spstarr: right, but trying to write to the card must require root access no?
airlied: spstarr: dri apps don't run as root
Obscene_CNN: notes DMA is cool that way ;)
spstarr: ugh
airlied: thats the point of DRI
airlied: to provide non-root access to the graphics card so users can run apps
spstarr: couldn't we have done some sort layering to limit root where needed only?
spstarr: ie like qmail horror
otaylor: spstarr: I'm sure the kernel *could* send the CS streams out over a pipe to some userspace checking daemon
evil_core: libGL error: drmMap of framebuffer failed (Cannot allocate memory)libGL error: reverting to software direct rendering
evil_core: l
otaylor: spstarr: but no, it wouldn't be a good idea.
spstarr: no, not a good idea, no
evil_core: what can I do with that? (its c,mon problem for glide wrappers in wine)
spstarr: otaylor: couldn't SELinux help in some way?
airlied: spstarr: no
spstarr: ok
airlied: spstarr: what problem are you trying to solvE?
spstarr: reduce overhead
otaylor: (selinux is already involved too much in kms as it is :-()
airlied: so you should just remove selinux
airlied: that causes overhead ;-)
spstarr: selinux is off :)
bridgman: spstarr, something has to understand the command streams going to the GPU
bridgman: no matter what level the checking happens there's going to be overhead
airlied: I can't see how you think moving the CS checker to userspace would make it less overhead anyways
spstarr: less locking?
bridgman: if you check outside the kernel then you need some kind of crypto validation between checker and kernel so kernel knows the packet is coming from a checked source
bridgman: and that's even more overhead
spstarr: uck
spstarr: forget that!
Obscene_CNN: wouldn't moving the cs checker to userspace reduce the time a spin lock is held?
spstarr: you'd put the 'drm' in drm :)
airlied: if the kernel could trust userspace, life would be a lot simpler
spstarr: laughs
airlied: Obscene_CNN: we don't hold a spinlock
Obscene_CNN: maybe we should just rewrite our idle loops in assembly so we can get nothing done quicker :)
mcencora: airlied: IIRC, texdepth and fp-indirections2 failed too with tiled textures
mcencora: airlied: also I need to disable texture tiling for 3D textures and cubemaps (or implement (un)tiling of them)
evil_core: http://bugs.freedesktop.org/show_bug.cgi?id=13553
evil_core: I got this error
evil_core: I am using 2.6.33 nonfedora kernel :P
spstarr: v2.6.34-rc1
spstarr: -rc1 is tagged
evil_core: spstarr: it was to me?
spstarr: no
spstarr: just pulled git master
spstarr: trying to solve my intel GPU lockup issues also
evil_core: old i810 and vt switches?
spstarr: i965
spstarr: it locks up, so much unusable, regression somewhere
evil_core: lockups or black screens?
spstarr: i tried 2.6.32 even it locked up
spstarr: evil_core: locks and any audio loops over and over in buffer
spstarr: no GPU reset even attempted
bridgman: aw crap, I thought the merge window was open longer
evil_core: but i965 is probsably not affected like i915 and older
evil_core: what branch of frm-2.6 should I use?
spstarr: bridgman: hes not accepting merges now with -rc1?
evil_core: current works too stable for me :P
spstarr: doesn't think this process linus is using is working anymore
spstarr: not enough time to fix problems in the merge windows, especially on code that is quite volatile
bridgman: fixes are ok, it's major new functionality that gets cut off
spstarr: well, drm is going though alot still
spstarr: glisse has mega code changes coming
spstarr: -rc1 looks to fix a USB audio issue of mine
bridgman: is that in drm or in userspace ?
spstarr: drm
spstarr: his gpu reset code im using now and gpu CP recording is coming next or so
bridgman: guess I'd better hand up IRC and go back to VPN
mcencora: agd5f: the depth blits should be doable, but we would have to create another fragment program, and render to depth buffer
agd5f: mcencora: yeah
User-007: i have the "OpenGL renderer string: Software Rasterizer" problem, hot to fix it?
User-007: how
soreau: User-007: Can you pastebin your /var/log/Xorg.0.log file to pastebin.com?
User-007: soreau, ill try, my internet conection is too slow
soreau: If you have curl installed, you could just use this command from your terminal: cat /var/log/Xorg.0.log | curl -F 'sprunge=<-' http://sprunge.us
User-007: ill use pastebin.org
User-007: here http://pastebin.org/106331
User-007: soreau, thanks for helping
soreau: User-007: I don't see anything that indicates dri isn't working. can you pastebin the output of 'LIBGL_DEBUG=verbose glxinfo' ?
User-007: its uploading but i saw this : libGL error: dlopen /usr/lib32/dri/r300_dri.so failed (/usr/lib32/dri/r300_dri.so: wrong ELF class: ELFCLASS32)
User-007: here http://pastebin.org/106339
soreau: Are you running 64bit?
User-007: yes
soreau: I guess you'll have to install mesa packages that are compatible with your system. Installing mesa from git you could configure it to build it right maybe
soreau: I think debian divides mesa into libgl1-mesa-glx and -dri packages
soreau: make sure they're the right arch
FIReun: 64bit is the only way to go!
shadowmaster: er, recompiling mesa as 32-bit libraries on a pure amd64 a.k.a. x86_64 system is hard.
shadowmaster: so hard I haven't succeeded. I guess I'm supposed to get a complete cross-compiler environment with 32-bit X libraries, etc. Which would be...hard.
shadowmaster: or wait until Debian's ia32-libs package reflects Mesa 7.7, which is already in the repo.
jcristau: shadowmaster: a 32bit chroot is easy...
shadowmaster: doesn't it require downloading stuff? ;)
jcristau: yep, does.
User-007: soreau, i have both
User-007: ill try to compile mesa by myself, do you recommend 7.8 or 7.7?
shadowmaster: (actually, now that I think of it I could just download the x86 Mesa 7.7 package from the repository, tear it apart and replace the 32-bit mesa here with that)
User-007: 32 bit mesa?
shadowmaster: yeah, needed for 32-bit programs which can't talk with 64-bit libraries
FIReun: lost what shadowmaster is trying to do
FIReun: or User-007
FIReun: why would you want 32bit mesa on a 64bit install?
FIReun: is clueless in the matter
shadowmaster: for running 32-bit programs which for one or another reason you cannot recompile as native 64-bit programs
soreau: User-007: At least 7.8 if not master branch from git
FIReun: shadowmaster: sure, I have mplayer32 w/lib32 as apropriate to run it on my 64bit system
shadowmaster: bye, bye KMS, I'll miss you ;(
shadowmaster: hm, maybe it wasn't a good idea to load drm/radeon before X with UMS here. No text consoles work
shadowmaster: the screen even turns off when trying to switch to them
User_007: i am with problems on recompiling mesa
User_007: when i do "./configure --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --disable-gallium" it says that file is not found
User_007: bash: ./configure: File not found
User_007: (i am in mesa folder)
soreau: You need to run it from the mesa directory where the configure script is
User_007: i am already in mesa directory
soreau: User_007: Do you have a file named 'configure' in that directory?
User_007: nope,
soreau: How did you download the mesa code?
User_007: git
User_007: as http://www.x.org/wiki/radeonBuildHowTo
soreau: Use ./autogen.sh instead of ./configure
User_007: ok
User_007: i have compiled mesa 7.8. it still with software renderizer....
User_007: so i tried to compile master branch of radeon driver, and it doesnt run
shadowmaster: what do you mean by "doesn't run"? does it crash? /var/log/Xorg.0.log (pastebin)?
shadowmaster: and are you using a current libdrm?
User_007: oww, libdrm i almost forget it... hot to compile it?
User_007: my libdrm version is 2.4.18-2
User_007: is it enough?
BioTube: yes
User_007: well, so the problem is to load the drivers from /opt
soreau: User_007: Try 'LIBGL_DRIVERS_DIR=$PREFIX/lib/dri glxinfo' where PREFIX is the --prefix you specified to autogen
User_007: so 'LIBGL_DRIVERS_DIR=$PREFIX/opt/xorg glxinfo
BioTube: no, LIBGL_DRIVERS_DIR=/opt/xorg/lib/dri glxinfo
User_007: http://pastebin.org/106569
User_007: ops
User_007: here: http://pastebin.org/106587
User_007: look just after line 241
BioTube: try setting LIBGL_DEBUG=verbose
User_007: http://pastebin.org/106590
BioTube: it seems mesa was built against an incompatible version of libdrm_radeon
User_007: so, ill need to come back to 7.6?
soreau: User_007: At this point, you might as well build libdrm, then mesa and ddx against this libdrm version
User_007: soreau how to build libdrm?
soreau: User_007: It should be in the link in the topic here
soreau: I think there's a link to a link to mesa/drm
User_007: soreau, they teach how to compile mesa and ddx, but not drm
BioTube: User_007: with 2.4.18, you really just need to feed it a prefix
BioTube: you can disable the intel library and libkms, if you want
soreau: User_007: Read where it says "UPDATE: With libdrm >= 2.4.18 libdrm_radeon is built by default, now (configure-option --enable-radeon-experimental-api is obsolete)."
User_007: humm
User_007: but i have already build mesa 7.8-devel so what i need to do?
BioTube: rebuild
User_007: BioTube, what i need to do to rebuild it by the right way?
BioTube: make clean && make
User_007: just make, no prefix needed?
User_007: (i am using checkinstall instead make install is it ok?
BioTube: plain clean won't remove the configuration
BioTube: and checkinsall calls make install anyway
User_007: but what is the diference between the last time i done make, and this time?
BioTube: the version of libdrm being built against
BioTube: so long as you set the environment variables right
User_007: when will i set the variables?
BioTube: before calling configure
User_007: well, so i have made make clean
User_007: what is the next step? "./configure --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --disable-gallium" ?
BioTube: like I said, you won't need to rerun configure unless you've changed something
User_007: ok, but you said that i need to set the right variables, but if i dont change anything, what will change?
BioTube: you need to set the variables to build and link against the stuff from /opt/xorg if you're putting libdrm there
BioTube: and you will need to rerun configure if you didn't set them the first time around
User_007: i have set they the first time
BioTube: then you don't need to rerun configure
User_007: just make and checkinstall?
BioTube: yep
User_007: ok, ill do it,
User_007: now its configured to put libdrm in the right way?
BioTube: should be
User_007: how can i check it?
User_007: (i still have libdrm from apt, is it ok?)
BioTube: just check the debug output from glxinfo; it should tell you if things got resolved
User_007: but i dont need to do anything?just by build the second time will solve the problems?
BioTube: that should do it
User_007: ok, now i understand
User_007: ok, mesa installed
User_007: now, ill have to build radeon again right?
BioTube: if the ddx is working, no
User_007: the last ddx i done is not working, i am using the distro one bacause this
BioTube: then rebuild, by all means
User_007: yes, its fast
User_007: atombios_crtc.c:650: warning: dereferencing pointer ‘spc3_ptr’ does break strict-aliasing rules
User_007: all done, now i reboot?
BioTube: you should only need to restart X
User_007: it doesn't worked ... ill send a pastebin
User_007: see http://pastebin.org/106655
User_007: its the xorg.0.log
soreau: Seems to be incomplete
BioTube: does X crash?
User_007: yes
soreau: I would rebuild ddx against libdrm anyway
User_007: so i use the distro driver and it works, but not the real direct rendering
User_007: i rebuilt radeon driver (xf86-video-ati)
soreau: Did you get any interesting messages in syslog?
User_007: syslog?
soreau: dmesg
User_007: dmesg only? no grep? its very big
User_007: i see no interesting messages... no errors..
soreau: are you using kms?
User_007: no, i think no.. i disabled it by default on last kernel compilation (2.6.33)
User_007: except if my distro set it by defalult in some place and don't comunicate me
soreau: 'dmesg|grep modeset' should tell you if it's enabled
User_007: i have tried to boot with radeon.modeset=1 and i saw no change
User_007: [ 131.451251] [drm] radeon defaulting to userspace modesetting.
soreau: If you have 2.6.33 kernel, built libdrm, ddx and mesa and are not having compiz start by default I'm not sure why X would fail to start
User_007: disable
User_007: i dont use compiz
User_007: by build libdrm you say build mesa again?
soreau: You're supposed to build libdrm first then mesa and ddx against that libdrm
User_007: guy, how to build libdrm?
User_007: is the same command that make mesa right?
User_007: or i have to git something else, make, and then build mesa?
User_007: is this http://dri.freedesktop.org/wiki/Building right?
soreau: Yes, everything you need to know should be there
soreau: http://wiki.x.org/wiki/radeonBuildHowTo
soreau: actually, the link in the toppic here
User_007: soreau, i dont see the place that tells how to build libdrm. is this made with mesa?
soreau: User_007: For lidrm, you want to clone the source with 'git clone git://anongit.freedesktop.org/mesa/drm'
soreau: Then install it and build mesa and ddx against that libdrm
User_007: ok, i have lost the part of libdrm from git
User_007: soreau, done with libdrm (.19)
soreau: User_007: When you're configuring ddx, make sure it says Kernel Modesetting: Yes
User_007: so i will need to use kernel modesetting
soreau: Then rebuild mesa against the newly installed libdrm
soreau: You just want to build ddx with kms available
User_007: libdrm -> mesa -> ddx
User_007: do i need to reboot because the new libdrm?
User_007: i have put it on /opt/xorg, is it ok?
soreau: shouldn't have to
User_007: will it not work?
soreau: restart X of course
User_007: i need to install libdrm on any place or where i want is ok?
User_007: it must be on /usr/local/lib or just in /opt/xorg?
User_007: wait a sec
soreau: Read the portion in http://wiki.x.org/wiki/radeonBuildHowTo "Configuring system to load mesa and libdrm from /opt/xorgConfiguring system to load mesa and libdrm from /opt/xorgv"
User_007: i come back...
User_007: libdrm must be on /usr/local/lib or just in /opt/xorg?
soreau: User_007: See the section in http://wiki.x.org/wiki/radeonBuildHowTo "Configuring system to load mesa and libdrm from /opt/xorgConfiguring system to load mesa and libdrm from /opt/xorg"
User_007: yes, that's why i have installed it on /opt/xorg...
User_007: i have configured all to start by /opt/xorg... maybe that's why the distro version haven't work , xD
User_007: wait a sec
poet: Is temp monitoring supported for R600? It doesn't seem to be a feature listed on the feature page
poet: I also tooka quick glance through the source repo and couldn't find any obvious notes
spstarr: hmm
spstarr: recompiling the game with -O3 -mtune=core2 has improved some FPS albeit a little, so did the newer mesa changes from agd5f
spstarr: but KMS is still dog slow