EruditeHermit: is there somewhere that is a pastebin for images?
EruditeHermit: tinypic was being slow
EruditeHermit: playing video with the radeon driver after about Dec 2nd causes a shift
EruditeHermit: I am trying to figure out which commit it was that did this
EruditeHermit: perhaps fix scissor setup for XV?
MrCooper: EruditeHermit: sounds like a job for git bisect
EruditeHermit: MrCooper: I'll read up on it, but would you be willing to help if I had questions?
EruditeHermit: MrCooper: I am going to sleep now
MrCooper: just ask here, someone should be able to help
EruditeHermit: but I'll try to do it tomorrow
EruditeHermit: if I have time
EruditeHermit: thanks for the suggestion
reinoud: Hi Alex
MostAwesomeDude: Hey, people. Sorry for being gone so long. Vacation's officially started, what should I put on my plate?
MostAwesomeDude: My "big" goals are to get LLVM->r300 stuff working, and I've got an RE project from my school. Dunno what you all are up to, though.
glisse: MostAwesomeDude: i will push my gallium bits
glisse: got them on a machine here
glisse: i need to push things in gallium-0.2 first
MostAwesomeDude: glisse: Thank you *very* much.
MostAwesomeDude: Is it just FF stuff, essentially?
glisse: i will push the winsys
glisse: the other part is better to start from scratch again as it wasn't done in cs spirit
glisse: and it's buggy never really worked beside drawing tri-flat
glisse: at least with winsys you got somethings on the screen
glisse: note that you need dri2, so my ddx
MostAwesomeDude: Hm. 'k. I need to upgrade everything here anyway.
MostAwesomeDude: What's the right kernel for getting a working GEM nowadays?
glisse: well kms+dri2
glisse: i think airlied tree on kernel.org
glisse: there is a fedora rawhide branch their
reinoud: agd5f ?
agd5f: reinoud: hey
reinoud: got any usefull info from the vbios?
agd5f: reinoud: haven't had a chance to look at it yet
z3ro: MAD|adventures: how's it going?
Cyntek: Good morning everyone.
spstarr_work: hullo MAD, agd5f
Cyntek: I'm running a ATI 9600SE Agp card 128MB, with Windows XP Sp3, and I have downloaded the latest ati radeon driver from ati/amd website.
Cyntek: I am experiencing a reboot problem with the latest drivers and it looses Digital Signal.
agd5f: Cyntek: this channel is for open source Xorg drivers, not windows drivers
Cyntek: anyone have this issue, with the 9600 SE card
Cyntek: oh. k!
MostAwesomeDude: z3ro: Doin' good, just getting back into the groove of not doing school. :3
ejs1920: I was about to start figuring out why glxgears had become 30% slower, and some opengl things were now too slow to be smooth
ejs1920: But it was just because I'd forgotten that the fedora Xorg rpm scriptlet removes ModulePath lines from xorg.conf
ejs1920: I think a line with "ModulePath" and then "nvidia" should stop that
agd5f: ossman: so we are hitting hw limits using the clipped triangle on hi-res displays. the hw guys suggest we use point sprites instead
ossman: point sprites?
orkiz2: airlied: kernel 126.96.36.199-152.rc2.fc10.i686 and -ati 62 now let me hibernate/resume nost of the time on my RV350. Thanks
orkiz2: Occasionally though, the resume process hangs, but I think that that is independent of -ati.
orkiz2: moeSizlak: Did that work out to be the same as well for you?
moeSizlak: i never had a problem w/ slleep/wakeup
moeSizlak: but i also use my own kernl.org kernel
moeSizlak: my only problem is lots and lots of video glitches and random lockups when using composite effects on my agp rv350 64mb vram
orkiz2: moeSizlak: ok
moeSizlak: occasionally upon wakeup, kpowersave will popup an error window that says "error 1"
moeSizlak: but everything seems to be fine despite the error
spstarr_work: agd5f: I noticed with rv350 + kms I see tearing on video :)
spstarr_work: when the video redraws you see /
spstarr_work: triangle tear
spstarr_work: most notable on mp4 videos
airlied: spstarr_work: thats fixed , just not in fedora
spstarr_work: with mplayer
spstarr_work: airlied: ahh nice
spstarr_work: so thats what was fixed by ossman / agd5f?
ossman: airlied, how much have you tested non-kms on f10?
airlied: ossman: it should work similiar to F9.
ossman: I get crashes with the f10 kernel, but not the f9 one (with the same userspace)
airlied: I mess up every so often though particularly around agp
ossman: the is igp
airlied: ossman: what sort of crashes?
ossman: a general protection fault. so neither a oops, bug or warn_on
ossman: I don't have an actual dump handy right now unfortunately
ossman: airlied, there is nothing from radeon nor drm in the trace though. just some vm stuff
ossman: and it occurs when I'm torturing it with lots of large Xv frames
ossman: I'm going to do some more digging, I just wanted to check if you had any ideas
airlied: oh wierd, sounds like something corrupts something.
airlied: out-of-bounds copy or something wierd.
orkiz2: spstarr_work: Can kms be used with rv350?
orkiz2: On release of F10, that kernel caused complete screen corruption on my rv350 with kms
orkiz2: airlied: Is it expected on rv350 to go from 1390 FPS on glxgrears before hibernate/resume to 200 FPS after resume?
airlied: not expected know, wonder why that is.
airlied: orkiz2: the rv350 should work fine in PCI mode which it gets by default.
orkiz2: sorry, connection failure
orkiz2: afaict, it is in AGP mode with your kernel from friday and -ati 62
orkiz2: unless I ask for the bustype to be pci in xorg.conf
airlied: nope kms defaults to pci mode.
airlied: until I solve the corruption.
orkiz2: airlied: I see, let me see on the next reboot
orkiz2: airlied: Does that mean kms defaults to pci mode, but xorg works in agp mode?
airlied: pretty much.
orkiz2: airlied: Cool, thanks for the explanation
spstarr_work: orkid: non AGP
orkiz2: spstarr_work: ok, thanks
spstarr_work: airlied: i think it's good that you saw the corruption, since the mm is still hot code
airlied: spstarr_work: its wierd how its chipset specific, granted on the SiS I do see some very minor issues.
spstarr_work: but with the intel you get massive corruption?
spstarr_work: just as I had?
airlied: yeah, its very strange.
spstarr_work: is it possible they do not like dynamic GARTs?
spstarr_work: or is the memory not being cleaned out?
airlied: the code looks to do the right thing, but I need to write some test code
airlied: to figure out what operation is breaking.
airlied: I suspect we aren't waiting long enough at some point.
airlied: ajax: btw the r600 slowness to start was mostly trying to idle the r300 fifo which of course isn't there.
glisse: airlied: btw for 2d fglrx pad wait_until with a write to a 2d reg
airlied: glisse: any 2D reg in particular?
glisse: one related with 2d blit
glisse: but i guess they just picked up one reg
glisse: i can look for the dump
glisse: hhhmm no
glisse: not on a plugged hd
glisse: doing computation so won't stop my computer before it ends :)
airlied: did you get it with mmiotrace?
glisse: i think this was with iba
airlied: oh yeah iba could do 2d packets I forgot that.
glisse: well it was in the ring
glisse: they write 71 times the same reg to fill the fifo
glisse: well with the repeat bit :)
glisse: also doing this was somehow helping to avoid lockup
airlied: that might explain why splitting 2d/3d works better on those rs690s.
airlied: as they locked up.
glisse: in the 3d engine
airlied: yup thats what I was seeing on the rs690
glisse: basicly i think it's to make sure that the whole engine is stall and don't start executing 3d before 2d is done
airlied: 3D engine locked up until I split the 2D/3D IBs.
glisse: maybe the isync reg is not working properly :)
airlied: I wonder if the in-kernel blits need some help also.
glisse: when i was testing i tweaked kernel to always do that
airlied: yeah I suspect I need to collect some fglrx traces particularly from rs480s.
airlied: I think the final split of 2D/3D made them more unstable again.
glisse: yup seeing what fglrx does is always helpfull maybe we should setup a repo like nouveau and have some kind of automatic dumping so we can spot pattern
glisse: i guess many workaround are directly in the driver and not documented anywhere
airlied: I think the errata list is probably 100 pages long :)
airlied: esp for rs480
agd5f: glisse, airlied: you ned to write a downstream reg (SC for example) between two wait for 3D idle otherwise the SC block won't assert idle. that's why you have to add a SC write at the end of the 3D IB.
airlied: agd5f: any ideas for 2D :)
agd5f: might be the same for 2D
agd5f: ossman: point sprites are textured points of variable size
EruditeHermit: hi, how do I check PCI id?
bridgman: lspci will tell you what devices and IDs you have
bridgman: probably only source code will tell you which IDs are supported
benh: airlied: ping
benh: airlied: did you commit something for this PCIe GART endian vs. swapper issue ?
benh: airlied: back on hacking X on this 440 board this week, so I'll try to gather all the fixes
benh: and send you a batch once I get all the problems solved
airlied: benh: no I was waiting to see if it was the problem.
benh: I'll have a look today
benh: you commited some of my crazy debug I forgot to remove :-)
benh: xf86DrvMsg(..., "TOTO SAYS %016llx\n" ...
airlied: hehe.. I saw the go past the other day and wondered where it came from :)
benh: allright, where do we populate the PCIe GART
spstarr: airlied: hibernate/resume worked
benh: ah there !
benh: airlied: is the GART covered by a surface ?>
airlied: benh: nope, just the default swapper
airlied: benh: its populated in ati_pcigart.c when the CP is enabled
benh: yup, found that
benh: airlied: that rulez http://www.exetel.com.au/residential-hspa-pricing.php
benh: airlied: 15 bucks a GB 3G data plan with USB modem :-)
airlied: benh: oh thats no bad.
benh: static IP too :-)
spstarr: wonders what to make for dinner
spstarr: I'd like some triangles with some textures a la carte with some vertexes to go please.
benh: airlied: allright, I've stuck 0 into SURFACE_CNTL just before calling drm_ati_pcigart_init
benh: airlied: but it seems still busted ... it hangs somewhere initializing
benh: airlied: I'll have to dig, it could well just be some more crackpot with >32-bit addresses that I haven't fixed since it definitely goes further on Bimini
EruditeHermit: ah, the latest git commit fixes the video issue
airlied: benh: does writeback succeed?
EruditeHermit: also, where in lspci is the pciid?
EruditeHermit: I am still not seeing it
airlied: agd5f, ajax : I suck my tv-out atombios workaround, busted other things, I have a lit up dce32 now.
benh: airlied: dunno yet, gotta fix some debug stuff yet
benh: loading r100 microcode :-)
benh: I must be missing my domain fix
benh: looks better
benh: with one card
benh: let's do some rendering
benh: ok, so xterm window displays
benh: and then machine locks up with an infinite serie of
benh: [drm:radeon_freelist_get] done_age = 5
airlied: so gpu locked up
benh: writeback test succeeded btw
benh: right, it locked up pretty quick
benh: airlied: what is PCIE_TX_GART_BASE supposed to contain ?
airlied: start of the GART table in GPU space
benh: I see
airlied: benh: is PCIE coherent on this platform?
benh: the vmap of the GART should be non-cached
benh: I'm about to verify that
airlied: ah yes you alloc using _PAGE_NO_CACHE
benh: I wonder if the card has a problem with the PCIe link being only 4x
airlied: not sure where we enable the pcie link count
airlied: think atom can set it up
airlied: 0xa2 in the PCIE indirect regs
benh_: where ?
airlied: the first 3 bits are link count, 0,1,2,4,8,12,16
benh_: in the config space ?
airlied: nope the PCIE indireect regs
benh_: what are those ?
airlied: its where the gpu pcie bits are
airlied: okay dce32 merged at least for DVI
benh: reg 0xa2 doesn't appear
benh: in my M56 doco
airlied: benh: yeah its not something you'd ever set manually
benh: we should probably set GART_TLB_INVALIDATE when enabling it btw :-)
airlied: I seriously doubt the hw is dumb enough
benh: airlied: let me check, I'll add a read
airlied: if the gart hasn't been on before maybe, but how often does that happen :)
benh: quitting/restarting X
benh: the TLB can contain crap no ?
airlied: we turn the GART off/on
benh: but we don't invalidate the TLB
benh: and do we know fure sure the TLB comes up clean ?
airlied: I think turning in off/on does that
benh: I know processors where it doesn't :-)
airlied: no harm doing it anyways.
airlied: I think we do on the IGPs
benh: we have to wait for the bit to clear or something ?
airlied: nope I tried that before and it doesn't work.
airlied: I think just writing it is sufficent on the pcie one
benh: we need to check what ATI says
airlied: I asked
benh: we need to clear it tho no ?
airlied: I have code in kms to do it already.
benh: ah, it blew up earlier now
airlied: I jsut set it, readback and clear it
benh: doing the gray thingy
benh: 0xa2 reg contains 0x36
benh: which would be x16 according to your table ... ouch
benh: what is 0x3 ?
benh: 0x30 I mean
airlied: some reconfig bits.
airlied: read back
airlied: so it requested 16, only got 4
airlied: which seems right.
benh: let me also force writeback off see if that helps
benh: died a bit later
benh: could run an xterm this time
benh: then it died
benh: airlied: surface_cntl is 0x100 (translation dis, that's it) at the time of the GART init
benh: airlied: at least without any fbdev and on first start of X from boot
benh: so that's ok
airlied: so its either some 36-bit or coherency issue?
benh: yeah well
benh: there should be no coherency issue
benh: ie ,cache is off
benh: unless I screwed up
benh: which I'll check in a minute :-)
spstarr: airlied: I will do rapid testing when you start looking at the corruption if you have patches not pushed
benh: but then, I wonder what 36 bit issue ... RAM is in low 32-bit
airlied: spstarr: hopefully today, had to finish dce32 stuff first.
benh: and GART seems to be properly populated
benh: works for a few commands in fact
spstarr: airlied: the night is very young here (10pm soon)
airlied: benh: maybe fix it on the powerstation first :)
benh: that's cache coherent :-)
benh: did you try on the powerstation ?
airlied: I don't think I can do much with X on the G5 here.
benh: it just locks up under load ...
benh: why ?
airlied: same on the G5 I think.
benh: no serial port ? :-)
airlied: well netconsole works mostly.
benh: well, the thing is, that 440 CPU is nice because it has really no ordering issue .. not much at least
benh: no speculative loads etc...
benh: how do you generally go at debugging such lockups ?
airlied: with kms I have a lot of debugging hooks now as well for dumping the ring etc.
benh: what kind of indication do you have of what happened ?
airlied: so I just dump the interrupt and ring info
benh: I see the DRM debug about dispatching some indirect buffers
airlied: and see if the irq counter is stalled,
airlied: and then see if the ring is stuck
airlied: if the ring is stuck I have hacked up dumpers for ring and indirect buffers
benh: ok so I'm not sure what to look at here, I'll have to dig into the code
airlied: yeah I'm a bit lost on what could make powerpc any different
benh: you don't want to pop by canberra one of these days and debug that with me ? :-)
benh: could be an endian problem somewhere but I doubt it
airlied: benh: hehe I'm not allowed more than 2 km from home, baby appears any day :)
airlied: benh: you using master -ati driver?
benh: so I see in the log
benh: a bunch of radeon_freelist_get
benh: done_age = 0
benh: done_age = 1
benh: done_age = 2
benh: to 5
benh: and then it's always 5
benh: how do that work ?
airlied: so the gpu crashed in there.
benh: I forgot all about the buffer aging thingy
benh: well, that's the first things emitted
benh: ie, that's nothing before that anyway
airlied: we emit the age after each buffer
airlied: which gets written to a scratch reg + writeback to page
benh: after/before ?
benh: I see age before any cp_indirect
benh: ah ok
benh: the card emits the age
airlied: we emit the age after, we check them before
airlied: we stick the age into the command stream, and when it gets there it emits it
benh: do we dump the age in the log when we emit an ind buffer ?
benh: [drm:drm_ioctl] pid=3035, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1
benh: [drm:radeon_freelist_get] done_age = 0
benh: [drm:drm_do_vm_sg_fault] SG fault: page_address=dc036000 count=2, flags=0
benh: [drm:drm_ioctl] pid=3035, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
benh: [drm:radeon_cp_indirect] idx=1 s=0 e=120 d=1
benh: [drm:radeon_cp_dispatch_indirect] buf=1 s=0x0 e=0x78
benh: [drm:drm_ioctl] pid=3035, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1
benh: [drm:radeon_freelist_get] done_age = 1
benh: etc ...
airlied: I think buf=1
benh: that's the age ?
airlied: not sure about age.
airlied: but until it goes over 16 I think it''l be the same
airlied: when it dies use avivotool to look at RADEON_CP_RB_RPTR and RADEON_CP_RB_WPTR
benh: when it dies it's locked up in kernel
benh: hrm... possibly not always since it doesn't always die in the same place
benh: I wonder if it's some of the voodoo timing & credit stuff in the PCIE registers that need adjusting
airlied: if its that sorta things it'll be really painful to figure out.
airlied: I'd hope the hw is smart enough to get that right by default
benh: you wish
benh: I still don't quite get this age thingy
airlied: the card CP shoves the age into the scratch when it gets that far in the ring
airlied: if the ring is dead, it won't reach that point
airlied: so won't ever see a newer age.
benh: so every now and then
benh: we insert in the ring a command to write a new age
airlied: we do after every IB
airlied: if its set to be discarded
benh: in which case wouldn't we discard ?
airlied: we discard nearly always
airlied: we don't discard when we want to submit part of an IB and keep writing to it from userspace
airlied: but that isn't done that often.
benh: so we don't log the age at that point, I'll add some debug
benh: airlied: so with writeback hacked off, we basically only do reads from PCIe
benh: airlied: I'll look at the various RX_ stuff in the PCIe registers too
airlied: benh: pretty much, no writes
airlied: benh: it might be worth checking if a GART error occurs either
airlied: PCIE 0x18
benh: RPTR is stuck
benh: ok, I'll dump that
benh: RBBM_STATUS = 0x98030140
benh: CP_RB_RTPR = 0x00000042
benh: CP_RB_WTPR = 0x00000108
airlied: the latset avivotool can dump PCIE
benh: WPTR increases for each new packet
benh: ok, I'll build that
airlied: okay ring it stuck so something bad happened.
benh: avivotool is in its own git ?
airlied: nope radeontool
benh: no error in lspci -vv in the PCIe error reporting
benh: airlied: in your home dir ?
benh: yeah, there's 3 in various people homes :-)
benh: found that one
benh: might have to fix it for 36-bit
benh: it stopped after the 5th ind buffer or so
benh: I see the page faults spaced by 64k
benh: ah it's using libpciaccess, that should work
EruditeHermit: (--) PCI:*(0@1:0:0) ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] rev 0
EruditeHermit: from Xorg.0.log
benh: airlied: is there a branch or something ?
EruditeHermit: is it supposed to have the PCIID somewhere in there too?
benh: airlied: the one I have here doesn't dump anything
benh: airlied: or I'm missing a command
benh: could be useful if you updated the usage string :-)
airlied: benh: hehe.. oops.
airlied: basically regmatch PC:0xa2
airlied: will dump a PCIE reg
benh: you haven't added stuff to dump the GART & ind buffers etc...
airlied: not there.
airlied: its all tied up in the kms code.
benh: avivotool's on crack
benh: let me see
airlied: wonders what ppc code is in it.
benh: it's me or you're missing a return statement at the end of map_radeom_mem() ? :-)
airlied: I fixed that on the g5 I think
benh: segv in radeon/get/set
airlied: okay pull again
benh: on the stwbrx
airlied: thats the version from my G5
benh: PCIE_RX_ERR_LOG is 0
airlied: is DFS on?
airlied: try turning it off.
airlied: okay I just checked (granted this is with kms), but I can get logged into gnome on rv515 on the G5
airlied: oh bad things without kms same as you I suspect.
benh: at least it's always dying in the same place :-)
airlied: machine is running but Xorg is at 100%
benh: with or without kms, I didn't quite get ?
benh: it's using XAA, so no DFS
airlied: I dare suggest trying EXA for lols.
benh: I can but it's not likely to make things better, is it ? :-)
benh: oh and attempting to quit X in that state is fun
benh: it gets timeout trying to update the MC registers :-)
benh: do we do anything different in r2/3xx/AGP vs. r5xx/PCIe in the actual content of the packets & ind buffers ?
airlied: EXA might try the codepaths differnt
airlied: not for XAA we just use the blitter pretty much
benh: I was hoping that would at least work :-)
benh: ie, it's pretty boring stuff
benh: EXA can only be worse unless I disable Render & DFS
benh: EXA + RenderAccel "0" + AccelDFS "0"
benh: display content is garbage
benh: it's not locked up, but it's shadow of my previous boot covered with crap, looks like RAM decay
benh: ie, looks like it's didn't actually write anything to the screen
benh: RPTR is stuck a lot earlier
benh: so we start, RPTR=WPTR=0xe
benh: I see a bunch of pages faults (ie, we write a lot more to the ind buffer than we do with XAA, probably an UTS)
benh: that gets submited, at which point RPTR=0x13 and WPTR=0x15
benh: and RBBM_STATUS has bits 0x80000000 and 0x10000 stuck
benh: grr, that M56 doco has no bit defs for RBBM_STATUS
benh: so CP_CMDSTRM_BUSY and GUI_ACTIVE both stuck
benh: so the first ind buffer killed it
benh: I wonder if I can control the max burst lenght on PCIe, maybe something is stuffed there
benh: nah it's fine
benh: MaxReadReq is set to 128 bytes
benh: that's the min
benh: no PCIe error detected
benh: airlied: do you have any experience dumping the PCIe GART TLB ?
airlied: nope, no idea what is in the regs
benh: PCIe 0x18 (PCIE_TX_GART_ERROR)
benh: ie, invalid read
airlied: I wonder do you have an endian issue somewhere
airlied: with an adress.
airlied: benh: bbl.
benh: airlied: normal PCI GART works just fine ... any code path that would be different that you can imagine ?
benh: airlied: could it be that the GART HW is reading from the GART through HDP and thus byteswaps ?
benh: GART_RDREQPATH_SEL 6 0x0 Read request path
benh: 1=Direct Rd Req to MC
benh: whacks 0x40 in there
benh: output is still fucked
benh: but it doesn't blow up any more
benh: well, it does differently and later
benh: airlied: weird, have you seen the definition of PCIE_TX_GART_BASE in the M56 doco ?
benh: airlied: especially the blurb about using HDP versus not ?
benh: I think the description is backward tho
spstarr: any stuff yet airlied ? :)
spstarr: airlied: baby alert! oh my
rnoland_: benh: what are you guys looking at? I've got a couple of reports of "garbled" output but haven't got enough info to identify any consistency yet.
benh: rnoland: r5xx PCIe on a powerpc 440 embedded board :-)
benh: rnoland: -possibly- (or not) related to lockups on PowerStation too
benh: rnoland: basically, the engine hangs shortly, on the first ind buffer with EXA and the 5th one with XAA
rnoland_: ok, these aren't ppc, so...
benh: rnoland: I need to dump what's up, it -could- be when we start stuffing pixels in the buffers or shit like that
benh: rnoland: not sure yet
airlied: benh: ah that might make sense
airlied: the HDP vs MC paths.
benh: I get strange results if I try MC
benh: any idea what would cause swapping with HDP ?
benh: RBBM_GUICNTL ?
benh: we pretty much set it to NONE always with EXA
benh: in > r300
airlied: benh: yeah not really sure what could do it.
benh: I'm getting crapzillions of RADEONCopyCP
benh: just for the gray screen
airlied: yup it does a crazy tiled fill.
benh: well, that kills it
benh: funnily, before any pixel hits the screen
benh: is that using UTS ? I'll try disabling that too
benh: just the first batch of these kills it
benh: so no UTS
benh: just a whole bunch of boring blits
benh: is enough to kill it
airlied: yup just lots of 2D blits.
airlied: so you should be able to confirm src/dest
airlied: vs whats in that PCIE error rreg
benh: whacks a FLUSH_RING() in RadeonCopy
benh: ah yes, I need to look at that
benh: I was wondering if it was trying to read past an indirect buffer end in fact
benh: blows on first ind buffer with EXA and it's clearly full
benh: but that's a bad explanation I think ... with XAA, it blows after a while but none are full
benh: (I can see the page faults :-)
benh: one thing...
benh: we let the CP do a 32-bit swap
benh: so we write everything in the ring in native endian or 32-swapped for some stuffs
benh: maybe that's busted
benh: I wonder how hard it would be to disable that
benh: and just swap ourselves everything we stick in the ring
benh: it would be easier for me to write a simple unit test in fact
benh: I should use my vbe tool to setup a simple linear mode
benh: and write a little hack in userspace
benh: boot with mem= to reserve some physical RAM
benh: setup the PCIe GART there
benh: fire up the CP
benh: and pipe selected commands into it
benh: airlied: if i do a FLUSH_RING in every RADEONCopy and disable UTS, it works VERY VERY SLOWLY :-)
benh: but that's because I have serial console debug on every indirect buffer in the kernel
benh: lets see which of those 2 things makes the difference
benh: it's random
benh: now it failed on the wait-for-idle before userspace did anything
benh: have to run
benh: smells like reading form PCIe sometimes cause it to go bonkers, dunno yet what's up