Radeon IRC Logs For 2008-10-30

MostAwesomeDude: Whoo. Updating my radeon-fog-coords branch (col1/fogc split) makes SW TCL bug out, and HW TCL draw pretty cyan and black blotches all over the screen.
MostAwesomeDude: Damned fog.
MostAwesomeDude: bashes head against wall
orkid: u lose brain cells like that
orkid: recommends not doing it
MostAwesomeDude: Not as many as I lose struggling with this shit. :3
marcheu: airlied: I think the reason for nouveau being stable is more along the lines of “we don’t pull thousands of lines of cruft”
glisse: airlied: for the record i am using an agp rv350 without problem on kms
airlied: glisse: yeah its wierd, fun bridges again…
airlied: marcheu: we don’t pull cruft either, we just give people commit 🙂
marcheu: yeah right there’s not cruft in radeon 🙂
marcheu: no*
airlied: I wish I could remove some code from it :), maybe the hyperz I heard the guy who wrote it is crazy 🙂
marcheu: I honestly wouldn’t care 🙂
MostAwesomeDude: I wasn’t aware that we were actually using the hyperz.
marcheu: we are on r100 and r200, because some guys didn’t wait for the specs, and instead RE-d it
airlied: I don’t think we have specs for r100/r200 hyperz even now.
marcheu: actually the registers are covered in the DDK
airlied: we have specs for r300 hyperz and nobodys written it 🙂
marcheu: too bad, cause that + tiling doubled the performance on my r100
MostAwesomeDude: I thought we didn’t have tiling for r100 and r200?
glisse: marcheu: why carring about perf if your game lockup after 1min 😉
airlied: glisse: its makes gears faster 🙂
airlied: who actually plays games 🙂
marcheu: MostAwesomeDude: so, if you always think wrong, you should say the opposite of what you think
MostAwesomeDude: marcheu: Yep.
MostAwesomeDude: On a completely unreleated note, I think fog’s hard and impossible. :3
glisse: youpi 215636 lines of ref/unref free/pending log to analyze to find where buffer are not free
marcheu: airlied: see, pulling the DRI cruft instead of moving to gallium 🙂
glisse: time to wrote a program to analyze log
glisse: marcheu: next week i am on gallium =)
airlied: marcheu: I await a stable API 🙂
marcheu: glisse: cool, and the weeks after that you get r600 docs ?
glisse: once i have dri2 which it’s far away now that i have this bo stuff mostly working
airlied: I think we need to fix the current drivers before worrying about r600
glisse: marcheu: i told you week after we get r9xx docs 😉
MostAwesomeDude: glisse: Count me in, although I might not be able to contribute a lot, I’ll try.
glisse: don’t be jealous 😉
glisse: dri2 isn’t far away
marcheu: it’s like UXA being merged back into EXA, I’ll believe it when I see it 🙂
airlied: marcheu: also a driver that doesn’t run out of RAM 🙂
glisse: oh i also need to track down who the hell in mesa alloc a bo of the size of vram
airlied: glisse: where’s that?
airlied: or rather when do you see it.
glisse: don’t know it doesn’t hurt me yet, i am still trying to find which vertex path doesn’t free it’s gtt buffer
ossman: morning
airlied: marcheu: where’s my LLVM targetted at a GPU ISA anyways 🙂
glisse: i see it with glxgears it’s one of the first few buffer allocated
MrCooper: glisse: wouldn’t it be natural to do GEM/TTM, DRI2 and Gallium together?
ossman: I take it from the topic that you tend to get quite a few questions about r600 🙂
ossman: is there any info newer than the july promises of specs by september though?
glisse: MrCooper: well in order to be able to compare gallium with current radeon i though that would be a good plan to first do the test in radeon
glisse: abstraction is working
glisse: just got a memory leak
glisse: which means out of gtt memory after 10sec of gears 🙂
marcheu: airlied: hehe well when radeon runs out of vram it also causes crashes… at least for nouveau we know how to solve them :p
marcheu: granted I think the radeon hw is pretty crappy in comparison
marcheu: I’m hoping we get an FPGA with a DAC + some RAM and make it a fast OSS graphics card one day…
MostAwesomeDude: I’m hoping that we get dedicated fog channels in vertex memory.
ossman: marcheu, isn’t the whole Open Graphics thing exactly that?
MostAwesomeDude: But that’s not really a big priority, I fear. :3
airlied: marcheu: we don’t run out of RAM with the mm now.
glisse: MostAwesomeDude: newer gpu are all about moving away of any fixed pipeline 🙂
airlied: I can open lots of windows in compiz and al-tabl.
airlied: it goes slow as hell but it doesn’t die
marcheu: ossman: no they want to design once and for all, I want something that’s reprogrammed on the fly when you launch doom3
marcheu: airlied: well IME radeon crashes when you fill up vram…
ossman: marcheu, ah
airlied: MrCooper: the problem with changing all the bits at once is you have nothing stable to sit on… its nice to have on bit to trust 🙂
spstarr_work: glisse: what?!
spstarr_work: glisse: I’d be in favour of a rewrite of r3xx/r4xx 🙂 r5xx+ seem to be a different code base i think
spstarr_work: er marcheu
rmh3093: im trying to compile pango and im getting this error:
rmh3093: libtool: link: `/usr/lib/libGL.la’ is not a valid libtool archive
rmh3093: im using the r300-buffmgr-fedora branch
rmh3093: any ideas?
marcheu: spstarr_work: what are you talking about ?
MrCooper: rmh3093: where did you get libGL.la from? Didn’t think Mesa ever used libtool, at least not in this millenium
rmh3093: MrCooper, equery b libGL.la says it belongs to my mesa package
rmh3093: and all i did was take the default gentoo ebuild for mesa and tweak it to pull from airlied’s repo
MrCooper: sounds like a question for #gentoo or so then
rmh3093: they probably dont care since im using a custom ebuild, i just though maybe something changed upstream that is breaking it
MrCooper: no libGL.la upstream
MrCooper: unless airlied changed it to use libtool or something, but that seems unlikely
rmh3093: MrCooper, yes the ebuild seems to play with libGL
MrCooper: FWIW, in Debian we’re working to eliminate .la files completely, as they tend to be more of a problem than any use
rmh3093: yeah i thing gentoo is too
rmh3093: its just taking some time
MrCooper: not sure adding .la files to projects where upstream never had them in the first place is a good way to achieve it though 😉
rmh3093: well, the .la in the mesa package probably has been there for a long time
rmh3093: not something new
rmh3093: i will ask in #gentoo
agd5f: spstarr_work: r3xx/r4xx/r5xx use the same code base for the 3D driver
spstarr_work: agd5f: hmm
spstarr_work: agd5f: so then r5xx would have the same mess as r3xx?
agd5f: spstarr_work: you mean the AGP issues?
spstarr_work: yep
agd5f: AGP is generally a problem regardless of the asic
glisse: spstarr_work: agp is broken in so many place
spstarr_work: so then it will take us longer to fix AGP related issues ;/
spstarr_work: glisse: well, until AGP is totally killed off 🙂
spstarr_work: we still need it
glisse: for me agp is things of the past
glisse: i am sad constructor still release gpu for it
glisse: i would be so happy if ati did follow nvidia policy (well what was their policy about that few years ago)
glisse: but as there is a market their
glisse: you can ignore it
glisse: can’t
agd5f: I think everyone wants to see it die except marketing people who see upgrade markets
glisse: maybe this why i am not in marketing area 🙂
quicksilver: well I quite like being able to upgrade without changing my motherboard.
quicksilver: but clearly I can’t keep doing that for ever
spstarr_work: motherboards are cheap
spstarr_work: < 70 bucks
glisse: quicksilver: agp is a pain in the ass i got no other word for that technology…
quicksilver: spstarr_work: clearly I’m even cheaper 🙂
spstarr_work: hehe
quicksilver: glisse: I know nothing about what it’s like to write drivers for, so I’ll defer to your wisdom 😉
quicksilver: If I wanted to buy an ATI card to play with GLSL under linux, what would be a good choice?
legis: what is good value of FPS for a X1650? using glxgears
bobbens: glxgears is not a benchmark
legis: Is that I have this error: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
legis: I wanted to know if what I have know(no rendering) will be ok for normal stuff, videos etc..
spstarr_work: glxgears to me is, “Yay hw accel GL worked!”
bobbens: not even that
bobbens: since some cpus can get pretty high fps
bobbens: glxinfo | grep direct
spstarr_work: yeah
spstarr_work: i do that first
spstarr_work: but just cause direct is enabled doesnt mean glxgears wont..crash 🙂
bobbens: usually glxinfo crashes too 😛
legis: I think is has to something with some wrong mesa lib but can’t fix ti.
bobbens: i stick to debian packages
bobbens: or i’ll blow up my system
legis: bobbens: yeah, I’m using debian sid, only debian pkgs
bobbens: latest sid is working fine here
bobbens: X550 though
bobbens: which is r3xx not r5xx
legis: this r5xx
bobbens: yes
bobbens: i actually got an r3xx knowing it would “work” out of the box soon 😛
legis: looks like my only choice know is the propietar ones
legis: s/know/now
bobbens: r5xx should work
bobbens: not sure if with debian packages though
agd5f: legis: r5xx should work
agd5f: legis: if you have a problem with the 3D libs, you should still get 2D and Xv
legis: agd5f: Ok, should be fine for wacthing videos right?
tlp: Xv is for videos, yeah
legis: I’ll just wait for a debian update heh, I’m tempted to use the pkgs from experimental
agd5f: legis: yeah, assuming the you have the drm loaded. run xvinfo to check
legis: agd5f: for what sould I look for?
agd5f: legis: Adaptor #0: “Radeon Textured Video”
legis: agd5f: yeah, its there
agd5f: then you should be all set for video
tlp: is nervous because he bought the same card legis has
tlp: we’ll see what Intrepid does today.
legis: tlp: let me know! heh
legis: agd5f: k, thx
DoYouKnow: Hi. I’m having some trouble with my ati radeon 200m. Sometimes when I boot up ubuntu I get images from the previous bootup that flashby chopped up and pasted on noise
DoYouKnow: sometimes when I close windows, my ati fills in the dark spaces with lots of “noise”
DoYouKnow: it only does this on linux, not windows
DoYouKnow: *ati radeon express 200m
DoYouKnow: what’s the best way to fix this?
DoYouKnow: I think it’s probably a kernel setting
MostAwesomeDude: DoYouKnow: The first one occurs because you’ve got graphics card acceleration.
DoYouKnow: hmm
spstarr_work: DoYouKnow: thats buffer
MostAwesomeDude: See, all these pixmaps are loaded into the card when it’s accelerated, and (unlike what most people believe) the contents of RAM, especially VRAM, stay there for a while when you reboot or power off.
DoYouKnow: so how do I fix that?
MostAwesomeDude: Every time I start my laptop, I see either a bunch of noise, or my wallpaper from last boot, before the new one draws a second later.
DoYouKnow: yeah
spstarr_work: MAD: when you reboot you see it yeah its still in the backbuffer
MostAwesomeDude: You don’t fix it. It’s working as intended. :3
spstarr_work: (one of them)
MostAwesomeDude: It just takes a second to upload that data to the card, that’s all.
DoYouKnow: have there been any approaches to fixing it to make it more smooth like windows?
spstarr_work: MostAwesomeDude: although the new DDX i do not see this anymore, only when switching into composite to see the other backbuffer
spstarr_work: MostAwesomeDude: with kdm i got the X stipple pattern now
MostAwesomeDude: DoYouKnow: XD, Windows GDI isn’t smooth, it just has a different set of glitches.
spstarr_work: with AGP off…
DoYouKnow: a different version of the kernel?
MostAwesomeDude: I’m guessing your DRM may not be loaded; that can cause it to take a while to upload new stuff to the card.
DoYouKnow: DRM… hmm… xorg.conf setting?
MostAwesomeDude: No, kernel module.
MostAwesomeDude: Try “sudo modprobe radeon” and check dmesg for errors.
DoYouKnow: no errors
MostAwesomeDude: Do you have a /dev/dri/card0?
DoYouKnow: yes
MostAwesomeDude: Any errors in xorg.conf?
DoYouKnow: errors in xorg.conf?
MostAwesomeDude: Yeah.
MostAwesomeDude: Errors.
MostAwesomeDude: In xorg.conf.
MostAwesomeDude: Or you could pastebin it and have one of us look at it. :3
bobbens: xorg.log you mean
MostAwesomeDude: bobbens: Yes, I *do* mean xorg.0.log. Still asleep. :c
bobbens: i tab complete, don’t know it’s full name 😛
DoYouKnow: xorg.0.log?
DoYouKnow: I can’t find it
DoYouKnow: hold
bobbens: /var/log/Xorg.0.log
DoYouKnow: ah found it
DoYouKnow: ./var/log
DoYouKnow: ok well
DoYouKnow: I don’t see anything
DoYouKnow: I’m checking for something I can grep for
DoYouKnow: so I can automate it
bobbens: generally “EE” or “WW”
DoYouKnow: nope, no errors
MostAwesomeDude: Hm. Could you pastebin it anyway?
DoYouKnow: ok
DoYouKnow: http://pastebin.com/m3d261a47
DoYouKnow: the driver is early in development, since my radeon r300 (I think) just recently became supported by the open source radeon
glisse: DoYouKnow: well r300 is supported since 2 or 3 years can’t remember
glisse: of course it’s still not really feature full or bullet proof
MostAwesomeDude: DoYouKnow: Add Option “AccelMethod” “EXA” to your device settings to make stuff faster. :3
bobbens: glisse: 3 or 4 i’d say 🙂
DoYouKnow: ok
MostAwesomeDude: IIRC the R300 project started 5 years ago, and has had working code for ~3 years.
bobbens: i remember running it on my 9600 when it was bleeding edge 😛
glisse: bobbens: i was at the begining of it, the older it’s the older i am 🙂
bobbens: that’s cheating 😛
glisse: so let say it has been started 1 year ago ! so i am young again
bobbens: i started using it at the beginning too
spstarr_work: heh
spstarr_work: MostAwesomeDude: ‘faster’ ;p
spstarr_work: *cough*
spstarr_work: how bout we just chuck EXA, UXA whatever and just move 2D to gallium as a unified 2D/3D front 😉
MostAwesomeDude: spstarr_desk: Very funny. We’re already trying to deprecate XAA.
libv: MostAwesomeDude: if only real world would accept it
spstarr_work: MostAwesomeDude: touch it and i will cut your fingers off 🙂
MostAwesomeDude: XD
orkid: hopefully r6/7 xv is uvd in fglrx are going to be usable by christmas
orkid: s/is/and/
spstarr_work: is going to try fglrx tonight and see
spstarr_work: since we reached a dead end for now
legume: latest xorg git + radeon + exa + compiz is borked for me, xserver from june , was OK. I guess this is an xserver issue and not radeon?
legume: borked = crash sometimes on alt tab + xterm gets blacked out on rotating cube (can fix by maximise/restore)
spstarr_work: which card
legume: rv530 AGP
glisse: waoou we got some vertex emission which ask for an offset beyond the buffer it allocates
legume: It’s OK with xaa + xaanooffscreenpixmaps
agd5f: legume: borked like hang or borked like corruption?
legume: agd5f: xterm content gets blacked out when it gets focus, but I can recover by maximise/restore
legume: agd5f: I can sometimes get a segfault by alt tab
agd5f: legume: can you get a backtrace of the segfault?
legume: agd5f: I could try (need to see how) it just says segfault and nothing else currently
agd5f: legume: http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
legume: agd5f: emerald is mentioned but I thinks that’s just because it’s the last thing I run in .xinitrc
agd5f: is it the xserver that segfaults or some app?
legume: agd5f: not sure if it’s server or emerald, but I get dumped out of X
agd5f: sounds like the xserver then
legume: agd5f:ok I look at the wiki any try to get more info
agd5f: legume: thanks!
legume: agd5f: Haven’t done it with gdb yet, but got a trace by redirecting stdout/err – it looks like a mesa problem
legume: agd5f: http://www.pastebin.ca/1241003
legume: agd5f: I think I backed up my old r300, will see if that works later
agd5f: legume: yeah looks like it
saschpe: hi guys, I have a slight problem with the “radeon” driver since xorg-7.1 (occuring on 3 last ubuntu and 2 last fedora distros), the login manager (gdm and kdm) freezes soon after startup.. the only workaround is setting _Option “BusType” “PCI”_ or _Option “NoAccel” “1”_. I wonder if someone has the same problem and/or a solution (xorg.conf: http://pastebin.com/m6ba75acd)
saschpe: maybe I should add that my card is a Mobility Radeon 9700 and that I had perfect DRI support (compiz, quake3, ..) before that driver update that introduced the freeze
airlied: saschpe: did Option “AGPMode” help it?
saschpe: airlied: not really
legume: agd5f: I get the same rendering problems & crash with my old r300, which used to work. Maybe it’s libglx.so that changed
agd5f: legume: old r300 card or 3d driver?
spstarr_desk: hello
spstarr_desk: grins at airlied
spstarr_desk: such woes are us r3xx agp users
legume: agd5f: driver
agd5f: saschpe: just to clarifiy, did you try the different agp modes? Option “AGPMode” “4” or Option “AGPMode” “8”
legume: spstarr_desk: it was OK with june xserver, and also OK with current radeon + june xserver/mesa
saschpe: agd5f: not all of ’em recently, only “4”, but I remember doing that with the last x.org release
spstarr_desk: legis: EXA or XAA?
agd5f: legume: I think something in 1.5 is fishy
spstarr_desk: agd5f: do we have a list of the commits for 1.5?
spstarr_desk: perhaps narrow down which one(s) cause problem
agd5f: spstarr_desk: see teh xserver 1.5 branch
spstarr_desk: well, there’s a lot 🙂
legume: spstarr_desk: If you mean me – EXA XAA is OK (with nooffscreenpixmaps) EXA seems OK without compiz
agd5f: It’s probably one of the EXA or TFP changes
spstarr_desk: agd5f: revert? 🙂
agd5f: spstarr_desk: if you can find the offending commit
spstarr_desk: so i’d have to play the git bisect game? 🙂
spstarr_desk: oh fun
legume: agd5f: yea it seems that way, I haven’t had any trouble with the games I’ve tested (no compiz) with this mesa – apart from ut2004 regression, but that’s a known issue
agd5f: legume: can you reproduce it with xserver from git master?
legume: agd5f: it is from today
agd5f: ah ok. I asumed you were using 1.5
legume: agd5f: Ah I thought 1.5.99.1 counted as 1.5
spstarr_desk: thats closer to 1.6
spstarr_desk: although i wonder if i should build git xorg and see if EXA is better or not
agd5f: master has the glyph cache stuff which makes text much faster
saschpe: ok, bye
airlied: spstarr_desk: EXA in F10 is master EXA
spstarr_desk: ok
spstarr_desk: so then bad 🙂
spstarr: is in composite mode.. and im gonna stay in it with AGP on to see what happens
airlied: glisse: did you contemplate before making the kernel COMMIT_RIN always pad to 16-dwords?
spstarr: airlied: i think some of your DDX fixups and drm changes might have made non-kms composite work more stable, but we’ll see so far it hasn’t blown up
spstarr: i wont VT switch however
glisse: airlied: contemplate ?
glisse: oh
glisse: well it was very hackish on each commit i padded with nop packets 🙂
glisse: easiest way as code make many assumption after COMMIT
airlied: glisse: did it help anything? I’ve hand padded some places for CS.
airlied: but I’m wondering should I just go with padding on commit.
agd5f: It shouldn’t hurt anything other than waiting space
airlied: as long as I make the wait check aligned as well it should all be happy
agd5f: r6xx requires buffer size alignment, r3xx migh have as well
glisse: airlied: well it definitly helped in few case
agd5f: might depend on the chunk size set in the CP
airlied: yeah I wondered about the ring setup stuff
glisse: i aligned on 8 dwords
airlied: I expect fetching 16 dwords over DMA is better than random sizes.
glisse: airlied: i think this is related with FETCH_SIZE param of cp
airlied: glisse: yes thats what I would expect.
agd5f: yeah, me too
glisse: airlied: we really want each ring access to go through some functions
glisse: so we can easly do things like that
airlied: glisse: in the kernel we have the macros, I don’t think we do anything outside them
glisse: as well as other alignment stuff you can see in fglrx
agd5f: VAP has a fetch size as well for vetex buffers
airlied: its not a major amount of sites if you ignore the old r100/r200 code 🙂
glisse: airlied: i mean nuke the macro and have some cleverness to minize ringwritefunction call
airlied: glisse: I don’t see a major downside in the macros.
airlied: glisse: as long as nobody hacks around them
glisse: airlied: well i see them as an invitation to bad behavior
airlied: glisse: well thats what code review is for 🙂
glisse: mmy thinking is that by nuking them we will actualy review the code which today use them
airlied: I read most of it yesterady when playing with padding 🙂
glisse: also bear in mind that cs doesn’t use lock
glisse: or shouldn’t
glisse: so we can have concurrent access
airlied: glisse: we need a ring mutex in the kernel also.
glisse: lot easier to handle concurrent ring access in a single function
airlied: but hiding that in inline functions isn’t going to happen
airlied: have a function lock and another funcion unlock is always a mess and not kernel way of doing things
airlied: explicit locks might take longer to write but they also are a lot easier to read later.
airlied: the other thing I meant ot mention for bufmgr is pthreads.
airlied: we can have concurrent access to the bufmgr…
glisse: airlied: well i am thinking to a single function which take a mutex on enter and free it on exit
airlied: how do we write the values to the ring in the middle?
glisse: what you mean ?
airlied: it gets messy if you really want atomic access across a number of writes.
airlied: do you pass an array of values into the function to go into the ring?
airlied: and use memcpy to put them in there?
glisse: oh this why i talked about cleverness 🙂
glisse: this was my first thinking
glisse: but there might be other option
airlied: I think for some cases that might be messy esp if we have any loops.
airlied: or conditionals.
glisse: well maybe MACRO are fine, still we need a mutex
glisse: also we definitly need to nuke macro like WAIT or FLUSH
airlied: if we don’t need to access the ring from IRQ context ever :), which hopefulyl we don’t.
agd5f: we should probably pad IBs too
glisse: agd5f: yup IB are aligned in fglrx all the times
glisse: i think we should makes this userspace problems
airlied: return -EINVAL on unaligned IBs 😛
tlp: hmm. I don’t suppose there are AGP cards that are incompatible with certain motherboards, eh? Just booted my X1650 and have multicolored lines on my monitor (before and after the system is booted).
spstarr: tlp: if it goes away is just vram leftovers
tlp: no, it doesn’t go away
spstarr: thats not good 🙂
tlp: indeed :p
tlp: the screen is unreadable
tlp: I’m going to pop it in anothe rmachine real quick
airlied: tlp: happens in the BIOS?
airlied: sounds like bad VRAM
tlp: yes, in the bios
tlp: eh
tlp: I see that there is a power supply connector on the card. Would not having that connected have anything to d owith it?
airlied: that would usuaully make it beep and give out at startup
airlied: but it might help to try
spstarr: hmmm flash videos are corrupt
agd5f: yeah, that could be a problem
spstarr: but i still haven’t crashed the gpu yet
spstarr: airlied: if it really is AGP.. then why is this only crashing with kms?
tlp: heh, I feel dum b
spstarr: you say kms doesnt do much different than what the DDX did when programming the AGP no?
tlp: that fixed it
tlp: I’ve never had such a fancy card before :p
spstarr: my 9700 shows a red text if you dont plug in the floppy power connector
spstarr: -a
tlp: (typing on a Jornada 720 keyboard, which explains the typos I keep making)
spstarr: heh
spstarr: exaCopyDirty: Pending damage region empty!
airlied: spstarr: different command submission, different ordering.
spstarr: hmm
glisse: airlied: i pushed a new tree this times things works, i got softlockup in openarena but i can restart X and i am back in business
glisse: will hunt this one this weekend then dri2+new cs
airlied: glisse: so its just bufmgr on old CS now using code in libdrm?
glisse: airlied: yup but with a lot of change to mesa r300
spstarr: yum
airlied: glisse: from bufmgr branch?
glisse: r300-bo-cs branch in my repo
airlied: oh lots of code to bash regressions out of 🙂
glisse: yup but i haven’t found a better way than one big conversion, it only touch memory management & cmd assembly
airlied: glisse: I thought bufmgr was doing it pretty well.
airlied: without my hacks…
airlied: nha was doing good stabilisation in between each change.
airlied: so regression hunting was easy
glisse: well bo in bufmgr revealed to be a nightmare with dri2
tlp: Sweet. It works.
tlp: (Out of the box Intrepid)
airlied: wierd I thought DRI2 was just passing handles from the other side, and we would ignore them for the legacy case as it can’t do DRI2
glisse: map/unmap and ref/unref weren’t properly done, not mentioning that sarea was still everywhere around and few others things like bad dma management ….
glisse: which in the end made the dri2 a pain the ass to do on top of bufmgr so i slated a simple bo interface and cs interface which does what we want for new cmd style and convert bufmgr to this
airlied: but its regressed openarena 🙂
airlied: my issue with doing these big changes and then pushing forward is we never fix the old stuff.
glisse: yup it regressed openarena which dies in a busyloop
airlied: nha was doing it in a progression that was at least bisectable.
glisse: i know that
glisse: i tried doing it incrementaly but this didn’t workout
glisse: if you want to trash this one no problem i move to gallium
glisse: anyway zzzZZZzz for me now 🙂
airlied: oh I’m interested in how it works, I just wonder if it’ll be mergeable
airlied: without major regressions anytime soon.
spstarr: let’s cut our loss and move to gallium 😉
spstarr: fresh start
airlied: we still have to sort r100/r200 which gallium isn’t really suitable for
spstarr: they can remain in legacy no?
spstarr: they seem pretty good
airlied: not really we would want DRI2 on them.
airlied: and kms.
spstarr: well, you have kms working on your r100/r200s no?
airlied: not witth 3D.
spstarr: oh
spstarr: a lot of effort converting DRI1 -> DRI2 ?
spstarr: or just structure changes
airlied: porting to memory manager like r300
agd5f: spstarr: the 3D driver needs MM love
spstarr: oh, pain
spstarr: but i thought the mm stuff was going to be common to all
airlied: spstarr: and magic.
agd5f: in the drm yes
spstarr: so one method if you implement on r300 then r200/r100 would follow the same approach no?
airlied: spstarr: it still involves writing code.
spstarr: of course
airlied: and testing it all
spstarr: i can help there
agd5f: the 3d drivers still use the old static allocations from the ddx
airlied: and not regressing things too much.
spstarr: my lone r1xx (rv250)
agd5f: r2xx actually
spstarr: Radeon 7500?
agd5f: that’s rv200
spstarr: so its an r2xx
agd5f: no, it’s an r1xx
spstarr: my mistake, r1xx, (rv200) 🙂
agd5f: rv200 = r1xx rv250 = r2xx
spstarr: i can test kms/3D on the r1xx when ready
tlp: legis: Just FYI, Intrepid works with this card out of the box.
spstarr: hmm kwin turned off composite on its own
spstarr: haha
spstarr: it saw something was slow
spstarr: and notified me
spstarr: fine, it stays off then 🙂
tlp: Interesting. When AIGLX is enabled and I run glxgears, glxgears leaves “ghosts” of itself when I move it around.
tlp: err, Compiz I mean
spstarr: 🙂
spstarr: code time
otaylor: airlied: I’m seeing *horrible* text performance with rawhide everything except for the kernel (which is back at 27.3-34)
otaylor: airlied: Like “top in a gnome-terminal pegs cpu”
spstarr: otaylor: oh you hit the ‘disable agp’ kernel 🙂
spstarr: and dfs
otaylor: spstarr: Still…. even with that, it shouldn’t be this bad 🙂
spstarr: heh
otaylor: I’ll try rebooting into a new kernel, though
otaylor: bbiab
spstarr: -34 didnt have it
otaylor: OK, much better performance with the current kernel, at least with modesetting on. Though massive glyph cache corruption with modesetting on….
otaylor: expects to be rebooting again in a moment
airlied: otaylor: r500?
otaylor: airlied: r300
airlied: or r300 AGP?
otaylor: (AGP)
airlied: have you the latest -ati
airlied: -38 from koji
otaylor: This is -34
otaylor: I’ll try grabbing -38
spstarr: looks at -38
otaylor: airlied: kernel 2.2627.4-58 still reasonable to be testing with?
airlied: otaylor: I’ve done more since that…
airlied: like added mtrr to make stuff not so slow 🙂
spstarr: airlied: nice 🙂
otaylor: airlied: Grabbing the latest kernel from rawhide – good idea? Foolish idea?
airlied: otaylor: its already tagged in for the final release 🙂
airlied: so probably a good diea.
spstarr: in otherwords, we have no choice 😉
otaylor: OK, no corruption so far, performance seems to be within reason, definitely looking better
airlied: otaylor: you can force agp modes with radeon.agpmode=x on the kernel command line, but it may bring back some issues 🙂
otaylor: airlied: So, this kernel is disabling agp?
airlied: otaylor: yes by default.
airlied: until I can resolve the issues later.
otaylor: airlied: Well, it’s not like we use agp much anyways…
spstarr: otaylor: DFS off hurts….
otaylor: airlied: How are the command buffers being handled? Are they in vram?
airlied: otaylor: no just using PCI DMA
otaylor: spstarr: You should not be hitting DFS
airlied: otaylor: except for firefox 🙂
spstarr: otaylor: oh but i do, and i can crash it badly :/
airlied: or did that get fixed?
otaylor: airlied: Yeah, still there, but I’ve never seen big issues there even with no DFS
otaylor: airlied: interms of performance
spstarr: otaylor: yesterday i was testing for airlied and DFS was blowing up
airlied: otaylor: yes it shouldn’t hit that bad.
spstarr: today im in non-kms + EXA w/ DFS w/o composite and its holding so far good even VT switch
airlied: the main corruption I’m seeing seems to be GPU specific which is a bit uggh.
spstarr: i donno but something you did airlied has improved my non-kms use WITH AGP 4x ok
airlied: otaylor: the xchat scrolling one.
spstarr: 🙂
otaylor: airlied: I don’t think I’ve ever seen that on r300
otaylor: airlied: Though my running r300 with kms has been very, very limited
airlied: otaylor: I’m only seeing it on rv5xx.
airlied: my r580 seems fine.
airlied: which means it’ll be a real pain to track down.
otaylor: airlied: it’s presumably a timing issue of some sort?
otaylor: airlied: based on it being random, and on adding flushes mostly, but not entirely fixing it
airlied: otaylor: yeah something is racing, a cache flush or invalidate
carrot_top: Is there any idea when the driver will be released for Xorg 7.4?
airlied: carrot_top: 6.9.0 already was
carrot_top: where can I download it?
airlied: http://xorg.freedesktop.org/archive/X11R7.4/src/driver/
carrot_top: which one?
airlied: http://xorg.freedesktop.org/archive/X11R7.4/src/driver/xf86-video-ati-6.9.0.tar.bz2
carrot_top: Does this driver support hardware acceleration?
carrot_top: and 3d graphics?
airlied: carrot_top: you probably want to run a driver from your distro.
airlied: the Xorg driver only supplies the 2D setup/accel pieces not the 3D bits.
carrot_top: Which driver do I need to get the 3d bits?
airlied: carrot_top: what distro are you running? and on what card?
carrot_top: Fedora 9 and the card is radeon 9550
airlied: so you shouldn’t need anything from here.
airlied: F9 comes with support for that card out of the box.
carrot_top: But not the 3d bits. Can you tell me where I can get a driver with the 3d bits?
airlied: not it should have all the 3D bits
airlied: at least all the currently available open source 3D bits
carrot_top: Then why cant I run games like morrowind?
airlied: it might need more GL than the open source dirver support.
carrot_top: Ok, do you know when or where I could go to find out when the proprietary driver is to be released?
airlied: in which case you might need to go look at fglrx.
carrot_top: fgrlx?
spstarr: carrot_top: AMD’s proprietary video driver
carrot_top: Yeah
airlied: the prop driver.. it should be in one of the F9 repos I can’t name.
spstarr: Livna 🙂
spstarr: or whatever they call it now
carrot_top: what would the package be called?
spstarr: erm…
airlied: I think channel #fglrx
airlied: or #ati soory
spstarr: go to rpm.livna.org but ^^^ can help you
carrot_top: thanks
otaylor: airlied: Just saw the “xchat” corruption in gnome-terminal on my rv350
spstarr: otaylor: what sort of corruption?
spstarr: i see something with xchat too
spstarr: minimize maximize?
spstarr: garbled area above text ?
otaylor: spstarr: text randomly changing to black-and-white garbled blocks
spstarr: yes
spstarr: i see that with kms
otaylor: spstarr: (But not in the glyph cache … next time it redraws its fine)
spstarr: otaylor: i see that also with menus
otaylor: spstarr: I think it’s any text
spstarr: the cache is bad then it fixes
spstarr: yes i think you’re right
otaylor: spstarr: not the cache … it’s actually the drawing
spstarr: i was wondering about that
otaylor: spstarr: We’ve been seeing it (or sometihng nearly identical) on some r5xx for months
spstarr: ive seen that for months also
spstarr: i didnt really care enough since it didnt affect use
airlied: otaylor: cool so it might be just timing then on all chips.
airlied: I tested with no glyph cache code and it still happened.
spstarr: airlied: if there is a timing issue could that cause hangs if timing is off?
airlied: spstarr: that would be a different sort of timing issue.
spstarr: ok
airlied: my standard test is run xchat get some text in it and reize it a lot.
spstarr: airlied: i just minimize and restore and see the corruption
spstarr: airlied: with EXA i see a long ‘delay’ in repainting xchat the same areas where the corruption occurs..
airlied: I thought it might be HDP flushing but I added that to no avail locally.
spstarr: which is interesting
spstarr: I see it now also with EXA and no composite
spstarr: when the window reappears the text conversation area is empty while the rest of the window is painted
spstarr: and the names scroll area
airlied: spstarr: tyhat doesn’t shound liek it at all
airlied: well maybe its realted.
airlied: damn typing..
spstarr: airlied: in composite i get black lines dots and random things in the text area and other places when minimizing and restoring
spstarr: and popup menus
airlied: https://bugzilla.redhat.com/attachment.cgi?id=320140
airlied: that is what we are seeing.
spstarr: yes
spstarr: i see that also
spstarr: oh
spstarr: that
spstarr: no
spstarr: i will try to capture what I do see
spstarr: i do see that on loading your image briefly then it vanishes
spstarr: hmm this wont be easy to screenshot
spstarr: GOT IT
spstarr: http://www.sh0n.net/spstarr/corruption.png
spstarr: airlied: i see this in chat and other windows when big drawing operations happen
spstarr: it happens when i load your attachment url
spstarr: airlied: i also have flash that gets corrupted too with EXA
airlied: spstarr: composite?
spstarr: EXA composite is on if you kept it on for non-kms
airlied: no I mean GL stuff.
spstarr: none on
airlied: it just look like old buffer behaviour.
airlied: or old pixmap contents.
spstarr: when its on i get a similar effect
spstarr: xchat shows that when it initially reappears
spstarr: i can get you the composite corruption in a moment
spstarr: i will reenable composite mode and try to capture xchat
spstarr: airlied: if i can get you more types of corruption I see, maybe it can help solve some issues based on how it looks to you
airlied: spstarr: you have what looks like old pixmaps being wierdly reused.
spstarr: airlied: what causes that? DDX? widget layer?
airlied: could be anything, it isn’t worrying me as much as the other wierd one.
spstarr: i’ll try to reproduce what i see in xchat see if its related to your corruption issue above
spstarr: otaylor: whats in your xorg.conf? have one?
spstarr: i took out all the ricer options
otaylor: spstarr: “AccelMethod” “EXA” “AccelDFS” “false”
spstarr: in kms with composite?
otaylor: spstarr: No composite
spstarr: since our DFS is disabled by kernel and that’s ignored
spstarr: ok i will boot into kms mode in a few mins
otaylor: spstarr: trying to get some work done this evening, wasn’t brave enough to try compiz again
spstarr: heh
tlp: Is there anything exciting available for r5xx cards that’s not in Xorg 7.4?
otaylor: (Actually, working on metacity-clutter, but don’t need to run it at the moment)
airlied: tlp: nothing major, I think bicubic xv filtering is the major feature added since then.
tlp: ah
spstarr: to kms…
spstarr: interesting
spstarr: composite started up when i had it left on, and it didnt crash when i shut it off..
spstarr: (lucky)
spstarr: ok let’s try to get some corruption you saw
spstarr: airlied / otaylor : did you see it while the window was visible or on from a minimized -> restore state?
airlied: spstarr: it normally happens on scroll the window
otaylor: spstarr: just normal visible window … doing stuff to it
spstarr: or just text glyph corruption appeared
airlied: or resize.
spstarr: so far nothing
spstarr: i do see corruption when composite is on.. i will get that screenshot after
spstarr: i am still using -37 for DDX with your patch + memory leak fix manually added in
spstarr: airlied: xorg doesnt state that AGP is forced to PCI
spstarr: oh drm
spstarr: [ 0.883283] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
spstarr: [ 1.837239] [drm] Forcing AGP to PCI mode
spstarr: so i can use 256MB system ram for aperture or it is using that now?
airlied: still only 32MB.
spstarr: ok
spstarr: [ 91.046040] mtrr: base(0xe1144000) is not aligned on a size(0x5a4000) boundary
spstarr: 😉
spstarr: 2.6.27.4-68
spstarr: still no text glyph corruption yet
otaylor: spstarr: it’s a race … I wouldn’t worry to much that you *aren’t* seeing it… though obviously the better we know how to reproduce reliably,the better
spstarr: just going about my normal use
spstarr: airlied: its interesting i get the mttr notice when i vt switched and returned
spstarr: ok i just got corruption now…
spstarr: but highlighting with mouse it went away
spstarr: the text was cut off
tlp: X11 error: BadAlloc (insufficient resources for operation)
tlp: This is what I get from mplayer when compiz is enabled (r5xx)
airlied: tlp: with EXA turned on?
tlp: doubt it, let me check
tlp: fixed it, thanks
tlp: Is that something that can’t be automatically enabled by the distro?
agd5f: tlp: we’ll probably make EXA teh default soon
tlp: ah
agd5f: the issue with Xv you are seeing is actually an XAA issue
spstarr: airlied: with kms on, i dont get that pattern of corruption when viewing image but a black area
spstarr: odd
spstarr: agd5f: have you seen http://www.sh0n.net/spstarr/corruption.png type corruption before? whats your thoughts on that? same as airlied ?
tlp: I need to try some things and update the RadeonPrograms wiki.
spstarr: i do not see this in kms at the moment however
agd5f: spstarr: looks like old pixmaps
spstarr_desk: shit
spstarr_desk: X just crashed
spstarr_desk: checking dmesg/logs it restarted kdm
spstarr_desk: agd5f: i would think we do something cleaner then that though
otaylor: spstarr_desk: I’m not completely sure that’s not just a) bg=None handling with Composite leaving the content unintialized b) slow redrawing
spstarr_desk: composite off
spstarr_desk: i am checking as to why X just crashed
spstarr_desk: 1826.959403] [drm:radeon_gem_ib_get] *ERROR* Major case fail to allocate IB from freelist ffff
spstarr_desk: [ 1826.959413] [drm:radeon_cs2_ioctl] *ERROR* ib_get failed
spstarr_desk: [ 1834.753808] mtrr: base(0xe1144000) is not aligned on a size(0x5a4000) boundary
spstarr_desk: oh badness
spstarr_desk: Fatal server error:
spstarr_desk: DRM Command submission failure -22
spstarr_desk: the gpu however is not dead only X blew up and restarted ok
spstarr_desk: ffff? it went to the very end of whatever it was doing?
spstarr_desk: attaches gdb to X incase it crashes again
airlied: spstarr_desk: the GPU never gave it back the IBs so it died.
spstarr_desk: hmm
airlied: ponders if I need longer retries there or not.
spstarr_desk: airlied: if X crashes the crash might tell us why it didnt
spstarr_desk: not familiar with what an IB is.
airlied: its a command buffer that we fill things into and give to the card.
airlied: its supposed to give them back when its finishe processing them
airlied: it sounds like it didn’t I should dump more info on the ring when that happens.
spstarr: is there a specific time period it has to give them back?
agd5f: a time stamp gets written to a scratch register
airlied: probably not long enough 🙂 I must check if that code needs more retries.
airlied: but if someone submits 16 IBs from userspace before the kernel finishes one I thin kthe GPU is nearly always locked up.
airlied: but it could happen I suppose.
agd5f: maybe the timestamps weren’t coming through
spstarr: they cannot be queued by drm? or they have to be all sent at once?
airlied: it is queing them 16 is the limit.
spstarr: ok
airlied: at the moment it just waits on the fence that TTM submits after them.
airlied: it cycles through all the buffers looking for one that has been used up.
tlp: hmm. In respect to updating the wiki, I’m not sure how to rate this game. I wouldn’t recognize minor texture problems if I saw them, most likely.
agd5f: airlied: we could free buffers sooner if we set two fences, one for the buffer and one for the surface sync. not really relevant in this case though
airlied: agd5f: actually I do lay down two counters I just don’t really use the first one 🙂
airlied: I think I found the corruption by accident.. of course by saying this it will happen again.
spstarr: heh
airlied: bans himself from every writing CP packet3s
spstarr: wow that was a long stall out
airlied: agd5f: I tried turnning on the GART don’t pass throught bits.
spstarr: again
airlied: and it led me to the culprit 🙂
spstarr: stall out
agd5f: 🙂
airlied: my fill vram with 0s had the wrong ROP
agd5f: I knew those would come in usefula t somepoint
airlied: so it was trying to read from SRC_OFFSET
airlied: which was 0
airlied: it NMIed on the first clear.
spstarr: now i am getting stalls constantly when a flash video is loaded but not played with youtube.com
spstarr: 🙂
spstarr: well i know how to crash gnome-terminal 🙂
spstarr: keep hammering the restore button
spstarr: it crashes
spstarr: at least i think it is
airlied: spstarr_desk: what restore button?
spstarr: maximize
airlied: does gnome-terminal crash or X
spstarr: well that’s how i used to get X to blow up
airlied: but does g-t crash?
spstarr: constantly doing full screen minimize on apps as fast as i can
spstarr: i will tell you im gonna attach gdb to one
airlied: huh?
airlied: you can’t tell if g-t crashes or X crashes without gdb?
spstarr: no no
spstarr: i think thats a separate issue
spstarr: not X crashing t
spstarr: as aside affect of my weird use of gnome-terminal i think *it* is crashing but when using it in this way it sometimes would crash X too
spstarr: no, is exiting normally says gdb i guess when i try to force it to maximize over and over the window ‘X’ moves close enough to the cursor to close gnome-terminal
spstarr: hmm, hard to trigger the X crash
airlied: okay kernel gone into koji for building
airlied: it might actually fix lots ofthings.. accessing illegal memory ftl.
spstarr: nice
spstarr: i can reenable agp with kernel param =4 (to set AGP 4x?)
spstarr: assuming my lockup(s) come from any other areas you’re fixing now
airlied: in theory yes.
spstarr: ok, will try once i trigger this to crash.. somehow again

Radeon IRC Logs For 2008-10-30

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-5-28

RadeonHD.org | Radeon IRC Logs For 2008-11-03

RadeonHD.org | Radeon IRC Logs For 2008-12-14