spstarr: glisse: when you wake up, I wanna test lots of patches if you have some please.
agd5f: suokko: what's the problem with tv-out you are seeing?
airlied: agd5f: btw the mm bus still doeson't seem happy for me with i2cdetect
airlied: agd5f: http://fpaste.org/8jji/raw/
airlied: is my hacked up test for it on the r580
airlied: agd5f: though i2cdetect does work on the hw i2c to see my monitor
agd5f: airlied: is there anything actually on that bus? If it's not used, it may not be wired up properly
airlied: agd5f: I think the theatre video in is on it
agd5f: airlied: do you have my fix for bus probing?
airlied: agd5f: yup everything that I put in drm-radeon-testing at least
airlied: i2cdetect now works fine for the edid
agd5f: airlied: I dunno. I haven't looked at the mm bus yet
agd5f: let me double check the regs
airlied: agd5f: wierd it should be using r100_hw_i2c_xfer for the mm bus
airlied: but I'm not seeing the unsupported asic warning
agd5f: yeah, r5xx still has the old mm i2c hw controller
airlied: oh the cdoe is fine with that
agd5f: there are actually two h2 i2c controllers
agd5f: s/h2/hw/
agd5f: the display one (dvi_i2c) and the mm one
airlied: maybe prescaling needs to be different for the r500
agd5f: airlied: oh, yeah, probably
airlied: we have it different for R520
airlied: in the r500 case
airlied: does that apply to any other r5xx?
agd5f: I don't think so. I was told it was r520 only
agd5f: but r580 might be similar
airlied: I tihnk it works with UMS so I should go compare
airlied: reboots to UMS land to make sure it can see the theatre
airlied: can't see it on that card in ums, no idea why, will try other card
agd5f: airlied: the theatre stuff was usually on the VIP bus
agd5f: it was generally the tuners that were on i2c
airlied: the theatre control was i2c
airlied: at least I think it was last teim I played
airlied: I have a tuner card in now I'll play with
airlied: ah maybe I misremembered, I'll have to add VIP support for that card I suppose
fireun: man, this commentary feels like a word for word replay of last night
fireun: woops, wrong chan
agd5f: VIP stuff hasn't changed so you should be able to use that on older asics as well
spstarr: morning suokko
spstarr: agd5f: you're changing the i2c code for r1xx+?
spstarr: agd5f: that might likely break my TV tuner support, if i ever used it again, util analog TV is terminated up here
airlied: spstarr: it doesn't work under kms now
AndrewR: airlied, flags = RADEON_CREATE_PIXMAP_TILING_MACRO | RADEON_CREATE_PIXMAP_TILING_MICRO; http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_dri2.c
AndrewR: airlied, for DRI2BufferDepth. Not really shure why it want to blit to/from it with just gears ... something was weird with my ddx hack, i have it reverted for now.
spstarr: airlied: I dont think tv tuner ever worked even with KMS, never had KMS for the r1xx at the time.
spstarr: I really am excited with glisse's KMS todo list.
spstarr: airlied: wrt to GLSL, what % of support is completed? or is it now just optimizing that?
spstarr: since I can enable it, but get about < 1 fps for advanced GLSL programs
mcgregor: indeed, I am also looking forward to see 2.6.34 with power management. this is currently the only thing I really care about at the momet since everything else seems to work quite fine ;) (for me)
spstarr: PM I'd like because i just worry about overheating, even though the CPU can handle 100C ok
spstarr: but I assume Lenovo made sure even if the GPU could get to 70C it wouldn't cause problems
spstarr: (i dont know the GPU temperature only CPU from ACPI)
spstarr: the stalls are my biggest concern though
mcgregor: well, I care for PM because my laptop consumes 35-40W when it's idle! guess power would go down by 10-15W with a good power managment
AndrewR: suokko, http://lists.freedesktop.org/archives/nouveau/2010-January/004647.html (tool for automatically finding out the texture layout for Gallium drivers) , by Luca
AndrewR: suokko, not really helpful for us, on pre-r300 .. but may be you can extract some ideas/code from it?
Ivanovic: agd5f: around? have you seen what i wrote about the missing texture stuff some 12h ago? should i post it at bugs.freedesktop.org or is it a dupe?
DanaG1: hmm, random thing about xorg: even with the open drivers, resize is still laggy!
DanaG1: I say, it's an Xorg issue, NOT just a fglrx issue.
DanaG1: Happens on radeon and nvidia, too. =รพ
eichi: hello - someone knows, when there will be the next release?
eichi: of -radeon driver
glisse: airlied: i should have said that earlier but it would have been better to not include my r6xx/r7xx checker patch
glisse: i did have a new one which does change less thing
glisse: let me know if you want me to do a patch on top of this
airlied: glisse: no I can rebase that tree
airlied: send a whole new vesion
spstarr: glisse: ping
airlied: &
glisse: ok
spstarr: glisse: i blew up your CS checker :)
glisse: spstarr: no i haven't any new patch, i will look at your regression
spstarr: glisse: suokko thinks we might have a locking contention with disk i/o and GPU stalls
spstarr: glisse: we dont know though
spstarr: glisse: as only happens with KMS
spstarr: i have enabled blktrace debugging and lockstat if that might help you
glisse: spstarr: please stop merging tree by yourself
glisse: either use 2.6.33 or drm-radeon-testing
spstarr: glisse: i do
spstarr: drm-radeon-testing can be rebased on linux-2.6 from linus?
glisse: spstarr: don't do that
glisse: use standard 2.6.33-rc
spstarr: well Linus 2.6.33-rc7 id out
spstarr: id
spstarr: is
spstarr: so the differences from my tree are basically -rc7
spstarr: glisse: I also noticed with your CS checker i had huge disk i/o storms
spstarr: reverting this stopped this
spstarr: glisse: even more interesting is, someone mentioned for me to try using no-preempt and I had less GPU stalls overall
spstarr: seems to be something bad going on
spstarr: glisse: I am very intrested in your KMS todo list mentioned
spstarr: glisse: any debugging you want me to turn on further in kernel or will /proc/lock_stat or blktrace give you more info?
glisse: no i have never used those
spstarr: ok
spstarr: maybe suokko and you can hash something on the stalls he is also encountering
spstarr: glisse: I remain in UMS for now as I also have GPU lockup which isn't reporting any kernel dump
spstarr: glisse: I also have triggered more text glyph corruption
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/more-text-corruption.jpg
spstarr: this seems to be quite specific though in the corruption itself.
spstarr: see #radeon log as agd5f thinks its something just being off
spstarr: i will hold on that because you have more CS code checker code coming
glisse: i still don't understand why i can't reproduce any of this isues
hexa-: hi
spstarr: heh
spstarr: glisse: well the panic i logged happened when there was severe disk i/o contention while I was playing my usual game SL
spstarr: it just finally cracked and panic'd
glisse: which panic ? is there a bug for it ?
spstarr: there is something wrong with the new CS code
spstarr: yes
spstarr: https://bugs.freedesktop.org/show_bug.cgi?id=26438
spstarr: glisse: not pretty
spstarr: does the drm write a lot of inodes to disk?
spstarr: it melted down for me
suokko: glisse: &(&glob->lru_lock)->rlock seems problematic from lock stats
spstarr: morning suokko
suokko: There is max hold time 21ms
suokko: hi
spstarr: glisse: we can ignore the 'radeon 0000:01:00.0: vbo resource seems too big for the bo
glisse: glob is the ttm stuff ?
spstarr: ' part
spstarr: glisse: agd5f mentioned the KMS path does not deal with VBO size limits in GPU yet
spstarr: so we can ignore that until its implemented
suokko: glisse: [
suokko: [
suokko: glisse: You could download spstarr's lock stats from http://people.freedesktop.org/~suokko/stalls_locl_stats (large file 138kb)
suokko: glisse: also dev->struck_mutex is held for long time sometimes but maximum is 9ms (or 9 million jiffies I guess)
suokko: or that was hold time total. sorry
suokko: hold time max is 5.8k only
spstarr: I should say does the drm manipulate inodes alot
spstarr: suokko: then there's those weird JCPU and stats in process times thing
suokko: btw, We probably should check that there is no sleeping in context where irqs are disabled
suokko: There is kernel debugging option for that too
suokko: "The integer part of the time values is in us."
suokko: What does that exactly men in the kernel?
spstarr: what context is that from?
suokko: spstarr: That is defination for lock stat time keeping values
spstarr: oh 'us'
spstarr: microseconds
spstarr: convert that into ms
spstarr: so &(&futex_queues[i].lock)->rlock 2476 [
spstarr: er
spstarr: so 5812.49 is us
spstarr: 5.81249 milliseconds
spstarr: simple enough
suokko: yes
phercek: radeon kernel crash in 2.6.33-rc6 like this: http://pastebin.com/m7415b611 ; worth a bug report?
suokko: phercek: Any kernel crash or mesa crash is wroth bug report
suokko: To obad sometimes they can't be fixed if it is not reproducible
phercek: ok; is xorg.conf, dmesg and Xorg log enough ? it is probably not very reproducible; happened once during operations I do often
adamk: phercek: The kernel is tainted. I doubt anyone would look at the bug report :-) If you can reproduce it without the vmware modules loaded, I'd say definitely report it.
suokko: Why does it report first not tainted and then later it reports tainted?
spstarr: here's to glisse's GPU lockup recorder code coming
spstarr: im curious to how that will work
phercek: adamk: cool thanks for saving the work :) if I get the crash without vmware I'll report it; not very probable since I need vmware so it means first to finde it kind of reproducible with vmware and then try without it
spstarr: if it dumps the fences and bo to disk somewhere
spstarr: i have to say:
spstarr: &sb->s_type->i_mutex_key#1: 0 1 102.52 102.52 102.52 1217 14922 0.26 135905.29 2028023.66
spstarr: [
spstarr: is pretty foul
spstarr: 135905.29
spstarr: or even
spstarr: 2 2 7.90 8.48 16.38 659 6991 0.00 46137.65 1665984.05
spstarr: [
spstarr: wth is the wifi device doing
spstarr: iwl_mac_hw_scan / iwl_bg_scan_completed
spstarr: if i'm associated to an AP what is it doing?
spstarr: need to read those functions to understand
suokko: spstarr: network manager is all the time udating wifi networks jsut in case you would look for new network
spstarr: suokko: ugh
spstarr: is there a way to stop or stall it from doing it so much?
suokko: And that aio wait in sb->s_type->i_mutex is very long but I don't think that lock is shared with us
spstarr: im not sure if that was due to second life manipulating it's disk cache or not
spstarr: I have it set to use 500-1GB of disk space for textures and other data
spstarr: recommended 500+
spstarr: but most of it is cached
spstarr: unless i visit a new place
spstarr: it would be nice to see what lock is shared by what
spstarr: but im not sure that info is available?
suokko: spstarr: It is there. You get list of all callers when there is contention
spstarr: oh
spstarr: the in each grouping
spstarr: yeah the aio is not related
suokko: But problem is that it doesn't know about any locks already held when entering the lock
spstarr: something would need to walk the locks to report the locks held
spstarr: does the ttm need to use a global lock?
suokko: It has t orequest pages from global and put them back
spstarr: so from the VM
suokko: spstarr: But stalls are probably caused by &rdev->cs_mutex
spstarr: the command submission stuff?
suokko: yes. That lock is held way too long
suokko: Smaller but still problematic lock is &dev->struct_mutex
spstarr: well, it is possible if a GL scene is quite busy you might have alot of commands to send CPU?
spstarr: er GPU
suokko: But yo ucan do that without holding lock for all the processing
spstarr: even so, the GPU should not stall if it still has to render existing textures and primitives
spstarr: yeah
suokko: Locks are required only for shared dataaccess
spstarr: thats right
suokko: So we should be doing most of processing with private buffers and only shortly use locks to acquire shared objects
spstarr: but if you have one GPU what are you sharing that data with or this just designed to be multi GPU ready?
spstarr: unless the data is handled by CPU then yes, you'd need a lock
spstarr: for SMP
spstarr: suokko: today I will run this test with UMS and dump lock stats
sannes: hm, since 2.6.33rc1 using two screens with kms fills the "spare" space with white, think it is intented?
spstarr: or wait if glisse has updates CS code checker
spstarr: updated
spstarr: since we want to be on same page with his latest code.
suokko: glisse: What does &rdev->cs_mutex protect?
suokko: In others words. CAn we just lock it shortly in begin. Check for GPU hand and allocate ib. Wht would any more after tht need locking?
suokko: /hand/hang/
spstarr: suokko: do we have to wait for the GPU to respond to a CS submission?
suokko: no
spstarr: ok
suokko: We simple add the commands to a ring bufffer and change write pointer so GPU will know to read up to the write pointer
spstarr: that should be a small lock then
spstarr: we have to parse the commands prior | lock --> send to ring buffer, change write pointer | unlock ---> parse....
spstarr: for the next batch
spstarr: depending on the CS size you can push to GPU at one time
spstarr: I need to read the r6xx docs as I see more and more of the code and read the channel
suokko: spstarr: It is a bit more complex system: enter kernel -> lock device/IB-> check device staturs, request for indirect buffer -> unlock device/IB -> parse incoming commads and write to IB -> lock ring -> write packet that points GPU to IB -> unlock ring -> back to user space
spstarr: so everything that goes to ring buffer is in an IB?
spstarr: all CS commands get put into an IB then pushed into ring buffer?
suokko: We can write directly to ring too but most stuff goes to IB now
spstarr: so how many command stream packets can we fit into an IB?
spstarr: oh wait
suokko: Depends what sizes packet are coming in but in average maybe 1k or so
spstarr: a command stream packet is different kinds
spstarr: ah
suokko: For 3D that is
spstarr: so we push IBs into the ring buffer and the GPU's CP deals with them?
spstarr: yes
spstarr: The CP processes both ring buffer and linear buffer commands streams. For 3D, the commands are processed and
suokko: yes. CP then fetches the stream and parser the commands
spstarr: this generates a stream of register activity
spstarr: I see
spstarr: GPU packet method seems quite logical
spstarr: easy to extend
spstarr: so the radeon cs parser code is to parse the 'order' in what the driver wants to send the ring buffer?
spstarr: or is it also to generate the respective packets
suokko: spstarr: parser is checking for incorrect commands and changing bo pointers to what GPU sees for them
spstarr: PM4 packet types
spstarr: ah ok
spstarr: im not understanding how you can get incorrect commands (other than a bug in DRI from the bo generated from mesa?)
spstarr: or thats just a sanity check because we know we can get incorrect commands regardless?
suokko: spstarr: It is public interface. Any user space application can write commands there
spstarr: ah
suokko: Some spyware could write directly to GPU and read what is anywhere in VRAM or another malware could just hang the GPU
spstarr: makes sense
spstarr: I thought we only allowed root processes access to the drm via libdrm
spstarr: i guess that is moot when X right now requires root
spstarr: unless a user running glxgears for example, is loading the dri as non-root
spstarr: looks at lsod
spstarr: lsof
spstarr: according to it, root owns the DSO loaded
spstarr: i see now
spstarr: yes malware/spyware could easily
spstarr: suokko: but even with the CS parser in the drm driver, why would it be taking longer in KMS vs UMS?
spstarr: both UMS and KMS use the same DRI driver
spstarr: the DRI has no knowledge of KMS?
suokko: no they don't
spstarr: oh wait..
spstarr: DRI1 vs DRI2...
suokko: Everything is different
spstarr: hmm
spstarr: I thought DRI2 was just extensions from DRI1?
spstarr: so the code difference wasn't supposed to be too much?
xming: ok I have loclstat and irq tracer on
spstarr: xming: what GPU?
xming: how should I proceed? Launch a 3d app (glxgear) and cat /proc/lock_stat?
spstarr: no
xming: spstarr: rc670 (3850 agp)
spstarr: glxgears stall is not related
spstarr: you can try though
spstarr: you have to enable the kernel to record the lock stats
spstarr: echo 1 >/proc/sys/kernel/lock_stat
xming: I have debugging on and ext4 commit back to 5 sec, and it stalls are worse now
spstarr: 0 to turn off, echo 0 > /proc/lock_stat to clear the stats
xming: spstarr: it's already enabled
suokko: xming: More like this: reset the stats; start new collection session; start complex 3D which will stall &; sleep 30; get the stats to some files;
xming: okee
suokko: Orbetter jsut let that some 3D to run while you start the stats collection
spstarr: xming: I had stalls with EXT3 also, and thats what stats i gave suokko
xming: suokko: so echo "0" > /proc/lock_stat && echo "1" > /proc/lock_stat && ut2004 play 5 minutes && sleep 30 && cat /proc/lock_stat
spstarr: no
spstarr: echo 1 >/proc/sys/kernel/lock_stat <--
spstarr: you have to tell the kernel to start recording it
spstarr: it is updating that info in real-time
xming: 13:52 < xming> spstarr: it's already enabled
spstarr: so you will see it appear each time you cat it
spstarr: er appear/update
xming: hmm
spstarr: its not enabled by default
xming: it's here
xming: # cat /proc/sys/kernel/lock_stat
xming: 1
xming: # cat /proc/sys/kernel/lock_stat
xming: 1
spstarr: then its recording
spstarr: for me i dont have it on by default
xming: so echo "0" > /proc/lock_stat just clears the counters?
spstarr: ya
sannes: KMS bug/regression should be reported where now? Still freedesktop.org even if it is in the kernel?
xming: spstarr: then I need to 'cat /proc/lock_stat' every sec while I am playing the game?
spstarr: xming: but it is going to be updating real-time basically
spstarr: xming: when you see a stall or stalls
spstarr: that's how i captured mine
suokko: hmm
xming: I can't :( ut2004 caputure my mouse, and switching to vt takes too long
spstarr: script it :)
spstarr: its just output daa
spstarr: data
xming: that mean cat /proc/lock_stat every sec or so
xming: but then how do I correlate the stalls to the right time?
spstarr: just redirect output of /proc/lock_stat >> /tmp/some.log
spstarr: it will grow
suokko: ut2004 &; sleep 20; start_reset_trace(); sleep 30; save_stats_in_file(); stop_trace()
suokko: That is what you want
xming: ok I will try
suokko: So that you are playing ut when the colelction starts
suokko: Then jsut play it for 30 seconds and hope for stalls and then read what you got to log
spstarr: you cannot play game in window mode?
xming: but then I can't tell you when in the stats were the stalls happening
spstarr: the numbers will tell :)
xming: spstarr: window mode caputures my mouse in *that* window
spstarr: and which locks did at the time
spstarr: ugh
xming: spstarr: okee :D
suokko: xming: One single large dump of stats is the best option
xming: I will do
suokko: Don't try to get anything in between
xming: closes FF
xming: and irc later before I start :D
spstarr: suokko: as soon as glisse as some new code, i'll be doing the tests again w/ KMS today (8am) im gonna get a little sleep for a few hours
spstarr: since glisse's time zone differs i have to try to be up different hours to compensate
xming: spstarr: or move :D
spstarr: I think .fr is 5 hours from me still like UK
spstarr: so it's already 1pm
xming: oh that's just 1 hour diff. not much
spstarr: maybe for you :)
xming: good to know that I am between you 2 :p
xming: GMT+1 here
spstarr: yea
spstarr: GMT-5 here
xming: -5? is that uk?
spstarr: Eastern Time
xming: sorry, I misread thought you were in uk
spstarr: If I was it would be 1pm for me
spstarr: I'll be back in a few hours will read backlock
spstarr: log
xming: suokko: http://pastebin.com/d224c64db -> does that seems to be good to you?
suokko: xming: yes
suokko: If it works then you could addd there irsoff tracing too same
suokko: But I don't know where that writes the output :/
suokko: is looking the source
suokko: Looks like it will output to dmesg
xming: how do I enable that?
xming: is reading ftrace.txt
suokko: I saw it only in kconfig
xming: oh you think it's enabled by default when it's enable in kconfig?
suokko: echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
xming: hmm my /sys/kernel/debug/ is empty
suokko: ou need debug fs mounted there
suokko: you*
xming: ah
suokko:
suokko: That is correct path
xming: ty
xming: 14:14 < suokko> echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
xming: doesn't that turns it off?
xming: shouldn't I echo "1" > /sys/kernel/debug/tracing/tracing_max_latency ?
suokko: That was what I saw in kconfig
suokko: "The default measurement method is a maximum search, which is
suokko: disabled by default and can be runtime (re-)started
suokko: via:"
xming: I see that
xming: it's 0 here by default
xming: # cat /sys/kernel/debug/tracing/tracing_max_latency
xming: 0
xming: and I dont' see anything in dmesg
xming: cya later, going to try this
suokko: heh. Now I just tough of better benchmark: start_reset_trace(); ut2004 -timedemo; read_stats_to_file(); stop_trace();
suokko: That way we get about same test case everytime so comparing results to ifferent runs would give some references if anything is better
xming: suokko: ok I will do that again, now I have my stats file, what should I do?
xming: suokko: or just restart and do the timedemo?
suokko: xming: Can you upload it somewhere?
xming: suokko: http://wojia.be/lockstat.out.bz2
suokko: xming: Is that kernel without preemption?
hexa-: has anybody seen an error like this one on an r300 graphics adapter with radeon driver?
hexa-: libGL error: drmMap of framebuffer failed (Cannot allocate memory)libGL error: reverting to software direct rendering
suokko: I saw it once in some wine log debug log that was posted. There ws others mmap calls failing too. Is selinux or apparmos enabled for you?
xming: suokko: yes it's with no preempt
suokko: xming: It has a lot less lock contention compared to preemption
suokko: But still max-hold-times are too long
hexa-: suokko, that was me, like last week :)
xming: suokko: yes that was my conclusion yesterday, preempt make the games unplayable here, stall every 5 sec or so, no-preempt makes is bearable, less frequent stalls and stalls last less long
hexa-: suokko, as far as i can tell i don't have selinux but apparmor
suokko: xming: So it looks like locking is the problem :/
xming: suokko: I told that to spstarr, and he has the same conclusion after he tried a no preempt kernel
Ronis_BR: hi all
Ronis_BR: when I use radeon without KMS, the opengl windows always stay on top :D
Ronis_BR: like, I open glxgears, if I cover with another window, like dolphin, I continue to see the gears
zhasha: Ronis_BR: that's normal
xming: suokko: 00:48 < spstarr> this is a clear result for me though, ive never had KMS *this* smooth before
zhasha: turn off compositing and it'll work
Ronis_BR: zhasha: normal?!
Ronis_BR: zhasha: I know
Ronis_BR: zhasha: but I like compositing :D
adamk: Ronis_BR: That's why DRI2 ws created.
zhasha: then turn on KMS, and DRI2 will follow
adamk: Ronis_BR: Among other reasons.
hexa-: suokko, I'll try and disable apparmor and retry
Ronis_BR: ah
Ronis_BR: good
Ronis_BR: adamk: too bad I have many problems with KMS
Ronis_BR: adamk: artifacts and a much bad performance
zhasha: before DRI2, a DRI app (like mesa gl) would draw directly to the front buffer
Ronis_BR: zhasha: I understand
Ronis_BR: zhasha: so, seems I'll have to wait until KMS is optmized right
adamk: Works great here.
Ronis_BR: adamk: with my video card performance with KMS is almost 60% without it
Ronis_BR: adamk: is there a way to enable DRI2 but disable KMS :) sorry if it is too dumb
adamk: No.
xming: suokko: with preempt the userspace get preempted and the radeon kernel code gets pushed back?
zhasha: don't think so, but that's not dumb at all
adamk: And what did you use to test performance?
Ronis_BR: adamk: smoothness of compositing, FPS of KDE, FPS of glxgears with and without compositing
zhasha: anything above your screens refresh rate is a waste of swaps
zhasha: and KMS swapbuffers is slow as all hell
Ronis_BR: zhasha: can be
Ronis_BR: zhasha: glxgears and some GL apps flicker toooo much
zhasha: and thirdly, glxgears ONLY benchmarks swapbuffers
Ronis_BR: zhasha: :D
zhasha: I used to get 2000FPS in glxgears, now I get 300
Ronis_BR: zhasha: screensavers got flicker too
zhasha: it doesn't matter
zhasha: the flicker is an entirely different matter
Ronis_BR: zhasha: I don't know, but it isn't happening without kms
zhasha: that's because it's not syncing to your monitors vblank signal
Ronis_BR: zhasha: btw, without kms radeon is awesome, the performance is almost like fglrx
Ronis_BR: zhasha: is there a way to make it syncs?
zhasha: try with driconf
Ronis_BR: hum
Ronis_BR: maybe I'll try
Ronis_BR: zhasha: but the problem os swapbuffers will affect compositing performance right?
zhasha: not in the slightest
Ronis_BR: zhasha: I mean, will I feel it at daily use?
zhasha: let's say you can get 300FPS in glxgears
hexa-: suokko, unloading apparmor doesnt change anything
zhasha: that means you'll be able to swap 5 times faster than your monitor can even show
zhasha: so no, you won't ever be bothered by it
Ronis_BR: ah, ok :)
Ronis_BR: I'll give a try now
Ronis_BR: again :D
zhasha: the only bottleneck will be the DRI2 path of any given driver being slower than the DRI1 path
hexa-: thise is the full paste http://pastebin.com/m4eccccf3
Ronis_BR: zhasha: I'll try here now
Ronis_BR: hates conflicts on git merge...
hexa-: asd
suokko: hexa-: You could try to see what goes wrong there with libdrm change: http://sprunge.us/QCDA
hexa-: patch against libdrm_radeon?
xming: suokko: I am going to make a ut2004 timedemo script so we can all be using the same thing, that is if you find it usefull
adamk: thinks that would be a great idea.
glisse: airlied: if you drop my cs checker also drop the bogus utilities
adamk: So what do the developers think it will take to get s3tc working on r600 at roughly the same level as it's at on r300-r500 (ie. enough to enable the highest textures on NWN)?
hexa-: haha great, it works, i dont know why
hexa-: but I am now missing my cursor :)
suokko: hexa-: That patch shouldn't have fixed anything ... It should only report the error code that kernel is passing to user space
hexa-: ok, now it doesnt work anymore :)
hexa-: i know, i saw the printf :P
hexa-: the mmap allocate error even triggers when opening winecfg
hexa-: there is not really any output
hexa-: and mmap() failed: Cannot allocate memory does occur occasionally
hexa-: like 40% of the time
Ronis_BR: airlied: ping
Ronis_BR: zhasha: man, KMS is working properly know
Ronis_BR: now*
Ronis_BR: zhasha: and something very good happan, now I can hibernate and resume :D
Ronis_BR: zhasha: not sure if it was KDE related or something
Ronis_BR: zhasha: but you are true, glxgears goes from 1000FPS to 500FPS
Ronis_BR: zhasha: but I can't see differences
hexa-: mmap seems to be pulseaudio reltaed
mjt: is suspend/resume (s2disk) supposed to work on r600 with kms nowadays? :)
xming: mjt: works here
mjt: here on amd780g after resume I'm getting blank screen. always.
mjt: only hard reboot fixes it for me
xming: mjt: I have rv670 (3850)
xming: mjt: must be a karma thing :p
mjt: yeah, no doubt about that one :)
xming: mjt: could you still ssh into it? To get some useful info
agd5f: spstarr: we don't split large vbos tht are larger than the hw can yet regardless of ums/kms
soreau: MostAwesomeDude: r300_texture.c:83:r300_setup_texture_state: Assertion `is_r500 || (pt->width0 <= 2048 && pt->height0 <= 2048)' failed.
soreau: MostAwesomeDude: Can't enable compiz when resolution is larger than MAX_TEXTURE_SIZE
soreau: MostAwesomeDude: Works with classic ok
xming: when using kde composite, the logout/restart/shutdown dialogue does not appear here, anyone has experienced this?
agd5f: soreau: 2048 is a hw limitation on r3xx/r4xx
soreau: agd5f: I know that but compiz 0.9 gets around it in software
soreau: and with classic mesa, it works
mcgregor: mjt, works here on rv730 (laptop) s2disk+s2ram okay
agd5f: soreau: does it? or does classic just not catch it?
soreau: agd5f: It has always worked
soreau: agd5f: With compiz 0.8.x, it will just have the remainder display garbage
soreau: with 0.9, it works around this in sw
mjt: mcgregor: lucky you ;)
soreau: agd5f: and, it used to work with gallium afaik
mjt: but ok, it looks like my (local) issue, at least somewhere it works. Thanks.
soreau: agd5f: But now it doesn't. This is the first time I've seen such an error message
taiu: maybe it reports too big max texture size to programs
mcgregor: mjt, I believe it works only onmy laptop, last time I tested my desktop computer it didnt
adamk: I was under the impression that it would work in compiz 0.9.* only if you used the copy mode, and not texture_from_pixmap. But I could be wrong about that.
agd5f: soreau: classic might have silently masked the w/h or capped it at the max value
adamk: Especially as I've never tried.
soreau: adamk: Copy mode?
soreau: agd5f: As it should have :)
adamk: soreau: Isn't there a way of using compiz 0.9.* without GLX_EXT_texture_from_pixmap?
mcgregor: mjt, but generally it works. if not, it might have different reasons I guess.
soreau: adamk: I very highly doubt it. You would have to ask onestone
agd5f: soreau: no it shouldn't. the app should query the max texture size and not send large textures if the hw can't handle it
soreau: agd5f: Well I've never had a real problem with it, not sure why it should be any different now
soreau: agd5f: If you make a window larger than the MTS limit, it will become garbage or lose it's title bar for example, but not sure why you would need a window that large
adamk: soreau: SmSpillaz certainly seems to think so: http://forum.compiz.org/viewtopic.php?f=89&t=11944&p=76498#p76498
adamk: soreau: Of course, I have no idea if he's right.
soreau: adamk: We're all in -dev right now, you can ask him yourself :)
soreau: I think what he's saying there isn't exactly what he meant
taiu: soreau: what does glxinfo -l |grep GL_MAX_TEXTURE_SIZE give?
adamk: Meh. I'm working on something now and really don't want to get distracted more than I already have :-)
soreau: taiu: It is as agd5f said. 2048
agd5f: soreau: the window becoming garbage is not good behavior
soreau: adamk: FWIW, it works with 2080 as a total for both screens fine with 0.9 and with or without copy-to-texture enabled
agd5f: soreau: also is your dektop is larger than 2048 pixels that would be one example
soreau: agd5f: It is. It's 2080
soreau: and it's working fine with classic mesa now
agd5f: soreau: then there's the problem
soreau: classic mesa is broken?
adamk: I can tell you that I can run compiz on KDE4 now, across two monitors totalling 2560x1024 with a MTS of 2048 without experiencing a single problem graphical issue.
soreau: adamk: And with compiz-0.8.x, correct?
adamk: If it suddenly stopped working when I upgraded to a system using gallium3d, I would consider that a major regression.
mike-burns: Good morning, and welcome to "let's get DisplayWork working", our daily show in which I try to make my DisplayPort monitor work.
adamk: Correct, with compiz-0.8.*
agd5f: soreau: classic driver shouldn't accept textures larger than the hw limit
agd5f: soreau: and compiz shouldn't be using them
mike-burns: Since last time I've upgraded to Linux 2.6.33-rc6, and am using the xf86-video-ati driver from git. xrandr still doesn't recognize the DP monitor, even though it works from non-X (BIOS, boot, console).
mike-burns: I've enabled KMS, too, just in case.
mike-burns: So any other suggestions?
soreau: agd5f: So you're saying classic mesa and compiz are in an evil plot to trick my card into working correctly?
agd5f: soreau: you're getting lucky
soreau: bah
soreau: Consider what adamk said
agd5f: when it does try and sample from a texture larger than 2048 you'll get undefined behavior
soreau: agd5f: Well I know you are right, but I strongly disagree since it does work
soreau: and I bet, if I comment out this check it would still work *tries it*
adamk: soreau: What application is currently drawing your wallpaper?
adamk: If you kill/disable it, and simply let compiz draw it's own wallpaper (making sure the wallpaper is not larger than 2048) does compiz start?
soreau: adamk: I always use compiz to draw the wallpaper
soreau: but, I will try disabling wallpaper plugin
soreau: nah, it still craps out
adamk: So, in other words, you're not even trying to draw a texture larger than 2048.
adamk: Your resolution is just larger than 2048.
adamk: What is the maximum 3D size for that card? That might be the issue. Perhaps it has nothing to do with MTS.
soreau: Hmmmm
soreau: adamk: AFAIK, it's the same as the MTS but I could be wrong. It's an rv350
adamk: I actually think it's 2560.
soreau: The weird thing is, glxinfo alone gives this fail message
adamk: Errrr.
soreau: So I definitely think something is fishy, especially since it's doing r500 assert
soreau: on an r3xx
adamk: I'm having a hard time figuring out how that is anything but a bug :-)
soreau: me too
soreau: commented the check altogether, building..
soreau: success
soreau: compiz is up and running
soreau: There is r500 check code in r300_texture.c
soreau: that sounds like a half-asleep or tired-n-emotional (drunk) mistake to me :D
soreau: I sometimes forget the r3xx driver is for r5xx too
Ivanovic: agd5f: do you want me to report the issues with frogatto and the missing background to bugs.freedesktop.org?
agd5f: Ivanovic: sure
Ivanovic: agd5f: anything beside the stuff i posted in here required?
Ivanovic: no, i don't know the exact build dependencies, i just know that (beside the stuff i have for wesnoth) glew is required
agd5f: Ivanovic: dmesg if using kms, xorg log, config, any error messages
Ivanovic: strangely there is no error, the background texture is just missing
Ivanovic: cf http://imagebin.org/83782 and http://imagebin.org/83784
mike-burns: Anyone have suggestions on making DisplayPort work? Linux 2.6.33-rc6, KMS, xf86-video-ati from git, DP->DVI connecting Thinkpad T500 (DP) to Apple 30" (DVI) (with a converter).
twnqx: it sometimes randomly works, actually
agd5f: mike-burns: file a bug. it works for most systems
twnqx: then, next release, it randomly doesn't
mike-burns: agd5f: WHere do I file the bug?
agd5f: mike-burns: https://bugs.freedesktop.org
mike-burns: agd5f: Thanks.
agd5f: mike-burns: you'll probably want rc7 or 8 or whatever the latest is since airlied had some last minute DP fixes
Ivanovic: rc7 is latest
twnqx: Thinkpad T500 <- i had a driver that worked on that laptop... in november
mike-burns: Oh hey, look at that. Last I looked rc6 was the latest.
mike-burns: I'll try rc7 and file a bug if that doesn't work.
twnqx: hm, 2.6.33rc...
twnqx: mike-burns: do you use KMS?
mike-burns: twnqx: Yes.
twnqx: kernel driver as module or static?
mike-burns: Module.
twnqx: final question: does suspend/resume work?
soreau: adamk: agd5f: FWIW, I found that I can just start with GALLIUM_ABORT_ON_ASSERT=false and get it working this way
mike-burns: twnqx: Haven't tried lately. Didn't on a prior kernel.
twnqx: *sigh*
twnqx: i once had a combination of 2.6.31.6 + some git driver
twnqx: that would do KMS, 3D, display port, suspend/resume
mike-burns: Was it Radeon or Intel? This laptop has both.
twnqx: radeon
Ivanovic: agd5f: is there a way to force the renderer use software mode?
twnqx: intel doesn't seem to be connected to the displayport, right, mike-burns?
twnqx: or was it just the intel driver?
mike-burns: twnqx: That's the rumor.
agd5f: Ivanovic: LIBGL_ALWAYS_SOFTWARE=1
Ivanovic: looks like stikonas managed to do so yesterday, but, uhm, this seems to not work for me (using RADEON_ALWAYS_SOFTWARE=1 that is)
mike-burns: twnqx: I gave up on making the Intel driver work after I found that rumor. xrandr didn't mention DP at all.
twnqx: exactly.
twnqx: same here ;)
agd5f: mike-burns: generally on hybrid laptops only the LVDS and possibly the VGA are muxed
twnqx: VGA is, LVDS is, DP doesn't seem to be
mike-burns: Ah, yeah.
agd5f: stuff like DVI and DP are only connected to the discrete card
mike-burns: I've tried xf86-video-ati, -radeon, and the displayport git branch of -intel, on kernels 2.6.30, 2.6.26, and 2.6.33-rc6.
mike-burns: With and without KMS.
agd5f: mike-burns: the dp isn't connected to the intel card
mike-burns: Yup.
twnqx: can it be connected? *whips out soldering iron*
mike-burns: I also tried the displayport branch of -intel in FreeBSD 8, which told me I needed a kernel > 2.6.23 or something. Which is why I'm on Linux.
mike-burns: (This was before I learned that it's not conncted.)
adamk: Heh... You'll be lucky if a newer intel driver ever works on FreeBSD in the foreseeable future.
mike-burns: It'd be nice go to back to FreeBSD, but I'll survive under Debian so long as I can get this 30" working soon.
adamk: The DRI/DRM/Xorg maintainer is in a tough spot with intel. Newer drivers won't work without the memory manager, and the current driver in ports won't work on a newer version of the X server.
adamk: It's possible that the next ports update will break X for intel users entirely.
adamk: But, anyway, that's OT for this channel.
Ronis_BR: adamk: but radeon drivers will remain the same right
adamk: Yes, newer versions of radeon compile just fine on FreeBSD. There is still no KMS/DRI2 support.
mike-burns: Oh I just realized that adamk is the adamk who fixes bugs related to FreeBSD.
mike-burns: adamk: Thanks for fixing bugs on my favorite OS.
adamk: I wouldn't say that I've fixed bugs on FreeBSD. I have certainly helped any number of people with configuration issues though :-)
adamk: bbl
Ivanovic: agd5f: https://bugs.freedesktop.org/show_bug.cgi?id=26471
Ivanovic: agd5f: any more info needed?
Ivanovic: that is: no log (neither the game nor any system log) seems to contain any relevant error/warning
havocp: hi guys, looking for the scoop on hardware video decode ; * do the available hardware specs for radeon describe how to implement it? * do the open drivers implement it yet? * which one of libva/vdpau/xvba/ etc. is really relevant and which is some weird fork? etc.
Ivanovic: 1) not for uvd, but for the plain shaders it should be enough (no expert there!)
Ivanovic: 2) no
Ivanovic: 3) they all differ
Ivanovic: one is from intel, one from nvidia and one from ati
Tommeh: thought libva/VA-API was an open project, which Intel were going to support?
havocp: on 3) maybe X.org upstream has some sense of consensus on which one is "the future path"? (which one would the community use for open drivers if they got UVD specs)
Tommeh: The only decent/usable video-decoding API in use, which is actually supported, is VDPAU (sadly)
havocp: Tommeh you're saying because nvidia supports that well on their drivers, or because it's a better API?
Tommeh: havocp: I'm no developer - however it seems that developers have been happy enough to support it.
havocp: on the newer chips, is the hardware video decode tangled up with the GPGPU / ATI Stream stuff, or is that two separate aspects of the hardware?
jcristau: there doesn't seem to be a lot of people working on video on either the intel or radeon drivers. read pretty much nobody.
Tommeh: havocp: the inner-workings of XvBA and how it's implemented would be a question for AMD - let us know if you have a response, heh
havocp: guessing that means the open specs don't describe the GPGPU functionality either ;-)
Tommeh: I don't believe so
Tommeh: Only 2D/3D docs so far, to my knowledge?
Tommeh: I'm sensing some irony in the name choice of 'Havoc' for man interested in GPGPU :)
havocp: hehe
glisse: havocp: open doc does describe shader -> describe gpgpu
glisse: putin everythings together is a lot of work
glisse: you don't write graphic driver or video accel in one night with one dev
havocp: sure, just trying to understand what anyone is working on already, and which things have fundamental blockers (like lack of specs)
Tommeh: glisse: that's great to know :)
Tommeh: I didn't realise it was enough documentation to perform gpgpu
glisse: we have enough to do with current doc before wondering if we miss anything
havocp: I can imagine that gpgpu tends to replace hardwired support for specific video codecs, but I don't have a clue if they really did that or the chip still has hardcoded silicon that knows about mpeg
havocp: are there any specific people trying to work on gpgpu or video decode that I should talk to?
Tommeh: havocp: I would imagine it would be the former. VDPAU is only supported on Nvidia cards that can stomach CUDA, for example.
glisse: we can support vdpau too
Tommeh: is looking forward to Nvidia's GT220-based MCP to replace the 9300/9400 MCP
agd5f: havocp: there is some work for video decode and opencl over gallium
havocp: Tommeh I think fglrx only supports video decode on the cards with ATI Stream so that's one reason to speculate
havocp: agd5f: right, I saw Zack R had a pretty old blog post about it
agd5f: havocp: on AMD chips, r1xx-r5xx used the 3D engine for video decode. on r6xx+ you can use the 3d engine or the UVD block
Tommeh: glisse: do you mean, you could write a back-end for VDPAU that runs in the radeon driver by using GPGPU?
agd5f: Tommeh: vdpau is just an api like opengl
agd5f: you can write a backend to implement it on any capable hw
Tommeh: Ah-ha.
havocp: agd5f: oh so pre-r6xx there's not really a video decoder to be in the open specs anyway - they just sped stuff up with shaders and similar?
agd5f: havocp: yes
havocp: (do the open radeon drivers use gallium?)
Tommeh: agd5f: do you think we should all be concentrating on making VPDAU universal?
agd5f: Tommeh: I'm not really a video decode expert
havocp: agd5f: that implies to me that there isn't any magic decoder feature omitted from the specs? or is the "UVD block" such a feature?
havocp: in r6xx
agd5f: havocp: there is no decoder stuff missing from the specs
agd5f: UVD is r6xx+ only and we haven't release any specs on that yet
agd5f: havocp: however, UVD specs are not necessry to write video decode support on r6xx+
agd5f: you can use the 3d engine too, just like eariler asics
havocp: agd5f, great info, thanks ... I was assuming there was stuff in the chip similar to the dedicated mpeg decoder silicon lots of cell phones have
agd5f: havocp: for r6xx, that's what UVD is
havocp: but pre-r6xx, sounds like video decode is "just" a software/driver feature and there isn't a dedicated piece of silicon for it?
agd5f: correct
agd5f: havocp: there's hw for it, it's just general purpose hw used for 3D as well :)
havocp: you said r6xx specs aren't out yet - that means for all r6xx features or specifically the UVD? the open drivers support r6xx though right, presumably just extrapolating the r5xx docs?
agd5f: havocp: only UVD
agd5f: r6xx/r7xx 3d specs are out already
havocp: got it
agd5f: havocp: http://www.x.org/docs/AMD/
agd5f: http://www.x.org/wiki/DataSheets
chithead: uvd is not r6xx specific is it? iirc there was an r500+uvd too
cornair: where is teh key to disable drm.debug at runtime? (echo > /proc/.../ )
cornair: 'v found it
agd5f: chithead: rv550 had uvd, but for the most part it's r6xx+ only
agd5f: not sure how many rv550s actually made it out into the wild though
Rabenklaue: hi, when using my ATI 200M with kernel 2.6.31 (xfree86-video-ati, libdrm and mesa from git) with KMS enabled (from staging drivers section) all works fine, but with 2.6.32 and 2.6.33 (rc5 and rc7) I can't start X as it freezes my whole system.
Rabenklaue: Does anyone know, whether this is a known problem and if there is eventually a workaround?
glisse: Rabenklaue: sounds like a bug
Rabenklaue: glisse: Seems so, just googled a bit and there are many people using >= 2.6.32 with radeon and KMS having the same issues.
glisse: Rabenklaue: got links ?
Rabenklaue: http://www.pubbs.net/xorg/201001/48887/
glisse: i wouldn't call 1 bug many :)
Rabenklaue: glisse: Just looking for more
glisse: anyway it's a bug
glisse: i need to retest my rs480
bridgman: seems like that link is talking about crashes happening some time after X starts up
Rabenklaue: I'm just getting the latest git versions as mine are ~1 week old. Hopefully the bug is solved so far.
bridgman: your problem is freezing system during X startup
bridgman: if I understand correctly
Rabenklaue: bridgman: One time I manged to get some shells with openbox and one time I saw the compiz boot logo. But mostly it freezes while starting up.
Eythan: hello, i am using the git version of xf86-video-ati driver, i have radeon 5850, 2D works ;) thx to all dev
Rabenklaue: And in most cases I'm able to return to my my virtual console (CTRL-ALT-F1), but while switching back the whole system freezes.
Rabenklaue: But there isn't anything useful in Xorg.log (no (WW), no (EE))
bridgman: anything in dmesg ?
bridgman: under KMS some of the work done in X before moves to the kernel...
Rabenklaue: bridgman: I'll have a look after updating libdrm/mesa/video-ati
Eythan: from my /var/log/Xorg.0.log : (II) RADEON(0): Manufacturer: IVM Model: 5608 Serial#: 16843009 --> Sapphire Radeon 5850 1 Go
Eythan: i m running on git version
Rabenklaue: http://codepad.org/qYVTR6te
Rabenklaue: Openbox started successfully, but after running glxgears the system has been frozen again.
Rabenklaue: Looks like a problem regarding mesa/opengl
Rabenklaue: And while loading radeon: http://codepad.org/RfH2FpvB
Rabenklaue: The same problem on 2.6.32: http://bbs.archlinux.org/viewtopic.php?pid=673937
chithead: agd5f: I think most widespread r500 with uvd was m71
chithead: lenovo had it in one of their t-series
mike-burns: Update: 2.6.33-rc7 didn't make DisplayPort magically work. Filing a bug report now.
agd5f: chithead: that's an rv550
chithead: ah yes
twnqx: right... which mesa/drm should i use with git ddx?
twnqx: i have drm 2.4.17/mesa 7.7
chithead: twnqx: should be ok, as long as libdrm was built with --enable-radeon-experimental-api
twnqx: is there a way to figure in retrospect?
soreau: What is the max texture/gl size for r8xx?
chithead: configure of xf86-video-ati will tell whether kms is enabled
twnqx: CONFIGURE_OPTIONS="--enable-udev --enable-nouveau-experimental-api --enable-radeon-experimental-api" - seems gentoo does by default
xming: twnqx: yes gentoo has --enable-radeon-experimental-api on
twnqx: right. let's see if git head still crashes my laptop.
agd5f: soreau: 16k iirc
agd5f: soreau: r6xx/r7xx is 8k
soreau: agd5f: How many crtcs does it have?
agd5f: soreau: but mesa doesn't currently support textures larger than 4k
agd5f: soreau: evergreen has 6 crtcs
soreau: wow
soreau: agd5f: Hmm.. why does mesa have this limit?
agd5f: soreau: core mesa has some assumptions about max texture size that need to be updated
spstarr: back
AndrewR: "warning: remote HEAD refers to nonexistent ref, unable to checkout." trying to git clone http://cgit.freedesktop.org/~osiris/mesa/ ....
spstarr: yay - http://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal is APPROVED
AndrewR: want to see how hierZ looks like on rv280? (experimental part, commented out in driver ?)
amarsh04: could be interesting AndrewR: 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)
spstarr: agd5f: isn
AndrewR: amarks, http://imagebin.ca/view/ZFfgH79l.html
spstarr: agd5f: oh yeah, that's right its not being split in the DRI code for UMS or KMS.. the vbos...
AndrewR: amarsh04, suokko, agd5f http://pastebin.ca/1790436
suokko: AndrewR: What mask did you use in clear for that effect?
AndrewR: suokko, (0xff << 22) | (0xff << 6) | 0x003f003f;
spstarr: glisse: going to run lockstat tests with preempt enabled again and go though it with UMS/KMS.. shortly once i look at git commits to drm and such.. along with any mesa r6xx stuff..
agd5f: AndrewR: did you get it working?
suokko: AndrewR: I suspect that mask is wrong for r200
AndrewR: ok, so back to archive .....
spstarr: suokko: let's see what new info I can get for you
Neo_The_User: I am trying to create a flush in the openchrome driver (for via hardware) so the window doesn't make copies of itself all over the screen but since this is #radeon and #openchrome is always dead, I'll generalize this question. How do you figure out where to make the DDX flush and if that means debugging the DDX, how do you debug the DDX without debugging the entire xserver?
suokko: spstarr: I the largest problem is the locking in radeon_cs.c
spstarr: what is it doing that keeps the lock held for so long?
AndrewR: suokko, http://marc.info/?l=dri-devel&m=109960901000240&w=2 ?
agd5f: Neo_The_User: the accel infrastructure provides a sync hook. exa or xaa for example
Neo_The_User: wait i think im asking the wrong thing here. flushing is done in mesa. so i need to debug mesa...
Neo_The_User: where do I ask for questions about using MESA_DEBUG?
spstarr: ok so in radeon_cs_ioctl() we setup a mutex lock, oh my...
spstarr: suokko: that is a long lock
agd5f: Neo_The_User: #dri-devel
Neo_The_User: thank you agd5f :D
AndrewR: suokko, basically, i need to use RADEON_3D_CLEAR_HIZ packet....
spstarr: suokko: why do we have to reinit the CS parser each time we call the ioctl?
spstarr: oh my..
spstarr: that function
spstarr: I can see why this causes contention
suokko: spstarr: It creates new parser state object everytime and loads data from submited command stream to it
spstarr: we cannot reuse an existing parser state object?
spstarr: or does it keep growing in size?
suokko: Current design should be possible to change so that we onl hold lock shortly in begin and end
suokko: If we had shared parser state we couldn't do that
spstarr: hmm
spstarr: got any patches that change the locking?
suokko: spstarr: No. I didn't want to start reading all the code that is called from parser to check where exactly locking is required
AndrewR: suokko, like this? http://pastebin.ca/1790474
agd5f: AndrewR: new i2c patches
AndrewR: agd5f, oh, thanks ...
AndrewR: suokko, err, http://pastebin.ca/1790479
suokko: AndrewR: In old kernel code R200 had always zero in clear mask
spstarr: suokko: well, it's glisse's code :)
AndrewR: suokko, but original patch assumes rv- version of r200 radeon (incl. my rv280) has no HierZ ....
suokko: spstarr: That why I don't mess with it ;)
spstarr: suokko: so you think it is probably this code vs the ttm and radeon specific code that is causing the stall.
suokko: It was the largest single lock held in your stats
suokko: 23ms maximum time while next highest was 5ms
spstarr: im going to re-run these stats with a new build of today's kernel of linus-2.6 + drm-radeon-next only.
suokko: That 5ms is barely visible stall when as 23ms would be already clearly visible
xming: radeon_ring_lock radeon_ib_schedule radeon_cs_ioct190.7 msec 3.9 %
xming: radeon_ring_lock radeon_ib_schedule radeon_cs_ioct190.7 msec 3.9 %
spstarr: put back preempt then give you a more rounded view of with a running log of stats as xming did
spstarr: ouch xming
xming: 190ms is LONG
spstarr: xming: what were you doing in your game?
xming: spstarr: not game, just firefox
spstarr: !
spstarr: xming: preempt is off?
xming: my X has hickups now
xming: preempt off
xming: I didn't had that when freshly rebooted
twnqx: ok, GIT freezes with 2.6.31.6 :P
xming: it's getting worse by hour I would say
spstarr: suokko: you want my next stats with preempt on or off?
twnqx: but seems to at least come up with 2.6.33-rc7
spstarr: xming: that seems right, you note i said later that i started getting more and more stalls with no-preempt + KMS
spstarr: xming: so initially it was smoother
twnqx: yey, also suspend/resume works
agd5f: AndrewR, suokko: bit 27 of RB3d_ZSTENCILCNTL is FORCEZCLEAR
twnqx: now for KMS
agd5f: AndrewR, suokko: IIRC, only r200 had heirZ. the rv chips only had fast z clear
xming: spstarr: yes I come to the same conclusion
suokko: r200=radeon 8500 right?
agd5f: suokko: yes
agd5f: 8500 and 9100
xming: now in game it even misses mouse events, so kind a get an auto fire mode for free :D
spstarr: heh
spstarr: turns on quad core
twnqx: congrats! the current git driver + 2.6.33-rc7 works better than most combinations i've tried so far!
xming: steals one core from spstarr
twnqx: i wish i'd have brought my display-port -> hdmi adapter :P
xming: twnqx: you buy stuffs from yourself? :p
twnqx: nah, but i'm spending my weekends in another city
twnqx: guess where my adapter is :P
AndrewR: agd5f, may be someone who still has r200 (original) will want to copy .. for now i just making kernel patch (for packet 0x37 - at some point i really wnat to write checks for stuff this packet may have ... )
xming: twnqx: oh sry, I read is as bought
AndrewR: agd5f, to copy my hacks and try them
twnqx: watches some more roadrunner on the system where he can't get WLAN to work while having no network cables
xming: radeon_ring_lock radeon_ib_schedule radeon_cs_ioct194.6 msec 2.7 %
xming: maybe I should reeable preempt
twnqx: OpenGL renderer string: Mesa DRI R600 (RV635 9591) 20090101 TCL DRI2 <- is accelerated, right?
xming: twnqx: yes
xming: twnqx: to a certain degree
suokko: xming: That problem means ring buffer is full and GPU is not runnig fast enough to handle the full ring buffer
xming: suokko: I have a rv670 (3850), so it can't handle that I scroll in firefox?
twnqx: it'a an ATI....
suokko: xming: No idea why ring is full. But that function which was pointed by latenctop loops while waiting free place in ring
xming: even watching .avi in mplayer stalls
twnqx: Oo
twnqx: -vo xv ?
xming: I didn't had this before (while I on the ext. usb hdd), now I can remember that this happens a few times after I started using SATA (even with preempt on)
xming: twnqx: yeah xv
twnqx: strange, works perfectly here
xming: twnqx: happens only once or twice every 30 min or so
suokko: twnqx: You could try to collect info about ring reservation with http://sprunge.us/TKVh. Too bad it will spam a lot to your dmesg
twnqx: actually
twnqx: i'm pretty happy.
twnqx: hmmmm there's some weird lag when typing
spstarr: suokko: I didnt think the ring ever gets full?
spstarr: suokko: because the CP is constantly taking stuff from it?
spstarr: suokko: does the GPU signal if the ring does get full?
suokko: spstarr: Some operations take long time to perform in GPU but only take short whiel to submit from CPU
suokko: spstarr: Simple math
spstarr: ok
spstarr: suokko: the GPU ring buffer is serial in nature?
suokko: We have ring buffer (array wti hgiven sizes) and 2 pointers. First is write pointer that points how far we have writen
suokko: And read pointer which points where GPU is currently reading
suokko: So anything after read pointer and before write pointer is reserved space for GPU
spstarr: suokko: so sort of like an 'IP'
spstarr: is there a reason the GPU's ring buffer is not multi path?
spstarr: and only serial?
spstarr: I would think not all operations pushed into the ring buffer require sequential dependencies?
spstarr: or this is not the case?
suokko: spstarr: It is jsut communication stream. CP will then push the commands to GPU and will process more before GPU handles the command
spstarr: ok
spstarr: so there is another queue for CP
spstarr: suokko: which other kernel option you want me to turn on?
spstarr: Interrupts-off Latency Tracer?
suokko: spstarr: That one would be nice check that something isn't turning interrups off for long time
spstarr: ok
spstarr: do you want me to put back glisse's new CS code?
spstarr: or keep that removed from my tree?
spstarr: 1dc3b2951d3a6da2e93b42cf1d70ebae3f609fc1
suokko: idk
Rabenklaue: Noone? http://codepad.org/qYVTR6te
ernstp: wow, I can actually log in to world of warcraft with opensource drivers and kindof play
ernstp: it badly messed up and slow, but it
ernstp: 's running!
AndrewR: agd5f, still no luck with i2c ...
spstarr: building kernel...
spstarr: so this is as glisse would have it but with linus's latest changes in linux-2.6
ernstp: now I'm going to file bugs on WoW operation :-)
AndrewR: agd5f, http://pastebin.ca/1790531 (dmesg)
spstarr: there has not been many changes post -rc7
Vhozard: Cna someone help me?
Vhozard: can*
Vhozard: Trying to find an ati driver with full vsync 2D support
spstarr: looks at the ddx changes
agd5f: Vhozard: Xv? compiz?
Vhozard: agd5f metacity/compiz. ive sorted out video (xv) already
agd5f: AndrewR: does this patch help? http://www.botchco.com/alex/xorg/kms_hw_i2c_grab_bus.diff
agd5f: Vhozard: what hw and version of mesa are you using?
spstarr: libdrm is quiet
Vhozard: agd5f mesa version I dont know. Last one on Ubuntu 9.10. Hardware: HD4850
Vhozard: Last *stable* one
Vhozard: (not beta/alpha)
AndrewR: suokko, http://pastebin.ca/1790543 (mesa-hyperz-hacks)
agd5f: Vhozard: you need 2.6.33 and mesa 7.7 or git master
agd5f: Vhozard: however, the sync stuff is busted in mesa git master due to the intel dri2 swap buffers merge
AndrewR: agd5f, compiling ....
Vhozard: agd5f Great. Any way to get vsync with latest fglrx drivers?
ernstp: Vhozard, I don't think they give you vsync on anything...
agd5f: Vhozard: iirc fglrx should work out of the box
ernstp: agd5f, they do? on 4xxx hardware?
ernstp: Vhozard, iirc they're full of options for vsync but they don't do anything
Vhozard: agd5f ernstp I get Vsync on videos (gl - ATI fast cards preset on SMPLAYER) and in games, but just not in metacity/compiz
ernstp: Vhozard, with opensource radeon?
agd5f: ernstp: they support the various glx sync extensions IIRC. the app has to use those extensions however
AndrewR: suokko, for osiris's mesa tree - should i just manually git checkout interesting branch? (because auto-checkout fails)
Vhozard: ernstp Not with open radeon, only with fglrx.
ernstp: agd5f, ok, last I tried, some 9.9 release, they didn't give me vsync on anything, no matter what app/test
suokko: AndrewR: I jsut created new local branch from mesa master and then used git pull with remote path
agd5f: Vhozard: with the open drivers tear free Xv will work without a compositer. if you want tear free compiz you need interrupt support (drm from kernel 2.6.33) and a newer mesa
Vhozard: ernstp I got vsync on glxgears with 9.9 and vsync forced
ernstp: agd5f, does vsync work with kms?
Vhozard: agd5f interrupt support + drm?
ernstp: Vhozard, oki, nice. but not on movies, or?
Vhozard: ersntp Try to use SMPlayer and use the preset ยจgl - ATI fast cardsยจ
ernstp: Vhozard, yeah that should work, but the colors are off
agd5f: Vhozard: if you are using the open drivers you need a newer drm since the one with your version of ubuntu doesn't support the features you want
ernstp: agd5f, I don't get vsync in compiz with "this week"-everything
agd5f: ernstp: I just said it's broken in mesa git master due to the intel dri swap buffers merge
suokko: Vhozard: You can also set VSYNC on in compiz config manager
spstarr: oh neat HyperZ
Vhozard: suokko LOL, ive tried that ofcourse xD Doesnt work
spstarr: AndreasD: can that work be applied to r6xx+ ?
ernstp: agd5f, oki, right
ernstp: agd5f, btw, I could start World of Warcraft and enter the game, nice work!
ernstp: agd5f, I mean, it's a pretty big test
agd5f: Rabenklaue: does this patch help your rs4xx hang? http://www.botchco.com/alex/xorg/force_crtc_on_for_timing.diff
agd5f: ernstp: cool
Vhozard: agd5f thats open source vsync supporting version doesnt have 3D support?
agd5f: Vhozard: ? the open source driver supports 3D
markinfo: i have just compiled 2.6.32-7 and newest ati driver from git but I can't to get this message away:
markinfo: [dri] This chipset requires a kernel module version of 1.17.0,
markinfo: [dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel.
suokko: markinfo: libdrm is missing KMS support
MostAwesomeDude: markinfo: Rebuild libdrm with --enable-experimental-radeon-api then rebuild DDX.
suokko: And yo uhae to first install the recompiled libdrm vefore recompiling the ati driver
Vhozard: agd5f I mean the open source driver DOESNT have support for 3D for HD4xxx (R700)
markinfo: I have taken this one: http://packages.qa.debian.org/libd/libdrm.html version 2.4.17-1, It should be wit this option already - or not? see https://buildd.debian.org/fetch.cgi?pkg=libdrm;ver=2.4.17-1;arch=amd64;stamp=1264976293
Ivanovic: uhm, it has
markinfo: --build=x86_64-linux-gnu --enable-udev --enable-radeon-experimental-api --enable-intel
MostAwesomeDude: markinfo: Do you have libdrm_radeon?
MostAwesomeDude: markinfo: When you configure the DDX, it should say "Kernel Modesetting: yes"
Ivanovic: Vhozard: that is the driver for the r700 series does basically what the r600 driver does, too
markinfo: MostAwesomeDude, libdrm-radeon1 version 2.4.17-1 is here. What means "configure the DDX" ?
Ivanovic: it is far from perfect and well tuned, so you will most likely still have some glitches, but there is basic 3D with the r6xx and r7xx cards
Ivanovic: (and glitches should be reported!)
Vhozard: Ivanovic i havent seen any good 3d acceleration yet on r700 cards
Ivanovic: that is i am already able to play ut2004 with my hd3850 card, though with reduced details and a reduced resolution
Ivanovic: and world of goo runs without a problem
Ivanovic: ah, now you say *good*
Ivanovic: that is different from "none at all"
Ivanovic: yes, things are not well optimized so far, but basics do work
AndrewR: agd5f, no ....
Ivanovic: and yeah, eg opengl in zsnes does work, too
MostAwesomeDude: markinfo: xf86-video-ati
spstarr: building mesa trunk
markinfo: MostAwesomeDude, i do not know what you mean - but can be senn here something? http://paste.debian.net/59195/
markinfo: it is config log before compilation of ati Driver.
markinfo: it is config log before compilation of ati Driver.
Vhozard: Ivanovic And game support with R700
Vhozard: Ivanovic FPS over 20 possible?
markinfo: is it necessary to work dualscreen settings with grandr to be properly installaed libdrm?
Ivanovic: Vhozard: depends on the games
Ivanovic: *which* games do you try?
Ivanovic: world of goo works perfectly smooth over here
Vhozard: wolfenstein enemy territory
Ivanovic: no idea
twnqx: glxgears roll perfectly here, too
Ivanovic: twnqx: they say not too much
twnqx: less than a 10th of my gtx285, though
Rabenklaue: agd5f: applying the mentioned patch made it even worse: After switching back to my virtual console, the system freezes. Before that I experienced this behaviour only being in the X environment
Ivanovic: they already roll perfect with plain software mode
Vhozard: lol, I can roll glxgears with about 600 fps without any acceleration at all
Ivanovic: and the numbers you get there say *nothing* about real usecases
twnqx: i have no better use cases on linux :C
Ivanovic: basically just a way to make guessing if opengl is accelerated or not easier
Vhozard: Ivanovic Well its says a little. I mean 65k FPS makes sure you arent only using software accel.
twnqx: i have 1.8k :(
MostAwesomeDude: Gears isn't a benchmark.
Ivanovic: [22:22:58]
MostAwesomeDude: You can go faster with llvmpipe than with r100.
MostAwesomeDude: Instead of guessing, read glxinfo's output.
twnqx: so is there a decent benchmark on linux?
MostAwesomeDude: openarean
MostAwesomeDude: *openarena, even.
MostAwesomeDude: That's a good starting point.
twnqx: i meant... something dedicated
MostAwesomeDude: ipers?
twnqx: like 3d mark
MostAwesomeDude: Haha, nobody's written one.
chithead: you mean synthetic benchmark?
twnqx: yes
Vhozard: Geekbench
chithead: what good would that be
twnqx: i see no real world use of 3d in linux so far
adamk: phoronix has a collection of applications they use.
Ivanovic: use phoronix-test-suite and run it eg with openarena
MostAwesomeDude: I'd much rather prefer the "can it move fast enough to let me frag the other guy?" benchmark.
Ivanovic: that sounds good enough as "dedicated test suite"
Ivanovic: ;)
AndrewR: MostAwesomeDude, i saw lp-binning branch merged ... do you have any numbers? (myself only has 950Mhz cpu, so nothing interesting at speed front .....)
twnqx: sadly only games from last century run on linux...
twnqx: hm, last millenium?
Ivanovic: uhm, there are games from the last years running on linux
MostAwesomeDude: AndrewR: I'm told that it can run OA, but I haven't tested it myself.
Ivanovic: yeah, many of those are rather old, but they work nontheless
twnqx: last thing i played was f.e.a.r. 2
AndrewR: twnqx, i was impressed by DarkPlaces ... (Nexuiz)
twnqx: played nicely in 1920x1200
Ivanovic: eg ut2004, prey, doom3, quake4, wesnoth, openarena, worldofpadman, jack keane, ankh 1+2, ...
AndrewR: twnqx, it was first time i saw per-pixel lighting with open-source drivers... on r600. In last year
Ivanovic: those are all games that came out less than 10 years ago
twnqx: mh
Ivanovic: you can even add etqw in the list of games available
BioTube: I'd love to see portal working with FOSS drivers, but it still needs fglrx
adamk: Does quake4 actually work properly?
AndrewR: twnqx, i also have bad habit for running old 3dmark in wine .... sometimes it even work ....
Ivanovic: there *are* games, just not most of the AAA games out there
adamk: It requires s3tc.
twnqx: next i'll play is far cry 2 however :P
sshc: My opengl games are randomly crashing, and this gets outputted: drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream. See dmesg for more info.
Ivanovic: i have *not* said that all of those will work perfectly (or at all) using the open source drivers
BioTube: sshc: anything interesting in dmesg?
Ivanovic: it is just wrong to say that there are no (native) games available on linux
sshc: It seems to happen much more often when something such as firefox is eating a lot of RAM
sshc: BioTube: I found one perhaps relavent line
sshc: 2
sshc: well, a few
BioTube: pastebin'em
sshc: "[drm] Num pipes: 2", "neverball: page allocation failure. order:4, mode:0x40d0", "Pid: 25710, comm: neverball Not tainted 2.6.32-ARCH #1", and below that, "Call Trace"
suokko: sshc: KMS or without KMS?
sshc: suokko: I'm not sure, tbh
suokko: dmesg | grep modeset
sshc: suokko: [drm] radeon defaulting to userspace modesetting.
sshc: suokko: only output
suokko: sshc: https://bugs.freedesktop.org/show_bug.cgi?id=23993
AndrewR: suokko, ok, compiling osiris's tree .....
suokko: AndrewR: Did you hook the code to r200 too?
suokko: It is not hooked in osiris's tree yet
AndrewR: suokko, no ....
AndrewR: suokko, i'll try to do what .... should i look at r300 as example
AndrewR: suokko, ?
suokko: There is one commit which adds the support to r300
suokko: Same should be done for r200 too
spstarr: ok time to test new kernel debug...
sshc: suokko: is there a way to fix this?
suokko: sshc: There is the patch to fix it in the bug report
twnqx: wow, the irq thingy is solved in recent ddx/kernel?
twnqx: didn't notice in the beginning
suokko: Too bad it is too later for 2.6.33 kernel
twnqx: mh?
twnqx: oh
sshc: suokko: too later?
sshc: suokko: will the fix be included in future kernels?
sshc: and how soon?
BioTube: from the kernel.org frontpage, it looks like there'll be an rc8
AndrewR: suokko, "radeon/r300: preparation for tiled textures" ?
suokko: sshc: When the patch is ready to included into kernel. I hope I can get it to 2.6.34 and backported to stable branches after it.
spstarr: suokko: ok about to run the tests
suokko: spstarr: Did you saw xming's script to run the ut timedemo?
xming: suokko: I haven't done it yet :p, will need to make a decent demo first
xming: random demo (a map with bots) is not the same every time
spstarr: suokko: modifying it to concat lock dep info
xming: while pre-recorded is the same every time
spstarr: suokko: and set 15 second intervals up to a maximum of 15 cycles
spstarr: but since the stats are real-time
spstarr: any stalls would not be recorded however if not caught
spstarr: maybe i'll make it 20
suokko: spstarr: They are also incremental unless ou reset the stats
spstarr: ok it is?
spstarr: ok
suokko: And I think it is easier to read only the full stats
spstarr: then i'll just have a while loop spin and wait 30 seconds then
suokko: Than trying to read multiple small stats and trying to see something from them
suokko: spstarr: sleep 30; shhould be good enough
spstarr: ok so it will spin for 50 times and sleep for 30 seconds
spstarr: then exit? so we get the most stalls i can out of that time
spstarr: as long as GPU doesn't lockup :
spstarr: :)
xming: I just had a +/- 5 second stall in mplayer :(
AndrewR: mplayer often stalls if mozilla/firefox update its tabs in background (for me on sub-1Ghz machine)
suokko: firefox is bad for OGL too. It is just doing too much rendering all the time
spstarr: seeing contention...
FIReun: anyone know what all this debug stuff is in my dmesg? -- http://pastebin.com/f619adc42
FIReun: pin, unpin, bdi_sched_wait, ect...
spstarr: suokko: whats interesting is im saying in this same scene/ region in SL and all the texture primitive info *should* be cached
spstarr: so I would not expect to see given its already stored
AndrewR: suokko, agd5f after reading dri-devel archives i have impression texture micro-tiling (at least on my card) may not work for rectangular textures ...so, i have no hope for speeding up textured xv?
suokko: AndrewR: You can use padded texture to pow2 size
AndrewR: suokko, and waste tons of ram .. may be i'll try this (if i found my way in xv code)
suokko: So if you have xv at 55x43 you just use 64x64 hw texture
AndrewR: suokko, 1920x1088 is my target size ;) 2 Mpix rougly ....
AndrewR: suokko, rounds nicely to 2048 .... not sure if there will be any speed benefit ....
AndrewR: suokko, may be special case for way-too-big xv images ....
spstarr: still collecting stats
suokko: Depends on what processing is done for video. If there is any shader work that requries accessing adjacent pixels then there would be quite nice benefits
AndrewR: suokko, from waht i remember without looking at code - there was some ati_fs work (color conversion)
MostAwesomeDude: soreau, airlied : I'm back in the mood. Are there still broken things from the MRT shader work?
suokko: AndrewR: But texture tiling only helps if you need adjacent pixels from next or previous row
suokko: pixel shader in it self won't necessery need tiling if it only reads one pixel or one pixel output
spstarr: suokko: this should be a pretty good log once done
AndrewR: suokko, MostAwesomeDude used some heavy shaders for scaling on r300 ... may be he knows if his waor will benefit from texture tiling ...
AndrewR: suokko, *if his work ....
suokko: AndrewR: yes. If the output is scaled then you will get some help from tiling
MostAwesomeDude: Tiling should help in all but some rare corner cases. There's a good reason why fglrx uses it for everything.
agd5f: Vhozard: the open source driver DOES support 3D on r7xx
agd5f: AndrewR: r200 supports macro and micro tiling just fine
agd5f: only limitation is that textures have to be aligned to a tile multiple, but that's not much different than the normal alignment requirements
agd5f: AndrewR: textured video can use tiling just fine
spstarr: suokko: contention seems to be getting worse we'll see the stats
agd5f: and it will give you a nice boost since adjacent pixels have a better chance of staying in cache
xming: spstarr: what changed? Patches? Preempt?
spstarr: im using preempt with new CS code this time.
spstarr: stats done
spstarr: suokko: lemme put them up for you
spstarr: suokko: http://www.sh0n.net/spstarr/radeon/lockstat.out
spstarr: you can now see who has the most contention
spstarr: and ttm is pretty up there.
spstarr: radeon also with 21996.27
spstarr: suokko: this is over at least 10 mins logging
xming: waittime is in us? I hope it's not ms :D
spstarr: radeon_cs_ioctl 6777 ugh
AndrewR: suokko, if i hook up code in r200_tex.c only - i have nicely garbled textures ....
spstarr: radeon_ring_lock
spstarr: suokko: so running this longer shows more locks that are maybe an issue
suokko: AndrewR: The tiling format is not same as with r300. So it needs changes in tile/detile code
suokko: spstarr: Yes. All large max-hold times are what we should fix
spstarr: ya
spstarr: suokko: what other info do you want me to record next?
spstarr: non-irq event times?
spstarr: i can redo this test again for 10 mins using that stats
Vhozard: agd5f: Vhozard: the open source driver DOES support 3D on r7xx. I can play a quake-like game on more then 20 fps?
AndrewR: suokko, nice task ....
suokko: spstarr: It would be good to test
spstarr: suokko: I noticed no I/O disk contention though from this info
agd5f: Vhozard: openarena works fine here
suokko: spstarr: There is no lock depency graph there
Vhozard: agd5f which card are you using?
suokko: You would need that to solve why block IO affects us
suokko: Because there is some lock which we share indirectly with them
xming: Vhozard: ut2004 runs between 13~85 fps here on a rv670, so it works
suokko: Or some how we enter block IO handling from inside out code
spstarr: echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
spstarr: suokko: i didn't turn off lock dep graphs did I?
suokko: spstarr: read the sus fs README file
suokko: sus/sys
Ivanovic: Vhozard: one important question is which card exactly you have and what cpu you use
evil_core: hi all
spstarr: suokko: for which data?
Ivanovic: (plus of course which mesa version and which kernel!)
agd5f: Vhozard: just about every r6xx and r7xx card we make
xming: I didn't get anything (in dmesg) with echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
evil_core: how can I get VSync, teariung in movies is very annoying
suokko: spstarr: /sys/kernel/debug/tracing/README
spstarr: suokko: oh for that
Ivanovic: evil_core: by downgrading something before some intel buffer thingie was merged in
spstarr: oh neat
spstarr: the kernel provides a built in README :)
evil_core: Ivanovic: theres n oreally other way?
xming: suokko: oh nice, that's what I need to enable irqsoff
Ivanovic: evil_core: looks like some change there broke vsync (i don't know any details, not even the exact package or commit) for most systems
spstarr: blk function_graph irqsoff function sched_switch nop
evil_core: Ivanovic: somebody told me that Xv doesnt depend on Mesa
spstarr: suokko: any tracers want other than those?
Ivanovic: and in regards to videos: one or two displays?
spstarr: i did not enable all of the tracers before.
BioTube: evil_core: you need to disable compositing for Xv to sync
markinfo: the last problem - why does not kernel use KMS just when it starts? I need to make manually modprobe radeon (console swirch to graphic mode) or to start xserver.
evil_core: BioTube: it pure WMaaker :)
Ivanovic: markinfo: the kernel can use it
Ivanovic: markinfo: but to do so the module of course has to be loaded when it is started and the option has to be set so that modesetting is active
evil_core: Ivanovic: one, it was working some time ago
spstarr: we want to irqsoff right now
evil_core: but I am upgrading mesa//libdrm sometitimes many time a day
Ivanovic: if you compile the radeon module in, you should either select the modeset active by default param
markinfo: Ivanovic, where to do that? (on debian)
Ivanovic: or add radeon.modeset=1 to your grub line
spstarr: suokko: which tracer info do you want: latency-format, parent-print?
spstarr: sleep-time?
spstarr: there a whole bunch
Ivanovic: uhm, you define this when configuring the kernel eg via make menuconfig
suokko: spstarr: I don't know. I haven't used the tracer
spstarr: i will go with sleep-time first.
evil_core: CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/rs600.c
evil_core: Automatic merge failed; fix conflicts and then commit the result.
Ivanovic: (that is if the module is built in or built as module and if kms should be active by default)
evil_core: [can I force it to sync?
suokko: All I would like to know if there is any code taking long time in irqs disabled code path in your kernel ;)
suokko: spstarr: Do you have swaping going on while running the test?
AndrewR: suokko, latest patch from francisko may help with swapbuffers? (PATCH] glx: Fix SwapBuffers regression introduced by 01923fb72d. at mesa-devel)
suokko: There is quite large hold times and wait times for page fault handler
spstarr: suokko: not this time
spstarr: im not running many processes for this yest
spstarr: if i ran virtualbox i would begin swapping probably
suokko: spstarr: Your previous data shows max lock hold time for page faults 52ms and max wait time 4ms
spstarr: tracing active...
suokko: So there is something funny going on there
spstarr: i might have been running virtualbox im sure of that
suokko: lucky you didn't hit that 52ms read locked mutex with write attampt ;)
xming: oh I don't have disk swap, and I don't think there is a lot disk i/o while playing ut2004
spstarr: in this test, im not, so we have consistant results/
evil_core: error: Untracked working tree file 'drivers/gpu/drm/nouveau/nouveau_grctx.c' would be overwritten by merge. Aborting
suokko: evil_core: What are you trying to merge?
evil_core: drm-2.6
evil_core: I want to get copy of drm-radeontesting
evil_core: to refresh it
suokko: evil_core: better use the branch as easy if there is conflicts
evil_core: dont remember that I were apllying patches/changing filesi n that dir
evil_core: suokko: what cmd?
evil_core: * drm-radeon-testing, its git branch, I got also master
spstarr: stopping trace
spstarr: suokko: here comes data
suokko: evil_core: git reset --hard origin/drm-radeon-testing
Vhozard: Ivanovic agd5f I said which card already: a HD4850. CPU I dint tell: Intel E8400
suokko: That way you get your branch to same state as remote branch is
spstarr: suokko: http://www.sh0n.net/spstarr/radeon/noirq-trace.txt
evil_core: # git reset --hard origin/drm-radeon-testing
evil_core: HEAD is now at 9666baa drm/radeon/kms: clean up some low-hanging magic numbers
evil_core: [root@sinistar drm-2.6]# git pull
evil_core: Already up-to-date.
evil_core: it means all right?
agd5f: Vhozard: yes, that card works fine
evil_core: it didnt took any time, so its innormal for me ;)
xming: Already up-to-date!!!! You are at the last commit
evil_core: ok, thx
evil_core: but what should I downgrade to get VSync?
Ivanovic: Vhozard: and now just make sure that you are using the latest mesa git version with a recent kernel (like 2.6.33-rc7) as well as some really new libdrm (plus xf86-video-radeon) and you should have usable 3D
suokko: spstarr: You captured one bad delay. 943 microt seconds is quite long time without irqs
spstarr: suokko: and my GPU locked up im back..
suokko: spstarr: But that trace was very short only
spstarr: heh
spstarr: suokko: it was about 2 mins
spstarr: i can re-run longer
suokko: I think there is something that needs to be configured differently
spstarr: the screen just goes blank and i have to do a hard power off
suokko: evil_core: mesa has the bug
spstarr: suokko: i can give you all the data you want, but i just need to know what :)
evil_core: suokko: and it causes Xv flickering?
Vhozard: agd5f Ivanovic Thank you both very much!
suokko: spstarr: First of all you should probaly upload the lock stat to the bug report. It should help a lot in fixing the worts latencies
spstarr: suokko: doing so now
suokko: I don't know how to use the kernel tracer to collect all the information what we need. So I have to first find time to play with it
spstarr: ok
spstarr: i will keep all of that compiled in so we can turn it on on demand
spstarr: crashed again
spstarr: suokko: I can trigger GPU lockup with firefox and rapidly scrolling though my own bug report
spstarr: twice now.. heh
spstarr: back into UMS right now
evil_core: UMS means nonKMS or non-gallium?
spstarr: Usermode Setting
spstarr: ie, old VT switch mechanism
spstarr: so non-KMS
xming: I never got ums working, it hangs after being 2 sec in X
spstarr: that shouldn't be...
xming: never bothered to look into it
spstarr: xming: what GPU? I've been using UMS more than KMS with my r6xx
xming: 3850/rv670
evil_core: but KMS is better
xming: it's better, but slower for the moment
evil_core: or maybe was until VSync has been broken :/
spstarr: suokko: another curious thing noticed
spstarr: with KMS scupties take longer to render vs UMS
evil_core: not for me
spstarr: basically, scupted primitives
evil_core: I got r500, and more wine games were running in KMS, and many quicker
xming: spstarr: with kms and kde4 composit on, I can't get the logout/shutdown/restart dialog to display, you don't happen to know a solution?
evil_core: compositing sucks from definition
evil_core: less battery, less FPS and less RAM
spstarr: i dont use composite right now, i do see dialog, but i use KDE 4.5/trunk
xming: spstarr: with composite off, I also see the dialogs (kde4.3)
spstarr: im not sure what the official term for 'scupted primitives' are called for graphics
xming: I am a sucker for expose
spstarr: but they are primitives designed from textures from the colour
spstarr: http://halfmanhalfdog.com/wp-content/gallery/blender/blend3.jpg
suokko: spstarr: nurbs?
spstarr: yes
spstarr: nurbs
suokko: http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline :)
spstarr: second life calls them scupted primitives, for some reason
spstarr: like OpenGL teapot is a nurb i think?
spstarr: 1 primitive to make a shape
FIReun: I'm still looking for a fix for my laggy mouse in my 3d games (which are fast now!)
spstarr: yes
spstarr: NURBS: NURBS modelling uses series of curved splines to define the shape of an object and are excellent for smooth, organic shapes. The methodology behind sculpted prims is very largely based on them.
spstarr: thats what they are basically
spstarr: im amazed how you can make something so complex from 1 primitive with nurbs
suokko: FIReun: I suspect your CPU is running way too fast for GPU and you have very long rendering queue. But that is just speculation
xming: spstarr: oh they do appear, I just have to wait like 9 seconds, everything is stalled, then after it appears eveything is stalled again for another +/- 10 sec
spstarr: mine look sort of deformed
spstarr: they will eventually render properly
suokko: spstarr: I once had fun implementing non-uniform spline with javascript to move a image in a web page :)
spstarr: while I can make simple primitives nerbs seem painful to make
spstarr: ooh very nice
FIReun: suokko: hmm, any way to test this theory? make rendering changes to force slower cpu?
spstarr: i dont quite understand how nurbs work and how colours influence the shaping of a nurb
suokko: FIReun: Which card you have?
FIReun: suokko: I'm running max res, 32bit -- rs480
spstarr: http://download.blender.org/documentation/oldsite/oldsite.blender3d.org/117_Blender%20tutorial%20Fun%20with%20nurbs.html
FIReun: suokko: fps looks reasonable, but mouse is lagging behind in put
suokko: I think I can hack a test case for you which limits rendering speed
suokko: That means your fps drops maybe 20& but cpu is never much before GPU
FIReun: suokko: I tried export SDL_VIDEO_X11_DGAMOUSE="0" which was a fix in the past for this kind of activity
FIReun: suokko: my fps is only in the 30s as it is
suokko: 20% that is
FIReun: ah
FIReun: I just wish I could prioritize mouse over gpu
FIReun: s/gpu/render
spstarr: looking at that tutorial I assume the end resume is just using one primitive to render that face
spstarr: resume->result
FIReun: suokko: hmm, may also not be polling my mouse fast enough either, have to look at polling freq again
xming: found the problem, it's the "logout" desaturate effect
suokko: FIReun: http://sprunge.us/NQbg
suokko: FIReun: Do you have the input delay in all games?
FIReun: I only have one to test with atm
FIReun: ioquake based
Ivanovic: you could probably install the ut2004 demo
Ivanovic: that is clearly a different engine
suokko: I have seen it only in saurbraten menus (in-game is smooth)
Ivanovic: ;)
FIReun: I'm running into free hd space at the moment with two setups installed
FIReun: I'm about this | | close to making the new kms setup perm
suokko: yes. I have input elay only with simple scenes like menus
FIReun: not totally sure yet the best way to make that happen either, should I "dd" and then resize the partition, or is "cp -R" gonna catch everything (perms and /proc stuff)
suokko: FIReun: tar czf
FIReun: /boot and /home are seperate partitions, just the system partition being copied over
evil_core: it looks like I get VSync in quake3 in KMS, but not in mplayer(Xv)
suokko: tar has also some backup switched but I never did use them
Ivanovic: i'd use partimage, works nicely if the target partition will be larger than the current source
Ivanovic: (as in put the backup tar onto some external drive)
suokko: evil_core: sounds like you have some else bug there. Are you sure it is missing vsync really?
FIReun: Ivanovic: I'm not backing up tho, just taking a new install on one partition and using it to replace the old one
FIReun: ext2->ext3
evil_core: suokko: yes, I started now nonKMS and quake3 tears horribly
evil_core: in KMS maybe it wasnt synced, but not so visible
FIReun: suokko: hmm, lsmod |grep mouse shows psmouse.ko -- but its a usb mouse on a machine with a synaptics pad?
evil_core: I got r500 and master drm/xf86-video-ati/mea
evil_core: mesa*
FIReun: I get a weird ofset line about a quarter of the way down
FIReun: I'd say its tearing, but a very thin one in the same spot almost all the time
FIReun: like maybe 10px are offset or something
FIReun: otherwise mplayer may not have looked this good before
FIReun: fast, no artifacts, low overhead
FIReun: (well, the weird mirror lines)
suokko: evil_core: Can you pastebin your xor.log and xvinfo?
evil_core: sure
evil_core: I found that I got less skybugs in UMS
suokko: I could even play some test images without tearing that used to tear when I run the cpu in powersave mode
evil_core: it doesnt makes sense to me ;)
evil_core: but I am using ondemand now, maybe it broken something
evil_core: before there were performance probably(default)
evil_core: but you can share your test images
suokko: evil_core: They won't be any problem your cpu/gpu. I have old system :)
suokko: I'm jsut searching for some HD clips for tearing test
FIReun: brb, xrestart
evil_core: suokko: http://carme.pld-linux.org/~evil/varia/dri_report/
suokko: evil_core: You had quite a lot config optinos in xorg.conf. But I couldn't see anything what is broken
evil_core: suokko: somebody told that Mesa is broken in master
evil_core: .join #pam
airlied: agd5f: on my X600 I find two devices on the mm i2c bus \o/
suokko: evil_core: But only affects if your window manager is using opengl
evil_core: suokko: its wmaker, so no way
suokko: evil_core: I can even play 720p video in mplayer without any tearing
agd5f: airlied: are there actually devices on it?
airlied: agd5f: yeah its an AIW of some sort
agd5f: sweet!
airlied: agd5f: http://people.freedesktop.org/~airlied/0001-drm-radeon-kms-expose-mm-i2c-bus-to-userspace-for-te.patch
agd5f: airlied: now we just need a way to hide the internal bit-bang buses
airlied: is the hacked up patch
spstarr: eek
spstarr: http://cgit.freedesktop.org/mesa/mesa/commit/?id=8b0b5ace4871847f7d8608e0ce6f67b7c5731ea7
spstarr: oh
spstarr: wouldn't have noticed
evil_core: suokko: r500 never got VSync in UMS
agd5f: evil_core: yes it did
evil_core: hmm..somebody told me I need KMS
agd5f: airlied: I was thinking perhaps we should just walk the i2c gpio table and add all the i2c buses and then just add pointers from the connectors and such
agd5f: evil_core: for r6xx+ you do
evil_core: I got r500
agd5f: evil_core: the glx vsync stuff is broken at the moment in mesa master due to the intel dri2 swap buffers merge
agd5f: at least with kms
airlied: agd5f: yeah that might make sense to expose them all
evil_core: I got XV VSync only withy KMS in the past, and none at the monent with both :/
agd5f: airlied: then the mutexes and locking would be easier
agd5f: evil_core: xv vsync only works if you are not using a compositor
evil_core: I am not
suokko: I think wmaker did do some stuff that compositors do when I saw it last time
evil_core: or maybe its not with KMS now
evil_core: its not with KMS
Hackus: Dave do you have to buy your own GPU's to write and test against or does redhat buy you guys a couple of GPU's to work on?
spstarr: airlied: We've determined that there are ugly lock stalls causing the issues in KMS.
evil_core: no, I hate it. even 1080p dytarted working dmoothly noew
evil_core: but hour ago they werent
evil_core: its rarely working smooth. when it lags, then Xorg uses 95% CPU, when its working smooth, then Xorg uses ~20% CPU, and mplayer uses 80%
evil_core: its random
evil_core: when it works smooth, I can play simoultanously 2 1080p at once
airlied: Hackus: AMD mostly buy them
airlied: though some of them are my own ebay specials and some are Red Hat ones
evil_core: hmm...iceweasel is causing that
evil_core: its not non-vsync, but glitches
evil_core: like with dynclcks
evil_core: and slowness
BioTube: iceweasel/firefox seems to cause all sorts of slowdowns
suokko: evil_core: wmaker is causing clear tearing for me. None in GNOME
BioTube: maybe it's connected to why my box loves to lock up
evil_core: port js to w3m and animated gif :/
suokko: evil_core: wmaker is causing clear tearing for me. None in GNOME
suokko: So it is somehow wmaker related problem. I just don't know how
evil_core: http://xwinman.org/vote.php
suokko: and again wifi reconnect :/
evil_core: nobofy uses GNOME ;)
Jonimus: I'm about to build kernel 2.6.33-rc7 are there any patches that you guys would like tested?
evil_core: nobody*
Jonimus: What is so great about WMaker?
Jonimus: I mean if its number one on that page it must be for a reason
Jonimus: I mean it looks rather plan to me in the screen shots...
Jonimus: well w/e back on topic
Jonimus: so I assume there are no new kernel patches that I should be testing yet?
adamk: Some people like plain. Most patches go directly into one of the git trees for testing.
Jonimus: ahh kk
airlied: Jonimus: drm-radeon-testing branch has loits
adamk: I have a hard time keeping the branches straight ever since one became three :-)
airlied: forgot to make blog posting public
airlied: doh
Jonimus: hmm, ok, I might try that out then, I'm currently running the rc7 but I might try one of the git branches then
airlied: just pull that into -rc7
airlied: it'll just get all the radeon patches
Jonimus: hmm ok, well I'll try that in a bit
Ronis_BR: airlied: hey fellow
Ronis_BR: airlied: the hibernation is working now with KMS
Ronis_BR: airlied: don't know if you guys did something or if it was related with KDE
markinfo: why with "linux //vmlinuz-2.6.32.markinfo root=/dev/mapper/linuxen-debian--xfce ro quiet radeon.modeset=1" in grub2 does not want start kernel in graphic mode? is the code needed for KMS completely in kernel? Because I have compiled with CONFIG_DRM_RADEON=m and boot partition is on ext3, but system resides on raid0 which is started with the help of initrd. Later "modprobe radeon" works good.
markinfo: what is needed to start immediately with KMS?
airlied: Ronis_BR: what gpu was it again?
BioTube: markinfo: you need to build the module directly into the kernel with the requisite firmware
Ronis_BR: R700
Ronis_BR: airlied: R700
airlied: hmm notthing springs to mind ;-)
Ronis_BR: maybe it was kde related
Ronis_BR: because I'm using 4.4 know
markinfo: Biotube should be set - CONFIG_DRM_RADEON=y, CONFIG_FIRMWARE_IN_KERNEL=y, ... and what about: CONFIG_FB_RADEON=m But here to put firmware for radeon?
Jonimus: airlied: where will I see more powersave and performance changes, userspace or kernel?
BioTube: markinfo: CONFIG_FB_RADEON should be set to 'n'
airlied: Jonimus: all kernel
Jonimus: ahh kk
BioTube: markinfo: and for r600/r700, you need to include the correct rlc firmware
Jonimus: then I'll def build a kernel form git later tonight
BioTube: must be included as radeon/Rx00_rlc.bin to work
markinfo: I have r520 ... where to put "radeon/Rx00_rlc.bin" ?
airlied: don't need it for r520]
FIReun: sighs
markinfo: airlied, from dmesg: [ 2190.938170] [drm] Loading R500 Microcode
markinfo: [ 2190.938173] platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
BioTube: markinfo: it'll be included automagically by the switch
BioTube: only the rlc firmware for r600/r700 is new enough to be forbidden from the entering the tree
markinfo: But if i compile it in the kernel - it can not be unloaded? sometimes after shutdown of xserver flickers the monitor.
BioTube: right - builtin modules are ununloadable
Jonimus: airlied: stupid question but do you have a link to where I can get that branch I'm blanking
airlied: http://airlied.livejournal.com/
airlied: Jonimus: git utl is in there
Jonimus: thanks airlied
suokko: This will sounds like impossible but xv do tear if I don't run something ogl first.
suokko: saurbraten first for a few seconds and then all xv tear is gone
suokko: while running from clean restart xv tears very badly
spstarr: hmm
airlied: suokko: wierd, that'll be fun to figuire out ;)
suokko: yes. Which state it is that prevents tearing and is not handled by ddx
airlied: agd5f: wierd my rv515 is acting fine now, it might be the udelay change I made fixes it somehow
Ronis_BR: airlied: I have just tested
airlied: suokko: do simple apps like trivail/clear or trivial/tri make it happen?
spstarr: glisse: When you get time, please look at https://bugs.freedesktop.org/show_bug.cgi?id=26087 I have some updated lock stats if any of that data helps you.
spstarr: glisse: this is using your new CS checker code.
airlied: spstarr: I've remove that now
airlied: until glisse updates it
Ronis_BR: airlied: man, you really don't know why? :D
bryceh: agd5f, would you mind taking a look at http://bugs.freedesktop.org/show_bug.cgi?id=26302 ? I've had a bunch of people inquiring about that problem.
suokko: airlied: Too bad my card hangs if I try to dump the registers. Would be easiest just to see differences before and after saurbraten
airlied: bryceh: you should maybe get some of the r100 fixes from 2.6.33
airlied: 47381156a8f0d793bacfa346cc4cc515399525f7 will help a bit
bryceh: airlied, ok thanks
airlied: but you might need some other bits around it
airlied: if you are really intent on shipping 2.6.32 with KMS enabled it would be nice to backport 2.6.33 radeon into it
airlied: otherwise I doubt we can really help you
airlied: though I expect there are still some r100 issues
airlied: its just not high on anyone's priority list
bryceh: I'll mention that to the kernel team
Ronis_BR: airlied: that's make me afraid because it may be broken again on the next build :D
suokko: evil_core: ping
spstarr: airlied: ok
DanaG: www.csc.calpoly.edu/~dgoyette/Screenshot.png
DanaG: interesting... that's what I got on resume from suspend, with radeon kms.
airlied: DanaG: what card?
spstarr: airlied: i haven't crashed his code since though, that may have been a fluke from all the disk i/o swapping
DanaG: RV635. It's set not to lock on resume.
DanaG: And as I moved around, it "cleared" the garbage and redrew what was supposed to be there.
DanaG: Also odd: resume took 11 seconds, according to dmesg; on the Intel netbook, it feels more like 0.5 seconds.
spstarr: hmm
spstarr: drm/radeon/kms: set gart pages to invalid on unbind
Ronis_BR: is anyone getting small fonts corruption with R700+KMS?
spstarr: airlied: this is for IGP only?
airlied: spstarr: what is?
spstarr: drm/radeon/kms: set gart pages to invalid on unbind
bryceh: airlied, will help be provided for the 2.6.33 radeon bits once development focus has moved to 2.6.34?
airlied: bryceh: yes as we'll be maintaining them for a while longer
AndrewR: suokko, may be it was delayed vblank in drm? powersaving or something like this ... (xv tearing gone afre OpnGL app run)
airlied: bryceh: like if you ship 2.6.32 bits please tuirn off KMS
airlied: I'd rather not be flooded with users complainging in here
markinfo: do i need FB_RADEON_BACKLIGHT ? it is under Support for frame buffer devices (FB [=y])
markinfo: for radeon KMS
AndrewR: suokko, delayed - as not fire interrupts at module load/init, wait until someone starts to use it
AndrewR: suokko, but may be this functionality was removed, not sure
agd5f: suokko: 3d state has nothing to do with the xv vsync stuff. the driver just inserts a vline stall before the rendering
agd5f: however, if you are using the glx sync stuff, you need to enable vblanks via the drm first
bryceh: airlied, very well
suokko: agd5f: What does memmove do for xv?
suokko: Because when there is problem memmove shows in profile with 40% share
agd5f: bryceh: yeah, you really need to backport the 2.6.33 bits
MostAwesomeDude: suokko: When DMA doesn't work, you need to memcpy/memmove the texture out to VRAM.
agd5f: suokko: most be something in the xserver. there's no memmove in the driver code iirc
bryceh: agd5f, sorry I've been too swamped with work to check in on status
airlied: remembers to fix stupid white borders
suokko: I didn't have debug symbols in radeon_drv.so but somehow kernel entry for memmove was called if there was tearing
suokko: So resultion is that dma doesn't work unless I run some gl stuff
bryceh: agd5f, is a newer libdrm/mesa needed as well or will it work with 2.4.17 and 7.7?
MostAwesomeDude: suokko: memmove in ther kernel?
MostAwesomeDude: Might be a problem with TTM somehow.
ymanton: hm, what am i missing when libGL tries to open swrast_dri instead of a hw driver
suokko: Wait not in kernel. There is just profiling entry for kernel under memmove
agd5f: suokko: figure out where the memmove is coming from
MostAwesomeDude: ymanton: DRI name? Check xdriinfo and also LIBGL_DEBUG=verbose info
agd5f: bryceh: mesa 7.7 is fine
agd5f: we should probably roll a libdrm 2.4.18 though
ymanton: MostAwesomeDude: yeah, i thought the ddx was supposed to provide that. xdriinfo says: Screen 0: not direct rendering capable.
airlied: bryceh: 7.7 + the fixes on the branch
airlied: no 7.7 the release
airlied: agd5f: yeah might be an idea
MostAwesomeDude: ymanton: Sounds like the DDX isn't setting you up properly.
agd5f: althought it looks like the radeon interface hasn't changed since 2.4.17
agd5f: as long as you configure with --enable-experimental-api
agd5f: radeon-api
BioTube: the fact that it builds by default isn't enough?
agd5f: BioTube: not in 2.4.17
BioTube: agd5f: my point was that that switch has since been flipped
agd5f: BioTube: yes, but if a distro ships 2.4.17 they need to enable it
ymanton: this is -ati from git, i see libdri,libdri2,libglx all being loaded...
MostAwesomeDude: ymanton: Oh, you're on a radeon.
bryceh: confflags += --enable-radeon-experimental-api
bryceh: RADEON = yes
ymanton: MostAwesomeDude: yes, unfamiliar territory
bryceh: looks like we're fine
spstarr: suokko: im getting swap issues now
MostAwesomeDude: ymanton: Check Xorg log. The DDX is fairly verbose about why DRI fails.
agd5f: bryceh: might want to get 2.4.18 when it gets released since there are some fixes in the common drm mode code IIRC.
agd5f: but 2.4.17 should be ok for radeon kms
bryceh: agd5f, ok thanks. We've suffered from regressions when updating to newer libdrm in the past, so have to be careful updating it, but I'll put it on the todo list to look at
spstarr: capturing the lock info
airlied: bryceh: pretend its a binary driver :-)
ymanton: the only thing of note i see is: (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
bryceh: airlied, what do you mean?
airlied: bryceh: just upgrade and take the pain ;-)
bryceh: airlied, I actually care about -ati
ymanton: and nothing interesting in the kernel log
agd5f: ymanton: check dmesg and see what failed
airlied: I don't think I've seen any libdrm issues outside the experimental bits though
spstarr: suokko: this being non-kms right now
airlied: and well experimental is there for a reason
agd5f: ymanton: what card are you using?
ymanton: agd5f: mobile 3470
agd5f: ymanton: what kernel?
ymanton: week old linus
agd5f: ymanton: can you pastebin your dmesg?
spstarr: suokko: generic_file_aio_write+0x4c/0xad yeah that is like before
spstarr: suokko: but in UMS, no radeon locks came up at all listed.
airlied: spstarr: no locks in the kernel
airlied: in UMS since its *U*
airlied: not *K*
spstarr: airlied: but we still go though the drm to the GPU even with UMS?
airlied: spstarr: it just suses the BKL
spstarr: ahh ok big kernel lock
ymanton: agd5f: http://pastebin.com/mb3c1e84
agd5f: ymanton: Feb 8 20:44:02 novo kernel: [ 6.079808] [drm:r600_startup] *ERROR* Failed to load firmware!
airlied: lols I had a memset to make the borders whit
agd5f: ymanton: you need the rlc firmware for the irq controller
agd5f: ymanton: http://people.freedesktop.org/~agd5f/radeon_ucode/
airlied: bryceh: oh amke sure you get the RLC firmware if you backport 2.6.33
ymanton: agd5f: ah, didnt spot that
agd5f: ymanton: put it in /lib/firmware/radeon/ or wherever your kernel looks
spstarr: agd5f: what does the RLC stand for?
agd5f: spstarr: run list controller or something like that. I don't remember exactly.
spstarr: oh ok
dougmencken: hi, is there any driver (except fbdev) for my card : 0001:10:15.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
agd5f: dougmencken: it's supported by xf86-video-ati
agd5f: tv
dougmencken: how to know if any 2d (at least) accel works or not (not using common sense)
dougmencken: $ xdriinfo --> Screen 0: not direct rendering capable.
dougmencken: $ xvinfo --> X-Video Extension version 2.2 screen #0 no adaptors present
airlied: dougmencken: pastebin the /var/log/Xorg.0.log
dougmencken: http://pastebin.com/m288e56b4
MostAwesomeDude: dougmencken: You don't have xf86-video-ati installed.
dougmencken: I'm using Fedora 12 repos and so the kernel too
dougmencken: now googling xf86-video-ati
suokko: No luck. I can't get sysprof to load the debug symbols of ddx
dougmencken: trying to build it; ./autogen.sh --> configure.ac:33: error: must install xorg-macros 1.3 or later before running autoconf/autogen
ymanton: i was having better luck without the rlc fw, now i get a hard lock
spstarr: yeah there is something bad in the CS checker airlied at least in UMS mode.. i never can test with KMS as GPU locks up as a different issue.
spstarr: swapping like mad and im running out of ram frankly
spstarr: i have 1GB free
spstarr: removes it from his tree again for now
dougmencken: ./configure: line 13001: syntax error near unexpected token `XINERAMA,' << still can't ./autogen.sh ; are there any instructions on how to build and install xf86-video-ati?
MostAwesomeDude: dougmencken: You mentioned F12. Why aren't you just using F12 repos?
dougmencken: yum search xf86-video-ati prints "Warning: No matches found for: xf86-video-ati"
MostAwesomeDude: It's called xorg-x11-drv-ati.
dougmencken: ok, found it, trying to yum install
spstarr: ah ok you removed it already from git
dougmencken: installed it; so now I need to reboot or just logging out and startx will be enough?
BioTube: restarting X should suffice
MostAwesomeDude: Restarting X should be sufficient in your case.
soreau: MostAwesomeDude: I know at least alpha blur was broken by the MRT addition, here on rv350
dougmencken: thank you for assistance
MostAwesomeDude: soreau: Even more broken? :3
soreau: MostAwesomeDude: By broken, I mean it causes real-transparent terminals to be fully opaque and for windows making transparent with OBS (ie. Alt+Scroll) they actually dim darker and darker until the last 10-15% then go from dark all the way to transparent
soreau: MostAwesomeDude: This is of course, the only real valid method of alpha blur, gaussian
soreau: +with somewhere in there
dougmencken: hi again, can't start X now
dougmencken: xinit: No such file or directory (errno 2): unable to connect to X server
dougmencken: from log: (II) LoadModule: "vesa" (WW) Warning, couldn't open module vesa (II) UnloadModule: "vesa" (EE) Failed to load module "vesa" (module does not exist, 0) (EE) No drivers available. Fatal server error: no screens found
soreau: dougmencken: Do you have vesa set as the driver in xorg.conf, by chance?
soreau: You should probably try without an xorg.conf, so it will automatically choose radeon
dougmencken: oh, really, Driver "vesa"; so I rename xorg.conf to something and try again
soreau: That's the first thing I would try
dougmencken: quit
spstarr: erm
spstarr: there is a conflict with atombios.h
spstarr: and linux-2.6 from linus
spstarr: fixes locally
spstarr: oh whitespace madness
dougmencken: now from X.org again ;) well, how to test new driver's capabilities? and why are supertux and globulation2 so slow (1 frame in 2-3 seconds)?
soreau: dougmencken: First, what is the output of 'glxinfo|grep renderer'?
dougmencken: OpenGL renderer string: Software Rasterizer
soreau: There is your problem. You don't have 3D working
soreau: Can you pastebin your X log?
dougmencken: okay
dougmencken: http://pastebin.com/m542293d0
airlied: dougmencken: is radeon loaded in the kernel?
airlied: lsmod | grep radeon
dougmencken: 4 lines
airlied: ah ppc I wonder if something is off there
airlied: can you pastebin dmesg
airlied: ?
airlied: rv100 is really old so odn't expect much out of it
dougmencken: vgaarb: invalid PCI address! \n [drm] Initialized drm 1.1.0 20060810 \n [drm] radeon defaulting to userspace modesetting. \n [drm] Initialized radeon 1.31.0 20080528 for 0001:10:15.0 on minor 0 \n vgaarb: invalid PCI address! (4 times)
dougmencken: (the last lines of dmesg; others are unrealted, I think)
airlied: wierd no idea why its doing user modesetting by default
MostAwesomeDude: stabs in the dark
MostAwesomeDude: dougmencken: Did you build this kernel yourself?
airlied: doesn't look like it
dougmencken: now, it's 2.6.31.12-174.2.3.fc12.ppc from Fedora
soreau: That is exactly what I was about to ask
soreau: and I am wondering, why it is choosing xaa by default
airlied: dougmencken: boot with radeon.modeset=1 on the command line
soreau: sounds like old ddx somehow
airlied: no low memory defaults to XAA in UMS
MostAwesomeDude: soreau: Or old xorg.conf.
soreau: ah.
soreau: MostAwesomeDude: No, I had him load without an x conf
MostAwesomeDude: soreau: Ah.
dougmencken: so need I to reboot?
soreau: but I am also curious, why the kernel params appear before the root=UUID ect too
soreau: dougmencken: Do you know how to edit the kernel parameters when you boot?
dougmencken: appending them, like 'quiet' and so
soreau: Yes. append radeon.modeset=1
soreau: and we will see what happens
dougmencken: okay, so cul :)
dougmencken: done it
dougmencken: [drm] Initialized drm 1.1.0 20060810 \n [drm] radeon kernel modesetting enabled. \n vgaarb: invalid PCI address!
dougmencken: $ glxinfo|grep renderer --> OpenGL renderer string: Software Rasterizer
airlied: now get the xorg log ;-)
dougmencken: http://pastebin.com/m192cf274
airlied: still no KMS, pastebin dmesg
dougmencken: full dmesg output: http://pastebin.com/m77887967
airlied: dougmencken: hmm I thought we'd killed radeonfb
airlied: you'll need to add video=ofonly to the command line also
dougmencken: so reboot with 'radeon.modeset=1 video=ofonly' appended?
airlied: yup
dougmencken: btw, what does it all mean? 'modeset' and 'ofonly'?
_KAMI_: hi I just tried kms again and it is still not workink for me
_KAMI_: on ubuntu
Jonimus: I think I know the answer to this but is there a way to have a different TTY on different outputs of my display?
Jonimus: or is X the only way to have the kernel not be in mirror mode?
airlied: dougmencken: ofonly makes powerpc not use the old radeonfb driver
airlied: and modeset turns on the new driver
_KAMI_: I git pilled and compiled ddx, libdrm, mesa again
_KAMI_: pull
_KAMI_: and started ubuntu drm-next kernel
dougmencken: done it; what info to provide?
soreau: Same as before, check glxinfo first
soreau: if it's still software rasterizer, pastebin x log
dougmencken: yep, software; dmesg: http://pastebin.com/m2f64ade9 ; /var/log/Xorg.0.log: http://pastebin.com/m55f09834
soreau: It's still loading radeonfb
soreau: Isn't there a way to blacklist modules on fedora or something?
dougmencken: doesn't know
soreau: As a brutal hack, you could just find radeonfb.ko and get rid of it
dougmencken: inside '/lib/modules/2.6.31.12-174.2.3.fc12.ppc'?
dougmencken: can't find it; CONFIG_FB_RADEON=y (not module)
soreau: That's suspicious.. airlied ?
dougmencken: and there's no single "radeonfb" string in dmesg output and xorg-log
soreau: in the dmesg you posted, it's listed several times
soreau: anyway, you don't want radeonfb loading because it messes things up
soreau: try to get a newer kernel if you can, configured without this option
soreau: I have to run out for a bit, bbl
airlied: dougmencken: I don't see video=ofonly on that command line
soreau: has some feeling he may have posted the same logs as last boot, somehow
dougmencken: http://pastebin.com/m10bd0932 << correct dmesg, not the old one
airlied: hmm just fixed that bug upstream
dougmencken: what was/is wrong?
airlied: bios bug causes the driver to oops
airlied: how many outputs on the card?
dougmencken: let me look; three: VGA, ADC and S-Video
airlied: hmm the ADC must be the unknown connector
dougmencken: I'm using VGA
airlied: it might also be a ppc card we have no support for
dougmencken: ?
airlied: its an apple card?
dougmencken: I bought this machine with this card
airlied: we normally have to had support explicitly on a card by card basis for Apple/ppc cards
dougmencken: all that I know is that this card has PEF "Joy!peffpwpc" drivers for Mac OS classic inside it
dougmencken: here's a dump of OF's device tree: http://manulix.wikidot.com/hidden:device-tree-my_G4
airlied: can you get the bios from it? cd /sys/bus/pci/devices/
airlied: echo 1 > rom ; cat rom > /tmp/rom ; echo 0 > rom
airlied: I suspect you'll have to build your own kernel to get something useful anytime quickly. I think there is a few things wrong with the new driver on older ppc
dougmencken: well, never built kernels for fedora (only for debian); so I'm inside /sys/bus/pci/devices/0001:10:15.0, there's rom file already (it's binary); need I to overwrie it?
airlied: echoing won't overwrite it
airlied: but no need it you can read it
airlied: can you send me a copy of it to airlied @ redhat.com
dougmencken: tar cjf it?
airlied: or as-is shouldn't be morethan 64k
dougmencken: 122880 bytes, actually
dougmencken: airlied, you can wget it directly from me via http, address http://upyach.co.cc/rom
_KAMI_: hi!
_KAMI_: platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
_KAMI_: r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
_KAMI_: I got this with 2.6.33 rc7 however I downloaded the additional firmwares
DanaG: weird... somehow I have xorg overlapped with my efi framebuffer console.... and anything I type is going BOTH to xorg AND to console!
_KAMI_: #/lib/firmware/2.6.33-020633rc7-generic/radeon$ ls -l R600_rlc.bin
_KAMI_: -r--r--r-- 1 root root 3072 2009-12-25 12:27 R600_rlc.bin
DanaG: www.csc.calpoly.edu/~dgoyette/Screenshot-1.png
_KAMI_: do you have ide what is going wrong?
soreau: _KAMI_: Is the kernel configged with appropriate firmware options and the firmware is installed to the correct location?
DanaG: weird... it thinks fgconsole is tty1.
_KAMI_: soreau: yeah the firmware installed to the correct location
_KAMI_: /lib/firmware/2.6.33-020633rc7-generic/radeon
_KAMI_: what is kernel configged with appropriate firmware options? It is a precompiled kernel by ubuntu team
_KAMI_: from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/
_KAMI_: soreau: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/BUILD.LOG
spstarr: ok, im now in drm-radeon-testing w/ fixes to atombios.h
spstarr: so i should not see swapping since CS checker is removed now
airlied: dougmencken: hmm so the rom isn't standard, not sure why we fail to detect that
soreau: _KAMI_: I believe if you use a initrd, you need to set it up in there too
airlied: dougmencken: so I think if you'd like to get it working we'll have to test with a kernel
soreau: I don't know the specifics though, maybe you can check the firmware section on the wiki in the topic here
dougmencken: what shall I do?
airlied: dougmencken: if you want to clone a kernel from git (Linus latest will do) I can send some patches to test
airlied: otherwise we'll be doing it via Feodra kernels which take a long time to build for me
dougmencken: I already have master branch and can git pull any time :)
airlied: cool so if you can get a master tree to boot make sure you turn off CONFIG_FB_RADEON and turn on CONFIG_DRM_RADEON_KMS
airlied: I'll send you a patch to try and get going
dougmencken: okay
_KAMI_: soreau: can you help me how to archieve it?
airlied: dougmencken: http://people.freedesktop.org/~airlied/scratch/ppc/
airlied: first patch is in there
dougmencken: getting it
soreau: _KAMI_: I don't know the specifics though, maybe you can check the firmware section on the wiki in the topic here
spstarr: bridgman: expect 5-10cm starting late tomorrow afternoon/early evening
spstarr: bridgman: It would not surprise me if we do get 5-12cm or only 5cm