flyback: bleeds everywhere from catching his big 12 inch feet on the side of a pc case
cxo: you've been bleeding all day today, are you on your period or something?
flyback: na just a klutch
flyback: na just a klutz
happycube: awesome... progs/redbook/texgen is working w/r300g now. :)
|JohnDoe|: ubuntu 9.10 Linux 2.6.31-02063106-generic driver opensource ATI Technologies Inc RS482 [Radeon Xpress 200M]
|JohnDoe|: glxgears well. 3D wine (bench play on linux, counter-strike) applications blink.
cxo: when I was in highschool I worked for a computer company as a technician, would cut myself so often. circuits were BLOODY SHARP back then
EruditeHermit: airlied, were the new files readable?
|JohnDoe|: (II) RADEON(0): Built from git commit f17657fdc83d8f4c0386d2c7dade98de5b94acbe
happycube: openarena runs cleanly on r300g too :)
hifi: cxo: learning from my hobby I'd never build computers as my job, never
|JohnDoe|: no :( out after run level
cxo: hifi, haha, yeah
cxo: builds cars these days
hifi: just one weekend and my hands are full of cuts and bruises
|JohnDoe|: http://pastebin.com/m677553d4 xorg.conf
cxo: happycube, want fps do you get?
cxo: that reminds me of this funny incident. I went for coffee with this female friend the other day, and she had her laptop, and wanted to get onto the internet and asked me to do it.
cxo: I had no friggin' idea in hell how to get Vista or Win7 or whatever that was onto the internet
cxo: felt so embarrassed
soreau: happycube: What do you mean by cleanly and what card are you testing with?
happycube: rv515... not incredibly fast, but cleanly=everything *looks* ok
happycube: etracer still overflows the CS tho
eosie: happycube: really? great
amarks: http://pastebin.com/m23a65bf5 - why does it not pick 2560x1600 by default?
amarks: does it just choose the last modeline?
amarks: xrandr doesn't even show 2560x1600 :/
amarks: where does xrandr get it's possible modes from?
MostAwesomeDude: Long story short, the video card gets them from the monitors.
amarks: radeon is doing the right thing, then xrandr (krandrtray) is going and setting to a different mode
amarks: unless i manually put 2560x1600 mode in xorg.conf
MostAwesomeDude: Well, if a userspace app wants to change the mode to something else, that's its problem.
amarks: why would a valid mode not show automatically in xrandr
amarks: the DDC gathered modelines are not in order, i.e. 2560x1600 is shown first then the rest, should that matter
cxo: your screen can do 2560x1600? what screen is that?
amarks: NEC 3090WQXi - just arrived
cxo: Can it do 2560x2048 (regular 4:3)
amarks: that is not a reported modeline
cxo: one day, when i stop spending money on cars, i'll get a nice screen
amarks: i am not used to this size monitor, it is frigging huge
cxo: need to move your head?
cxo: damn thats an expensive screen
cxo: how much did you pay for it?
hnsr: should be possible to add modes through randr, kinda weird that it is not picking it up though
cxo: you obviously have a video card that can do that res?
cxo: Some monitors have crappy EDID info
cxo: you might have to set the mode yourself
agd5f: flyback: tv-out always sends the native mode based on teh tv standard. the "mode" is just the desktop of a certain size scaled to the native timing of the tv standard. right now only scaling from 800x600 is implemented
cxo: I thought 800x600 is the TV standard
Pallokala: you have PAL, NTSC or something else
Nightwulf|work: hi all
EruditeHermit: ossman, hey
ossman: EruditeHermit, yo
glisse: ;win 5
EruditeHermit: airlied, I get the same result when I boot kms, stop X suspend from console and wake up again.
EruditeHermit: airlied, how do I unload radeon module after booting? It keeps saying its in use when I try
glisse: echo 0 > /sys/class/vtconsole/vtcon1/bind
glisse: as root
EruditeHermit: then modprobe -r radeon will work?
EruditeHermit: or must I unload fbcon first
glisse: yup will work
EruditeHermit: ok will try that now
amarks_: how do i tell kms to rotate my screen on boot?
EruditeHermit: very weird
EruditeHermit: airlied, does this mean anything to you? http://paste.ubuntu.com/326005/
EruditeHermit: I was able to unload radeon modesetting driver
EruditeHermit: it turned the backlight on
EruditeHermit: but I couldn't see anything
EruditeHermit: so I did modprobe radeon modeset=1
EruditeHermit: then I got the VT back with text I could see and that message was printed on it
EruditeHermit: when I then tried to do service gdm start, it freaked out and started blanking and unblanking the screen at which point I had to turn the power off to restart
EruditeHermit: why is it trying to call r100 commands?
glisse: EruditeHermit: agp ?
EruditeHermit: btw nice spelling of "failled" on the print debug =p
glisse: try loading radeon with agpmode=-1
glisse: EruditeHermit: yeah i am not native
glisse: and i am terrible with spelling
EruditeHermit: oh its a typo, nothing to do with native or not
glisse: even in my native mothertongue
EruditeHermit: glisse, so when do you want me to load with agpmode=-1
EruditeHermit: on the first boot or after resume
EruditeHermit: or both
glisse: well after resume is the most important
EruditeHermit: and why is it doing r100 commands for my rv350
glisse: the agp bridge likely doesn't come back in healthy state after resume
glisse: because r3xx gpu use the same cp as r1xx
EruditeHermit: so I boot with radeon.modeset=1
EruditeHermit: unload radeon
EruditeHermit: modprobe radeon modeset=1 agpmode=-1
Zajec2: what is CF?
glisse: to suspend you can do: echo -n mem ? /sys/power/state
glisse: thus we know nothing weird like vbetool get in the way
glisse: .win 17
EruditeHermit: what does the -n and ? do?
EruditeHermit: I thought it was echo mem > /sys/power/state
glisse: don't output the trailing newline
glisse: both should work
EruditeHermit: will try
glisse: oh it's echo -n mem > /sys/power/state
glisse: not ?
Zajec: how can I ask "git log" to show real order of commits?
Zajec: like what "git bisect" uses
jcristau: well. commits aren't linearly ordered.
glisse: git log always shows in chronological order
Zajec: glisse: i see two commits one by one in "git log"... then I fire git bisect on them (one as bad, one as good)
Zajec: and bisects see some magic commits that should be checked :|
glisse: bisect use divide to conquer tactis
glisse: you need to use git bisect skip
glisse: when you cna't test a commit
Zajec: glisse: yeah, that gave me 6 commits
EruditeHermit: glisse, so when I did echo mem /sys/power/state instead of pm-suspend, it didn't bring the backlight back up on resume
EruditeHermit: so that didn't help
glisse: does doing vbetool post helps ?
EruditeHermit: brings the backlight back
glisse: so we are not doing what the bios is doing
glisse: EruditeHermit: i am sure you already provided enough information
glisse: it's now just a matter of finding what we are missing
EruditeHermit: we have been unable to figure out exactly what though
EruditeHermit: airlied just mentioned to try this next
glisse: try what ?
EruditeHermit: unloading the module and s/r
glisse: EruditeHermit: well do unload s/r vbetool reloadmodule agpmode=-1 and report but i expect that this will give you a working setup
EruditeHermit: glisse, no error message on terminal when I loaded radeon modeset=1 agpmode=-1 but when I tried service gdm start afterwards, it started X but there was no output to the screen so I got the white LCD cloud when pixels relax to random state
glisse: did you get a working console after vbetool post ?
EruditeHermit: I could VT switch back to a working console
EruditeHermit: and reboot
glisse: after loading kms did you get a working fb console ?
EruditeHermit: although it seemed to be very small
EruditeHermit: as in
EruditeHermit: it was only in the top left corner
EruditeHermit: maybe at 800x600
EruditeHermit: whereas my screen does 1920x1200
glisse: does kms works before s/r ?
EruditeHermit: I am making up 800x600 but it was only filling the top left corner
glisse: what is the xorg log ?
EruditeHermit: kms works before s/r
EruditeHermit: and it works at 1920x1200
EruditeHermit: what do you want from the xorg log?
glisse: attach it to the bug
glisse: a working kms xorg log
glisse: and the non working one
EruditeHermit: so I never get to Xorg after resume
glisse: still their must be a log
EruditeHermit: i'll try
Zajec: glisse: you wrote in bug report my r600 debugfs ring info should be upstream
Zajec: glisse: which git should I watch? drm-next is quiet
glisse: drm-radeon-testing iirc
glisse: but i think i saw the patch pushed to Linus
glisse: well in one of the pull request
Kano: agd5f: why do you think telling somebody to use overide x y is a good idea? there are noobs out there that have got really no idea how to do that when there is no X running. you have got guide em really every step and that takes ages
Kano: agd5f: if you dont like a general override add a new colum to the csv file and use that for pcie override entries per pci id
Kano: but forget telling somebody to use an overrride when the chip is known that has got problems
EruditeHermit: glisse, submitted the logs to the bug
EruditeHermit: glisse, https://bugs.freedesktop.org/show_bug.cgi?id=23103
glisse: EruditeHermit: your ddx is not build with kms support
glisse: please test fedora 12 livecd will be easier for us to know that you a proper userspace
EruditeHermit: glisse, I already did and had the same problem
EruditeHermit: glisse, it should be built with kms support
glisse: it's not
glisse: log shows that it's doesn't know what to do with kms and that it overwritte kms setup
glisse: this explains why it doesn't work after suspend
glisse: if fbcon works, X will work
EruditeHermit: but I tried with fedora live CD and still had issues
EruditeHermit: the main issue is not with X but with the kms not turning the backlight on when resuming
glisse: i am not saying you bug doens't exist
EruditeHermit: we have to go through so many manual loading/unloading to get a working backlight
EruditeHermit: brb 1 sec
bjacques: Is it expected that there are no X visuals available for multisampling with an r520 using the free radeon driver?
glisse: we don't support multisampling
EruditeHermit: glisse, got to sleep now, thanks for the help today
bjacques: I see. Do you expect to implement it?
glisse: you welcome
EruditeHermit: hopefully you have enough info to figure something out =p
EruditeHermit: i can do some fedora livecd testing tomorrow
EruditeHermit: if necessary
glisse: bjacques: yes, but i think it's low priority for most people
bjacques: glisse: okay, thanks very much for the info.
kdekorte_: Is there a howto for building mesa with gallium/r500
chithead: kdekorte_: pass --enable-gallium to configure
kdekorte_: I did, but I was not sure if I got it or not
kdekorte_: I don't see 300g in glx-info
soreau: kdekorte_: I build with --with-dri-drivers="" --enable-gallium-radeon --with-state-trackers=dri,glx then cp $PREFIX/lib/dri/radeon_dri.so $PREFIX/lib/dri/r300_dri.so and set LIBGL_DRIVERS_DIR=$PREFIX/lib/dri
kdekorte_: soreau, thanks
kdekorte_: soreau, interesting.. but not real usable at the moment
soreau: kdekorte_: Depends on what you're trying to use..
soreau: Works mostly fine with 'basic' things like compiz
kdekorte_: grey or garbage when using clutter
soreau: but it obviously has trouble with textures and stuff
kdekorte_: and it is slower with glxgears
soreau: bah, who cares?
soreau: There's plenty of room for improvement
kdekorte_: yeah, it was interesting to see...
kdekorte_: I'll probably build it now and then to see how it is shaping up
Wizzup: Does 32-r8 include 3d support, or do I need to check out additional branches?
agd5f: Wizzup: contains 3d support
Wizzup: Thx, will try now
hifi: waits for his HD 4650
rhodan: waits until he earns enough money to buy a faster machine.
rhodan: I need more resolution, too. My panel only does 1400x1050.
soreau: rhodan: Only?
rhodan: soreau: Only.
soreau: I've never had higher than 1280x1024
rhodan: 1400x1050 is the bare minimum for me. I couldn't work with less.
cxo: my laptop does 1440x1050, but i dont use it
rhodan: Too bad they don't make high-res 15"-Screens anymore.
PsyMan: sure they do
cxo: i thought of selling it to one of you guys cheap, its got an R300 i think in it
Lutz_Ifer: ← 2560x1024
cxo: 1024 gross
cxo: at 2560 you should be packing 2048 on the vertical
soreau: I have updated mesa to latest afaik (emerge mesa-9999) but I still am seeing Mesa 7.7-devel. Is this correct?
soreau: Testing gallium, I see 7.8-devel
cxo: Mine says " GL_VERSION: 1.5 Mesa 7.8-devel"
soreau: I wonder how it's still using old mesa
cxo: make clean
soreau: emerge handles all of that
soreau: ls shows /usr/lib/dri/r300_dri.so and /usr/lib/dri/radeon_dri.so were just installed..
soreau: But /usr/lib/xorg/libGL.so.1.2 is not :P
soreau: hmm, this can't be right
hnsr: soreau, was getting that too on gentoo
Wizzup: No Framebuffer driver for KMS, no?
Wizzup: (uvesafb etc)
soreau: hnsr: Getting what?
hnsr: it worried me because I got the impression lots of stuff that was supposedly fixed wasnt fixed for me
soreau: hnsr: Did you find out how to fix it?
hnsr: yeah I deleted the git clone under distfiles, that seems to have fixed it, but im not sure why
hnsr: since it does a clean checkout I think everytime you emerge it
hnsr: a;sp. O dpm
soreau: I think it saves some info and does a git pull based on that but I'm not sure
hnsr: also, I don't have a libGL there, mine's under /usr/lib/opengl/xorg-x11/lib/
hnsr: linked from /usr/lib/
glisse: Wizzup: there is already a framebuffer with kms its call radeondrmfb
glisse: it doesn't print as an option in the framebuffer driver, it's activated by default with kms
soreau: hnsr: Ok thanks
cxo: the configure.ac for drm was written really badly
cxo: contemplates rewriting it
tmoertel: DRI isn't working for me because "Direct rendering is not supported when VGA arb is necessary for the device". Any way I can get around this problem?
soreau: tmoertel: using kms??
tmoertel: soreau: no, turned off w/ kernel param "nomodeset"
soreau: Does it work with kms?
tmoertel: kms causes other problems w/ my system, unfortunately
tmoertel: so I've never been able to test it w/ kms
kdekorte_: tmoertel, what the the other problems?
tmoertel: kdekorte_: boot-up (Fedora 12) seems to slow down to a crawl and the machine seems to freeze up
soreau: which card is this?
kdekorte_: And which kernel? I'm using F12 here as well
tmoertel: It's a "RV505 on a HIS Radeon X1550 PCI" (PCIe x1)
tmoertel: kdekorte_: Kernel = "Linux version 18.104.22.168-127.fc12.x86_64 (firstname.lastname@example.org) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) #1 SMP Sat Nov 7 21:11:14 EST 2009"
glisse: tmoertel: you opened a bug for that ?
kdekorte_: tmoertel that is the kernel I'm using on a couple of radeon machines.. and r6xx and r5xx machine..
tmoertel: glisse: not yet. didn't know if it was a bug or some config problem on my end
Wizzup: I get a black screen when trying to start X, and I can't get back to tty's either
glisse: tmoertel: am i right that your gpu board is a pci board not a pcie board ?
Wizzup: (KMS), 32-r8, xf86-video-ati-9999
kdekorte_: tmoertel, might try one of the newer kernels here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8
tmoertel: glisse: it's a pcie x1 board
kdekorte_: get the new libdrm as well too
tmoertel: kdekorte_: try one of those kernels *and* kms, right?
soreau: Wizzup: Did you compile libdrm with kms support then mesa, X and ddx after that?
Wizzup: Hmm.. probably not. Any chance of doing this with layman/portage?
soreau: Wizzup: Are you using x11 overlay?
Wizzup: I have it in my layman, yes
Wizzup: But not using everything from it
soreau: Well I assume xf86-video-ati pulled in libdrm and mesa 9999 packages?
tmoertel: kdekorte_: you think trying 2.6.32-0.51.rc7.git2.fc13, pulling from rawhide, is a reasonable next step?
Wizzup: soreau: not yet libdrm and mesa, will do now. Anything else?
kdekorte_: tmoertel, I would try the -145 kernel over the F13 one
soreau: Wizzup: Build libdrm 9999 first, then xorg-server, mesa and ddx (xf86-video-ati)
Luzipher: soreau: portage apparently didn't work right when switching from 7.7 to 7.8 ... or there was something odd in the git-repo ... my quick fix for getting 7.8 was to delete the local repo in /usr/portage/distfiles/git-src
kdekorte_: I think there are some problems with the F13 kernels
Wizzup: doesn't know what ddx is
tmoertel: kdekorte_: ok. (I'm in text mode now, so yum was my first choice of install)
kdekorte_: tmoertel, you can use this...
soreau: Wizzup: ddx = xf86-video-ati. Read the link in the topic
Wizzup: Will do
kdekorte_: koji download-build --arch=x86_64 --arch=noarch 142413
kdekorte_: to get those packages
soreau: Wizzup: and you might as well use xorg-server-1.7.1 if you aren't already
Luzipher: Wizzup: ddx is the X / 2D driver that does modesetting (in non-kms) and 2D accel afaik. It's radeon or radeonhd
kdekorte_: just run it in a new directory
tmoertel: kdekorte_: thanks! that will make my life much easier :-)
Wizzup: I was using that, until a few days back... But I guess I can start using it again
tmoertel: installs newer kernel and kernel-firmware . . .
tmoertel: is going to reboot into the newer kernel and try kms
tmoertel: kdekorte_: thanks for your help! I'm giving kms a try now.
kdekorte_: tmoertel, good luck
tmoertel: kdekorte_: :-)
tmoertel: OK. kms with the newer kernel didn't work, but I did get some clues.
kdekorte_: tmoertel, so? Any luck?
kdekorte_: tmoertel, does "dmesg | grep drm" show anything odd?
tmoertel: kdekorte_: no luck, but I did get a clue: kernel oops.
tmoertel: kdekorte_: radeon 0000:01:08.0: Invalid ROM contents
kdekorte_: tmoertel, open a bug in bugzilla.redhat.com, airlied is pretty good about fixing those..
tmoertel: kdekorte_: *ERROR* Unable to location a BIOS ROM.
kdekorte_: That is odd, do you have kernel-firmware installed?
kdekorte_: did you upgrade it with the kernel
tmoertel: kdekorte_: well, the plot gets thicker. Turns out this machine has a built-in low-end radeon, and that's what's causing the oops.
tmoertel: My RV505 is in PCI slot 4 (note the 01:08.0 above)
kdekorte_: tmoertel, might be a weird pci id, that needs to be added
tmoertel: Is there any way to tell the kernel to ignore the card in slot 0000:01:08.0 ?
kdekorte_: tmoertel, make sure you post your lspci output when reporting the bug
kdekorte_: tmoertel, can you disable it in the BIOS?
tmoertel: kdekorte_: let me check
kdekorte_: tmoertel, also might be a jumper on the MB
tmoertel: kdekorte_: nope, no way to disable the built-in radeon via BIOS. It's a DELL tower server that I'm using as a workstation, so the video is the build-in server video.
tmoertel: kdekorte_: If I disable kms, the video works but is slow because DRI doesn't work.
tmoertel: Explanation from log: "Direct rendering is not supported when VGA arb is necessary for the device".
tmoertel: kdekorte_: doesn't look like there's a jumper to disable the onboard video.
kdekorte_: tmoertel, what model Dell
kdekorte_: Never seen one that can't be disabled
cxo: its usually done in the bios
tmoertel: kdekorte_: PowerEdge T105
cxo: if the board detects a video card, it automagically disables the onboard one
tmoertel: cxo: for some reason it appears that the kms logic finds the onboard video and has problems interrogating it
kdekorte_: tmoertel, might try this: http://support.dell.com/support/topics/global.aspx/support/dsn/en/document?c=us&cs=04&l=en&s=bsd&dn=1033493
tmoertel: kdekorte_: that's for dimensions. the server setup screen is much more limited and has no video section.
cxo: no matter what you do its still physically on the bus. Just not enabled
cxo: the KMS driver should take into account for this scenario
tmoertel: cxo: do you know of any way to tell the kms driver, by way of kernel args, to ignore the card at a certain pci addr?
cxo: bug report time
cxo: I dont think there is a module param for that
cxo: both cards are radeon?
tmoertel: the on-board video is "01:08.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)"
tmoertel: the card is "04:00.0 VGA compatible controller: ATI Technologies Inc RV505 [Radeon X1550 Series]"
tmoertel: cxo: where should I report the bug? fedora? somewhere else?
kdekorte_: tmoertel, yeah you're gonna have to open a ticket on that. bugzilla.freedesktop.org or bugzilla.redhat.com should be ok
tmoertel: I'll go w/ redhat, then, since I already have an account.
tmoertel: thanks for your help.
kdekorte_: I read the manual for the T105, there is a new bios for it.. http://support.us.dell.com/support/downloads/format.aspx?releaseid=R231255&c=us&l=en&cs=04&s=bsd but not sure that will help
tmoertel: I installed that BIOS earlier today. ;-)
tmoertel: kdekorte_: should I report the bug against the kernel?
adamk_: So has libdrm changed repos yet? I see something on the mailing list about Kristian rebasing it in ~/krh/libdrm...
agd5f: adamk_: it's still in the same repo. the kernel bits are gone now though
soreau: hnsr: That worked, thanks again
soreau: So classic mesa has updated the gl version string to 2.1 as well...
soreau: I wonder why :P
hnsr: to make things exciting!
adamk_: agd5f: Would that explain why libdrm no longer compiles on FreeBSD? It's actually looking for linux specific headers.
gimzo: when will r300 get gl 2 ?
MostAwesomeDude: When nha and I finish it.
gimzo: is that a day away or a month, or 6 months ?
MostAwesomeDude: Full GLSL support is a ways off. Enough GLSL support to do basic things should be there already in Gallium.
gimzo: with gallium I only get black screen with reddish squares in place of xbmc :)
gimzo: so I'll wait a bit more
MostAwesomeDude: Uf, XBMC.
gimzo: the only thing I tried, besides glxgears which works perfectly :)
tmoertel: kdekorte_: bug submitted: https://bugzilla.redhat.com/show_bug.cgi?id=540593
gimzo: I'll test with openarena and the like, when I find the time
MostAwesomeDude: Well, file a bug if you like.
agd5f: adamk_: libdrm should still compile
gimzo: what does happen when I file a bug, I guess you have enough work in it even without reported bugs ?
adamk_: agd5f: Yeah, not on FreeBSD any more :-)
agd5f: adamk_: probably want to let krh know
MostAwesomeDude: gimzo: r300g bugs aren't guaranteed to get fixed in any timeframe, but I *do* accept them.
adamk_: Hmm... I let rnoland know on #dri-devel. I can send an e-mail to the mailing list though in reply to his most recent e-mails about the libdrm changes.
Wizzup: What is usual performance? I'm getting 1.2k on glxgears with kms, and 2k without. I remember getting a lot more. 4670 HD
MostAwesomeDude: r600's still not very optimzed. Also GINAB.
cxo: tmoertel, bug airlied about it a 100 times and he'll look at it. RedHat is used on Dell servers quite often
cxo: MostAwesomeDude, how much "optimisation" do you need for GLXGEARS!?
MostAwesomeDude: cxo: You'd be surprised. It's possible to squeeze OVER 9000 FPS out of older cards.
hifi: please do that :D
soreau: It's not too difficult if you resize the gears window to smallest possible.
soreau: MostAwesomeDude: Since when are you advocating it's a benchmark :/
cxo: soreau, why not just minimize it then?
cxo: what hifi said, now!!!! :)
adamk_: It should just be eliminated altogether.
MostAwesomeDude: soreau: I'm not. I'm noting how easy it is to get silly numbers.
MostAwesomeDude: The X850 used to do ~8000 FPS with older infrastructure.
cxo: it is a benchmark when drivers are this crappy
MostAwesomeDude: Pfft. OA is a way better benchmark.
cxo: equally antiquated
Zajec: osiris: hi, do you have a moment for radeon?
Zajec: osiris: could you check http://bugs.freedesktop.org/show_bug.cgi?id=25197 ?
osiris: Zajec: hi.
osiris: one moment
Zajec: osiris: does my last comment (recent commit to mesa partly fixing openarena) makes any sense?
Zajec: osiris: (or is that just random, that I sometimes can start openarena's menu?)
soreau: ok, that was a fluke. classic mesa is still reporting gl1.5
Zajec: osiris: generally it seems it's that new tree mipmap code that started causing problems for me
hagabaka: is it a known problem that some characters get "corrupted" after a while using a recent version of X/radeon driver/kernel?
Zajec: osiris: so nothiing to bisect I'm afraid
Zajec: hagabaka: probably some EXA issue, not sure if it's know one or not
Zajec: hagabaka: just wanted to point to EXA
osiris: Zajec: I need to analyze the r600 code a little, I think there're bad things happening
otaylor: hagabaka: yes, it's known
hagabaka: is there a workaround?
otaylor: hagabaka: no
otaylor: hagabaka: https://bugzilla.redhat.com/show_bug.cgi?id=529081 is the fedora bug
otaylor: hagabaka: it got a lot better after airlied did some drm fixes, but there are residual problems
hagabaka: is it a problem in radeon or X or kernel? just so I can watch for new versions
otaylor: hagabaka: kernel and/or mesa
otaylor: hagabaka: See https://bugzilla.redhat.com/show_bug.cgi?id=529081#c57 for glisse's suspicions about mesa problems
Zajec: osiris: ok, if you need any testing, catch me here or write in bug report :)
Zajec: osiris: is that possible to revert mipmap patches from master?
Zajec: osiris: have ieda/
osiris: Zajec: I'll probably need some more debugging info from you.
osiris: Zajec: I think reverting the merge should just work
osiris: otaylor: could you update the status of #18212 and #24963?
otaylor: osiris: On the first, that was a one-off crash, not something I was hitting reliably
otaylor: osiris: On the second, I don't have a setup for testing upstream mesa at the moment; your earlier patches worked when applied to the Fedora 7.6 packages
Wizzup: MostAwesomeDude: GINAB?
MostAwesomeDude: Wizzup: Gears Is Not A Benchmark
otaylor: osiris: I can close the first one if you want (freedesktop doesn't have an INCOMPLETE status, but I can close it FIXED with a a comment)
osiris: otaylor: ok, I'll wait for report about the second one. you can close the first one, reopen if you'll hit it again.
cxo: Gears Is A Benchmark for unoptimized drivers
Jonathan_L: How do I set my Radeon driver to load with Kernel mode Setting on at boot? (to fix OpenGL and flickering issue)
soreau: Jonathan_L: Which distro?
Jonathan_L: I have asked before, but I haven't gotten an answer that works
cxo: build radeon into the kernel
Jonathan_L: Ubuntu 9.10.
cxo: drm, radeon and fbcon
soreau: Jonathan_L: You need to add radeon.modeset=1 to your kernel boot parameters.
Jonathan_L: Once I booted with recovery mode (Ctrl+Alt+F1 don't work, black screen only) and reloaded the driver manually, it worked great then
soreau: Depending on which version of grub you are using is how you would do this
Jonathan_L: soreau: Where and how? Last time I added that in some file
Jonathan_L: Wait - in grub? Then I have to add it manually every time the kernel is updated!
soreau: cxo: You can have radeon built into the kernel and disabled by default
soreau: Jonathan_L: Yes
cxo: soreau, why would it be disabled by default?
Jonathan_L: soreau: No other way? (I've got grub 1.93-something-beta)
soreau: Jonathan_L: It is not default in ubuntu yet so you would have to do it this way or build your own kernel
Jonathan_L: I'm not building a kernel
soreau: cxo: I am just saying, building it into the kernel does not necessarily mean it will be enabled
cxo: at the moment, it does
otaylor: Jonathan_L: the grub updating scripts in Fedora keep kernel options when adding new kernels, don't know about Ubuntu
Jonathan_L: soreau: Which file to edit?
Jonathan_L: otaylor: How?
cxo: Jonathan_L, i think 2.6.31-15 or whatever comes with 9.10 is too old. I'm using 9.10. Check the wiki on the topic
soreau: Jonathan_L: /boot/grub/menu.lst
Jonathan_L: I'll check if it's the same here
stikonas: no, it's /etc/default/grub
soreau: Jonathan_L: cxo is wrong
stikonas: if you are using grub2
otaylor: Jonathan_L: Don't know the exact details, but I think they just look at the command line for the previous kernel, and use that to build the new one
soreau: stikonas: You are wrong. He is using grub1
Jonathan_L: soreau: Not anymore, this is using 1.93 something
Jonathan_L: grub2 here
Jonathan_L: Fresh install when I got 9.10. (kept /home)
soreau: Jonathan_L: Ok, here: http://www.cairo-dock.org/ww_page.php?p=ATI%20cards&lang=en
soreau: That happens to tell you how to do it for grub2
cxo: soreau, http://www.x.org/wiki/radeonBuildHowTo#head-a6271d23a9199673cea21478e0198d772a55fad3
Jonathan_L: I'll check
soreau: Why the hell they name grub2 when it's 1.93 we may never know
cxo: soreau, you need to add drm-next yourself if you want it to work on 2.6.31
soreau: cxo: I guess you are misunderstanding. Check the staging drivers section
osiris: Zajec: apply this patch and run the openarena with RADEON_DEBUG=tex
soreau: You can build the kernel with radeon built in and have kms disabled by default
osiris: Zajec: http://pastebin.ca/1684060
Jonathan_L: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.modeset=1" ??
cxo: soreau, you can. But thats not the case
cxo: modeset is enabled by default already
soreau: cxo: The whole point is, he asked how to enable kms and you said build radeon into the kernel = wrong.
cxo: You're treating a symptom soreau , not the problem
cxo: his kernel is too old
soreau: No it is not.
cxo: "But kernel has to be from Dave Airlied's drm-next branch that will be merged to 2.6.32. "
soreau: Karmic has radeon kms caps, you just need to have radeon load with modesetting
Jonathan_L: I HAVE KMS working, it's just NOT ENABLED by default. As I said, it worked when I rebooted and reloaded the driver with modesetting on
Zajec: osiris: compiling, i saw HUNK with offset 7 lines, but hope it will be alright
Jonathan_L: If this works - thanks you!
soreau: cxo: Also, the wiki is already out of date and needs updating
Jonathan_L: Now, just a question: "sudo update-grub -- Generating grub.cfg ... -- No path or device is specified.
Jonathan_L: Try ``grub-probe --help'' for more information."
Jonathan_L: What does that mean?
soreau: Jonathan_L: No idea. I have not confirmed this works for grub2
soreau: I haven't even messed with grub2 yet
Jonathan_L: soreau: Well, I'll try.
Jonathan_L: I'll be your guinea pig then ;)
soreau: cool :)
Zajec: osiris: http://pastebin.com/m251f3df5
Jonathan_L: Gonna reboot now
Zajec: osiris: crashed before menu, so probably should be even easier to debug (less messages)
Zajec: osiris: uh, some crazy values
Jonathan_L: fail :(
soreau: Jonathan_L: Did you get the update grub command to succeed?
Jonathan_L: Don't know
soreau: I don't see how you would expect it to work then..
mjg59: Jonathan_L: If update-grub isn't working, something is very wrong with your system
mjg59: Jonathan_L: You'd be better asking for help on that in an Ubuntu channel
Jonathan_L: It said device not specified or something before
soreau: or maybe there is a #grub too
[Enrico]: Jonathan_L: likely there is missing config in the grub config
Jonathan_L: grub.cfg ain't containing anything radeon
[Enrico]: Jonathan_L: so check /etc/grub.d/ and /etc/default/grub
mjg59: Or, more usefully, ask on #ubuntu
osiris: Zajec: I need one more with patch http://pastebin.ca/1684090
osiris: Zajec: revert previous one
Jonathan_L: Then what?
soreau: mjg59 is right. This really isn't the place to get help with grub related issues
soreau: Ask in your distros support channel or #grub if it exists
cxo: Ubuntu 9.10 uses /boot/grub/menu.lst
soreau: cxo: No it doesn't
soreau: If you upgrade from jaunty, it will not install grub2 however. A clean install will use grub2
Jonathan_L: only when you do an in-place install
Jonathan_L: That's why my laptop use grub2 while my parents' use grub
cxo: Ok, yeah Ubuntu-9.10 uses /boot/grub/menu.lst if you upgrade from 9.04
Zajec: osiris: http://pastebin.com/m78db8088
Zajec: big one
Zajec: osiris: that values are random
Zajec: Checking image level 0, face 0, mt 0x9e76890 ... MIGRATING
Zajec: miptree level 0
Zajec: width 0 vs 512
Zajec: height 2048 vs 512
Zajec: depth 0 vs 1
soreau: nha! :)
Zajec: osiris: sometimes I even get total wrong numbers like
Zajec: width -1210694656 vs 512
Zajec: height -1210694656 vs 512
Zajec: depth -1210694648 vs 1
nha: finished my qualifying exam today, yay :)
Zajec: osiris: and sometimes openarena starts with menu, so that is random
osiris: nha: congrats!
soreau: nha: That sounds like great news :D
osiris: Zajec: try doing make realclean before building
Zajec: osiris: do you mean "make realclean"? i did make clean && make -j 4 && su -c 'make install'
hagabaka: is anyone else able to use framebuffer console in rc6 kernel but not rc7 or rc8?
osiris: Zajec: yes, make clean doesn't always clean all the stuff
Zajec: uh, hate mesa for that one
Zajec: ok, make realclean, autogen, make, make install this time
osiris: Zajec: one more time http://pastebin.ca/1684143
Jonathan_L: sudo apt-get install checkinstall, then you do make checkinstall instead of make install
Zajec: osiris: http://pastebin.com/m26ed638e
Zajec: uhh :p
Jonathan_L: then you can uninstall with apt, instead of make uninstall
Zajec: it's from old one
Zajec: osiris: give me sec, compiling with last patch
osiris: Zajec: ok
Zajec: osiris: http://pastebin.com/m2d379725
agd5f: Zajec: IIRC, mesa doesn't build properly with make -j
Zajec: agd5f: oh, one more issue?
Zajec: good to know, huh
kdekorte_: agd5f, really, I use it with -j 4
agd5f: kdekorte_: didn't used to unless it was fixed recently
Zajec: osiris: does it find wrong mipmap? i can see "Found matching miptree 0x9ea4128" but there is not any other 0x9ea4128 in log
kdekorte_: sometimes I need to use make clean first, but I think that is just due to bad Makefile.am files
osiris: Zajec: I think I've found the bug
agd5f: osiris: btw, did you sort out what you were looking for on r600 lod bias?
Zajec: osiris: :)
Zajec: interesting it's just limited amount of ppl hitting that...
osiris: Zajec: replace mts[mtCount++] = img->mt; with mts[mtCount] = img->mt;
osiris: Zajec: in get_biggest_matching_miptree
osiris: agd5f: hmm, I don't remember what was it anymore :P
Zajec: osiris: :)
Zajec: osiris: was too lazy to clean again
Zajec: osiris: worked with just make
Zajec: will rebuild for sure
airlied: nha: congrats
osiris: Zajec: no need to make clean now
osiris: Zajec: only when you're switching branches, any many files are changed
nha: thank you :)
osiris: Zajec: *and
Zajec: osiris: ok :)
Zajec: osiris: have idea why you did not hit that?
Zajec: osiris: that should affect everyong, shouldn't it?
osiris: Zajec: somehow calloc doesn't zero out the memory for you
Zajec: uh... wow
Zajec: osiris: but that's real fix.... is it?
osiris: Zajec: does it work?
Zajec: osiris: yup, worked once, was playing openarena for 1min
Zajec: starting again
osiris: Zajec: then yes :)
Zajec: demo benchmark worked again
Zajec: next time, works great ! :)
Zajec: osiris: believe it's real fixing my issue
Zajec: osiris: can you commit that?
osiris: Zajec: sure, in a minute
Zajec: or want me to do more testing...?
Zajec: ok :)
Zajec: osiris: i guess this issue was merged to master from 7.7... so will probably need to patch both
Zajec: issue -> mipmap rework
osiris: Zajec: no, I'll push it to 7.7, then 7.7 will be merged to master
Zajec: will work as well ;) ok
Zajec: osiris: thanks a lot for your help and fixing
osiris: Zajec: np, thanks for testing
osiris: nha: so how should we call you now? doctor Nicolai? ;)
nha: no, no, just *qualifying* exams
nha: there's a long way to go still from here to "doctor" or anything like that
osiris: nha: what does it qualify you to?
nha: it's something you have to do here at the end of the first year of the phd to be fully accepted
nha: it includes presenting a research plan and presenting it, etc.
osiris: ok, I get it know
osiris: Zajec: what machine and os do you have?
Zajec: osiris: openSUSE 11.2 with self-compiled drm-next
Zajec: notebook Sony with M82 == RV620
kdekorte_: Zajec, 64bit?
Zajec: 32bit system, but 64bit processos if that matters
osiris: Zajec: does it have an hardened kernel or glibc?
Zajec: osiris: sry, what are both?
Zajec: don't know that
osiris: Zajec: nevermind
agd5f: Zajec: does it work unpatched if you make clean and rebuild without -j 4
osiris: Zajec: according to C spec, the calloc doesn't actually fill the allocated memory with zero if you're allocating memory for pointers
osiris: Zajec: it allocates the memory with null ptr values for that case
osiris: Zajec: which doesn't have to be 0
osiris: Zajec: and that's what's happening probably in your case
Zajec: agd5f: revert, realclean, autogen, make... in progress
osiris: Zajec: try writing simple program that just prints nullptr
Zajec: osiris: using calloc?
Zajec: osiris: or just *pth = NULL;
osiris: Zajec: no, just fprintf(stderr, "nullptr %p, %d\n", NULL, (uint32_t) NULL);
airlied: unless you are running on something made of bongs, cray(??)
Zajec: osiris: nullptr (nil), 0
osiris: then I don't know why calloc isn't filling the allocated memory with 0
osiris: airlied: any ideas?
Zajec: agd5f: "make" (without any -j) doesn't fix that
kdekorte_: airlied, I'm still occasionally getting the white line at the top of the cursor btw
osiris: Zajec: try printing some memory allocated by calloc(4, sizeof(int *))
airlied: osiris: its not getting reused later or something?
Zajec: osiris: did you mean
Zajec: int *ptr = calloc(4, sizeof(int *));
Zajec: fprintf(stderr, "ptr %p, %d\n", ptr, ptr);
airlied: where is the code?
Zajec: that gives: ptr 0x804b008, 134524936
airlied: kdekorte_: yeah I saw it once, no idea where it came from
Zajec: airlied: vim src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
osiris: Zajec: no, print ptr, ptr
osiris: airlied: lol, I totally forgot to free the memory
Zajec: ptr (nil), 0
Zajec: ptr (nil), 0
Zajec: for  and 
osiris: airlied: I would never thought that it could lead to such problems
airlied: also its off by one I thnk
airlied: if first is 3 and last is 6, num levels is 3
airlied: but the loop goes from 3- <= 6
airlied: which is 4 levels
osiris: airlied: yeah
osiris: good catch
osiris: Zajec: I've pushed the fix
amarks: are you guys running mesa HEAD? r600?
ossman: I am
ossman: HEAD from yesterday at least
amarks: has that major redraw issue been fixed?
kdekorte_: amarks, what major redraw issue?
ossman: I haven't seen any redraw issues here
amarks: move a window around and watch the artifacts appear
kdekorte_: amarks, fixed long time ago
amarks: are you sure? i saw it the other day
kdekorte_: I have not seen it for months
amarks: ok let me try HEAD again
kdekorte_: make sure you have the DDX as well
kdekorte_: and probably libdrm
amarks: yes i have the latest
amarks: as of last night
amarks: just not mesa
kdekorte_: amarks, what kind of card do you have?
kdekorte_: and what kernel?
Zajec: osiris: great, thanks :)
Zajec: osiris: do you want it to live in 7.7 for some time (testing by ppl) before merging to master?
Zajec: osiris: or could you merge 7.7 to master now?
Zajec: hm, i can see merging mesa_7_7_branch into... mesa_7_7_branch
Zajec: that git is too weird for me
amarks: kdekorte_: http://imagebin.org/72712 here, you can see mesa is rather broken
amarks: just tried HEAD
kdekorte_: amarks, have you tried something other than KDE?
amarks: no, i only use kde
amarks: who broke it!
amarks: it's completely ususable
kdekorte_: are you using the Opengl or xrender backend?
amarks: it is set to opengl but it is rather sluggish
kdekorte_: So this is a new problem that just started?>
amarks: yes it is a regression
kdekorte_: osiris, is the patch you just did, could it fix amarks issue?
kdekorte_: amarks, have you tried bisecting the problem with git?
kdekorte_: that would be quite helpful
amarks: yes i did, it appeared to be 2198497203ec427f836978098028abf3350e5e57 but it's all ifdefd?
osiris: Zajec: merged
osiris: kdekorte_: and what's the issue?
amarks: so it did not make sense to me
Zajec: osiris: :)
kdekorte_: osiris, screen shot here: http://imagebin.org/72712
kdekorte_: amarks, new code just hit git, can you pull and try again
amarks: for mesa?
kdekorte_: amarks, yup
amarks: ok give me a sec
osiris: kdekorte_: probably no, but you won't be sure until you try :)
kdekorte_: osiris, it is amarks issue...
kdekorte_: just helping him out
amarks: no it is still broken
kdekorte_: amarks, did you restart KDE?
kdekorte_: amarks, run make distclean before building?
amarks: gentoo is building it from scratch when i emerge
soreau: amarks: hnsr notified me of an issue with stale 'stuff' being left over in portage distfile git directory
amarks: tsk tsk
amarks: i'll wipe the git src
soreau: If you are trying to emerge latest code, you should probably remove libdrm, xf86-video-ati and mesa from /usr/portage/distfiles/git-src then emerge the trio again
soreau: amarks: I did not appreciate to find this either but apparently I'd been running old mesa for some time now :P
Zajec: oh... anouther regression for wine game :|
amarks: soreau: how frigging ugly
soreau: looks over at chithead
MostAwesomeDude: Could anybody with an r300, using current git, grab the r300g-draw-buffers branch from my repo and confirm that e.g. glxgears still works? My r400's not in at the moment and I can't reboot.
MostAwesomeDude: I just want to make sure I'm not breaking things before I push to master.
soreau: MostAwesomeDude: I will
amarks: waits for git to do it's thing
soreau: MostAwesomeDude: Can you tell me exactly what I should do please?
MostAwesomeDude: soreau: It's two patches that should have zero effect on rendering.
spreeuw: present git works ok on r600 dri1 fyi
MostAwesomeDude: soreau: Add git://anongit.freedesktop.org/~csimpson/mesa as a source, fetch, and checkout the branch r300g-draw-buffers.
MostAwesomeDude: Alternatively, in cgit, just grab the two patches and apply them.
amarks: spreeuw: are you dri2 adverse?
soreau: MostAwesomeDude: Link to cgit for the patches?
spreeuw: not necessarily
spreeuw: how shoudl I enforce it?
MostAwesomeDude: soreau: The top two of http://cgit.freedesktop.org/~csimpson/mesa/log/?h=r300g-draw-buffers
spreeuw: someone said it was autodetermined mesa compiletime
amarks: soreau: is there a gentoo bug on this stale issue?
osiris: Zajec: what regression?
Zajec: osiris: didn't bisect yet, but wine game Tony Hawk Pro Skater crashes as soon as I start it
Zajec: osiris: earlier it crashed only on res change
Zajec: osiris: playing with defaul 640x480 was working fine
Zajec: as it's kind of wine crash, i don't get mesa erorr/backtrace
soreau: amarks: I have no idea unfortunately
Zajec: however should be possible to bisect
ossman: airlied, ping
Zajec: and hope it's not mitmap texture work regression ;)
soreau: MostAwesomeDude: I applied both to latest mesa master. Any special way to build?
amarks: soreau: bugger
MostAwesomeDude: soreau: Nope, just rebuild your r300_dri.so and test.
soreau: MostAwesomeDude: ok
soreau: MostAwesomeDude: Just to be clear, I am testing classic not gallium right?
MostAwesomeDude: soreau: Right. I tested the gallium side of this a while ago.
MostAwesomeDude: I just wanted these patches cleaned up so I could go back to blissfully not caring about them. :3
soreau: MostAwesomeDude: building
soreau: MostAwesomeDude: Curious, what made you think it may impact gears in anyway?
MostAwesomeDude: soreau: Not particularly gears. Anything with a non-trivial fragment program should work fine.
MostAwesomeDude: (Or segfault, if I messed up.)
MostAwesomeDude: You can try anything you like. This really shouldn't affect rendering; this is just me working around the fact that I can't shutdown for a few more hours.
amarks: right, so i wiped git-src, rebuilt the trio, still the same redraw issue. i notice if i move the window around very slowly, there is no articfacts, if it do it remotely like normal, artifacts as before
soreau: amarks: To be sure, glxinfo|grep nGL shows 7-8 devel, yes?
soreau: Well at least that is a good indication you have the latest code now
amarks: but is anybody else seeing the issue?
kdekorte_: amarks, not with gnome
kdekorte_: but I don;t have kde
spreeuw: will switch to kms dri2 too then
spreeuw: all I need to switch is libdrm right, with experimental, and then rebuild ddx and mesa
amarks: so cgit displays the commit order, can i trust that when using EGIT_TREE=xxxx emerge -1 mesa
spreeuw: per wiki
apexo: what's the state of power management with kms?
amarks: is EGIT_TREE pointing to the last commit i want included?
kdekorte_: apexo, Zajec is making progress, but as far as I know, nothing committed yet there was an article on Phoronix the other day
apexo: my new machine doesn't seem to like non-kms mode, so it seems i'm stuck with. the dynclocks module parameter doesn't seem to make a difference and with kms i seem to be using like 5w or so more that with forcelowpowermode
apexo: kdekorte_: okay, thx
MostAwesomeDude: soreau: Still building?
soreau: MostAwesomeDude: Something is not right.. compiz black screens and glxgears feels worse than swrast
stikonas: amarks: I have this issue with broken kwin
amarks: stikonas: on mesa HEAD?
stikonas: yes, latest git, but I have reverted some commit so I'm on my own branch to avoid this issue
MostAwesomeDude: soreau: Wait, performance dropped?
stikonas: amarks: I've reverted 286bf89e5a1fc931dbf523ded861b809859485e2.
amarks: stikonas: what did you revert?
soreau: MostAwesomeDude: This is with KMS. gears works but is slower than with swrast and compiz does not work at all (runs but with black screen)
MostAwesomeDude: soreau: Alright, thanks. Guess I'll need to get osiris to look at it.
soreau: MostAwesomeDude: Ok
MostAwesomeDude: osiris: Ping. Could you look at r300g-draw-buffers on my repo? It adds MRT fields to the fragment shader compiler, but appears to not work on classic.
mokoloko: I've heard about this magic repo for f12 that has the latest radeon stuff that should fix it's biggest issues with kde
mokoloko: you guys know it? :)
soreau: MostAwesomeDude: I'll report back if I find out I screwed up somewhere :)
osiris: MostAwesomeDude: sure thing
apexo: kdekorte_: oh. I'm still behind 5 days on phoronix's rss. that would explain why I didn't see the news yet. well, think I feel lucky, so I just patch it in :-)
MostAwesomeDude: osiris: It should be pretty simple; classic doen't attempt more than one MRT.
soreau: mokoloko: rawhide?
mokoloko: No I don't wanna go there yet :D
kdekorte_: mokoloko, I haven't heard about any repo... just koji has the latest packages
spreeuw: (II) [KMS] drm report modesetting isn't supported.
amarks: so a git tree at a particular commit is just that, a snapshot of the code base as of that commit?
soreau: amarks: more or less
stikonas: amars: have you fixed your corruption?
stikonas: amarks: ^^
amarks: stikonas: yes but it is not the same commit as you
stikonas: osiris: do you have any idea why 286bf89e5a1fc931dbf523ded861b809859485e2 can cause a corruption in kde?
amarks: up to 48dfd3938e428295c45692cfde0a2afff04a7970 is good, but if i set EGIT_TREE to the next commit 2198497203ec427f836978098028abf3350e5e57 the corruption is there
amarks: but it is all IFDEF DEBUG - is debug set?
osiris: stikonas: what gpu? are you using kms?
amarks: osiris: why would 2198497203ec427f836978098028abf3350e5e57 cause corruption on rv790
spreeuw: hmm why isnt my r600 loaded with kms
osiris: amarks: no idea
stikonas: osiris: KMS, OpenGL renderer string: Mesa DRI R600 (RV730 9480) 20090101 TCL DRI2
osiris: amarks: you should report a bug against mesa core
amarks: osiris: i assume we are not setting debug by default
Zajec: amarks: did you completly recompile mesa using each commit?
Zajec: checkout 1 && recompile
Zajec: checkout 2 && recompile
amarks: i set EGIT_TREE=xxxx emerge -1 mesa
Zajec: does it rebuild mesa?
amarks: to move around the commits, this is correct yes?
chithead: amarks: yes
amarks: Zajec: yes
Zajec: amarks: :|
chithead: amarks: if a commit is in several branches, you may need to specify EGIT_BRANCH too if you don't want to pull from master
amarks: i just don't understand why that commit is relevant
kdekorte_: using git bisect without all the gentoo stuff might be interesting as well
osiris: MostAwesomeDude: lol, glxgears is giving me 4fps
spreeuw: OpenGL renderer string: Software Rasterizer
MostAwesomeDude: osiris: :C
spreeuw: any idea why this is picked over r600?
spreeuw: trying out kms
kdekorte_: osiris, is the dri loading properly? Perhaps a missing symbol?
MostAwesomeDude: What mistake could I have made in only 40 lines? Hmm...
apexo: [ 0.664177] [drm] radeon: dynamic clocking initialized
apexo: now that's pretty cools
apexo: down from 24.5 to ~21.2w
osiris: MostAwesomeDude: it fallsback to software rendering somehow
kdekorte_: apexo, run it for a bit and see if you get 1. lower power and 2. no corruption
MostAwesomeDude: osiris: Maybe fragprog compiles are failing?
MostAwesomeDude: It *does* work on r300g.
apexo: not as good as without kms, but about half the way (without kms I was at 18w)
apexo: but that was with forcelowpowermode, and I think I "hacked" it for even lower freqs
kdekorte_: apexo, I think there is more to be done, once irqs are added to the r6xx driver
osiris: MostAwesomeDude: r300compiler error: get_used_ptr: index 32767 is out of bounds for file 3
spreeuw: zcat /proc/config.gz | grep KMS
apexo: kdekorte_: I guess there is no way to figure out the current power state (gpu/mem freqs)?
spreeuw: is that enough?
apexo: and/or what radeon kms thinks are the upper/lower bounds?
kdekorte_: apexo, thought there was something in debugfs
MostAwesomeDude: osiris: Ugh. That's completely unrelated to what I changed, which means unfun debugging lies ahead.
MostAwesomeDude: I guess I'll have to stare at it more later.
Zajec: apexo: there is, debugfs
Zajec: mount -t debugfs debugfs /debugfs
Zajec: cat /debugfs/dri/0/radeon_pm_info
Zajec: some say you should not mount to /debugfs... some idoelogy, but it works ;)
apexo: Zajec: ya thanks, just figured that out ;-)
Zajec: apexo, kdekorte_: we should downclock to lower value on many machines
apexo: engine clock: 337500 Hz
apexo: memory clock: 792000 Hz
Zajec: also should downclock memory which should be easy
Zajec: once we get IRQs
kdekorte_: Zajec, do you know if that patch has been committed anywhere yet?
Zajec: decreasing PCI lanes for DPMS off should be safe as well
Zajec: kdekorte_: no, I have to work on it still
Zajec: kdekorte_: just need 1 free day
apexo: Zajec: as long as dynamic upclocking is part of the plan (e.g. when I plug in my DVI) ... then that's great :)
kdekorte_: Zajec, I remember agd5f, was decreasing lanes in the DDX
Zajec: kdekorte_: yup
Zajec: just too many things to do, so it takes a long
Zajec: +learning, +work
kdekorte_: Still wondering when irqs will hit master
Zajec: today osiris fixed noticed regression, so 1 thing less ;)
Zajec: kdekorte_: hopefully days according to bridgman
Zajec: he wrote sth about doing it before thankgiving day...
kdekorte_: Zajec, oh nice..
Zajec: or whatever it's called, not sure
Zajec: afk working
kdekorte_: that is Thursday..
kdekorte_: Anyone have a google wave invite? I would like to try it out
amarks: osiris: i opened http://bugs.freedesktop.org/show_bug.cgi?id=25251
osiris: MostAwesomeDude: I believe that in set_pair_instruction you should set target like this pair->RGB.Target |= 1 << i
osiris: same for alpha
MostAwesomeDude: osiris: Ah, I see. Is OR the correct thing there? Is it legal to write to multiple MRTs in one inst?
kdekorte_: Any one looked at the pointblast demo.. the points are squares.. seems to happen on r5xx and r6xx
kdekorte_: the terrain demo looks good on r6xx, but the textures don't like up on r5xx
agd5f: kdekorte_: points are implemented as rects in the hw. you need to add support for aa points to make them round
kdekorte_: agd5f, yeah thought thats what the problem was.. seemed to be the Alpha was ignored
MostAwesomeDude: GL points are rects; GL AA points are ovals.
MostAwesomeDude: Yay for 3D. :T
kdekorte_: agd5f, where would you start on that issue?
agd5f: kdekorte_: there's a section in the latest r5xx guide about how to do it
agd5f: kdekorte_: you'd need to add some instructions to the fragment shader to deal with it
agd5f: you could use the coordinate stuffing to pass the coords though
kdekorte_: agd5f, hum... might have just went over my head, but I'll try
osiris: MostAwesomeDude: no idea
MostAwesomeDude: osiris: Yeah, it's not a bitfield.
MostAwesomeDude: It's 0-3.
MostAwesomeDude: We should probably make sure that it's in that range before setting it though.
osiris: then pair->RGB.Target = i
agd5f: MostAwesomeDude: mesa shouldn't try and use more than you tell it the hw can handle
airlied: ossman: ?
MostAwesomeDude: agd5f: Yeah, I think I may have subtly messed up by making a Gallium assumption.
osiris: amarks: I think you misbisected it
osiris: amarks: did you use git bisect?
amarks: osiris: no, i used EGIT_TREE=xxx emerge -1 mesa
amarks: for before and after
osiris: amarks: what does it do?
amarks: it is supposed to move back and forth through the commits
osiris: amarks: and how did you obtained the commit ids?
amarks: it does show the correct order yes?
osiris: amarks: nope
amarks: you're kidding!
osiris: amarks: actually yes, but only if there are no merges between branches
amarks: what is the point of it
amarks: ok but branch merges are shown too right
amarks: as an entry
amarks: osiris: do you agree that 2198497203ec427f836978098028abf3350e5e57 directly follows 48dfd3938e428295c45692cfde0a2afff04a7970
osiris: amarks: yeah, but commits that were merged get mixed with the commits of the branch that you're merged into
osiris: amarks: no
osiris: amarks: git tells that 219849~1 is dc41d62250ce51f28e94f1d365836ac9f2ff8907
amarks: so cgit is deceptive
osiris: amarks: to properly bisect it you should clone mesa tree, and use git bisect
amarks: i was trying to avoid getting into that
MostAwesomeDude: It's the only way.
stikonas: osiris: I get exactly the same corruption as shown in amarks's screenshot, but I have reverted 286bf89e5a1fc931dbf523ded861b809859485e2
stikonas: so it is definetely related issue
amarks: that touched r300, does that matter for r600?
osiris: stikonas: I don't understand. are you saying that reverting 286bf89 fixes the corruption for you?
stikonas: yes it does
stikonas: that commit also toches radeon_common.c
osiris: amarks: the change in radeon_common.c affects r600 too
amarks: i see
stikonas: ir changes something related to radeon_firevertices(radeon); though I have no idea what this really does.
osiris: stikonas: flushes current command stream to GPU
amarks: osiris: 48dfd3938e428295c45692cfde0a2afff04a7970 is more forward in master than 286...5e2 right?
stikonas: amarks: you can use gitk to have a graphical view of commits
osiris: amarks: I don't know how to check it
osiris: off for today
amarks: eix gitk: no matches, nice
stikonas: I think that 48fdf3 was introduced in parallel to 286...5e2
stikonas: and then 2 branches got merged
stikonas: amars: 48fdf3 is in line 132
chithead: I think you should file a bug so the issue does not get lost
fscan: amarks: i think you have to compile git with tk use flag for gitk
amarks: oh it is part of the git package
amarks: fscan: yes you are right, +tk for gitk
EruditeHermit: tormod, hey
aszlig: narf, still blank screen at startx :-/
tormod: EruditeHermit, hi, everything runs fine?
EruditeHermit: tormod, did you compile DDX with DRI2 support?
tormod: always did
EruditeHermit: glisse, was of the opinion that it was not when I showed him my logs yesterday
aszlig: hm, okay, maybe now someone could point me in the right direction, got that problem for a few weeks now :-/
aszlig: xorg.log without any errors
aszlig: dmesg without any errors
aszlig: (could post them here again if you want)
aszlig: mesa, dri and ddx all at latest git
tormod: EruditeHermit, it is a module loading issue, so the DDX check for DRI2 fails, see https://wiki.ubuntu.com/X/RadeonKMS
airlied: EruditeHermit: I didn't realise you'd be using a broken userspace
airlied: that won't have helped at all
tormod: EruditeHermit, you get the same error message as if the ddx was built without DRI2
aszlig: and ddx is definetly compiled _with_ modesetting support (as showed by the autoconf script)
EruditeHermit: airlied, what part of the log makes you think its broken userspace?
EruditeHermit: airlied, glisse said the same thing
EruditeHermit: but where in the log do you deduce that?
airlied: you haven't built it with kms support
EruditeHermit: tormod says that it is
airlied: Xorg.0.log.beforesuspend1 isn't a KMS driver
tormod: it is a myth that "RADEONDRIGetVersion failed" === built without KMS
airlied: tormod: no its not
airlied: tormod: not sure who told you that
EruditeHermit: Ah i think I know what it is
airlied: thats is in fact the you built without KMS error (yes it needs fixing)
EruditeHermit: tormod is right
tormod: airlied, I have seem this message myself
airlied: tormod: then you build without kms support
tormod: airlied, no :)
EruditeHermit: so what is happening is that whenever I boot, the first time I get software rendering
airlied: this isn't hard to work out
EruditeHermit: when I logout and back in, I get the DRI2 radeon Mesa working
EruditeHermit: perhaps its that which is showing up
tormod: airlied, it is a race
airlied: oh wait this is because the distro doesn't load dirvers?
tormod: airlied, the ddx checks for the drm stuff before it is loaded
airlied: now I know why I refuse to fix bugs on other ppls distros
MostAwesomeDude: tormod's right, but only because technically RADEONDRIGetVersion also fails when fglrx.ko is loaded. On the other hand, this is kind of noticable because it'll give versions like 8.54. :3
airlied: tormod: the point of kms is the driver is loaded before X starts
airlied: X shouldn't cause the driver to load
airlied: can ppl stop packaging stuff until the distro is able to actually use it?
EruditeHermit: airlied, no matter, I can get you good logs
EruditeHermit: the problem still stands
airlied: EruditeHermit: you can't if you start X at all, unless you modprobe radeon manually
cxo: So much Intel GPU mesa work. At this rate the i815 will be faster than an R700
airlied: once the UMS driver runs you've screwed the kms driver
airlied: cxo: most of the speed of 3D is in memory bw, so no.
cxo: airlied, i can get you the BEST logs!
cxo: cuts wood
aszlig: okay, and i'm a bit stuck with gdb, shouldn't gdb load the symbols from /usr/lib/debug in debian?
EruditeHermit: tormod, ok, adding fbcon to /etc/modules or /etc/initramfs-tools/modules doesn't work
airlied: add radeon to /etc/modules
airlied: really radeon should be loaded in initramfs
cxo: aszlig, symbols are in the files you're debuging itself. You need to have built the binaries with debug symbols
airlied: i.e. distro support require for kms not to suck ass
cxo: i think Ubuntu loads radeon in initrd
EruditeHermit: airlied, so add radeon modeset=1 to /etc/modules
EruditeHermit: should I put it in /etc/initramfs-tools/modules?
tormod: airlied, radeon is loaded before X starts in Ubuntu
airlied: tormod: so why is it not working?
airlied: the race can't exist if radeon is loaded
tormod: I don't remember exactly but there was something with fbcon loading
tormod: EruditeHermit, you see the KMS kicks in (small fonts) before X starts right?
EruditeHermit: ah well
EruditeHermit: not sure
EruditeHermit: there is the splash that obscures it
EruditeHermit: do you want my bootchart?
EruditeHermit: would that help?
aszlig: cxo: hm, shouldn't X use dl() for loading modules, so i guess gdb should be able to find these symbols, right?
tormod: EruditeHermit, no it doesn't appear on the bootchart. but boot without any splash stuff
EruditeHermit: shall I hit escape
EruditeHermit: when the splash appears
EruditeHermit: and try?
tormod: remove splash from the boot options
EruditeHermit: that works too
aszlig: cxo: okay, this means that i have to recompile xorg with debugging symbols? but that would mean that xserver-xorg-core-dbg is unnecessary? O_o
airlied: I should probably make the DDX fall over in a heap rather than start at all if KMS support isn't built in
MostAwesomeDude: What'd be really nice is if Ubuntu used Plymouth.
aszlig: cxo: ah, sorry, my error, i attached gdb to the binary without debugging symbols
EruditeHermit: tormod, yeah the text becomes small
EruditeHermit: airlied, is this a good log?
tormod: MostAwesomeDude, plymouth was considered for 9.10, then it was decided to not have any splash, then unfortunately someone threw in xsplash
airlied: yes if X has never started before
kernelpanic: is there any hope of getting smooth fullscreen flash video working on my 2560*1600 screen using mesa, xf86-video-ati and drm master and a rv530le? I haven't found any hints on how to do this...
EruditeHermit: airlied, yep X has never started before
EruditeHermit: airlied, if I disable splash, it seems to remove the problem
MostAwesomeDude: There's a moral here.
MostAwesomeDude: DON'T MAKE YOUR SPLASH SCREEN START AN ENTIRE X SERVER JUST TO DRAW SHINIES ON THE SCREEN
tormod: MostAwesomeDude, actually the idea is to start THE X SERVER early, not one for splash screens
MostAwesomeDude: tormod: Well, sure, but if you're gonna do that, you need to have kernel graphics starting early.
tormod: yes, that should have been the case, radeon is loaded early, before this X server should be started
aszlig: http://pastebin.com/d19a33999 <- does this help with anything?
aszlig: this keeps to be the state whatever i try to do
aszlig: graphics card is a RV370
EruditeHermit: airlied, so does this change anything?
aszlig: http://pastebin.com/d403a137d <- Xorg.0.log
aszlig: fortunately it's better than two weeks ago, now i can at least chvt and the vt is back again
EruditeHermit: tormod, so what is happening in my case?
airlied: EruditeHermit: well you can rerun some of the tests ;)
EruditeHermit: airlied, which ones do you want rerun?
aszlig: but still, x doesn't like to get out of that blank screen disease...
airlied: EruditeHermit: well basic s/r register dumps
EruditeHermit: thats not a problem =p
tormod: EruditeHermit, did you disable usplash only or also xsplash?
EruditeHermit: tormod, I just removed splash from the commandline
EruditeHermit: tormod, why would that make a difference?
EruditeHermit: usplash doesn't start X right
tormod: EruditeHermit, no it does not
tormod: I just want to know if usplash or xsplash is the problem? did you see xsplash?
EruditeHermit: xsplash is GDM
EruditeHermit: xsplash goes into GDM seamlessly
EruditeHermit: its just the brown screen before GDM right?
EruditeHermit: with the pulsating line
tormod: ok so then it is not what MostAwesomeDude and airlied are suspecting
tormod: yes that's xsplash
EruditeHermit: hang on
EruditeHermit: I also had radeon modeset=1 in /etc/modules
EruditeHermit: maybe that did it
EruditeHermit: let me try without and see what happens
aszlig: hm, wait for clients, as in terms of ordinary x clients, right?
tormod: you can not have options in /etc/modules, never mind
aszlig: so this backtrace won't help at all, anything else i could do?
airlied: so the thing is radeon won't autoload itself unless KMS is default
airlied: so adding modeset=1 won't change that.
tormod: airlied, yes it has to be on the kernel cmdline, right
tormod: I am pretty sure he has that
EruditeHermit: tormod, its not the splash screen
airlied: tormod: no it won't help even there
tormod: EruditeHermit, you can not have options in /etc/modules, never mind
airlied: the module can't know until you load it, however it can't load until you know you want it
airlied: chicken and egg, hence why distro need to either be kms or not be kms
EruditeHermit: so adding the module to /etc/modules made it load last time
tormod: airlied, it has to be compiled with KMS on by default?
airlied: tormod: the problem is the module table that udev reads
airlied: if we build it in by default then the non-kms radeon will get loaded
EruditeHermit: tormod, this time the text was big until Xsplash. After GDM loaded, I VT switched and it was small, but it was big until X splash.
airlied: however we had a number of regressions when that happened in Fedora
airlied: so we made the table only appears if the module has kms built in
aszlig: oh, and exactly the same is tha case if i turn modesetting off
airlied: however that screws up the "give users modesetting to try"
cxo: <--- n00b. But has KMS working.
EruditeHermit: airlied, your suggestion to add radeon modeset=1 to /etc/modules made it load last time.
aszlig: yah, working here, too, except with x...
cxo: I'm using Ubuntu 9.10 and its X
aszlig: anyway, any others here who have an RV370 but with working X?
tormod: EruditeHermit, you should have just "radeon" in /etc/modules and the options in a /etc/modprobe.d/ file
airlied: adding it to /etc/modules will work
airlied: as long as that hpapened before X starts
aszlig: airlied: apropos modules, could there be a module order issue in some way? means: could it help to init modesetting by module?
EruditeHermit: tormod, can I just have radeon in /etc/modules and specify modset at commandline?
airlied: aszlig: not really any ordering problems, distros need to work out fbcon should be built-in and everything works fro mtherer
aszlig: (at least that was the case facing the same problem but with intel kms)
tormod: EruditeHermit, that should work also
EruditeHermit: tormod, so does ubuntu need to change how things are loaded now?
tormod: EruditeHermit, for radeon kms yes
aszlig: airlied: okay, fbcon is built-in here
aszlig: damn :-/
tormod: the thing is that 9.10 does not really support radeon kms. but 10.04 will.
EruditeHermit: so something good came out of this discussion =)
cxo: 9.10 supports radeon kms if you change the kernel :)
EruditeHermit: cxo, even with a newer kernel it has issues as discussed above
tormod: cxo, I mean "support" as in official, and tested
cxo: It works fine for me?
cxo: EruditeHermit, what issue?
EruditeHermit: cxo, all the stuff we talked about just now
cxo: summarise s.v.p
EruditeHermit: airlied, ok, I will get the new dumps now. Sorry for the confusion.
EruditeHermit: cxo, ubuntu startup scripts were loading radeon too late
cxo: Too late for what?
cxo: is using Ubuntu's stock mkinitramfs, and it seems to be working fine
aszlig: hm... where do i find the register dump tool?
EruditeHermit: I think it was loading radeon non kms, starting X, then loading radeon kms
tormod: EruditeHermit, it would only load radeon once
cxo: Not for me. I get KMS within 2 seconds after boot, I get the white Ubuntu logo at native res
EruditeHermit: tormod, so you better summarize =p
tormod: cxo the white logo is not KMS
cxo: I know, thats just the splash program
tormod: EruditeHermit, I have to go now, really :) there is irc logs at radeon.org
hagabaka: are you getting a wrong resolution for the console? try adding the video configuration in menu.lst
cxo: But its at native resolution. There is no mode switch when X starts. Everything is seemless after Grub
EruditeHermit: cxo, oh I think the DDX driver was loading before the kernel module
EruditeHermit: thats what it was
EruditeHermit: brb must test this
cxo: Why is all that weird stuff happening?
cxo: I followed the wiki and it all works
aszlig: cxo: maybe it's because not everybody has the same kind of hardware you are having?
cxo: of course, but these guys are talking about scripts and stuff
airlied: cxo: if you build it yourself and enable stuff by default it'll work fine
airlied: the problem is distro builds
airlied: which if you read the conversation you'd understand
cxo: oh god!, distro builds!
cxo: the build scripts are out of whack
hagabaka: is anyone else having problems switching to console with 2.6.32 rc7/8 kernel, but no problem with rc6?
airlied: no they just have different requirements
cxo: why do people build with distro scripts, thats super lame
airlied: cxo: you still don't understand
cxo: ok it doesnt matter airlied
airlied: cxo: these are distro kernels, not builds of personal kernels
cxo: yeah, dont use the distro kernel, its outdated
airlied: cxo: again you fail to grasp the conceptr
airlied: so I'll leave it there
cxo: nudges airlied back to R700 3D code
airlied: hagabaka: what gpu?
airlied: cxo: I'm not working on r700 3d code.
hagabaka: radeon 9800 pro
cxo: airlied, who does r700 then?
airlied: hagabaka: got a dmesg and X log? are you using kms
airlied: cxo: amd ppl
cxo: oh like Alex
aszlig: and the r300?
hagabaka: I think I'm using kms, otherwise kwin effects wouldn't be working right?
airlied: fixed r100 3D last week
airlied: hagabaka: can you pastebin dmesg and Xorg log file?
airlied: is attempting to clean up generic radeon 3d code at the moment though
hagabaka: dmesg http://pastebin.com/fe55f542 xorg http://pastebin.com/f18ffd6d3
Ronis_BR: hi all
Ronis_BR: does drm-radeon-testing contain the latest uptate to drm?
aszlig: good morning =)
Ronis_BR: aszlig: good night :)
hagabaka: when I press Ctrl + Alt + F#, the screen just gets a few colored patches over whatever it was displaying
aszlig: Ronis_BR: "drm-radeon-testing" - git branch, package, ...?
airlied: hagabaka: some of the patches ajax posted might help, though not sure why you the wierd colored stuff
airlied: Ronis_BR: pretty much
Ronis_BR: aszlig: git
aszlig: Ronis_BR: never mind ;-)
Ronis_BR: airlied: thanks :)
Ronis_BR: aszlig: np :)
Ronis_BR: airlied: hi!
hagabaka: I don't have that problem with 2.6.32 rc6 though
Ronis_BR: airlied: well, I'm almost sure that the tuxonice+KMS problem is because something with tuxonice :(
airlied: hagabaka: yes I think we fixed a bug in the EDID parser that made stuff work differnt
airlied: for some reason your monitor is failing EDID under KMS
aszlig: airlied: hm, how to do a regdump of the cards current state?
airlied: but it seems to work later.
hagabaka: would the patches be in rc9?
airlied: hagabaka: they will if someone tests them and they fix anything
cxo: drm-radeon-testing hasnt had any updates for a while now
airlied: cxo: there hasn't been any code written
airlied: its not magic
cxo: sprinkles fairy dust on airlied
hagabaka: i don't know how to use those patches :(
airlied: hagabaka: where is your kernel from?
airlied: maybe they can build a test kernel or something
hagabaka: the patches aren't in "mainline" right?
airlied: no because Linus only pull known fixes
airlied: so if there is a chance they'll break at this point I won't send them to him
hagabaka: where are the patches?
Ronis_BR: to update my git clone I just need to git pull airlied_drm_remote drm-radeon-testing rigth?
airlied: hagabaka: http://people.freedesktop.org/~airlied/scratch/drm_edid_patches.mbox
cxo: Ronis_BR, yes, if airlied_drm_remote is what you called it
Ronis_BR: cxo: yes :)
cxo: here http://pastebin.com/m15c165c2
apexo: odd. I've hacked radeon_pm to radeon_set_engine_clock(rdev, 11000); radeon_set_memory_clock(rdev, 40500); ... but all I get is engine clock: 405000 kHz, memory clock: 792000 kHz ...
apexo: although there's a powermode entry with 110/405MHz timings. so the card should be capable of that
hagabaka: yeah, linux git is huge...
hagabaka: is it possible to just download a few recent revisions enough to apply the patches?
biotube: git clone --depth
EruditeHermit: blah, I have terrible driver luck
cxo: just sack the bugger and get yourself something smaller, like a 220EX
cxo: drive it yourself
EruditeHermit: airlied, ok I updated the bug with registers from what is guaranteed to be a working kms+DDX system
EruditeHermit: please advise as to what you want me to try next
airlied: EruditeHermit: try the resume, unload, vbetool post, load sequence now
airlied: don't start X at all
eosie: MostAwesomeDude: I've noticed r300c recompiles a VS everytime FS inputs are changed, is it worth doing the same thing in r300g?
MostAwesomeDude: eosie: No, we're trusting that the state tracker knows what it's doing when it binds a certain pair of shaders.
MostAwesomeDude: We *do* regenerate the RS, which is where we should be doing this stuff anyway.
MostAwesomeDude: RS is very flexible, and it's the best way to make any two shaders pair up.
EruditeHermit: airlied, you want me to boot, stop gdm remove radeon module, echo mem> /sys/power/state, resume, vbetool post, modprobe radeon modeset=1
airlied: yeah sounds like a good plan
EruditeHermit: or do you want me to prevent GDM from loading in the first boot
airlied: also you can try resuming with radeon loaded, and then unload it after resume
airlied: you can try without gdm going at all but its probaly not a big issue
airlied: now that your X is runnign sanely
MostAwesomeDude: Is there a version of radeon_cs_print that knows r600's pkt3s?
EruditeHermit: airlied, in the 2nd method you mentioned, I unload radeon after resume and then vbetool post and then reload radeon?
airlied: EruditeHermit: yup
EruditeHermit: ok will try both ways
EruditeHermit: airlied, so after doing it the first way, the results were the same as yesterday
MostAwesomeDude: Oh, fun times. WTF is pkt3 0x24? (Besides undocumented, that is.)
EruditeHermit: I loaded it without agpmode=-1 and I got the error unable to acquire AGP: -19
EruditeHermit: failed initializing CP: -22
MostAwesomeDude: Ah. IT_START_3D_CMDBUF. Apparently there's new and fun pkt3 to abuse.
EruditeHermit: airlied, what is it that you were hoping to find or what should I report back with?
TBBle: That's weird. Am I here?
MostAwesomeDude: Grar. And some other pkt3 are reused.
MostAwesomeDude: How perverse.
TBBle: Guess I am. Silly Pidgin. Anyway, I don't suppose anyone here knows anything about the ATI HDMI-audio patch that was posted to dri-devel last month? I've applied it, and now mplayer at least plays at the right speed, but I don't get any actual sound out.
biotube: TBBIe: you need radeonhd for HDMI audio support
MostAwesomeDude: biotube: There was a patch on the ML for KMS.
biotube: removes foot from mouth once more
MostAwesomeDude: TBBle: It's not quite officially blessed yet.
TBBle: Radeonhd doesn't support KMS, I understand, and I'm so happy with that part of the system, I'd rather not go backwards. ^_^
MostAwesomeDude: But it should work if you make sure to select the right audio card in whatever player you're using.
TBBle: Heh. Recaptcha just gave me "Scotch" on what is clearly a scanned piece of scotch tape.
TBBle: Hmm. I'm using the same device ALSA-wise that worked with fglrx, and as I say, adding the HDMI audio patch made mplayer play at the right speed, instead of something like 2x speed.
MostAwesomeDude: Well, I have no HDMI audio sink, so I can't really test anything.
TBBle: I didn't see any of the log messages I noticed in the patch appear when I tried to play stuff (or even when I plugged the HDMI in) although the ACR(?) speed messages appeared at modprobe time.
TBBle: Actually, that's another question. When's the best time to modprobe the radeon driver? I've got mine going in in the first stage of the initramfs, 'cause it seems if I delayed it until later X would hang. But I could be wrong about that last bit.
TBBle: Also, I merged drm-next _and_ drm-linus from drm-2.6 into linux-2.6/master. I wasn't clear on the difference, and show-branch seemed to indicated they didn't overlap. Was that wrong, or suboptimal?
TBBle: As far as my HDMI audio, I noticed that my onboard ALC1200-codec seems to have lost a lot of volume with the upgrade kernel, so it's possible it's just my pin config that's bad. Although I dunno if that's even applicable to the ATI HDMI codec.
EruditeHermit: airlied, same outcome when I try it both ways that we discussed earlier (i,e, unload and reload the module after resuming from suspend)
TBBle: Oh, hmm. The HDMI audio patch only supports certain families?
cxo: I think you need radeonhd for hdmi audio
biotube: cxo: [20:26]
MostAwesomeDude: TBBle: Loading KMS ASAP at boot is the general idea. If it gets autoprobed from initramfs, that should be early enough.
MostAwesomeDude: The important part is that it's loaded before X starts.
Droste: @airlied: FYI in this commit: http://cgit.freedesktop.org/mesa/drm/commit/?id=500f5b524000ed5930301f4303744cb4c0a19b75 the define for "DRM_MAX_MINOR" is being deleted completly and this breaks the build for xf86-video-ati. i don't think this was the intention of this commit.
aszlig: okay, this does also happen with a RV516 O_o
TBBle: I've got it loaded before autoprobing. It goes in right after udev starts, and that only because otherwise it hangs the boot process waiting for the firmware loader.
aszlig: oh, damn, it's r300, too
aszlig: but anyway, i guess the r300 should be working with latest git, right?
airlied: EruditeHermit: dmesgs mainly, if agp isn't coming back from resume thats a bit messy
EruditeHermit: airlied, will doing agpmode=-1 be any help?
EruditeHermit: on reloading the module
airlied: EruditeHermit: you might try that from the start
airlied: EruditeHermit: and get the dmesg
TBBle: Right, let's see if extra debugging output sheds any light on this.
TBBle: Got it. Using cunning grep-fu, it turns out the changes that patch makes to r600.c need to be made to rv770.c as well. ^_^
EruditeHermit: airlied, http://pastebin.com/m7c4fea1d
EruditeHermit: btw this is 2.6.32-rc8 no patches
airlied: EruditeHermit: its radeon.agpmode=-1
airlied: I thought you were running drm-radeon-testing or one of those
airlied: it would help if we could stick to just one tree
EruditeHermit: oh no
EruditeHermit: airlied, is this no good then?
airlied: since you suspended with agp enabled
airlied: the fix for agp suspend is in drm-radeon-testing
airlied: not in -rc8
EruditeHermit: so do you want me to compile drm-radeon-testing
EruditeHermit: btw I was never using drm-radeon-testing
EruditeHermit: you initially had me use drm-next
airlied: okay stick with the tree you have for now
airlied: boot with radeon.agpmode=-1
airlied: and do s/r cycle and get dmesg
EruditeHermit: airlied, do you want me to do the module unloading thing or just a standard s/r from inside X
Neo_The_User: does anybody know what HDP means in the latest drm-radeon-testing room?
Neo_The_User: oops. tree. not room
airlied: EruditeHermit: s/r from console and get dmesg, you can try unload/vbetool post/load again if you like
airlied: Neo_The_User: Host Data Path
Neo_The_User: thanks a million!
EruditeHermit: airlied, http://pastebin.com/md483ed
EruditeHermit: is that one useful =p
MostAwesomeDude: So yeah. Boy, it'll sure be nifty when we learn how to do context switches on r600. :3
airlied: EruditeHermit: I said unload after resume
airlied: though even with that did your console come back?
airlied: so you vbetool posted?
EruditeHermit: everytime I do it I HAVE to vbetool post
EruditeHermit: whether I unload afterwards
EruditeHermit: or before
airlied: cool, okay try a resume without unload and get that dmesg
EruditeHermit: so same console procedure
EruditeHermit: just suspend with the module loaded
EruditeHermit: unload module
EruditeHermit: vbetool post
EruditeHermit: load module
EruditeHermit: like that?
airlied: EruditeHermit: yup
EruditeHermit: sorry about the mistakes
EruditeHermit: this is complicated by the fact that I am typing blind
EruditeHermit: airlied, http://pastebin.com/m6151968f
airlied: EruditeHermit: okay so now do that with the VGA plugged in ;-0
airlied: and see if there is any sign of the vga coming back at all
cxo: looks at all the obfuscated proprietary hardware.....vomits
Magnade: this a good place to ask kms questions?
cxo: I had a HP X-Class graphics workstation back in the day. Till today that thing will never run linux properly, because all the chips on it were super proprietary Texas instruments junk
airlied: Magnade: as good as any
Magnade: k i have in my system 2 radeon cards basicly due to mobo having 1 built in (rs780) and the pci-e (rv620) just tried booting into a kms enabled kernel and it fails on loading rs780 firmware
Magnade: is there a way to force the thing to ignore the rs780? or is that required upload?
airlied: Magnade: it shouldn't fail to load the firmware
Magnade: on kernel .32-rc8 btw
airlied: its 90% chance you just used the wrong config
airlied: and firmware ended up not wherever it needed to be
Magnade: how can be considered a wrong config then?
EruditeHermit: airlied, you're kidding right?
airlied: EruditeHermit: nope, I think the VGA should be coming back now that we've figure out you were running something without my agp fixes in it
airlied: Magnade: did you build radeon into kernel or as a module?
EruditeHermit: airlied, do you want me to s/r from inside X or you want the same VT procedure?
Magnade: i think its built-in let me recheck
airlied: EruditeHermit: just do it from VT
Magnade: airlied: drm is in kernel
airlied: Magnade: so did you build firmware into kernel:
Magnade: airlied: im assuming not since i didnt tell it anything like that
airlied: Magnade: well thats a wrong config then
airlied: check its enabled
Magnade: # CONFIG_FIRMWARE_IN_KERNEL is not set
Magnade: airlied: any docs on how to set that up anyhwere?
Magnade: or is it better to just let userspace do it? (on karmic)
cxo: make menuconfig
Magnade: if thats aimed at me i meant set up the firmware blobs to be sucked in properly
MostAwesomeDude: Well, there's a firmware-linux package on Debian, dunno if Ubuntu builds theirs into the kernel or has it separate.
flyback: notes he's had a fun time on irc over the years, thx
Magnade: MostAwesomeDude: package doesnt seem to exist for ubuntu
Magnade: there i sa linux-firmware package tho
MostAwesomeDude: Magnade: Then they must build it in. So you have to, too,
MostAwesomeDude: Maybe that's it.
Magnade: so im looking for what rs780 in the filename?
Magnade: dont see anything in the package that says thats what im looking for
airlied: Magnade: you need to enable that option
airlied: if you are building your own kernel
airlied: and radeon is built in
airlied: if you are using ppa or whatever please ask the owner
Magnade: airlied: will it suck in the firmware magicly is more what im aiming at
Magnade: i like magic
airlied: the firmware is in the kernel tree
Magnade: recompiling then
Magnade: airlied: so im assuming kconfig doesnt allow for when built-in also dep on option x ?
airlied: Magnade: it might be possible, but Kconfig can get messy quick
Magnade: airlied: put a note in the help then?
amarks_: what is Maciej Cencora's irc nickname?
cxo: Can bad firmware permanently brick a video card?
cxo: ^like the firmware in the kernel
airlied: amarks: osiris
airlied: cxo: no
cxo: Did you guys make the firmware?
Magnade: well kernel booted this time but x feels slow now
Magnade: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Magnade: i guess that might cause that
cxo: yeah, that should be in /topic by now
airlied: Magnade: no thats normal
cxo: i think everyone has asked that question
airlied: r600 has no irq support
airlied: yeah I shuold remove the warning
Magnade: airlied: ok so x being slow is due to something else then?
cxo: do you know the status of the IRQ code in the IP review process?
airlied: non-optimised codepaths
airlied: cxo: no
cxo: Magnade, dmesg | grep -i drm
airlied: granted I us r600 allday long and I've never felt it slow
airlied: so I suspect other ppl are just moaning about firefox
MostAwesomeDude: Fx runs fine here.
amarks: airlied: thanks, have confirmed 286bf89e5a1fc931dbf523ded861b809859485e2 causes corruption for me, somebody else suspected this commit also
Magnade: fluxbox window painting/resizing here is painful
cxo: sounds like you've got graphics deacceleration enabled perfectly
Magnade: [ 0.767212] WARNING: at drivers/gpu/drm/drm_crtc_helper.c:1032 drm_helper_initial_config+0x5f/0x70()
airlied: Magnade: thats the card I assume nothing is plugged into
Magnade: hmm yeah before that i see rs780 microcode comment
Magnade: dont see any warnings or anything other than the above
Magnade: xvideo seems fine
soreau: Magnade: What is the output of glxinfo|grep renderer ?
airlied: does fluxbox do compositing?
Ghworg: cxo: Last report I saw is they (AMD) hope to get the review done and out the door before american thanksgiving
Magnade: OpenGL renderer string: Mesa DRI R600 (RV620 95C0) 20090101 TCL DRI
airlied: Magnade: you aren't using KMS then
Magnade: airlied: i think so re: composting
airlied: no wait that doesn't make sense
airlied: pastebin the Xorg log file
airlied: and dmesg
airlied: thinks he's going to stop supporting ppl who aren't running Fedora
MostAwesomeDude: The best revenge is living well.,
MostAwesomeDude: So I'll port Plymouth to Ubuntu.
cxo: loves the fedora Nazism
MostAwesomeDude: This is also why I refuse to ack anything that'll make Gallium run on non-MM kernels.
airlied: wonders how you got a DRI1 glxinfo
airlied: unless you just can't cut-n-paste
cxo: maybe the userspace is out of date
airlied: no you get sw rendering
Magnade: this should be the xorgontheedge ppa
airlied: assume failure to c'n'p
airlied: Magnade: yes the edge of last week
airlied: okay no idea why its slow
airlied: if you can reproducec with a real desktop env maybe I could care
cxo: Is PPA, PPC spelled incorrectly?
Magnade: and i dont see why you say failure to cut and paste
airlied: the GL renderer string is inconsistent
airlied: with the logs
Magnade: interesting that
cxo: cos you should see something like this :
cxo: GL_RENDERER: Mesa DRI R600 (RV770 9440) 20090101 TCL DRI2
cxo: did you build, drm and mesa and xf86-video-ati?
airlied: but there is no way it should ever show TCL DRI with kms enabled
airlied: so I thought the 2 got lost
Magnade: cxo: only thing i have built myself is kernel
Magnade: rest is from the ppa or karmic
cxo: You'll greatly benefit by using a newer drm, mesa and radeon xorg driver
Magnade: the version i see as installed for mesa is 7.7.0-git20091119+mesa-7-7-branch(so on and soforth)
cxo: doesn't matter, track git if its your own box
Magnade: cxo: im sorry but im too lazy for that
Magnade: ill do some force reinstalling at some point and see if i can clear out this version issue i apparently have
cxo: don't apologize, its your misery, not mine :)
Magnade: it prob explains the crash i had in that quantz game i tried tho
cxo: oh thats the new mind game, isnt it?
Magnade: just a simple puzzle game
EruditeHermit: airlied, so did you want me to suspend with radeon loaded when testing the external monitor?
Magnade: cxo: ^^
EruditeHermit: airlied, or should I have unloaded radeon and then suspended?
airlied: EruditeHermit: loaded
airlied: just wondered did you still get that pattern when agpmode was -1
EruditeHermit: airlied, I still do
EruditeHermit: airlied, and upon resume I get the pattern and I can't run any further commands
EruditeHermit: its hung
EruditeHermit: can't even ssh in
airlied: EruditeHermit: oh wierd, soplugging in VGA was the only difference?
EruditeHermit: I could try unloading radeon
airlied: doesn't matter
EruditeHermit: reloading radeon
airlied: I just wondered if the agpmode made a diff, it looks like you don't get ring errors
airlied: so I thought maybe it was all coming back properly except LVDS
EruditeHermit: they wouldn't make it that easy would they?
EruditeHermit: I wonder if the bugs are unrelated or if the same code will fix both
airlied: I suspect we have a 2 bugs :(
airlied: notices mixed pixmaps were off for r600
airlied: fedora has it enabled, maybe that might explain some slowdowns with 1.7 servers
EruditeHermit: its hard to know who else if anyone is affected by this
EruditeHermit: I wonder if this is widespread though
EruditeHermit: or just me
airlied: sounds fairly specifc to that machine
EruditeHermit: I wonder if in the grand scheme of things, your time might be better spent on features for others
airlied: well its nice to try and fix all the crazy cases, because they come back and bite you later usually ;-)
EruditeHermit: I just feel bad if I am taking inordinate amounts of time out of r600 development
EruditeHermit: the hordes of r600 users will be disappointed
airlied: nah I don't get to develop r600 that often
EruditeHermit: what are you working on other than this now?
airlied: maybe once I have < 100 bugs I might start looking again
airlied: just trying to fix as many bugs in F12 as we can before it becomes "enterprise" ready
EruditeHermit: since when was fedora enterprise ready ever?
airlied: EruditeHermit: every 2-3 years
EruditeHermit: fedora is on a constant period
EruditeHermit: it is so bleeding edge
airlied: EruditeHermit: F-13 will be very little change I suspect
EruditeHermit: does RH take specific fedora releases and use them for RHEL?
EruditeHermit: with a few modifications
airlied: pretty much
airlied: Fedora is RHEL upstream
EruditeHermit: so how many bugs do you have open on you now?
EruditeHermit: i thought you had 1000s
airlied: between myself/glisse I'd say 200 on F12
EruditeHermit: oh thats not so bad
MostAwesomeDude: O RLY?
MostAwesomeDude: That's a lot of bugs.
airlied: F11+F10 is probably another 2-300 each
airlied: generally once you jhave more than 10 its too many to read the email for
EruditeHermit: ah that sucks
EruditeHermit: getting to 100 is hard then
EruditeHermit: my rv770 has its own problems with fglrx
EruditeHermit: I just don't have good luck with graphics cards
wirry: mine get killed by the powersupply every time :(
wirry: i moved the pc around, the conector looses a bit of connection and on the next start: *Bzzp*
flyback: wirry what the fuck brand of power supply do you have