EruditeHermit: airlied, are you sure that drm-linus builds?
airlied: EruditeHermit: it did when I sent it t o him
airlied: EruditeHermit: did you git checout the drm-linus branch?
EruditeHermit: yep
EruditeHermit: its ok some android driver was not building
EruditeHermit: I just removed it
EruditeHermit: from the config
EruditeHermit: airlied, is it a 2.6.29 kernel in there?
airlied: EruditeHermit: no
airlied: hence why I asked if you checked out the branch
EruditeHermit: erk
EruditeHermit: which branch is it?
EruditeHermit: drm-linus
EruditeHermit: hmm
EruditeHermit: sorry a bit rusty with the git commands
EruditeHermit: I did
EruditeHermit: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
EruditeHermit: then what branch do I checkout?
EruditeHermit: git checkout drm-linus
EruditeHermit: ?
airlied: git checkout -b drm-linus origin/drm-linus
EruditeHermit: ok
EruditeHermit: building again
EruditeHermit: its not so bad
EruditeHermit: its building on a VM with many cores so it should be faster
EruditeHermit: err on a computer in a VM with many cores
EruditeHermit: not the real machine which is really slow
EruditeHermit: hmm
EruditeHermit: it still says 2.6.29-rc2
EruditeHermit: oh weird
hifi: why would a VM inside a single core machine be any faster than the host itself?
EruditeHermit: hifi, its a VM inside a different machine
EruditeHermit: which has 8 cores
EruditeHermit: ok figured it out
EruditeHermit: ignore my stupidity
EruditeHermit: building again =)
spstarr: a VM would have some overhead vs a native host
EruditeHermit: spstarr, yes but there isn't a way around that
EruditeHermit: a VM on an 8 core machine is better than a native one core machine that is approaching its 6th birthday
EruditeHermit: =)
spstarr: yes
spstarr: nice
spstarr: KDE recognizes what KMS is spitting out
spstarr: DVI-0, LVDS (Connected), DP, VGA-0 ports
twnqx: DisplayPort-0 ?
twnqx: so there's a naming difference between KMS and UMS? :P
spstarr: 'DP'
spstarr: i dont know why it just shows DP not DisplayPort-0 name
spstarr: assuming the name is being picked up from KMS <-> DDX ?
spstarr: XRandR shows 'DP' disconnected
spstarr: if UMS and KMS show different name maybe a bug to log?
twnqx: DisplayPort-0 disconnected (normal left inverted right x axis y axis)
twnqx: (from xrandr -q)
spstarr: DP disconnected (normal left inverted right x axis y axis)
spstarr: maybe should be fixed
jcristau: yes there's a naming difference between ums and kms, and it's not a bug.
spstarr: oh
spstarr: well shouldn't it be DP-0 though?
spstarr: if you had two display ports
spstarr: not on a laptop but say a dual-headed PCIe card or such
spstarr: you have DVI-0, LVDS (LCD screen), DP, VGA-0
spstarr: AFAIK, the Lenovo has a VGA-0 connector on BOTH the laptop and docking station but they are pass-though, same for DVI connector
spstarr: so not sure why the inconsistancy with DP vs DVI-0 / VGA-0 ?
EruditeHermit: airlied, its a 2.6.33 kernel right?
Tommeh: Morning all
airlied: EruditeHermit: yup
Tommeh: FYI, to all those that helped with my KMS/3D problems. I installed 2.6.34-rc1 which requested /lib/firmware/2.6.34-020634rc1-generic/radeon/R600_rlc.bin, so I symlink'd /lib/firmware/radeon/R600_rlc.bin and it worked fine. There's some problems with dual screens and KMS w/3D, but it's rectifiable - so thank you! :)
EruditeHermit: ok booting
EruditeHermit: airlied, ok so what do you want me to do now
airlied: EruditeHermit: boot s/r cycle, get dmesg on resume if ssh stays up
airlied: attach to bug
Tommeh: So dual screen issues - I have to use RandR to turn monitor #2 upside down, and then revert it back to normal before it works properly. Without that there is corruption and improper rendering of objects.
Tommeh: And also after I've done that (it's usable now) the contrast is far higher on monitor #2 when it was not without KMS.
Tommeh: Could someone show me where to file bugs for these? (Or check if they exist already.)
EruditeHermit: airlied, so kms is not booting up properly. I can't even see the login screen anymore.
EruditeHermit: its black
EruditeHermit: I hear the sound that says the login prompt is reached
EruditeHermit: ah it seems to have worked this time
EruditeHermit: airlied, it seems to think that my CRTC is connected to the tvout
EruditeHermit: https://bugs.freedesktop.org/attachment.cgi?id=33917
Tommeh: Would anyone like any debug info from this high contrast problem as I'm going to have to reboot into UMS, it's hurting my eyes now :(
airlied: EruditeHermit: I don't see that in that log
EruditeHermit: about 5 lines from the end
EruditeHermit: [ 330.650727] [drm] crtc 1 is connected to a TV
airlied: crtc 0 should be doing something though
airlied: wierdly the ring test fails
EruditeHermit: i thought it succeeds
EruditeHermit: what line is that?
EruditeHermit: are we looking at the same thing?
EruditeHermit: I see ring test succeeded in 1usec
EruditeHermit: twice in that log
EruditeHermit: no failures
marvin24: glisse: Anything I can do to debug https://bugs.freedesktop.org/show_bug.cgi?id=26887 further?
airlied: EruditeHermit: oops doesn't fail
airlied: trying to remember did it always fail before
EruditeHermit: the ring test?
EruditeHermit: not sure
EruditeHermit: there are a few old logs
glisse: marvin24: i will retest with my rs785
glisse: but mine was working
EruditeHermit: airlied, did you work with Christian Hartman on stuff?
EruditeHermit: in his dmesg on resume log the ring test also succeeds
marvin24: glisse: what leads to a fence error?
glisse: marvin24: it just that the ib or ring or gart is not working properly
glisse: marvin24: do you have iommu ?
airlied: EruditeHermit: he looks to have a different gpu
glisse: if so try booting with iommu=off
glisse: don't think it hurts thought
marvin24: PCI-DMA: using GART IOMMU
EruditeHermit: airlied, this is the only other dmesg that I have https://bugs.freedesktop.org/attachment.cgi?id=31055
marvin24: does this mean that iommu is used?
EruditeHermit: airlied, the ring test is relatively new isn't it?
EruditeHermit: airlied, want me to boot 2.6.32 kms and try the same thing?
glisse: marvin24: maybe i am not a specialist when it comes to iommu but i fear that i one point we might need to talk with them
glisse: EruditeHermit: if you have courrage to build kernel
glisse: http://git.kernel.org/?p=linux/kernel/git/glisse/drm-radeon.git;a=shortlog;h=refs/heads/drm-radeon-next
glisse: has patch for gpu lockup might help with your resume issue
EruditeHermit: glisse, do you happen to have just the patches that are different from drm-linus in airlied tree?
EruditeHermit: or can I git pull this into that branch?
glisse: EruditeHermit: patch are on dri-devel mailing list
glisse: http://patchwork.kernel.org/project/dri-devel/list/
glisse: 1,2,3 allmost on the top of the page
EruditeHermit: glisse, are they the 3 patches near the top?
glisse: yes
EruditeHermit: ok
EruditeHermit: will try
EruditeHermit: glisse, they seem to be r600 stuff?
glisse: not only
glisse: they cover all the radeon gpu
glisse: EruditeHermit: what is your gpu ?
EruditeHermit: glisse, r300
glisse: bugid ?
EruditeHermit: rv350 specifically
EruditeHermit: 23103
EruditeHermit: rv350 mobility M10
EruditeHermit: fdo bug 23103
glisse: seems you have several issue
glisse: maybe also AGP related
glisse: did you try loading radeon module with agpmode=-1
glisse: and suspend/resume with that
EruditeHermit: hrm
EruditeHermit: I don't remember
EruditeHermit: let me try
EruditeHermit: can I do radeon.agpmode=-1 at grub?
glisse: yes
EruditeHermit: glisse, that doesn't help
EruditeHermit: there are separate bugs
EruditeHermit: it would seem
suokko: glisse: time_after(0x0000 0010, 0xfeff ffff) returns true
suokko: but time_after(0x0000 0010, 0xefff ffcf) returns false
glisse: hu ?
suokko: glisse: I jsut don't believe that your wrapping protection is doing what you want
glisse: i will retest later but something is wrong their
glisse: maybe you need to add UL
suokko: glisse: That is exactly correct the way time_after is defined
suokko: It is defined to deal correctly with jiffies wrapping over maximum value
glisse: i guess expectation is that you never do op btw jiffies that have more then 1 << 63 diff
EruditeHermit: airlied, glisse anything else you want me to try before i head off to bed?
suokko: or 1 << 31 if you have 32bit system
glisse: EruditeHermit: no i think we need to look into reg dump, dunno if airlied already looked or not
suokko: glisse: So maybe all jiffies needs to be updated after resume (if jiffies are ticking in suspend time)
EruditeHermit: glisse, look at the bug, there are many reg dumps after resume
glisse: yeah we should update them unconditionaly thought i think jiffies don't progress while suspend
EruditeHermit: glisse, you might find something we missed
glisse: yeah i saw there was dump
EruditeHermit: I can get new ones if you want but thats something to look at first maybe
glisse: suokko: i will go over the jiffies stuff latter
EruditeHermit: ok gnight guys. if you want me to try anything, just attach to the bug, otherwise i'll be back tomorrow if you have time to continue
EruditeHermit: thanks for your efforts
EruditeHermit: I just hope we can find a solution soon =)
marvin24: glisse: iommu=off crashes before boot finishes
MostAwesomeDude: Thunderbird: Are you one of the d3d9 people? If so, could you weigh in on http://bugs.winehq.org/show_bug.cgi?id=22000?
Thunderbird: MostAwesomeDude, what bug number? (22000 is invalid)
Thunderbird: err, typo
Thunderbird: I do work on d3d but I'm not familiar with this area
Thunderbird: MostAwesomeDude, what I would recommend is to join #winehackers and ask stringfellow (Henri) about it
MostAwesomeDude: Thunderbird: Alright, thanks.
adamk: implicit criticism?
MostAwesomeDude: A bit. Something is direly wrong, and I think that (for once) it's not me.
adamk: Yeah, I just find it odd that he seems to think you're intentionally criticizing mesa, rather than asking for clarification and thoughts on the matter :-)
mazzachre: Still have not fixed my glxgears problem... But it is not really bothering me... so perhaps it will fix itself before I get time to do something about it...
mokoloko: http://img682.imageshack.us/img682/8207/d2coast080001.jpg here is hl2 screenshot running in dx9 mode. It looks like that at very specific point and here is how it looks like 99% time http://img641.imageshack.us/img641/1999/d2coast080002.jpg
mokoloko: GLSL disabled from the registry
MostAwesomeDude: adamk: Ah, I see, on the ML.
adamk: Yeah, I just found his wording odd. Like he pictured you doing a little jig when you saw this problem :-)
mokoloko: It behaves same in dx8 mode. Radeon 4850 here with latest 7.8 mesa from git and gotta tell FPS is very playable it's just that weird "overlay" that ruins it :P
MAD|final: I dunno if I'd ever do a jig over a bug that spans two different packages. :3
Thunderbird: perhaps it is some fog issue?
mokoloko: I've no idea but I bet it some "tiny" trigger somewhere that causes it :)
MrCooper: well, I think if you send basically the same report to two separate projects, at least one of them is bound to be confused
MAD|final: Yeah, I made a bad call.
spstarr: hello glisse
spstarr: glisse: no GPU reset so far.. just resumed from memory.. no lockup yet.
glisse: spstarr: glad for you
spstarr: glisse: KMS is still pretty sluggish though, but not crashing at least
glisse: ie sluggish ?
glisse: i guess it's kde usage which take unloved path
glisse: 0/win 5
spstarr: glisse: 3D games
spstarr: glisse: not composite
spstarr: it is really slow with second life for example
spstarr: in a GL scene where I should be getting at least 20-30 FPS
spstarr: i get 5-9
suokko: hmm. Can GPU be locked in GUI path so that it keeps GUI status active but can't advance processing
spstarr: i can go into GNOME but i don't buy the window manager causing such performance loss
glisse: oh, then i guess it's kind of normal
spstarr: glisse: you mean, for now? :)
spstarr: until optimization?
suokko: goes to read irc logs
mazzachre: spstarr, Any composition manager? I can say that if I run xcompmrg and make my windows transparent, fps in game drop to around 20%...
spstarr: composite is OFF
spstarr: glisse: it would be cool if we had a radeon_gpu_top tool like intel has
spstarr: to show where in GPU we have most loads
suokko: spstarr: Does it take 100% cpu usage when you run the second life?
spstarr: suokko: let me run it now..
Thunderbird: use a profiler like sysprof, it might indicate some slow paths
spstarr: sysprof seems broken with 2.6.33/34-rc1
suokko: spstarr: If it runs close 100% cpu (of at least single core) sysprof should show why it is so slow
spstarr: loading game up
spstarr: 93%
spstarr: 103
spstarr: 108
spstarr: some of that is due to texture/primitives being fetched from network
suokko: spstarr: Is single core close 100%?
spstarr: 89
spstarr: its hovering around 75-93
suokko: or is it running 50%/50% in 2 cores?
spstarr: 1 core
spstarr: i can force the game to use one core though
suokko: ok. THe profiling cpu usage would help
spstarr: ok let me try again to get sysprof to work
spstarr: it fails with some mmap error
suokko: Maybe there is some fedora patces that sysprof would need
spstarr: i built with fedora's spec file + patches for 1.1.5
spstarr: I just need performance counters and sysprof tracing right in kernel config?
oga: airlied/agd5f any idea when xf86-video-ati will release? I saw the RC a while back.
oga: also, will it be essentially git?
spstarr: suokko: yeah i wonder what is hitting CPU so much
spstarr: sysprof has had changes
spstarr: Stop using double mmap trick.
spstarr: maybe they fixed bug
spstarr: but i need to enable sysprof tracer in kernel as i didnt have it on
spstarr: why isnt sysprof merged into kernel?
spstarr: would be useful
spstarr: hrm
spstarr: git.kernel.org is dead
spstarr: or slow one or the other
suokko: spstarr: 130.239.17.7
suokko: try if that mirror works better
spstarr: yes
spstarr: pulled in linus's latest stuff
spstarr: which is just btrfs
spstarr: git4.kernel.org
spstarr: suokko: if sysprof works, i have mesa debuginfos installed
spstarr: maybe I should install the ddx debuginfo and libdrm ones also?
suokko: spstarr: First try to see which binary has most cpu time
suokko: spstarr: Then you can install symbols only for them
spstarr: ok
spstarr: i think in fedora it should show symbols properly since i last did this in debian time
suokko: Of course if yo uhave fast connection you can jsut install all (including X, X drivers, mesa, kwin, libpixman etc)
MrCooper: spstarr: sysprof 1.1.x should no longer need any special sysprof support in the kernel, just perf events
spstarr: MrCooper: os I should *not* enable the sysprof tracer option?
spstarr: os->so
spstarr: that is in linus's kernel tree
spstarr: stock 2.6.x
MrCooper: I don't know what that is
spstarr: hmm
MrCooper: what's the CONFIG_* identifier?
spstarr: CONFIG_SYSPROF_TRACER=y
spstarr: i do need CONFIG_PROFILING though also
MrCooper: it works here without that (the option doesn't even seem to be available here, maybe because I'm on powerpc)
spstarr: possible
spstarr: i'll compile it with both
MrCooper: I suspect that may be for sysprof 1.0.x
spstarr: lemme see if it has a help
agd5f: oga: I'm planning to roll another rc today
agd5f: release probably next week
spstarr: just says 'This tracer provides the trace needed by the 'Sysprof' userspace tool.
spstarr: googles
oga: ok, sweet.
oga: be out in good time to update as soon as we unlock after release.
MrCooper: spstarr: or maybe it was for the sysprof ftrace branch, which has been abandoned I think
spstarr: hmm ok
MrCooper: enabling that option shouldn't hurt though but it's most definitely not necessary
spstarr: ok, its building
brot: hi everyone. i wanted to know if there are some tools which can read the temperature of the RV670.
agd5f: brot: not at the moment
brot: thanks anyway agd5f :)
spstarr: agd5f: do you think we'll have a gpu top for radeon?
spstarr: i think the intel gpu top is interesting
suokko: spstarr: How does intel one work?
spstarr: it break it down into different GPU processes, like CS processing, vertex buffer usage, etc
spstarr: i have not played enough with it since the intel GPU for me right now locks up badly just using it
Thunderbird: suokko, there are a lot of tools like that; nvidia has their perfkit stuff; amd also has performance counters in their drivers
suokko: If it is just statistics from kernel module. That shouldn't be too hard. Patches are welcome ;)
agd5f: spstarr: you can query the various pipeline busy bits to see what blocks are busy
Thunderbird: both nvidia/amd performance counters are supported by Gremedy's gDebugger
Thunderbird: it would be nice if there was an open source clone for such a tool
suokko: Thunderbird: And that is only tough driver interface, right?
Thunderbird: which can hook into different drivers
Thunderbird: sure the tool ships a gl wrapper but it also hooks into the gpu performance counters
spstarr: agd5f: neat
agd5f: spstarr: GRBM_STATUS* regs
spstarr: i've seen some of those dumped when GPU reset code dumps to dmesg
spstarr: woohoo!!
spstarr: I just got hired
agd5f: spstarr: congrats
spstarr: thanks
Thunderbird: congratulations
Thunderbird: at what sort of company?
spstarr: RIM
Thunderbird: ah
Thunderbird: I have been there once in Waterloo
brot: nice spstarr :)
spstarr: it's been a very, very long process
spstarr: Thunderbird: your in .ca?
spstarr: back to kernel it just finished
Thunderbird: no, I'm not in .ca; 3 years ago I organized a study tour (for students; I was a student back then) and we visited canada for three weeks
spstarr: ah
spstarr: ok let's boot into new kernel
spstarr: well it works
spstarr: but the kernel did not like
spstarr: [ 244.590988] IP: [
spstarr: though the module is working heh
spstarr: i need X debuginfo also
Thunderbird: it is also important that you run sysprof as root else you lose information
spstarr: ya, su -m
suokko: agd5f: I have funny problem with rv280. Sometiems when I boot blitblt from vram to gtt is always causing junk data. I hae tried to reload kernel module+vbetool post. But even that is not enough to fix the problem. Only fix seems to be restarting. I could use a tip in debuging that which registers I should look for
spstarr: not sure why the kernel oops'd on load of module, its force to permanent now
spstarr: seems like a bogus oops though as it is working
spstarr: ok i have all debuginfos now let's run second life with debug symbols
spstarr: we're going to find out whats killing FPS now
spstarr: odd
spstarr: ati ddx builds no debuginfo?
suokko: spstarr: ati might be only wrapper and oyu need video-radeon
spstarr: oh yes i know why...
spstarr: i need that magic rpm package
spstarr: there used to be a rpm you needed or debuginfo would not be generated
agd5f: suokko: weird. I dunno. maybe hw issues?
spstarr: redhat-rpm-config
suokko: agd5f: might be
agd5f: suokko: using APG or pci gart?
spstarr: I didn't install the fedora main rpm which pulls in deps
suokko: agd5f: AGP
agd5f: maybe an AGP issue
suokko: Maybe Ishoudl test to reload agp module to see if it is some init failure there .
spstarr: xorg-x11-drv-ati-debuginfo-6.13.0-0.30.20100305gite7b41f8
spstarr: there we go
spstarr: done benchmark let's see
spstarr: I see something
spstarr: do_row() = 17.39% total
spstarr: t1_decode_cblks() = 8.91%
spstarr: VxHighPassV2FilterProcess() 6.01% total
spstarr: radeonReadRGBASpan_ARGB8888 2.48%
suokko: grr. Can't realod agp module in running system :/ some unamed processes is referencin it :/
suokko: spstarr: do_row sounds like software fallback
spstarr: yes suokko it is tiling
suokko: But I don't know where t1_decode and VxHighpass are located
spstarr: the tiling work mcencora is doing will fix that
spstarr: those seem to be coming from second life itself.
spstarr: I compiled binary with -O3 -mtune=core2 even
spstarr: oh VxHighPassV2FilterProcess is the SLVoice sound daemon
spstarr: we can ignore that
spstarr: acpi_pm_read is 9% almost with dynamic ticks, hpet turned off
spstarr: but with UMS why is tiling different?
spstarr: is tiling implimented differently in UMS vs KMS?
suokko: spstarr: It might be depend on where data is read from
spstarr: sysprof isn't showing much else otherwise
suokko: spstarr: If sw path goes to read from vram directly you are screwed while gtt is fast in pcie systems
spstarr: this is a pcie
spstarr: running sysprof again
spstarr: is looking at VxHighPassV2FilterProcess()
spstarr: it is not sound
spstarr: r600_cs_check_reg is 0.90% total
spstarr: heh google just shows ME mentioning VxHighPassV2FilterProcess
spstarr: Vx... that does sound like the audio daemon
spstarr: found it
spstarr: nm libvivoxsdk.so | grep VxHigh
spstarr: 0037f8c0 T VxHighPassV2FilterProcess
spstarr: it is the proprietary audio stub
spstarr: lets turn off audio
spstarr: rerunning sysprof test from scratch
suokko: spstarr: btw, I also did notice that software sound handling in pulseaudio was causing too much cpu load for me
spstarr: suokko: yes, i also notice this
spstarr: i try to use OpenAL <-> ALSA <-> PulseAudio which has brought the cpu down a bit
spstarr: second life uses openal backend
suokko: 15-20% when running OA
spstarr: but the pulseaudio backend directly used uses 40%
edwin: I was doing some profiling with perf record, and various fetch_texel_2d_f_* functions show up. Where are they defined? a 'git grep' in mesa tree doesn't help
spstarr: grep -r "fetch_texel_2d_f_*" *
spstarr: in mesa tree heh
edwin: static void FETCH(f_argb4444)
edwin: ah!
MrCooper: sounds like software fallbacks
suokko: Too many software fallbacks :/
spstarr: ok now we have better info from sysprof
edwin: maybe because I run wine with glsl disabled?
spstarr: do_row() is 21.02% total 21.56%
spstarr: the lack of tiling in r6xx is a huge hit on second life right noww
spstarr: hw accel tiling
MrCooper: more software fallbacks
suokko: agd5f: hmm. Looks like 8x is failin while 4x works. But about 90% of boots 8x works too
spstarr: t1_decode_cblks() 10.33%
spstarr: that looks to be also swcallback
spstarr: hmm
MrCooper: edwin, spstarr: RADEON_DEBUG=fall might give some information on stderr about why it's falling back
spstarr: lemme do that now
spstarr: t1_decode_cblks = OpenJPEG DSO
spstarr: thats something of a problem the game developers know about for openjpeg 1.3.x is crap 2.x is supposed to be better
agd5f: spstarr: tiling doesn't prevent sw fallbacks, it just provides better gpu cache utilization
spstarr: agd5f: yeah for memory its useful for
spstarr: tiling memory
edwin1: hey I just had a GPU lockup
edwin1: screen is black
edwin1: I sshed in, killed the app, but still black screen
agd5f: spstarr: do_row has nothing to do with tiling
edwin1: http://paste.debian.net/63556/
edwin1: ^log of lockjup
edwin1: is there anything I can do to get the screen back (its connected via DVI)
spstarr: oh it was maps wasn't it..
spstarr: agd5f: i mean mipmap stuff
spstarr: i thought someone was working on mipmap fixes in their own tree
spstarr: was it mcencora ?
spstarr: osiris was
edwin1: hmm
edwin1: Xorg is unkillable!
spstarr: radeon_tiled_textures
spstarr: this is different vs tiled memory?
spstarr: running with RADEON_DEBUG=fall
spstarr: migrate_image_to_miptree Trying to map texture in sowftware fallback.
spstarr: lots of that
spstarr: wow im being flooded with that
spstarr: migrate_image_to_miptree Trying to map texture in sowftware fallback.
spstarr: migrate_image_to_miptree Trying to map texture in sowftware fallback.
spstarr: there's a typo in the error msg :)
spstarr: well that seems to be why its so sluggish
suokko: I wonder what could cause the problem that agp 4x seems to work but inthis boot 8x doesn't
spstarr: what is a miptree?
spstarr: mipmaps ?
suokko: spstarr: yes
spstarr: ok so until osiris's mipmap tiling stuff is merged it will use sw callbacks?
spstarr: http://cgit.freedesktop.org/~osiris/mesa/log/?h=radeon_tiled_textures
spstarr: suokko: oh you're also committing to his tree
spstarr: suokko: anything i can test ?
suokko: spstarr: That was just one patch that I sent after reviewing it
agd5f: suokko: AGP is made of fail
spstarr: suokko: oh
edwin1: agd5f: any idea why my display didn't come back after the GPU reset? (I was in a wine game)
spstarr: suokko: should I log a bug for this, or it's already known given the work on the tiled textured stuff
shadowmaster: what exactly is the effect of the DynamicPM in the radeon ddx config? (yes, I read the manpage)
shadowmaster: *DynamicPM option
agd5f: spstarr: tiling has nothing to do with mipmaps or acceleration vs sw fallbacks. it's just an alternate method of laying out buffers in memory to better utilize gpu caches
suokko: agd5f: But I still suspect some driver error :/
suokko: in agp driver maybe
agd5f: shadowmaster: it lowers the clocks and number of pcie lanes when your system goes in to dpms sleep
[Enrico]: shadowmaster: when the monitor is tuned off via DPMS the gpu clock is slowed
spstarr: ok so then what migrate_image_to_miptree is doing would not be improved with optimizing the gpu caches?
shadowmaster: aha, not useful for me then ;(
spstarr: or its two separate things altogether in this case
[Enrico]: shadowmaster: you may want to try the new kms dynamic PM i'm happy with it (but it is not perfect, the algorithm is very basic atm.... but better then nothing)
[Enrico]: shadowmaster: this new *real* dynamic PM can be found in drm-next or in the new shiny .34 rc1 kernel
agd5f: spstarr: tiling just increase performance when sampling from a texture or rendering to a buffer. it has nothing to do with generating mipmaps or sw fallbacks
spstarr: suokko: you have a typo in that patch :)
spstarr: agd5f: ok, do you want me to debug this further or nothing I can do
[Enrico]: shadowmaster: and you must specify radeon.dynpm=1 in you kernel line to enable it (it is disabled by default)
spstarr: suokko: http://www.mail-archive.com/mesa-commit@lists.freedesktop.org/msg15354.html :)
agd5f: shadowmaster: dynamicpm on affects ums, for kms, there is different code in the drm
shadowmaster: [Enrico]: no, no dialy KMS for me due to external (e.g. not a bug in the drm subsystem) reasons :)
shadowmaster: um, daily
shadowmaster: and the last time I tried an RC kernel I blew up my /usr partition, so I'd just wait for the final release in a few months anyway
suokko: spstarr: I'm blind for typos.
spstarr: suokko :)
[Enrico]: shadowmaster: eheheh yeah that's why i use drm-next :)
spstarr: suokko: still gets the msg across anyway
mcencora: spstarr: what is the app that gives you many "migrate_image_to_miptree Trying to map texture in sowftware fallback" msgs?
spstarr: mcencora: Second Life in this case
spstarr: mcencora: im hitting it quite badly
spstarr: i have the binary if you want + source in tarball i built for core2
spstarr: and now i can see why i get so much stalls when i move around the scenes
spstarr: mcencora: you can also get a build from secondlife.com for linux instead it should still show same thing
spstarr: or i can test some patches if you have some
spstarr: still see 6 FPS even if i don't move in the game
spstarr: let's see what sysprof says
mcencora: spstarr: check where the radeonSpanRenderStart calls come from
spstarr: r600_cs_parse 3.69% on idle
spstarr: mcencora: looking
mfedyk: spstarr: if you don't get sysprof working, try out perf it may do what you need.
spstarr: mfedyk: it's working
spstarr: and its giving me good info
spstarr: mcencora: in r600_span.c: it is setup in radeonInitSpanFunc()
mcencora: mcencora: and what's calling this one?
spstarr: checks for DRI2
spstarr: looking
spstarr: this is called in r100CreateContext()
spstarr: er
spstarr: r600CreateContext()
spstarr: it is called from here
spstarr: but isn't that called once? to setup?
spstarr: there is a big comment in that function radeonSpanRenderStart
spstarr: since this is KMS, we are DRI2
suokko: spstarr: You could check from sysporof where the calls are coming in runtime
spstarr: doing so now
suokko: You can browse the stack up from bottom left corner
spstarr: im not seeing those functions called though
spstarr: do_row() only shows up looking further
spstarr: its not showing much in callers section
spstarr: do_row() -> bin/snowglobe-do-not-run-directly
spstarr: which is the binary name (shell script launches it)
spstarr: suokko: I am seeing r700 calls so mesa debug symbols are installed ok
spstarr: mcencora: anything else I should look for?
spstarr: suokko: i could try prof
spstarr: perf
spstarr: building perf
LameBMX: ello all .. im trying to enable kms in gentoo ... i get the whitescreen and software rasterizer any ideas?
LameBMX: let me know what you need pastebin wise to assist
[Enrico]: LameBMX: can you explain what did you done do enable it? (including kernel, libdrm, xf86-video-ati versions). i use gentoo too
suokko: LameBMX: Check the build how to in topic that you have build everything correctly
LameBMX: i was just waiting on that to load suokko
LameBMX: is kms not available without an overlay? so far i just enabled kms in radeon kernel module and rebuilt libdrm mesa and xf86-video-radeon
suokko: LameBMX: yes. You need 9999 packages from x11 overlay
LameBMX: if its not possible by passing options to branch in portage tree i think i will just wait
spstarr: ok i have perf built
spstarr: how do I use it for this
spstarr: ./perf report ?
[Enrico]: LameBMX: i *think* you must use xf86-video-ati 6.12.191 and lastest ~libdrm . a .33 kernel is also advisable. i'm not sure couse i use 9999 version of all of these packages (inluding mesa) and drm-next kernel
spstarr: record
spstarr: http://perf.wiki.kernel.org/index.php/Main_Page
LameBMX: yea i see mesa is a version behind .. i am on 2.6.33
LameBMX: scatch that .. mese 7.7 is good for my card i think .. x1300m i believe
[Enrico]: LameBMX: yeah mesa 7.7 is good
spstarr: perf needs the kernel symbol
suokko: spstarr: Could you upload the sysprof record?
LameBMX: yea my driver is old news ... hmmm
spstarr: suokko: yes
spstarr: lemme start it from scratch w/o audio on
[Enrico]: LameBMX: yeah unluck video-ati 6.12.191 is not in the main portage tree, but it should as soon as version 6.13 will be relased (i don't think they will add rc to the main portage tree, but it can happen)
spstarr: ok have xml
[Enrico]: bbl
LameBMX: yea ... ill see if its in layman x11
[Enrico]: LameBMX: it is
LameBMX: im not tryin to get too unstable ... reminds me of the old beryl days
LameBMX: things breakin every other day lol
spstarr: suokko: http://www.sh0n.net/spstarr/radeon/sysprof-sl.xml.gz
mcencora: spstarr: you could use oprofile and make it create a callgraph
suokko: spstarr: Looks like yo uare hitting the 64bit stack trace bug :/
spstarr: is there a bug #?
spstarr: suokko: stack trace bug?
suokko: spstarr: So either run sysprof in 32bit system or try oprofile with callgraph set to something like 20
spstarr: compiling oprofile into kernel...
spstarr: sec
spstarr: i've never used oprofile before
suokko: spstarr: sysprof should generate nice hierachical report of function calls
spstarr: i know the author of it though from ols
spstarr: suokko: hmm, so sysprof is broken for 64bit?
spstarr: turning on OProfile multiplexing support
suokko: I think glisse sayed that it works but you hve the bug still present
spstarr: hmm
spstarr: lemme see whats needed to setup oprofile
spstarr: oprofile needs none of the tracers
spstarr: oh there's a nice gui for it too
LameBMX: so i should be good with just the newer driver correct ... i would need additional config for libdrm or mesa?
spstarr: oh yeah oprofile looks really nice
spstarr: we can even look do annotation with source
Obscene_CNN: needs to play with oprofile sometime
spstarr: if fedora, its easy to install
spstarr: yum install oprofile-gui will pull in the rest
spstarr: if we can find out why im hitting software fallbacks so much this would be great
[Enrico]: LameBMX: you should not
LameBMX: i see xf86-vieo-ati caught kms in kernel ... just happened to glance there and see it during the build
[Enrico]: LameBMX: if you still have problems come back here and paste your Xorg.0.log (most of the time it reveal the issue)
LameBMX: im not leaving ... ill testbed it on my lappy first
LameBMX: :))
[Enrico]: eheheh
LameBMX: p4m x1300m lappy
LameBMX: p4c 9800xt desktop
LameBMX: its nice to be able to share sooo much
[Enrico]: :)
LameBMX: should i rebuild xorg-server .. libdrm is talking about its ABI may have changed 2.4.18 to 2.4.19 i believe
[Enrico]: LameBMX: well i can't tell you, sometimes it is needed sometimes not. so if you want to be sure it will work, recompile
LameBMX: yea im recompiling anyways .. better safe than sorry
[Enrico]: eheheh
spstarr: brb kernel w/ oprofile...
LameBMX: twiddles thumbs waiting for xorg-server to compile
spstarr: oprofile ready
spstarr: depth 20
mfedyk: are we going to get to a point where the latest radeon drivers have support for hardware before it comes out?
[Enrico]: mfedyk: who knows? let's hope..... it's free :)
mfedyk: or is the OSS radeon driver always going to be behind?
spstarr: installing oprofileui
LameBMX: well kms appears to be workin [Enrico]
[Enrico]: LameBMX: good work :)
LameBMX: renderer string isnt listing DRI2 though
[Enrico]: LameBMX: same here
[Enrico]: no wait
[Enrico]: OpenGL renderer string: Mesa DRI R600 (RV620 95C4) 20090101 TCL DRI2 :)
[Enrico]: this is with mesa 7.9-devel
LameBMX: OpenGL renderer string Mesa DRI R300 x86/MMX/SSE2 TCL
[Enrico]: LameBMX: dunno..... check /var/log/Xorg.0.log to see if it is loaded
LameBMX: (RV380 5460) btw
spstarr: running
[Enrico]: LameBMX: there should be a line like "Loading /usr/lib64/xorg/modules/extensions/libdri2.so"
LameBMX: AIGLX: Screen 0 is not DRI2 capable
[Enrico]: LameBMX: paste the whole Xorg.o.log pls
LameBMX: think thats just from mesa 7.7?
[Enrico]: Xorg.0.log*
LameBMX: i will when wgetpaste installs lol
[Enrico]: LameBMX: lol, use wgetpaste -s ca couse dpaste can't handle long files like xorg logs :)
LameBMX: http://paste.pocoo.org/show/188064/
LameBMX: mine dont default to dpaste ... i got sick of left right scrolling on a 1680x1050 monitor
[Enrico]: LameBMX: as you can see on line 322 [KMS] drm report modesetting isn't supported. <--- seems there is something wrong...... or you really need 9999
[Enrico]: LameBMX: RADEON(0): Option "AccelMethod" "XAA" , dude are you crazy? switch to EXA now!
suokko: LameBMX: Yo uneed to load kernel module before X starts
spstarr: 48994 22.1931 r600_dri.so snowglobe-do-not-run-directly do_row
LameBMX: whoa whoa .. so switch accelmethod to exa ... or better yet .. what should i have in my server args .. here ill pastbin my xorg.conf
spstarr: suokko: i have the info from oprofile now
suokko: spstarr: Can you create the calltrace report and upload it?
LameBMX: http://paste.pocoo.org/show/188067/
spstarr: looking at how you do that
spstarr: oh - c
spstarr: lots of warnings
LameBMX: its hasnt been touched since beryl days cept to comment out stuff thats been complained about in the 0.log
suokko: spstarr: opreport -p /lib/modules/`uname -r`/kernel -c
spstarr: it says my vmlinux is modified?
[Enrico]: LameBMX: i strongly suggest you to drop all radeon options and let the driver use the default
spstarr: and overflow stack not available
spstarr: warning: dropping hyperspace sample at offset 1fff0 >= 1ffc0 for binary /usr/lib64/libGL.so.1.2
suokko: spstarr: It can't quarentee that kernel file in hd is same as running one
spstarr: ah ok
spstarr: its dumping...
suokko: It will dump a lot of text
spstarr: oh wow that is a lot
spstarr: its in text file
suokko: That why sysprof is superior because of easy interface for reading the info
LameBMX: are my load modules still good [Enrico] ?
spstarr: but this is showing me very detailed info ok putting up file..
suokko: spstarr: If you want to do more profile. Considre installing 32bit system ;)
spstarr: baaaaaaaaah
spstarr: no 32bit!
suokko: o yo uhave more than 4G memory? :)
spstarr: I have 4GB in laptop
spstarr: suokko: http://www.sh0n.net/spstarr/radeon/oprofile-r600.txt
[Enrico]: LameBMX: dunno i don't even have an xorg.conf (but may be you can drop drm)
LameBMX: huh .. how you manage that one?
[Enrico]: LameBMX: i don't manage, i let xorg to do all automagically
[Enrico]: LameBMX: i just have an fdi policy to change my keyboard layout
mfedyk: [Enrico]: I'm just wondering if amd will be releasing the specs soon enough so the newest hardware can just work.
[Enrico]: mfedyk: dunno, but specs are not all... code is important too :)
LameBMX: wow .. corruption on startup that went away fast
LameBMX: http://paste.pocoo.org/show/188068/
suokko: spstarr: That profile is broken too :/
suokko: spstarr: For some reason it can't trace symbols in r600_dri.so
spstarr: !
spstarr: i have mesa debuginfo
suokko: yes. I think that is some 64bit dwarf reading bug too ...
[Enrico]: LameBMX: same line 322 as before
LameBMX: i see that
[Enrico]: LameBMX: it should say [KMS] Kernel modesetting enabled.
LameBMX: okay ... any ideas ... ill pastebin my kernel .config
suokko: LameBMX: dmesg?
LameBMX: http://paste.pocoo.org/show/188070/ ... .config
suokko: LameBMX: There is KMS info. It is kernel modesetting you know ;)
mfedyk: [Enrico]: oh, of course.
[Enrico]: LameBMX: yeah suokko is right paste dmesg
LameBMX: http://paste.pocoo.org/show/188071/ .. dmesg
suokko: spstarr: Can you give me the link to second life. I will profile it in 32bit system
[Enrico]: LameBMX: [drm] radeon defaulting to userspace modesetting. you didn't enabled kms in you kernel line
mfedyk: I'm mostly curious. I typically run hardware at least one rev behind.
[Enrico]: LameBMX: i assumed you did eheheh :)
[Enrico]: assumes too much he knows
mfedyk: which leads me to my next question... do you think r128 will ever get kms support?
LameBMX: [Enrico], did you check my .config .. it is enabled
[Enrico]: LameBMX: you have to add radeon.modeset=1 to your kernel line
[Enrico]: LameBMX: surely it is not, since it uses UMS. or you are specifying nomodeset or radeon.modeset=0 in your kernel line
LameBMX: http://paste.pocoo.org/show/188070/ ... peek at line 1461 [Enrico]
[Enrico]: LameBMX: btw when you build radeon KMS is always available, that option just make it the default or not
[Enrico]: LameBMX: read my last sentence
agd5f: mfedyk: the modesetting part would be trivial. the hard part would be converting the mesa driver
LameBMX: i dont have either in my kernel line ... ie via grub?
[Enrico]: LameBMX: via grub, or via modprobe.conf
LameBMX: i thought you mean in config
LameBMX: i could test via modprobe radeon radeon.modeset=1 correct?
LameBMX: i am passing no kernel or modprobe arguments to driver
[Enrico]: LameBMX: as i said .config means nothing since even if you don't enable CONFIG_DRM_RADEON_KMS you can get KMS with radeon.modeset=1 in grub
[Enrico]: LameBMX: CONFIG_DRM_RADEON_KMS=y just makes kms the default one
LameBMX: wow
LameBMX: i just lost backlighting
[Enrico]: LameBMX: so since you have CONFIG_DRM_RADEON_KMS=y you are disabling it someway since you don't get it
LameBMX: i specified it grub bootline
LameBMX: what would disable it ... something in modprobe.conf?
[Enrico]: LameBMX: that's an option yes
[Enrico]: LameBMX: or in some file in modprobe.d
mcencora: Thunderbird: do you have an idea what can be causing this? http://img203.imageshack.us/i/trl.png/
spstarr: phone....sec suokko
LameBMX: [Enrico], modprobe.d/ ... drm.conf and radeon.conf are all clean ..
spstarr: suokko: i have link yes sec
LameBMX: and the kernel line argument got me software mode
mcencora: Thunderbird: at first I thought it's occlusion queries, but disabling this extension didn't change anything
spstarr: suokko: http://secondlife.com/developers/opensource/downloads/2010/1.3/3219/Snowglobe-i686-1.3.2.3219.tar.bz2
Thunderbird: did you try lowering the shader quality?
Thunderbird: it has been a long time ago since I messed with that game
spstarr: suokko: I am running 1.4.0.0 though from svn tree which isn't much different in terms of rendering
LameBMX: [Enrico], deprecated modprobe.conf is also clean for radeon/drm entries
mfedyk: mcencora: what's wrong with that pic?
Thunderbird: at that time we had a lot of issues with floating point formats (that was when it ran in shader model 3.0 mode) and we have had a lot of fog issues (that was shader stuff)
Thunderbird: not sure what this is
[Enrico]: LameBMX: do you mean that with radeon.modeset=1 you don't get 3d?
mcencora: Thunderbird: I've disabled all the stuff I could in game
mfedyk: zooms in..
mfedyk: ahh
[Enrico]: s/3d/dri/
mcencora: Z ordering problems
Thunderbird: I remember there was a launcher in which you could disable things before the game started
LameBMX: thats what i mean ..
[Enrico]: LameBMX: paste the xorg log and dmesg for that setup then
LameBMX: http://paste.pocoo.org/show/188076/
LameBMX: dmesg reports modesetting is enabled
[Enrico]: LameBMX: yes i see it
LameBMX: http://paste.pocoo.org/show/188077/
[Enrico]: LameBMX: but still [KMS] drm report modesetting isn't supported.
LameBMX: so now its proper in kernel .. but driver dont see it
mcencora: Thunderbird: found registry keys, will check it
LameBMX: 356 has a weird getversion mismatch
[Enrico]: LameBMX: that's normal when you userspace is not compiled with kms support...... but it should..... what version of libdrm are you using?
LameBMX: now i can set radeon.modeset=1 in modprobe.d/radeon.conf correct?
[Enrico]: LameBMX: it is better to have it in grub imho
[Enrico]: but it is your choice
[Enrico]: LameBMX: and btw, is the radeon module autoloaded before the X startup? couse i'm worried it is not
LameBMX: well grub may get over written behind my back .. if i do both it wouldnt affect anything right
LameBMX: i am not certian on that
[Enrico]: LameBMX: i can't know, i use just the grub line, never tried with both
LameBMX: i have xdm in rc default
[Enrico]: LameBMX: as the warning in the xorg log says you should be sure!
[Enrico]: LameBMX: well did you listed radeon in the autoload modules config file? (the file changes with baselayout version 2
[Enrico]: )
spstarr: suokko: is there problems with 64bit profiling altogether in Linux?
spstarr: *sigh*
spstarr: that is a bit worrying if so
spstarr: no point with 32bit anymore for me
spstarr: suokko: I could build mesa for 32bit/libdrm for 32bit if you like
spstarr: just need to setup a mock
ernstp: lol, just found a wierd bug
ernstp: when I start gnome-help, X freaks out completely
LameBMX: [Enrico], libdrm is 2.4.19
LameBMX: from overlay
ernstp: that's on karmic with lots of bleeding edge radeon stuff
[Enrico]: LameBMX: for what i know that version supports kms and it is compiled with it enabled, so check that radeon is loaded before X start
ernstp: can anyone just try to start gnome-help (with kms and compiz) ?
mcencora: Thunderbird: unfortunately disabling everything didn't help either
[Enrico]: LameBMX: but since i'm not 100% sure, you can try with version 9999 (which i'm sure it works since i'm using it right now). but bet for radeon not loaded before X
[Enrico]: i bet*
[Enrico]: LameBMX: it is easy to check. do you get high resolution tty before X start?
Thunderbird: mcencora, typically games check a lot of texture formats and so on at startup
Thunderbird: you could try +d3d_caps to see which it enumerates
Thunderbird: and disable formats in directx.c
LameBMX: okay ... radeon.modeset=1 is set in kernel boot in grub .. modules.d/radeon.conf modules.autoload.d/kernel-2.6
LameBMX: it seems like anytime i have the nice framebuffer .. i dont get accelerated 3d
[Enrico]: LameBMX: wait, framebuffer? you can't use framebuffer with ksm.... ksm is the new framebuffer
[Enrico]: LameBMX: but as i said you can try (just to test) if with libdrm-9999 (and may be also video-ati 9999) it works
LameBMX: kms .. and yea enabling modesetting enables framebuffer .. you just cant select on specific one
LameBMX: software yet again
[Enrico]: LameBMX: wrong, to enable kms you must DISABLE framebuffers
LameBMX: it wont let you
[Enrico]: LameBMX: .......... :/
[Enrico]: well i have to go to study a bit now, bbl
LameBMX: it makes a new framebuffer selection when you enable it
LameBMX: http://paste.pocoo.org/show/188083/ ... dmesg
LameBMX: http://paste.pocoo.org/show/188084/ Xorg.0.log
LameBMX: i am unable to unselect "support for frame buffer devices" menuconfig - drivers|graphics
LameBMX: i could make it a module though
mcencora: Thunderbird: good idea
LameBMX: [Enrico], i did disable xdm .. modprobed radeon and it worked
spstarr: suokko: found anything interesting from profile?
ernstp: can someone with kms and compiz start gnome-help? my X freaks out, wondering if this is easily reproducible or not?
rindolf: Hi all. I have a << 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] >> - does radeon/video-ati support 3-D there in Mandriva 2010.0?
suokko: spstarr: sorry. I had a interrupt
suokko: and while I was away the latest mesa didn't compile for me :/
spstarr: doh
adamk: rindolf: You'd probably have to ask the mandriva folks :-) I'm not familiar with anyone here using that distribitiution.
Terman: also can't compile mesa
adamk: rindolf: 3D is definitely supported on that card with open source drivers if they are new enough.
spstarr: suokko: you want me to build for 32bit?
spstarr: my last git checkout that is
rindolf: adamk: ah.
suokko: spstarr: Now I got it to build
spstarr: ok
spstarr: im curious to see what your results show
spstarr: because we're hitting something bad
suokko: spstarr: You could run multilib system if you are only interested in user spaces profiling
spstarr: i have some 32bit stuff installed
spstarr: but not mesa/libdrm 32bit yet
spstarr: i can build these however in mock
Terman: xorg_crtc.c:287: error: dereferencing pointer to incomplete type
Terman: git head from 2 minutes ago
suokko: spstarr: All shared objects that are loaded by mesa has to be 32bit too
spstarr: suokko: mixing 64bit X server + libdrm 32bit/mesa should be fine as the DDX will just use 64bit libdrm
spstarr: suokko: ldd time...
spstarr: yeah GNU libc, libdrm, the X libraries suite (some of it)
spstarr: i have those for 32bit
suokko: good. x protocola should be 32bit/64bit safe but client sie libraries have to be 32bit
spstarr: ok let me build libdrm/mesa in mock 32bit from my git sources (package into rpm)
spstarr: then get the i686 build of second life, do i need a 32bit kernel however?
spstarr: ok setting up mock 32bit chroot
suokko: spstarr: Your sytem doesn't meat the minimum requirements
spstarr: ignore it
spstarr: suokko: it doesn't recognize 'mesa GPU'
spstarr: ive told them about that one
spstarr: you can override that in the gpu_table.txt file to force it, but its just a notice
spstarr: an r6xx more than meets the game requirements
suokko: spstarr: Funny it already hits one of performance bugs that I know about in login screen ;)
suokko: That is XGetImage
spstarr: heh
spstarr: its a real bitch
spstarr: its one of those games we should use for stressing the stack
spstarr: just cause it does so much crap
[Enrico]: LameBMX: i'm back. so if you disabled xdm and modprobed radeon then started X -> radeon was not loaded before X :)
spstarr: suokko: are scenes rendering slowly?
agd5f: mcencora: it should be possible to implement logic ops in the blit code, although, I'm not sure it's worth the effort
mcencora: agd5f: there're more important things to do :)
LameBMX: [Enrico], and i figured out how to do that in baselayout2 .. so i got the lappy goin good
suokko: spstarr: I'm still registering
spstarr: oh, ok
suokko: spstarr: Somewhat slow with remote desktop ;)
spstarr: hehe
[Enrico]: LameBMX: very well :) (i said you the file was changes with baselayout 2 eheheh)
spstarr: im building libdrm/mesa now in 32bit
LameBMX: lol i know [Enrico] i am about to fudge with the desktop ... i should be good with it though
LameBMX: ill brb
LameBMX: grrr
LameBMX: xchat isnt in $PATH on lappy ... and layman isnt installed on here
[Enrico]: lol
LameBMXa: ahhhhh
spstarr: suokko: once you log in, it'll probably put you to some welcome area
Obscene_CNN: incase anyone was wondering, adding likely/unlikely macros to the cs_gem_write_reloc in libdrm seems to be a win
suokko: Obscene_CNN: good :) Did you try my patch from mailing list?
Obscene_CNN: no I haven't
Obscene_CNN: needs to sign up for the radeon mailing list
suokko: Obscene_CNN: dri-devel
Obscene_CNN: needs to sign up for the dri-devel mailing list too
Obscene_CNN: ;)
spstarr: 32bit mesa built
spstarr: suokko: im ready try 32bit now also
spstarr: with oprofile i hope it spits out something now
spstarr: suokko: the 32bit build uses not openjpeg for texture rendering
spstarr: you can turn that off though in the secondlife script
spstarr: rename libkdu.so
DanaG: GLApp.cpp:(.text+0x14d): undefined reference to `glXSwapIntervalSGI'
DanaG: trying to compile ParallaxMapping: http://developer.amd.com/gpu/radeon/pages/RadeonSDKSamplesDocuments.aspx
spstarr: let's see is 686 is faster
spstarr: migrate_image_to_miptree Trying to map texture in sowftware fallback.
spstarr: oprofile time
spstarr: suokko: dumping oprofile stats
spstarr: suokko: this is a HUGE report
spstarr: its taking a while to process (oreport)
spstarr: suokko: i dont see anything else failing other than that error from migrate_image_to_miptree so far
spstarr: GPU reset
spstarr: glisse: X kept respawning over and over
spstarr: 12521.428290] radeon 0000:01:00.0: GPU lockup CP stall for more than 1003msec
spstarr: [12521.428297] ------------[ cut here ]------------
spstarr: [12521.428350] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:234 radeon_fence_wait+0x235/0x2d3 [radeon]()
spstarr: it spit out a path
glisse: spstarr: try killing some app
glisse: one app keep submiting buggy command stream
spstarr: glisse: i was trying to enable second life GLSL advanced shaders
spstarr: then it went boom
glisse: killall second life
spstarr: did
glisse: see if it goes back to normal
spstarr: X restarted itself to gnome login
spstarr: gdm
glisse: ah you killed too much
spstarr: it did
spstarr: I tried to vt switch but when i switched back X was restarted
spstarr: since it keept restarting X over and over
spstarr: trying again
Obscene_CNN: suokko, just applied your patch :)
spstarr: hmm
spstarr: i can't enable GLSL on x86_64
glisse: anyway i am off to bed
spstarr: trying i686
spstarr: ok
spstarr: glisse: i saved it this time
spstarr: killing the game stops reset
spstarr: suokko_: lemme know what you've noticed whenever
LameBMX: whaddup
suokko_: spstarr: I noticed that xserver crashed when I tryed to close secondlife
suokko_: grrr. It was double free
dougmencken: hi again; so any progress on support for OF-radeons?
spstarr: suokko_: export MALLOC_CHECK_=0
spstarr: i disable that for now
spstarr: there are issues...
suokko_: spstarr: double free shouln't happen in Xserver
spstarr: what distro
suokko_: But somehow secondlife was able to cause double free of cursor data
suokko_: Ubuntu
spstarr: xorg 1.7.5?
suokko_: no
spstarr: 1.7.4? or pre-1.8
suokko_: I'm still running 1.6.5
spstarr: oh wow
suokko_: I know I should upgrade ;)
spstarr: so you lost the profile info? ;( heh
LameBMX: DRI2 rocks
FIReun: prove it
spreeuw: show us your fps punk
FIReun: heh
FIReun: my next GPU will be an FPGA!
amarsh04: been reading www.opengraphics.org, FIReun? (-:
FIReun: amarsh04: not only was windows7 my idea, so was opengraphics.org
FIReun: cant back that up, and in fact wouldnt want the credit even if it *was* true
Obscene_CNN: damn shame they did that in Verilog verses VHDL
DanaG: GLApp.cpp:(.text+0x14d): undefined reference to `glXSwapIntervalSGI'
DanaG: hmm, linker error...
LameBMX: windows 7 was my idea! ... but kde people implemented them first
Jonimus: is anyone else having issues with mesa from git not building?
LameBMX: nope .. not using mesa from git i dont think
spreeuw: Jonimus: do a make clean and a autogen
Jonimus: spreeuw: my build script does that already but ok I'll try
spreeuw: if its not reported by others do a fresh checkout
spreeuw: sometimes it barfs
Jonimus: spreeuw: this is a fresh checkout
spreeuw: oh
spreeuw: one you never built in?
Jonimus: yeah
spreeuw: I'll do my script now
Jonimus: I tired added a make clean before the autogen.sh, hopefully this'll work
Jonimus: adding*
spreeuw: takes me only 90 seconds to do all 3
spreeuw: SSD phenom IIX4 ;P
spreeuw: oh, dont build other drivers
spreeuw: just radeon
Jonimus: I know
spreeuw: or r300 or whatever you need
spreeuw: ok
spreeuw: well it just built ok here
Jonimus: hmm it seems its gallium related, let me try disabling that
suokko_: spstarr: do_row is called from mipmap generation
suokko_: So hw accelerated mipmap generation would help
suokko_: But I don't know why second life is doing texture uploads all the time
Jonimus: yup it appears a recent commit broke the building of gallium
suokko_: spstarr: http://people.freedesktop.org/~suokko/second_life_profile.xml has example what correct profile data should look :)
spstarr: looking
spstarr: 7.1MB
spstarr: hmm
spstarr: suokko_: i wonder why its broken forme
spstarr: suokko_: was it sluggish for you also?
suokko_: spstarr: It had very variable framerate
spstarr: you didn't have stalls?
suokko_: IT looks like it is loading many textures inside short time frame and then running for sometime without texture uploads untill next uploads
suokko_: spstarr: variable framerate can be understood as stalls ;)
spstarr: heh
spstarr: well, even with the textures being loaded, the scene should still be smooth movement
spstarr: i will have to try sysprof again with 32bit this time
suokko_: spstarr: Not with that software mipmap generation because it takes many times more than hw or software generation in system memory
spstarr: oh nice sysprof is working w/o kernel module(?
suokko_: yes. It works for me
spstarr: let me try now
spstarr: stopped profile...
spstarr: still doesn't want to show callers
spstarr: suokko_: we still are hitting software fallbacks for mipmaps
spstarr: [13023.728128] radeon 0000:01:00.0: object_init failed for (86016, 0x00000002)
spstarr: [13023.728134] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (86016, 2, 4096, -22)
spstarr: [13023.728187] [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 21 pages at 0x00B6A000
spstarr: [13023.728192] [TTM] Couldn't bind backend.
spstarr: hmm
spstarr: thats new
agd5f: mjg59: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-expose-thermal-fan-i2c-buses.patch
airlied: agd5f: can you print out th name of the chip?
airlied: that the bios expects?
Jonimus: agd5f: will that patch work with 2.6.33?
spstarr: suokko_: oh
spstarr: suokko_: but you still see those fallbacks even when the scene and area textures are all loaded and rendered
mjg59: agd5f: I'll see if I can give that a go tomorrow
suokko_: spstarr: yes
spstarr: in UMS you don't see those huge stalls, Windows neither
suokko_: spstarr: I susepect that in KMS case mesa is accessing vram directly which is bad
spstarr: do we have debug to trace those paths?
spstarr: airlied: does sysprof work for you? its not giving me caller info
airlied: spstarr: on 32-bit fine
spstarr: so 32bit kernel as well as userspace?
airlied: not sure if building with framepointers enabled on 64-bit works or not
spstarr: aha
airlied: spstarr: last teim I used it at least
spstarr: ok, since oprofile, sysprof both didn't help suokko_ out from my output
mfedyk: hmm, kms seems much faster in a kernel without debugging enabled...
airlied: mfedyk: it is
airlied: esp lock debugging off
mfedyk: airlied: you're not kidding. switched off kms on that kernel then thought to look at .config
mfedyk: the f13 kernels have lots more debugging turned on (probably for the best though).
airlied: we normally don't drop debug until beta time
airlied: I get the feeling we need to probably try and make lock debugging more disablable at runtime
User_007: Hello, i come back... my problem of 3 days ago remain
mfedyk: I'm also testing btrfs, so debugging is probably for the best. I'll just have to run without kms and ignore the high system times and only look for correctness...
User_007: i have compiled libdrm, Mesa and radeon driver and the problem remains...
User_007: I can't run my self-compiled drivers. I get a black screen after boot, if i use Distros's driver, i get no hardware acceleration
cleary: User_007: which distro?
User_007: Debian Squeeze AMD64
cleary: which kernel are you using, and have you installed firmware-linux-nonfree?
User_007: 2.6.33 , yes,
User_007: it was working days ago... after an upgrade it stopped working
cleary: have you tried using xserver-xorg-video-radeon from experimental?
User_007: not yet
cleary: I'm a developer with the sidux project
cleary: we've pushed the experimental package into our fix.main
User_007: ill try
cleary: while I wasn't involved with that decision, I trust the guy who made it :)
cleary: you will probably also want to make sure you're using firmware-linux-nonfree 0.23
cleary: which got the rlc firmwares pushed into it
User_007: cleary, i'll try... thanks
User_007: ok, i will check
User_007: nope, i am using .22
User_007: but my card used to work on this a litlle time agor
User_007: ago
cleary: User_007: do a dist-upgrade too then
User_007: i do it everyday
User_007: cleary, i must use radeon from experimental or sid?
User_007: experimental appears to have a crash bug
mfedyk: User_007: is it hardware specific?
cleary: User_007: experimental
User_007: wait a sec
cleary: User_007: 0.23 of the firmware-linux-nonfree has been available for at least a few days
cleary: so you haven't dist-upgraded in that tine
User_007: 0.23 is for sid, for squeeze is .22
cleary: ah right
cleary: thought it would've made it
User_007: thank you cleary, it worked
cleary: np
SnowRaptor: Hey there!
SnowRaptor: were airlied's 2.6.32 patches incorporated to 2.6.33?
SnowRaptor: I mean, I'm using the 2.6.32 git with airlied's patches. I'd like to know if I'd get better stuff upgrading to 2.6.33 or pulling and buildiong 2.6.32 tree again
mfwitten: My distribution still refuses to build libdrm with --enable-radeon-experimental-api, because KMS/DRI2 support is apparently not ready for widespread use yet among radeon users. Is this still justified?
BioTube: mfwitten: the latest version of libdrm builds libdrm_radeon by default
kepstin: mfwitten, if you have to use a non-distribution kernel to get the radeon kms support anyways, you can probably manage to compile your own libdrm and x.org drivers, too :)
SnowRaptor: I'm using the 2.6.32 git with airlied's patches. I'd like to know if I'd get better stuff upgrading to 2.6.33 or pulling and buildiong 2.6.32 tree again
airlied: SnowRaptor: should do
SnowRaptor: airlied: should do which?
SnowRaptor: keep pulling GIT?
airlied: should have all the patches in it
airlied: 2.6.33 has newer stuff
mfwitten_: BioTube: By latest do you mean officially released? I've looked into how my distro builds it currently, and even the old commented-out `--enable-radeon-experimental-api' is no longer there, so maybe it is being built now by default.
mfwitten_: kepstin: Well, I think my distribution actually builds KMS into the kernel by default, but it's disabled by default as well or something. Anyway, I have indeed built my own custom kernel, so, you're probably right. However, I want to help my distribution move forward if necessary as well.
BioTube: mfwitten_: 2.4.18 dropped the --enable-radeon-experimental-api option and added a --disable-radeon option
mfwitten: BioTube: Ah! Well, I guess my distribution is now building it.
mfwitten: Someone should update the wiki, as --enable-radeon-experimental-api is no longer needed, I guess.
mfwitten: BioTube: I have xf86-video-ati 6.12.4 installed and it was built against libdrm 2.4.17, so I guess that KMS still won't work until I rebuild xf86-video-ati against this new libdrm (assuming that 2.4.17 was build without the radeon experimental API)?
mfwitten: Ah! I see, the wiki has ': With libdrm >= 2.4.18 libdrm_radeon is built by default, now (configure-option --enable-radeon-experimental-api is obsolete).'
BioTube: mfwitten: there hasn't been a KMS-enabled release of the ddx yet
mfwitten: ah
mfwitten: BioTube: Well, what does that mean exactly? How does that affect a system with KMS, etc.?
DanaG: wonders: how long will it be until debian gets KMS? =รพ
mfwitten: BioTube: For one, I assume you mean that there's no need to rebuild xf86-video-ati.
BioTube: mfwitten: you need to build from git master
mfwitten: BioTube: However, does that also mean there's no point in setting up KMS in the other components just yet?
mfwitten: BioTube: I see I see. Is this the last component then?
BioTube: DanaG: the ddx in experimental has it enabled
BioTube: mfwitten: yes
mfwitten: So, I just need to build from git master and VOILA! Everything should be in place; I'll no longer have unaccelerated 3D as a result of a KMS mismatch?
BioTube: mfwitten: as long as mesa was built against that libdrm, yes
mfwitten: (when my kernel has KMS enabled at boot, 3D isn't accelerated in X)
mfwitten: shoot
mfwitten: All right, I'll have to build that too, then.
AndrewR: wint rv280 again ....
AndrewR: *with
AndrewR: I tried too test new hw ReadPixels, but .... ./readpix -> Benchmarking...
AndrewR: Result: 256 reads in 4.004000 seconds = 2.331876 Mpixels/sec Not really what i wanted? No errors, no fllback messages
AndrewR: 2.6.34-rc1, KMS, everything from git .... clean mesa build
airlied: AndrewR: its not enabled for r200 I didn't think
airlied: I thought he only turned it on for r300
AndrewR: airlied, http://cgit.freedesktop.org/mesa/mesa/commit/?id=e167403e5809c447870644bd9ea09fad369706cf
airlied: AndrewR: oh cool
airlied: does it get slower if you turn if off?
AndrewR: airlied, , one moment, i need UMS for this test ....
airlied: just comment out the readpixels line in theory
AndrewR: airlied, 1.565947 Mpixels/sec or 1.570347 Mpixels/sec
airlied: AndrewR: was that UMS? or KMS with the RP turned off?
AndrewR: airlied, UMS
AndrewR: how to disable ReadPixels with KMS? some env var i missed?
AndrewR: *hw RP
airlied: no just revert that patch
AndrewR: .... will try later today .... /away for now, and thanks for everything, even if my demos/teapot now is nearly as dark as my real teapot .....
SnowRaptor: airlied: sorry about the delay. What kind of new stuff 2.6.33 has? I mean, reagrding radeon and the patches?
SnowRaptor: airlied: I couldn't find a changelog for the drm-radeon-testing
airlied: SnowRaptor: fixes and stuff
SnowRaptor: airlied: anything regarding rs430(ish) and the "psychedelic feature"?
airlied: SnowRaptor: doesn't ring any bells
airlied: but nothing stays in my brain like that for long
SnowRaptor: I see
SnowRaptor: any clue on why would My laptop LCD loose sync when the kernel loads uop KMS and changes resolution to the native? It happens *sometimes* when I boot the system
SnowRaptor: and it always get back to normal after it goes to DPMS Blank
SnowRaptor: It ssems like "lost sync", but I'm not sure if it's defined for LCDs.
SnowRaptor: The screen blinks alternating black and white horizontal stripes, 2pixels high in high frequency
AndrewR: byw, currently teapot demo just doing this in UMS mode: http://pastebin.ca/1833043
airlied: SnowRaptor: what gpu?
SnowRaptor: airlied: Xpress 1150
SnowRaptor: i guess it's rs430
SnowRaptor: or some crippled version of it
chithead: it's probably either rs400 (for intel cpus) or rs480 (amd cpus)
SnowRaptor: then it's 480
airlied: SnowRaptor: possibly something slightly wrong in the modesetting paths, or a timing issue
SnowRaptor: airlied: How can I give you useful info in squishing this bug?
airlied: SnowRaptor: log a bug with the laptop name, + dmesg
airlied: my rs480 seems to usually bring up the display in kms fine
SnowRaptor: that's the problem, dmesg shows nothing useful. Is there a debug switch to turn on in kernel config?
airlied: drm.debug=1 if you don't start X can be useful
SnowRaptor: that in the kernel boot optuions, right/>
SnowRaptor: just checked dmesg and it mentions something about ASIC bug
airlied: yeah rs480s are crap
SnowRaptor: where can I report the bug then? The link in topic only points to Mesa debugs
chithead: bugs.freedesktop.org
SnowRaptor: thanks
nilsson: anyone awake?
EruditeHermit: glisse, hey, your kernel patches didn't help s/r in bug 23103
EruditeHermit: airlied, got time today to continue with 23103?
nilsson: I've been spending the better part of the day tranisitioning from kubuntu to fedora, and I've run into a few issues w/xorg
nilsson: I'm trying to use a static xorg.conf on f12 http://pastebin.com/AiMuy0rg
nilsson: sorry xorg here >
nilsson: http://pastebin.com/fpgJC5Z2
nilsson: prev pastebin was Xorg.0.log
nilsson: basically, X won't even startup, it just hangs
airlied: EruditeHermit: so on resume no outputs are working with that kernel?
airlied: can you try resume with VGA?
nilsson: error message is basically: AIGLX - /usr/lib64/dri/r600_dri.so not found
airlied: if X is running do you get the IB problems still?
airlied: nilsson: thats not fatal
airlied: nilsson: does it start with no xorg.conf?
nilsson: it starts fine without an xorg.conf, however I want to use one
nilsson: b/c of my setup: dual-head w/rotation
airlied: can you login, and rotate using the gnome utuility?
airlied: just to make sure it works
nilsson: kde, yes it works
nilsson: krandrtray iirc
airlied: okay so you could probably start with a clean xorg.conf
airlied: and work your way up, that one is full of crap
nilsson: like what?
airlied: you can remove the Screen section, ServerFlags, AccelMeothd, DRI, RR stuff
EruditeHermit: airlied, do you mean IB stuff in dmesg?
airlied: BUsID
airlied: EruditeHermit: yes like you used to get
EruditeHermit: airlied, nope you saw my dmesg yesterday it seems to not be there anymore
airlied: EruditeHermit: so X was running when you suspended?
EruditeHermit: will do the VGA test now
EruditeHermit: X was running yes
airlied: nilsson: hmm it might be another problem what rpm -q xorg-x11-drv-ati
nilsson: won't I need the screen section for setting the virtual viewport size
airlied: I suspect rotate in the xorg.conf is busted
airlied: nilsson: not with F12
nilsson: xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.x86_64
airlied: okay if rotate is broken I haven't fixed it yet
SnowRaptor: airlied: here, thanks: https://bugs.freedesktop.org/show_bug.cgi?id=27008
airlied: try just notdoing the rotate with that xorg.conf
nilsson: just comment out Option "Rotate" "left" ?
airlied: yes
nilsson: ok, be back in a sec
EruditeHermit: airlied, ok when using the VGA out in clone mode there is corruption on the primary head. This is probably a different issue but just wanted to let you know.
EruditeHermit: airlied, after s/r with VGA connected, the VGA looks like that picture I posted before with the lines
airlied: is X running at 99% cpu or anything?
airlied: or can you chvt away back
EruditeHermit: X is not running at 99%
EruditeHermit: how do you want me to chvt
airlied: run chvt 5 as root in ssh
EruditeHermit: in my ssh shell?
EruditeHermit: ok
nilsson: now it looks really weird, like it's sheared to the right
EruditeHermit: airlied, no change
EruditeHermit: airlied, did you want me to chvt to the VT with X on it?
EruditeHermit: I think its 7 or 8 in Ubuntu
EruditeHermit: or even 9
EruditeHermit: 5 is a console
nilsson: iirc it's 7
airlied: EruditeHermit: away first then back
EruditeHermit: yeah nothing
EruditeHermit: the screen backlight isn't even on I think
airlied: EruditeHermit: on the VGA? still same?
EruditeHermit: oh you mean on the VGA
EruditeHermit: my bad
EruditeHermit: let me see
airlied: yeah I think getting VGA working first is probably the best plan
airlied: LVDS might take some persuading
EruditeHermit: lol
EruditeHermit: LVDS is the important one
SnowRaptor: airlied: thanks for the support, I'll check back here, probably with a better description of the bug. Maybe a video :)
airlied: SnowRaptor: yeah that mighr help
SnowRaptor: ok, thanks, c ya!
EruditeHermit: airlied, so after chvt it still shows the coloured vertical stripes as shown in the picture I took attached to the bug. However immediately after resume there was a square box that would move with the mouse. After chvt, the box is frozen and no longer responds to the mouse movement
nilsson: airlied, why doesn't xorg need the Virtual Size anymore?
airlied: nilsson: because with kms we get dynamic memory management
nilsson: ok
airlied: virtual was only a hack because we had to statically allocate everything in advance