agd5f: cd /sys/bus/pci/devices/
l3iggs: there's gotta be an escape character for that
l3iggs: ok, one sec
agd5f: replace
agd5f: lspci will tell you
l3iggs: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/342899
l3iggs: oops
l3iggs: 01:00.0 VGA compatible controller: ATI Technologies Inc R580 [Radeon X1900]
l3iggs: 01:00.1 Display controller: ATI Technologies Inc R580 [Radeon X1900]
l3iggs: what do i use in
l3iggs: 01?
airlied: 01:00.0
airlied: tab complete
airlied: it'll be 0000:01:00.0
agd5f: use /sys/bus/pci/devices/0000:01:00.0
agd5f: l3iggs: can you try this patch? http://www.botchco.com/alex/xorg/force_gb_pipes_to_one.diff
agd5f: against xf86-video-ati
airlied: otaylor: jrb tricked me intor running gnome-shell, nice!!
airlied: otaylor: just fixing a bug in radeon that stops it running
l3iggs: agd5f: i'm attempting to send you the bios file
l3iggs: ...waiting for your go
agd5f: l3iggs: just email it
agd5f: alexdeucher @ gmail.com
l3iggs: ok, i'm gonna try the patch, give me a few min while i figure out how to build this
agd5f: no problem
agd5f: l3iggs: disable the to test that patch. testing it with the dri will require a drm patch as well
agd5f: disable the DRI
l3iggs: holy smokes it's taking like 2-3 min to git clone this 5 MiB project?
l3iggs: ./configure: line 11954: syntax error near unexpected token `XINERAMA,'
agd5f: l3iggs: you'll need to install the xorg macros
l3iggs: when i run ./autogen.sh
agd5f: for your distro
agd5f: xserver dev packages
l3iggs: i think i might have found it
l3iggs: ok! successful build!
l3iggs: now where do i turn off DRI?
agd5f: Option "DRI" "False"
l3iggs: ah
agd5f: in teh device section of your xorg config
l3iggs: not in the code
l3iggs: in my .conf
l3iggs: ok
l3iggs: so do I try this with EXA or XXA?
agd5f: doesn't matter
agd5f: did you install it to the proper location? configure defaults to /usr/local unless you specify a prefix
l3iggs: Libraries have been installed in:
l3iggs: /usr/local/lib/xorg/modules/multimedia
l3iggs: i don't know if that's the right place or not
l3iggs: i apologize for my ignorance
agd5f: your modules are probably in /usr/lib/xorg/modules/drivers
agd5f: so either rebuild with ./autogen --prefix=/usr
agd5f: or copy the newly built drivers from /usr/local/... to /usr/...
l3iggs: ok
l3iggs: Libraries have been installed in:
l3iggs: /usr/lib/xorg/modules/multimedia
agd5f: ok
agd5f: see if it helps
agd5f: you applied the patch right?
l3iggs: yeah
l3iggs: i did
agd5f: cool
l3iggs: so my xorg.conf looks like
l3iggs: Driver "ati"
l3iggs: Option "AccelMethod" "XAA"
l3iggs: Option "DRI" "off"
agd5f: looks good
l3iggs: cool?
l3iggs: alright, reboot or just log out/in?
airlied: agd5f: will xaa use any pipes?
agd5f: airlied: yeah, we setup the raster pipes regardless of accel method
agd5f: they are shared for 2D
agd5f: l3iggs: just restart xserver
agd5f: might try rebooting if that doesn't work
l3iggs: too late
l3iggs: i am rebooting
l3iggs: interesting
l3iggs: login screen flashed something crazy, now looks good
l3iggs: and...
l3iggs: dang
l3iggs: same stupid thing: http://www.stanford.edu/~greyson/example.ogv
agd5f: l3iggs: pastebin your log?
l3iggs: let me double check that the patch applied
l3iggs: xorg.log?
agd5f: yeah
l3iggs: wtf, can't get to pastebin
agd5f: rafb.com or pastebin.ca work as well
l3iggs: http://pastebin.ca/1384519
l3iggs: Canada pulls through again
l3iggs: :)
l3iggs: whoa
l3iggs: it loaded radeonhd?
l3iggs: am i reading that correctly?
agd5f: yeah
l3iggs: mmm
agd5f: double check your xonfig
agd5f: *config
l3iggs: i bet i forgot to to comment a driver line in config
l3iggs: yeah
l3iggs: ok restarting X
l3iggs: alright
l3iggs: issue still present
l3iggs: correct log:
l3iggs: http://pastebin.ca/1384529
agd5f: l3iggs: http://www.botchco.com/alex/xorg/force_gb_pipes_to_one.diff
agd5f: new patch
l3iggs: ok
agd5f: pastein your new log when you restart
l3iggs: ok
l3iggs: is this over the previous patch or on a new tree?
agd5f: remove the old patch. git reset --hard
cnwesleywang: Can anybody tell me if the radeon driver 6.12.1 support XVideo or not in my ati mobility radeon x1300?
agd5f: cnwesleywang: yes
cnwesleywang: xvinfo seems fine but when using mplayer with vo xv,the moive just freeze,I don't know why,I m using ubuntu 9.04 with the latest update.
agd5f: cnwesleywang: is it just mplayer or all movie players?
airlied: try mplayer -ao null to rule out audio.
cnwesleywang: I have only mplayer. should I try another media player? how?
agd5f: totem should be installed by default
arekm: or -noaudio
agd5f: movie player under the sounda and video menu
l3iggs: http://pastebin.ca/1384561
cnwesleywang: wow, I don't know what to say. no audio and mplayer play very well,it seems some audio problem,thanks you guys.
l3iggs: try vlc
l3iggs: it's my fav
l3iggs: sudo apt-get install vlc
agd5f: l3iggs: new patch: http://www.botchco.com/alex/xorg/force_gb_pipes_to_one.diff
l3iggs: git reset --hard again i assume
agd5f: yes
agd5f: l3iggs: you see the lines in the patch that start with OUTREG(R300_DST_PIPE_CONFIG, 0);
l3iggs: yeah
cnwesleywang: maybe this is not the right place for my question,but does anyone know what the mplayer sound problem is? and why -ao alsa freeze the video?
agd5f: you can try uncommenting one of those lines at a time to see if any of them help
airlied: cnwesleywang: does -ao pulse help?
l3iggs: ok
agd5f: make sure only one of the OUTREG lines is uncommented at a time
airlied: cnwesleywang: I think its that something else already has sound open
l3iggs: so if i understand correctly, this card has multiple rendering pathways "pipes"
l3iggs: and you think one might be broken
agd5f: l3iggs: correct
l3iggs: so i'm trying each one individually
cnwesleywang: no, -ao pulse is just same with -ao alsa
l3iggs: got it
agd5f: l3iggs: each line assinged a different pipe to the 2d engine
l3iggs: alright
l3iggs: here goes
l3iggs: so my card has 256 megs of vram
l3iggs: i assume not all of it is used when i'm just tooling around my desktop
airlied: l3iggs: the problem with it being VRAM is usually VRAM is interleaved
airlied: so you end up with corrupt stripes
airlied: instead of not working
cnwesleywang: actually,my sound has so many problem since upgrade to ubuntu 9.04.
cnwesleywang: sound cars
airlied: cnwesleywang: pulseaudio most likely
cnwesleywang: sound cards
airlied: well pa finding bugs in alsa
l3iggs: hmm
l3iggs: ok, i'll try each pipe here
arekm: cnwesleywang: does ubuntu have oss emulation enabled && used on your system? (if I remember correctly apps still using oss emu will block sound even for other alsa native apps)
airlied: cnwesleywang: try killing any firefox running a flash player
cnwesleywang: How to check that oss thing?
arekm: lsmod|grep oss; lsof |grep /dev/dsp
l3iggs: cnwesleywang: mess with the sound playback device for Music and Movies in System ->Prefrences->Sound
l3iggs: each time you change that, close and reopen your media player
cnwesleywang: killall firefox no use. I will try mplayer after next reboot just before start firefox.
l3iggs: holy shit
cnwesleywang: lsmod|grep oss give so many lines. should I paste?
arekm: paste to pastebin.com
l3iggs: fooled...
cnwesleywang: lsof |grep /dev/dsp gives nothing.
cnwesleywang: lsmod: http://rafb.net/p/4EOhrP76.html
l3iggs: alright
l3iggs: tell me this doesn't look like bad ram: http://tinypic.com/view.php?pic=6izeyf&s=5
l3iggs: that's using pipe 0
l3iggs: do different pipes use different locations in vram?
agd5f: l3iggs: no
airlied: no they use differnt pieces of the chip for renderin
agd5f: 2d only uses one raster pipe
l3iggs: ok, well i'm on to pipe 1 then...
agd5f: l3iggs: you can skip pipe 1, that's what was set by default
l3iggs: ok, pipe 2 then
agd5f: also bad ram would manifest in noaccel mode as well
l3iggs: ooh
l3iggs: ok, i'll give it up
l3iggs: it's not ram :)
l3iggs: by the way airlied, you said you have this card too right?
l3iggs: do you run 2 displays?
airlied: l3iggs: I have the next one up, normally run it plugged into one 30" monitor
l3iggs: you don't suppose me having 2 screens has anything to do with this do you?
agd5f: l3iggs: shouldn't matter, but might be worth trying for the hell of it
l3iggs: no difference with one screen
l3iggs: if you guys get a chance, please look at http://www.stanford.edu/~greyson/example.ogv
l3iggs: this is a new version
l3iggs: and it might be more illustrative
l3iggs: i get the same thing with all four pipes
l3iggs: no
l3iggs: i take that back
l3iggs: pipe #3 gives me this log:
l3iggs: http://pastebin.ca/1384634
agd5f: l3iggs: looks like a mis-compile
l3iggs: i'm not doing make clean
l3iggs: let me try again
agd5f: should be ok without, but try it just in case
agd5f: l3iggs: just took a look at the video
agd5f: looks like bad coordinates
agd5f: l3iggs: I need to go to bed. I'll ping you if I think of anything
l3iggs: well thanks for all your help
l3iggs: i'll be in here
agd5f: l3iggs: sort of a long shot, but... http://www.botchco.com/alex/xorg/skip_nop_blit.diff
l3iggs: :)
agd5f: use with EXA
l3iggs: ok
l3iggs: by the way, i think the xorg log for pipe 3 might be real
agd5f: l3iggs: it's failing before it even loads the driver. size mismatch error with the module
l3iggs: maybe i f'd something then
agd5f: l3iggs: anyway. I'm going to bed. email me your results
l3iggs: alright, thanks again
agd5f: np
l3iggs: shoud i do this new test with dri off too?
MrCooper: l3iggs: btw you don't even need to load ati_drv.so, just put Driver "radeon" in xorg.conf
l3iggs: ok
l3iggs: thanks
MrCooper: the video looks like overlapping blits are just dropped on the floor...
l3iggs: i don't have good words to describe my problem
l3iggs: that's why i made the video :)
airlied: I wonder if there is a microcode buggy
airlied: I've never seen a real one
airlied: or do we bypass it everywhere now
MrCooper: unless I'm missing something, this is the 2D engine, so there should be no microcode involved with DRI disabled
airlied: MrCooper: good point.
MrCooper: in which case I'd suspect either a hardware or ROM bug
l3iggs: a summary of what i've tried and the results i've seen is here: http://www.stanford.edu/~greyson/test_reults.tar.gz
l3iggs: thanks for your help guys, i'm going to bed
osiris__: MostAwesomeDude: I get 'radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed' when running some 3d app with gallium driver
osiris__: MostAwesomeDude: it's the newest airlied's changes in libdrm. I'll try and revert them, but maybe it indicates some real problem
osiris__: MostAwesomeDude: partial success!! clear doesn't work properly - seems like some pitch issues, but the triangle in trivial/tri is drawn correctly
osiris__: MostAwesomeDude: unfortunately gears don't spin yet (whole window is blue), but it doesn't lockup at least
osiris__: MostAwesomeDude: I'll test some more apps later
twoerner: airlied: ping
airlied: osiris__: remove the assert, but really gallium needs to call the space accounting
airlied: twoerner: pong
airlied: osiris__: I'm happy to merge that swtcl in radeon-rewrite
airlied: or you can if you have commit.
osiris__: airlied: nope, I don't have commit access and I prefer it stays that way
twoerner: airlied: cpu usage is went up nearly 90% from release -5 to -8
twoerner: s/is//
twoerner: airlied: i am using xorg-x11-drv-ati-6.12.1-5.fc11.i586 and kernel-PAE-2.6.29.1-54.fc11.i686
airlied: twoerner: hmm wierd
airlied: osiris__: can you paste me a linke to the patch I lost it in the backlog
osiris__: airlied: http://pastebin.com/mdc42746
glisse: airlied: btw how can i know where is the current Xorg log on fedora ?
glisse: somehow it's nt /var/log/Xorg.0.log
airlied: it should be is X running as :0
glisse: well somehow it doesn't seems to use any logfiles
twoerner: airlied: it is the new kernel - maybe drm
glisse: i wanted to understand why it refuse to enable modesetting on boot
airlied: glisse: running X from terminal works?
glisse: yup
twoerner: airlied: i used release -4 before.. not -5
airlied: twoerner: ah I wonder what happened across the api divide
airlied: it shouldn't have affected r600
glisse: i think radeon module is loaded with nomodesetting but i add modeset=1 to kernel boot line
glisse: without*
twoerner: airlied: from -4 to -5 90% more..
twoerner: airlied: i am trying -8 no
twoerner: w
twoerner: airlied: same for release -8
airlied: twoerner: so -4 on the new kernel is fast, -5 is slow?
airlied: or is the kernel changed as well?
twoerner: airlied: i will use -4 with the new kernel....
airlied: it might not install, but you could try --force
airlied: as for r6xx I don't think the aPI changed
twoerner: airlied: release -4 with new kernel results in the same usage as -5 and -8
twoerner: airlied: it is a kernel drm thing
twoerner: airlied: i will use 2.6.29.1-37.rc1.fc11.i686.PAE with the -4 release again to test
MostAwesomeDude: osiris__: Excellent, I knew I had it.
MostAwesomeDude: Yeah, currently BEGIN_CS doesn't actually check size. :c
MostAwesomeDude: I need to fix that.
airlied: MostAwesomeDude: its not about begin_cs
airlied: MostAwesomeDude: it about the total referenced buffers fitting in VRAM/aperture
MostAwesomeDude: airlied: Oh, I'm running out of GART?
MostAwesomeDude: That sounds less than ideal. :c
MostAwesomeDude: What's the solution there?
airlied: no I'm just enforcing that you check now :)
airlied: you can't emit a relocation unless you've checked buffers will fit
MostAwesomeDude: If we can't, what recourse is there? Just flush and try again?
MostAwesomeDude: Also that sounds like a winsys job, yeah?
airlied: hmm not sure which layer would do it in gallium
airlied: in classic mesa at render entry point, I add all the buffers used to a list
airlied: i.e. color/depth/textures + dma
airlied: then I add new DMA buffers when I allocate them
airlied: then I readd all the curernt buffers after a current cmdbuf submit
airlied: actually after a current cmdbuf I just revalidate the curernt list
airlied: http://cgit.freedesktop.org/mesa/mesa/commit/?h=radeon-rewrite&id=05304d41f2d9ab7a66a8b976580c156b7b93a9d3
airlied: generally you have two fail cases.
airlied: 1) you can't fit all the buffers for this operation + previous operations.
airlied: in that case you flush and try again
airlied: as the flush should get rid of all the older buffers
airlied: 2) yo can't fit the buffers for this op in at all
airlied: in which case you flush, and sw fallback
MostAwesomeDude: 2Hm.
MostAwesomeDude: 2 sounds like a very, very, very painful fallback.
MostAwesomeDude: And I'd need winsys for that, not pipe.
airlied: well its unlikely to be hit
airlied: but its easy to hit with 32MB or 64MB cards with 32MB GARTs
MostAwesomeDude: Right...
airlied: in theory GL stops it from happening
airlied: if you size all the textures correct etc
airlied: the main thing is you need to know up front if you can fail before filling in any values in the cmdbuf
MostAwesomeDude: Kind of like how it's pointless to emit dirty state if it'll overflow the current CS...
MostAwesomeDude: ...so in that case, flush and mark all state dirty.
glisse: MostAwesomeDude: i think the best things here is to split winsys api in 2 one to register context buffer, one to to submit rendering data
glisse: so whenever you get rendering command from state tracker radeon pipe ask winsys if it's going to work
MostAwesomeDude: glisse: With pipe_transfer we have the ability to schedule our DMA transfers. We could always do very advanced checks there.
airlied: osiris__: pushed to radeon-rewrite thanks.
glisse: and if not ask for a flush
glisse: and after flush if things doesnn't even fit than fallback
glisse: MostAwesomeDude: i am not talking about transfer here
twoerner: airlied: hmm.. something changed between "Apr 03" and today, that results in this
glisse: i am talking about how you build the cs buffer
twoerner: airlied: it is not the ati driver or kernel
MostAwesomeDude: glisse: Are you talking about oversized CS?
twoerner: airlied: this is strange
glisse: MostAwesomeDude: general cs buffer buildup
airlied: twoerner: sounds :)
airlied: twoerner: you using mplayer.
twoerner: airlied: jup
airlied: does mplayer -ao null differ much?
twoerner: airlied: nope..
twoerner: airlied: the load og Xorg is high...
twoerner: s/og/of
twoerner: 4970 root 20 0 358m 34m 13m R 63.3 0.9 1:58.14 Xorg
MostAwesomeDude: glisse: I guess I'm confused. I mean, if we create a buffer object, that means that we've got the space for it, right?
airlied: MostAwesomeDude: no we don't validate until use
airlied: twoerner: not sure what else has changed.
MostAwesomeDude: So, until we actually submit our CS, we have no guarantee that the memory we wanted to use is even there?
airlied: MostAwesomeDude: and where do you mean space? GART? VRAM?
airlied: the other option is to add sched points to CS
airlied: so the kernel knows each portion of the CS will fit and can split up if all of it can't
MostAwesomeDude: airlied: Well, whichever. It just seems really, really weird that creating a BO doesn't actually *create* the BO. So I have to watch how much space I use...?
airlied: MostAwesomeDude: when you create a BO, where should I allocate space?
MostAwesomeDude: Don't we specify GTT or VRAM when creating BOs? /me goes to check
airlied: we can, but generally don't
airlied: we only have it for things like scanout and the ring
airlied: also if multiple processes wanted to do things, you could just allocate it all in one place
airlied: and stop everyone else
MostAwesomeDude: Hm. Okay, so how would I know how much memory I'm allowed to use?
airlied: MostAwesomeDude: you get limits from the kernel
airlied: the kernel will process a CS up to those limits.
MostAwesomeDude: airlied: CS size, total buffer size, etc.? Is this in your radeon-rewrite right now?
airlied: MostAwesomeDude: yse radeon-rewrite has done it all for agse, I just fixed it to be more right last week
MostAwesomeDude: 'k. Looks like yet another thing I have to add.
airlied: you can just comment out the libdrm_radeon assert if you want :)
airlied: but I really need it to find bugs.
MostAwesomeDude: I would not really balk at classifying r300-gallium as a bug. :3
osiris__: is there a way to set a breakpoint on memory access?
MrCooper: osiris__: yes, using the watch command, but I can never remember exactly how to use it and have to look it up every time I need it :}
osiris__: MrCooper: thx
MrCooper: np
airlied: yeah and from memory it sucks when things go out of scope
airlied: I used to end up doing casts of var address to 32-bit pointers
MrCooper: yeah, I remember doing something like that as well
osiris__: MrCooper: I'm tracing some nasty bug. any idea why VB->AttribPtr[_TNL_ATTRIB_MAT_FRONT_DIFFUSE] is empty when an app sets glMaterialfv?
MrCooper: nope
michael33t: hello
dli__: jwr : 多高？
osiris__: woot! next two bugs are squashed :)
spstarr_work: looks at radeon-rewrite
spstarr_work: r300: swtcl rewrite and cleanup
spstarr_work: two new DDX -8 and -9
spstarr_work: new mesa -8
spstarr_work: new libdrm 2.4.6
spstarr_work: * Tue Apr 07 2009 Dave Airlie
spstarr_work: will test
kdekorte: airlied, with todays F11 ati driver, I lost left/right rotation on my primary display.. it just allows upside down now
kdekorte: maybe a bug in gnome-display-manager... xrandr reports it right
osiris__: MrCooper: FWIW when MaintainTnlProgram == GL_TRUE setting material works but only for first call, next calls don't change the material color, so next primitives get the same color as previous.
MrCooper: osiris__: that probably needs to be fixed then :)
MrCooper: osiris__: disabling MaintainTnlProgram may be a good idea without HW TCL anyway, but it's just a workaround for this bug
megari: Heh. My new machine back at work has an HD 3470 and I was told to install Fedora 10 on it. That was a no go due to graphics issues, so I installed Fedora 11 Beta, which works like a dream 2D-wise.
megari: So I'll be enjoying Rawhide's graphics offerings for now.
hifi: megari: lucky one, my machine at work had a recent SiS integrated chip, didn't work at all except in VESA mode
agd5f: glisse: http://www.botchco.com/alex/xorg/0001-radeon-fix-crtc-routing-for-CRT1-on-r4xx-ATOM.patch
agd5f: glisse: http://www.botchco.com/alex/xorg/0002-radeon-fix-default-sclk-mclk-from-combios.patch
agd5f: glisse: http://www.botchco.com/alex/xorg/0003-radeon-pull-in-my-latest-modesetting-fixes-from-the.patch
glisse: agd5f: thanx
agd5f: glisse: I'm getting cp failure on r5xx with your latest kernel bits
agd5f: [drm:radeon_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
glisse: agd5f: rv515 or latter ?
agd5f: yeah rv530 here
agd5f: I just tried an rv410 and it worked fine
agd5f: rv530 has 512 MB or vram, I don't recall if yout code handles that yet or not
agd5f: *of
glisse: agd5f: should work
glisse: i have one 512M card on which it works
glisse: i will retest on rv515
glisse: right now i am tracking a ttm list bug :(
glisse: agd5f: do you have the log ?
agd5f: yeah
agd5f: glisse: http://pastebin.ca/1385105
glisse: agd5f: i should not return error so debugfs files are still alive
glisse: would be helpful to debug such kind of things
agd5f: yeah
osiris__: MrCooper: hmm, when MaintainTnlProgram is disabled the ctx->FragmentProgram._Current is null. any ideas?
glisse: agd5f: can you try with commenting out line 760 of radeon_device_init ?
glisse: so it should gives you debugfs files
osiris__: MrCooper: never mind, my mistake
agd5f: glisse: will do
agd5f: glisse: don't see anything much interresting in debugfs WRT the failure
glisse: agd5f: can you pastebin r100_cp* debugfs files
glisse: should be 2 of them
agd5f: yeah
agd5f: http://pastebin.ca/1385159
agd5f: http://pastebin.ca/1385161
glisse: agd5f: gart is not working
MostAwesomeDude: agd5f: Looks like you've got a new guy comin' in. Does he do IRC?
agd5f: MostAwesomeDude: he's been with us for a while
agd5f: not sure the firewall lets him do IRC. if so I'll try and get him on
MostAwesomeDude: Mm. Just wondering, that's all.
MostAwesomeDude: IRC > ML for getting stuff done, IME.
agd5f: yeah definitely
MostAwesomeDude: Well, cool either way. Nice to see moar AMD involvement. :3
spstarr_work: hmm
spstarr_work: MostAwesomeDude: whos the new guy?
spstarr_work: moar eh :)
glisse: hopefully i am done with ttm bugs
MostAwesomeDude: glisse: Rock. :3
lucxxx: hy all
lucxxx: is drm radeon r600 r700 support in master drm branch?
adamk: lucxxx, Nope.
chithead: lucxxx: it is in mainline kernel bug strangely not in drm master
chithead: s/bug/but/
lucxxx: so will be like in 2.6.31?
chithead: lucxxx: 2.6.30
lucxxx: ok thankyuo
agd5f: chithead: most of drm master is out of date. radeon and intel are now maintained in kernel now
embraceunity: :( fixme:gl_compat:add_gl_compat_wrappers GL implementation supports GL_ARB_fragment_program but not GL_EXT_fog_coord
embraceunity: does this mean anything [ 6394.036262] [drm:drm_unlocked_ioctl] *ERROR* ret = 57 -4
osiris__: looks like airlied won't make it with merging radeon-rewrite to master on time for mesa 7.5 :(
mattst88: seems very soon to make a 7.5 release
embraceunity: when is 7.5 expected?
mattst88: Brian said he wants to make the release on Friday
embraceunity: wow, that is soon
mattst88: 7.4 was just released something like a week ago
embraceunity: and 7.6 will be bugfix, so no merging to master then either I take it
spstarr: airlied: in new drm/dri/ddx
spstarr: tries kwin
spstarr: kwin fails
spstarr: VT switching works
spstarr: tries XRender mode
spstarr: screw it, compiz-gtk
spstarr: VT switch + compiz == yes
spstarr: kwin == fail
DanaG: heh, kwin calls "super", "meta". Aren't they different?
spstarr: i have stable eyecandy
spstarr: im sorry kwin can't give me that :/
spstarr: GNOME 1, KDE 0 in the composite dept
spstarr: er
spstarr: airlied: i just got corruption now
spstarr: text glyphs are garbled and i got some _ speckles
mattst88: OK, I've done 'git clone git://anongit.freedesktop.org/~glisse/drm-next glisse-drm-next', now, how do I track his drm-radeon-next branch?
spstarr: maybe I hit some check failure?
spstarr: airlied: http://www.sh0n.net/spstarr/corrupt.png
spstarr: but VT switching is working again in either state
spstarr: looks at cgit
DanaG: Oh hey, any of you remember when ATI last had the "discus" sort of logo?
spstarr: koji is missing radeon/r200/r300: fix missing dma buffer validation and r300 swtcl rewrite / cleanup
spstarr: builds mesa from git and builds an SRPM
DanaG: I found a "Radeon" (yeah, seems to be just "Radeon") card in an old Dell system at school.
spstarr: /root/rpmbuild/SRPMS/mesa-7.5-0.9.fc11.src.rpm
spstarr: builds it locally
spstarr: hmm need new libdrm
DanaG: oh, it was THIS logo: http://www.rivastation.com/go_e.htm?http://www.rivastation.com/review/ati-radeon-ve/radeonve_01_e.htm
spstarr: thats classic Radeon
spstarr: is not even r1xx
spstarr: pre-r1xx
chithead: the radeon was later renamed to radeon 7200 iirc
DanaG: I have a 64MB DDR Radeon 7500 AGP around here somewhere.
embraceunity: i be these didn't have working drivers either
embraceunity: bet*
DanaG: I've also seen a low-profile 128MB SDRAM (yes, SDRAM) Radeon 7500LE.
spstarr: heh
spstarr: I have a Radeon 7500 AiW
spstarr: its DDR
DanaG: Oh yeah, that LE had a VGA, an S-Video, and a header for another VGA -- which ended up tinted slightly blue.
DanaG: AIW 8500DV was also an interesting card: FW400, TV / VIVO, and dual monitors all in one -- on AGP, no less. Firewire on AGP... sounds like the same sort of issues would apply as the modern R600 and such with HDA controller on AGP.
spstarr: hmm
spstarr: radeon_screen.c:253: error: storage size of 'info' isn't known
spstarr: radeon_screen.c:256: warning: cast from pointer to integer of different size
spstarr: radeon_screen.c:259: error: 'RADEON_INFO_DEVICE_ID' undeclared (first use in this function)
spstarr: checks his build env
spstarr: kernel headers wrong..
spstarr: success
spstarr: Wrote: /root/rpmbuild/RPMS/i586/mesa-dri-drivers-7.5-0.9.fc11.i586.rpm
mattst88: go spstarr go
spstarr: tests his local mesa -9
spstarr: kwin fails
spstarr: installs compiz-kde
spstarr: ok, now with the latest changes let's see if i get corruption
spstarr: yes some speckle corruption
spstarr: __ __ corruption
soreau: spstarr: I experienced speckled highlighting text but only in kde (and haven't tested since updates yet)
spstarr: do you see this
spstarr: http://www.sh0n.net/spstarr/corrupt.png
spstarr: lots of random __
spstarr: __
spstarr: __ __ __
spstarr: __ __ __ __ __ __
spstarr: etc
soreau: No, not like that bad
soreau: Of course I'm just using whatever rawhide f11 beta installs/configures by default
spstarr: hmm
soreau: and I'm using gnome atm
soreau: Switching to tty takes a second and stops music playback until back to 'F1'
spstarr: well, this corruption isn't KDE specific
soreau: Should I be testing with or without kms?
spstarr: with kms
spstarr: which card
soreau: Radeon 9600 r350
spstarr: mobile?
soreau: no, agp
spstarr: rv350 or just r350
soreau: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600]
spstarr: how much vram
soreau: 256
spstarr: and you get no corruption like mine?
soreau: No, but I don't think I have kms enabled
spstarr: airlied added a new kernel param to restrict vram size for testing
soreau: Why, how much does your mobile have?
spstarr: maybe you can set yours to 64MB for video ram to see if you can get corruption like this
spstarr: 64MB
spstarr: which AGP 4x?
soreau: 8x max.. lemme see what it's using
spstarr: not that I think the AGP speed would cause this
soreau: I can't tell from x log right off hand
spstarr: dmesg will tll you
spstarr: [ 1.638756] agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode
spstarr: [ 1.638792] radeon 0000:01:00.0: putting AGP V2 device into 4x mode
soreau: dmesg doesn't say anything like that here
soreau: doesn't even mention radeon or agp
spstarr: hmm
soreau: It's all spammed I see..
soreau: prolly from the tty switches
soreau: A ton of: reserve_memtype: calling reserve_ram_pages_type for 0x14ac0000 0x14ac1000 8
soreau: spstarr: What's the option to enable kms exactly?
spstarr: radeon.modeset=1
soreau: Ok
spstarr: which DDX, kernel, libdrm and mesa are you using?
spstarr: you can get new ones from koji for F11 if you dont have them already (they should be pushed)
soreau: spstarr: How do I tell which ddx? kernel 2.6.29.1-52.fc11.i686, libdrm.i586 2.4.5-4.fc11, mesa-dri-drivers.i5867.5-0.7.fc11
soreau: throw a space in there somewhere
spstarr: xorg-x11-drv-ati
spstarr: 6.12.1-9
spstarr: your kernel is slightly out of date -54 is out, libdrm you're out of date with, mesa is now at .8
soreau: I have xorg-x11-drv-ati 6.12.1-8
spstarr: I use the koji static 1 hour mirror
soreau: I am new to fedora :p
spstarr: so whatever airlied pushes i get in 1 hour or manually fetch from koji
spstarr: :-)
spstarr: soreau: koji.fedoraproject.org
spstarr: you can grab RPMs before they hit the repo
soreau: I don't want to have a package system nightmare here
spstarr: nightmare?
spstarr: it all fits into place
spstarr: that's the nice thing about it all :)
soreau: I'll learn that later/soon enough I presume
spstarr: :)
soreau: If I don't cause an explosion first ;)
spstarr: hmm
spstarr: airlied: I see some tearing oddly
spstarr: i just had a tear just as the corruption hit (fully maximizing firefox)
soreau: spstarr: So which components would have to be collectively updated for the latest radeon stuff? (ie. what packages?)
spstarr: to emulate my env
spstarr: kernel, ddx, libdrm, mesa
soreau: and by ddx you mean xorg-x11-drv-ati, right?
spstarr: ya
soreau: k
airlied: spstarr: waiting on the t42 hopefully will have corruption
airlied: don't really see it even with 64MB VRAM limits
spstarr: airlied: hmmm
spstarr: should I try w/o AGP ?
spstarr: i can reboot
spstarr: unless AGP 4x really has a bug on the intel agp controller
airlied: spstarr: I think it might still happen
spstarr: hmm
spstarr: does it look to be some sort of alignment issue?
spstarr: as the corruption has a pattern
spstarr: |_|_|_|_|
spstarr: take for example this
spstarr: airlied: http://www.sh0n.net/spstarr/corrupt.png
spstarr: that really looks suspicious
spstarr: maybe we're going over a boundary?
airlied: its preety wierd alright
spstarr: hmm
spstarr: maybe an errata is needed
spstarr: since AMD no longer supports the r3xx on the proprietary driver maybe they can give us any erratas in that code? or point us ?
spstarr: since they had to cut the code out of the driver maybe we can get that?
airlied: nah it doesn't happen on my r300 :)
airlied: either of them
spstarr: which agp controller
airlied: intel
airlied: hence why I await the t42
spstarr: you think they'll replace the other person's laptop soon?
airlied: they already had a new one, she just was too busy :)
spstarr: oh
spstarr: I'm saddened i've given you _so_ much grief on this rv350 ;)
airlied: btw you have a laptop + desktop rv350?
spstarr: I have a Radeon 9700 PRO Aiw (r300) AGP
spstarr: but i dont have a LCD screen to plug it into yet (need to buy one soon)
spstarr: I will be testing kms on that as soon as i bump it to F11 (soon) and get the screen
spstarr: airlied: what about the other mobile edition chips
spstarr: airlied: what aperture size?
airlied: spstarr: agp is 128 I think on that machine
spstarr: 256 here
spstarr: AGP aperture is 256M @ 0xd0000000
spstarr: Intel 855PM Chipset
spstarr: looks up errata for that one
spstarr: http://www.intel.com/Assets/PDF/specupdate/253488.pdf - all erratas closed, (BIOS workaround)
spstarr: looks at 2nd pdf
spstarr: 2005
spstarr: none
spstarr: airlied: no known erratas that is the latest doc
spstarr: er
spstarr: yeah, thats the newest
spstarr: airlied: I hope your T42 will show the same corruption, then we can get the bottom of what the cause is
spstarr: airlied: idea, is there a kernel option in the drm code to resize the aperture ignoring what the bios says?
spstarr: so set it to 128MB instead for example
spstarr: aperture size == gart size in this case?
airlied: aperture is bios controlled
spstarr: and I remember with xorg.conf I set the GART size to 128 , could not use 256
spstarr: hmm ok
spstarr: what default gart size is drm driver using? or this is dynamic with kernel mm now
airlied: on agp its bios controlled
spstarr: ok
airlied: its different than how it worked before
airlied: its all dynamic up to a maximum
spstarr: what is the differences ?
spstarr: I see
spstarr: what is the maximum? the aperture size?
airlied: before we used to static allocate a chunk, and that was it
airlied: on agp aperture size, on PCIE its settable
airlied: we use 512MB mostly
spstarr: well,i only have 1 GB of ram in laptop
airlied: spstarr: btw you on kernel or kernel-PAE?
spstarr: how much is being used as video ram?
spstarr: non-PAE
spstarr: Pentium M has no PAE
airlied: mine does
spstarr: !?
spstarr: which pentium M?
airlied: Intel(R) Pentium(R) M processor 1.73GHz pae
airlied: from /proc/cpuinfo
spstarr: wtf? i have a 1.86Ghz
spstarr: model name : Intel(R) Pentium(R) M processor 1.80GHz
spstarr: flags : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2
spstarr: there's no pae (?)
spstarr: i doubt the kernel is misreading the CPU flags
spstarr: PAT is off.. kernel doesnt like it
airlied: "including all later Pentium-series processors except the 400 MHz bus versions of the Pentium M"
spstarr: PAT WC disabled due to known CPU erratum.
airlied: wierd.
spstarr: unless this is a 400 Mhz bus...
airlied: must be.
spstarr: lemmecheck the cpu family / stepping / model
spstarr: it is from 2004
spstarr: what i can do is get a PAE kernel and if it fails just reboot to the other one no?
spstarr: otherwise i need to find the bus speed
airlied: yup in theory that should work
spstarr: one sec getting PAE kernel
spstarr: i'll be shocked if it works
airlied: it probably should be in the cpu flags\
spstarr: yes, it should, so im almost 99.9% sure this kernel will not even boot
spstarr: still, doesnt hurt to try, worse i get a reboot
spstarr: have you been testing with PAT on or off?
spstarr: brb
airlied: whatever defaults
spstarr: nope
spstarr: not surprised
spstarr: i have the 400 Mhz FSB then
spstarr: oddly, i thought this was the better model :(
spstarr: I didnt realize at the time this has no PAE
spstarr: Page Addressable Extensions :(
spstarr: airlied: when we statically assigned the video memory + system ram used, what made that memory different vs dynamic memory
spstarr: memory fragmentation happening?
spstarr: airlied: was the memory that was statically assigned linear?
spstarr: or in all cases its always linearly addressed
airlied: we just allocated 32MB of RAM and put it in the aperture and never changed it
airlied: it just copied stuff in/out
airlied: now we dynamically move pages in/out
airlied: btw for that corruption do you have to do much t omake it happen?
spstarr: I have to open firefox and some additional windows like a gnome/konsole terminal
airlied: hm just got a bit of it now
airlied: need to sit at consoles more often
spstarr: maximize it, minimize it a for a bit, then restore it from offscreen
spstarr: then it becomes a rash
airlied: you get it without compiz?
spstarr: without compiz yes, as i a have now
spstarr: i have a firefox session, xchat and a konsole terminal
spstarr: is it EXA thats busted?
spstarr: no window decorations are corrupt
spstarr: even in the corrupt.png with compiz on, no window decorations corrupted
spstarr: but i have seen window decorations corrupt before, just not today
spstarr: should I try restarting X EXA Composite off?
spstarr: I'll need to recreate an xorg.conf
airlied: wierd its tricky to reproduce it
spstarr: i hit this so easy
spstarr: ok turning on EXA composite..
spstarr: off
spstarr: (**) RADEON(0): Option "EXANoComposite" "true"
spstarr: (**) RADEON(0): EXA: Disabling Composite operation (RENDER acceleration)
spstarr: now let's se...
spstarr: tries kwin for fun
spstarr: kwin still fails
spstarr: switches to compiz-gtk
spstarr: got some corruption
spstarr: airlied: interestingly i loaded a website in firefox with lots of images, but before firefox finished loading it i minimize it from full screen
spstarr: then my other window behind it is now inverted (partly) with __ __ 's
spstarr: boom, minimizing firefox and restoring it now my xchat window contents are completely garbled except the text box
spstarr: until i pressed enter now the text box is clear
spstarr: airlied: even more odd is minimizing xchat i get instant corruption in some PNG images in a full screen firefox window behind xchat now
spstarr: and now i minimized xchat again and firefox's PNG images are not corrupt anymore?!
spstarr: right now im in a X server with no xorg.conf at all
spstarr: let's turn it on with EXA Composite off and no other options
spstarr: airlied: DefaultDepth is 24
spstarr: no Virtual is same size as display 1400x1050
spstarr: Viewport 0 0
spstarr: ok, now in X with EXA Composite off and compiz-gtk loaded
spstarr: 'different' corruption
spstarr: we already know about the corrupt pixmaps on display issue (in fact there's a bug logged in buntu/KDE on this one they say its a patch in X org that causes that)
spstarr: but when I see is a grey/white checkerboard initially when a window loads or garble
spstarr: or it takes the root window background etc
spstarr: airlied: http://www.sh0n.net/spstarr/corrupt-pixmap.png
airlied: spstarr: did you have kde xrender compositing enabled?
airlied: for the corruption
spstarr: no, no XRender enabled
airlied: I can't get it without running compiz or xcompmgr
spstarr: right now im in compiz-gtk only
spstarr: EXA Composite off is *not* showing corrupt.png corruption
spstarr: i am getting other kinds of corruption but not like that
spstarr: airlied: is there a reason we get this kind of corruption when we fetch offscreen pixmap memory? (as in corrupt-pixmap.png) ?
spstarr: or that's a different issue elsewhere
spstarr: airlied: you have EXA composite enabled or disabled in your test?
spstarr: if disabled, you should not see the other corruption, im not seeing it
spstarr: im trying, and its not, (only the initial pixmap load garble on restored windows)
spstarr: unless there is a correlation somewhere?
spstarr: GOT SOME
spstarr: http://www.sh0n.net/spstarr/corrupt.png
spstarr: and now im getting more ..
spstarr: it starts off little then this accumulates
spstarr: now my xchat window is corrupt (the tabs)
terracon: you should be using konversation :)
spstarr: heh
spstarr: so we can conclude EXA Composite on/off doesn't make a difference
spstarr: airlied: maybe disable other EXA options? or dont bother?
spstarr: http://www.sh0n.net/spstarr/corrupt2.png