airlied: glisse: ping, just an idea should re relocate the tiling bits in the kernel?
airlied: so that userspace acn't get them wrong by accident?
airlied: it seems if we let userspace say it wants a tiled buffer, then the kernel should be able to edit the command stream to fix it up, and also provide surface config on mapping
airlied: not sure 100% how to emit the relocs for it but it might be easy to make work.
agd5f: airlied: unless otherwise specified we should just always use tiling, also anytime a mapping is set up, also set up an HDP surface
airlied: yeah my plan is to add a surface on bo map
airlied: I just want to have set tiling op though, and let the kernel do all the work of setting the tiling bits in the blits/3d colorpitch regs
airlied: by relocating them.
airlied: so if we change mode to interlaced etc we can just deal with it all in-kernel hopefully.
agd5f: good point
agd5f: kernel can also turn off tiling if it runs out of HDP surfaces as well
airlied: I think I can stick HDP surfaces on a fenced list, and tear down the maps in the kernel.
airlied: when it faults again it can get the map back.
airlied: granted it might trash in whcih case turning off tiling might be a better plan.
z3ro: 3.50K/s eta 6h 30m <- damn, so no playing with kernel-based tracing of fglrx for a while. =/
z3ro: also what the hell is in fglrx to get up to 72M?
airlied: z3ro: installler I thin
airlied: and different versions for diff apis
z3ro: hmm just seems pretty huge.
z3ro: I guess I
z3ro: I'm only noticing because the hotel's internet is like 5kB/s =/
MostAwesomeDude: IIRC they store all the debs, rpms, etc. inside the installer.
z3ro: I see
MrCooper: nope, just binaries for all X versions
MrCooper: packages are generated on demand
z3ro: really they should only need to support the latest one or two X releases imho.
MrCooper: they have to support the enterprise distros
z3ro: oh, right.
glisse: airlied: i don't think kernel needs to know about tiled or not
glisse: and i would rather not edit cmd stream
glisse: i have done more work to my cs checking branch and things are already complex enough with just checking that bo are no used beyond their limit
icewaterman: i know this must have been asked quite some time, but when is there going to be support for r6xx cards?
icewaterman: i mean accelerated support of course.
xnguard: icewaterman: Phoronix is speculating maybe a Christmas present, but I wouldn't hold my breath.
fwc: can anyone tell me how the open radeon driver does vs ATI's binary blob on an RV535 as far as performance/stability?
xnguard: fwc: So far as I know, the binary blob is almost always faster, either a little or a lot.
hifi: performance on 3D sucks, bad
hifi: 2D is fine and I haven't had any stability problems
fwc: yeah im using the open one right now, some 3d games "perform" OK but have weirdness going on and eventually crash the system.. others are unplayable :\ i got an ATI card just so i could get open drivers for it :D
fwc: ah well.. atleast its fine for general desktop usage
fwc: i was just wondering if maybe i was doing something wrong
icewaterman: old games work fine on my r5xx
icewaterman: but nothing fancy of course.
fwc: hmm, like enemy territory old?
z3ro: fwc: wolfet is basically quake3, so it should work fine...
z3ro: I mean, unless they added something that doesn't quite work right yet, eg fog.
fwc: i get like a section of the screen that flashes with a black box, game plays with decent frame rates.. but it crashes after a few minutes
fwc: system hardlock, agp fast writes are off, i dont know whats happening :\
hifi: funny thing was quake2 performs much more poorly than quake3 based games like openarena
z3ro: if you're getting a flashing black box drawn on the screen chances are something is going pretty wrong.
hifi: q2 has a really crappy renderer or something like that
z3ro: you should find a bug report about that
fwc: where should i look/post?
fwc: well im not 100% sure it hard locks, i didnt try remote access
fwc: but video shuts down and theres nothing in messages/syslog/the X log
z3ro: ok, but you shouldn't even get the black flashing box. since this happens, there is probably something going wrong in the driver, which might eventually lead to a lockup.
z3ro: also try to include as much info as you can. versions of everything, etc.
z3ro: and it might help to try the latest git versions, if you're not using those already.
fwc: no, im not.. where can i grab them at?
z3ro: there is a guide at http://dri.freedesktop.org/wiki/Building, but unless you know about compiling and installing things yourself you shouldn't try this.
z3ro: probably the easiest thing to do it file a bugreport, include as much info as you can, and hope someone can reproduce it.
fwc: hahah i think i can handle compiling it :)
z3ro: ok. I just don't like telling people "go compile and install this" then a few mins later "hey, you broke my system!" :P
fwc: haha yea, of course
fwc: fun, i have to upgrade some dependencies!
fwc: oh.. and EXA vs XAA?
z3ro: EXA is the replacement for XAA.
fwc: yeah, but is one of them more stable with an r500 for general use? or are they both up there? or am i somehow misunderstanding something?
z3ro: hmm I haven't heard of any major problems one way or the other... I think only performance would change.
fwc: ok cool, thank ya very much for everything
z3ro: no problem. :)
paxcoder: hey people. glxinfo says mesa, and i've installed all the right things, i think (including radeon dri, ati, mesa dri, and mesa glx)
paxcoder: xorg.conf is configured ok, i guess. what's the deal?
paxcoder: help. anyone?
paxcoder: do i need to remove mesa somehow or what?
agd5f: paxcoder: what are you trying to do?
paxcoder: agd5f: get 3d support
agd5f: paxcoder: can you pastebin your xorg log? also what card and what version of mesa do you have installed?
agd5f: paxcoder: if you have an r5xx card, you'll need mesa 7.2
paxcoder: agd5f: my xorg log used to work
paxcoder: card is X1200
paxcoder: mesa is debian's experimental
paxcoder: (i installed it just to get 3d)
agd5f: paxcoder: ok. can you pastebin your xorg log? also, did you install fglrx at some point?
paxcoder: ok, a sec. you'll get the link
paxcoder: agd5f: oh, you want the log
paxcoder: sry, wait a minute
paxcoder: agd5f: where is the log again?
agd5f: paxcoder: /var/log/
agd5f: Xorg.0.log usually
paxcoder: agd5f: ok, let me paste it somewhere. I also have trouble with my keyboard, so if you see what's happening, it would be greatly appreciated.
paxcoder: agd5f: here it is: http://pastebin.com/da45ced8
agd5f: paxcoder: log looks fine. can you pastebin the output of LIBGL_DEBUG=verbose glxinfo
paxcoder: agd5f: http://pastebin.com/d72addaa1
agd5f: paxcoder: looks fine. 3D driver is working
paxcoder: agd5f: OpenGL version string: 1.3 Mesa 7.2
paxcoder: shouldn't it say radeon or something?
agd5f: OpenGL renderer string: Mesa DRI R300 20060815 NO-TCL
paxcoder: so that's all i'll get?
agd5f: what do you mean?
paxcoder: Nexuiz runs like grandpa
agd5f: nexiuz may use some bits that aren't accelerated yet
paxcoder: agd5f: older version ran fine.
paxcoder: this one on lowest lags
paxcoder: is X1200 that bad?
agd5f: older version of nexiuz or driver?
paxcoder: agd5f: umm... i guess nexuiz
paxcoder: but rather than answering that answer my previous question
agd5f: if nexiuz uses lots of vertex shaders, it will be slow on IGP chips since they lack a vertex shader
agd5f: so it's done in sw
paxcoder: so i should search for vertex shaders, turn them off, and it should work?
agd5f: paxcoder: not sure. I'm not too familiar with nexiuz
paxcoder: thanks for help anyway. bb
airlied: glisse: the kernel has to know about tiling
airlied: it needs to know for scanout
airlied: I just dislike having mesa call get tiling regularly when it really doesn't need to.
airlied: the kernel hhas all the info.
glisse: airlied: it only needs to know for scanout
hifi: damn it's hard to find a AGP R5xx
hifi: on another note I'd probably get a new motherboard with a PCI-E model for the same price...
fwc: i just got a sapphire 512mb RV535 AGP 8x for $60.. sucks compared to what you can get for $60 in PCIE, but not hard to find :D
Xperiment62: when using the compiz WM all window title bars are removed
airlied: glisse: and for telling all the clients accessing the buffers
Xperiment62: anyone seen this happen before?
airlied: I don't think emitting a reloc for the COLORPITCH regs/DEPTHPITCH regs and TX ones is that much more overhead
CE: do all radeons support solid on A8 dst, and A8+A8 composition?
CE: i wonder who write the driver if nobody knows what the hw is capable of ;)
otaylor: CE: uh, go look at the sources
CE: i have but it wasn't really clear to me
otaylor: CE: but the assumption that anybody who wrote the driver is here and listening and is going to respond within 10 minutes...
CE: thanks for the hint, I'll have a look
CE: well, this is not the first time I ask ;)
otaylor: CE: Also note that the hw docs for r300 and r500 are available
MostAwesomeDude: The HW docs won't help.
CE: not really, no
otaylor: MostAwesomeDude: no?
MostAwesomeDude: The EXA code is self-documenting, although I could go look it up.
otaylor: MostAwesomeDude: they should tell you how to program the CB for writes
airlied: the hw docs mention the color dst format
MostAwesomeDude: otaylor: His question's not exactly answered in the r5xx docs. It's one of those things that just kinda works.
otaylor: MostAwesomeDude: I actually did look it up, and since it was self documenting, I figured the file reference would be more informative than giving my interpretation :-)
MostAwesomeDude: Also I thought there was somebody a couple days ago that was asking similar questions, did anybody else see that?
CE: after all, if anybody took an offense - sorry
MostAwesomeDude: I don't think asking questions is ever offensive in here, except when it's me asking airlied or marcheu too many stupid things. :3
MostAwesomeDude: CE: Yes, looks like all Radeons support solid with A8 dest. I don't see anything that falls back just for A8+A8 composite, so I think it should be fine.
CE: thanks :)
CE: is RADEONPrepareSolid the solid-accaleration setup stuff?
CE: seems like they don't support 24-bit destinations ... strange
airlied: we don't get a lot of 24-bit dests.
airlied: gpus don't really like packed unalgined formats.
CE: would that cause XRenderFillRectangles to fallback with an RGB24 destination pixmap?
MostAwesomeDude: No idea about specific fallbacks. That's up to the Xserver, not us.
CE: but isn't in the "RADEON_FALLBACK" case the fallback triggered by the driver?
airlied: CE: the fallback prints the reason
airlied: turn no the fallback tracing
CE: and whats the Bool return type for?
airlied: yup the driver causes the fallbacks
airlied: smacks MostAwesomeDude
airlied: is an RGB24 pixmap packed or is its XRGB32 really?
MostAwesomeDude: Ouchies. Okay, I'll shut up.
MostAwesomeDude: sits in corner
CE: airlied: ah, that would explain it
CE: thanks :)
spstarr: looks around
spstarr: airlied: any goodies for me to try agp wise?
airlied: spstarr: nothing really.
benh: airlied: radeon_card_posted() returns TRUE here on an absolutely non-posted card :-)
benh: I think we're doing the wrong thing
benh: I know old ATI Mac drivers, to test for posted, used to check the clock to see if the PLLs were setup
benh: maybe we need something similar
airlied: yeah I think checking if the crtcs are enable might not be the best
benh: ah no
benh: it's just a logic error in the code !
benh: ah wait, let me throw more debugging at it
benh: anyway, if I force the POST, it doesn't lock up
benh: airlied: fun, I manually peek at the CRTC enable before starting X on boot and it's disabled
benh: airlied: but it still thinks it's posted :-)
benh: time to add more ErrorF() !
airlied: both of them?
airlied: granted on avivo there is one crtc master en
airlied: we should probably just reaed that instyead othe or'ing
airlied: instead of the or'ing
benh: or we should just check if the PLLs have been setup :-)
benh: yeah, I checked both
benh: let me see what's up
benh: fun is that if I force POST it
benh: then quite X
benh: next time it -does- thing it's not POSTed :-)
benh: while it is
benh: really, the CRTC state isn't the right thing to check
benh: agd5f should see if he can come up with something better such as some PLL bit
airlied: well having the crtcs enabled when the card isn't posted would be bad.
benh: airlied: I don't think they are, let me see
benh: airlied: they don't seem to be at least when I poke with xmon
benh: airlied: anyway, it's just the wrong thing to test
benh: sprinkles more ErrorF and curses NFS root for weird things happening
benh: and for just generally sucking
benh: airlied: look at the code RADEONGetBIOSInfo
benh: airlied: it's being stupid
benh: airlied: it starts with posted=TRUE
benh: and it only flicks it back to FALSE if it -fails- radeon_read_bios
benh: well... guess what ? it works here
benh: ie, radeon_read_bios works just ifne
airlied: ah its prtobably working around another issue then.
airlied: it might not have been meant to fix the problem you are seeing :)
benh: well it should not assume POSTED when it can read the BIOS via sysfs :-)
benh: in fact radeon_read_unposted_bios is a misnomer
benh: because it reads re-enables access to the ROM to read the BIOS
benh: but that access has been disabled in the first place ... by POST !
benh: I think it's all backward
airlied: it does seem so, since the bios has to be able to read itself at bootup
benh: which is why it works for me the second time around
benh: or after I use x86emu
benh: because that indeed disables access
benh: which means that radeon_read_bios() fails
benh: which makes it use read_unposted_bios, which then works
benh: but then it looks for the CRTC regs which are off and thus decides it's not POSTed :-)
benh: well ... guess what ? it -is-
benh: so the whole logic seems to be totally backward
benh: so as it is
airlied: agd5f: << ^^
airlied: alex wrote most of that logic
benh: it will not try to POST when the card hasn't been and -will- try to POST if the card hsa been but isn't displaying anything :-)
benh: I think alex stayed awake too late that night or something :-)
benh: agd5f: I need to understand exactly what other problem you were trying to work around
benh: agd5f: so I can do a fix that doesn't break somebody else
benh: but as I see things, we could easily consider that when radeon_read_bios fails, it's actually posted :-)
benh: or just ignore that totally as part of the posted test
benh: just use whatever method works to read the ROM
benh: and -then- use some register to decide whether it's POSTed
benh: ideally, clock control, but I can live with CRTC, I don't mind too much POSTing occasionally
benh: is there any known case of RMX being busted on M11 NV ?
benh: some ibooks are having the panel go off dsplay a cycle of black, white, red. blue ...
benh: when tyring to set any scaled mode
benh: airlied: what's the status with POSTing older cards ?
benh: airlied: worth even trying on my old radeon 7000 ? :-)
benh: Xorg -configure generates a config file that lacks the domain numbers btw
benh: another thing to fix
benh: locked up ... but it -did- display funky thing on the screen :-)
benh: oh and it also thinks the card is already posted
benh: I suppose I could help debug that some time. I have x86emu working fine to POST that one
benh: and I know my way around bringing those old chips up
benh: ops :-)
benh: yes, the kb is working :-)
agd5f: benh: I don't recall what was up with the logic, probably working around some brain-deadness of x86
agd5f: benh: kms has post support for pre-atom that should work. the code in the ddx should only need minor changes
airlied: benh: the old chip tables should work, they do in kms, might not all be ported back though.
agd5f: airlied, benh: http://www.botchco.com/alex/xorg/fix_post_logic.diff
benh: airlied: ok, I'm not going to bother with them in userspace then
benh: agd5f: let me see
benh: agd5f: first look, patch seems ok
benh: agd5f: second look too, now if we could also make radeon_card_posted() smarter ... :-)
agd5f: cool. committed
benh: agd5f: such as check if the PLL or xTAL source is initialized or memory controller
benh: agd5f: let me try it :-)
agd5f: we check the crtcs in most of the test code I've seen at AMD
agd5f: dinner, bbl
benh: agd5f: yeah but X leaves them off when you quit
benh: agd5f: so we re-POST all the time
benh: agd5f: btw, have another fix for some 32 vs. 64 bit issues too
agd5f: true. I suppose when you quit it will restore the unposted state if the card was unposted
benh: you should see the big 1650Pro in a x4 slot dangling off a x4->x16 converter :-)
benh: I need to use some high density foam to keep the card in place and not rip off the connector
benh: agd5f: bon appetit :-)
benh: airlied: btw, I need to start looking at kms too, can you give me pointers there to where things are ?
benh: airlied: and how to use it ? :-)
benh: airlied: you have some fbdev emulation to test it without X ?
airlied: benh: branch in my drm-2.6 kernel.org tree drm-rawhide
airlied: yeah it runs an fb
benh: airlied: cool, so it completely replaces radeonfb ?
airlied: its a bit messy getting a userspaec at the moment as the API diverged.
benh: airlied: ie, I can start porting over the PM code ?
airlied: benh: in theory if the card has a useful bios we don't need PM code :)
benh: ah ok, yeah, glisse & marcheu were complaining of DRM API changes, blaming Intel :-)
benh: airlied: that's the theory :-)
airlied: benh: not this is just modesetting ones.
benh: airlied: in practice, I need it on powermac
chithead: benh: note that amd also sells pcie x1 graphics cards, eg. firemv 2250
airlied: benh: yeah no idea if the mac bios has any tables.
benh: airlied: for non-x86 cards, ie, built-in OF based chips
benh: airlied: it doesn't
airlied: how does it post? OF manually?
benh: airlied: all hard wired in the Apple driver, which is why my code is useful
benh: OF POSTs at boot, then the Apple driver has hard wired code to re-POST afaik
benh: on in linux, radeonfb knows how to re-POST M10/M11
airlied: but how does OF know how to POST? hardcoded?
benh: it seems to
airlied: lovely, then we need to port the code, pity they don't have the tables.
benh: chithead: ah ? interesting... r5xx ?
benh: chithead: do you have a pointer ?
airlied: granted first I need to get atom posting my card in the kernel
airlied: it appear to be mostly sensible endianwise
benh: airlied: yeah but the code is nice & self contained, should be no big deal
benh: airlied: also the code is useful for machines that don't power down the chip
benh: airlied: as it knows how to do D2 properly on M6,M7 and M9
benh: airlied: it's used on some thinkpads
benh: airlied: in addition to macs
airlied: benh: pci_set_ doesn't work?
chithead: benh: http://ati.amd.com/products/firemvseries/FireMV2250PCIe.html firemv 2250 http://ati.amd.com/products/firemvseries/FireMV2400PCIe.html firemv 2400 both pcie x1, and I think r500 based (but not 100% sure)
benh: airlied: haha, if only :-)
benh: airlied: you need a lot of crap to "prepare" the chip for going into D2
airlied: it does on later chips I think...
benh: airlied: and then a lot of crap to recover it from the massive pain
airlied: if not I'll have to get agd5f to look it up.
benh: airlied: check with AMD but that's the code they gave me back then
benh: airlied: ie, that D2 code comes from ATI initially
benh: airlied: I also have some dynamic clocks stuff in there that we might need to sync with the kms one
airlied: once its going on a ppc with an x86 card it shouldn't be too hard to port over the other bits.
benh: I have exactly the setup we need to try it out easily right here on my desk :-)
benh: an embedded card that boots in seconds and is easy to reboot :-)
benh: with an X1650 in one slot and an rv200 in the other
airlied: I got an atom trace from my rv515 last night, I just forgot to post it on an x86 first.
airlied: to see where the traces differ
benh: I'll look at the code in case I can spot something
benh: I actually went all the way to -understanding- that bloody atom stuff to do the endian fixing last time :-)
benh: I might have some remains of that in my brain, though I was pretty happy to flush most of it out, it wasn't pretty knowledge
airlied: benh: mainly need to add the swapper support
airlied: (beyond fixing atom)
airlied: swapper + tiling will all be similiar code I think.
benh: allright, let me finish fixing stuff on that embedded box first
benh: since there's some customer going on here
benh: and then I'll use the setup to look at kmd
benh: and I can finally get rid of radeonfb :-)
benh: though your fbdev emulation has no accel hook right ?
benh: can it have some ?
benh: ie, solid fills, blit and color expansion is what is needed for fbdev ?
benh: because I just added colorexpansion to radeonfb, it speeds things up enormously on davem's sparc box
benh: he'll kill me if kms is a regression there :-)
airlied: benh: we need to fix things to add accel.
airlied: like fbdev
benh: we can have specific backends, it's just 3 hooks or so
benh: no big deal
airlied: so code upstream first, then fix fbdev.
benh: yeah, agreed
airlied: its not the hooks, fbdev sorta assume a pinned frontbuffer
airlied: I need to add prepare/finish access hooks to it.
airlied: and also unpin the fbdev front buffer when X is goiing
benh: but then, with accel, fbdev doesn't touch the buffer anyway
benh: and you have hooks .. sortof
benh: you can provide you own fb_read/write or something like that
benh: ie, you can prevent the fbdev core from touching your front buffer every
airlied: it just was a bit slow I think
benh: but yeah, we can do things more nicely with the right hooks
benh: then we can add the hook for bringing back the console on panic and killing all other clients :-)
airlied: davem should stick to mach64s :)
airlied: benh: we had that one
benh: so FINALLY we'll see oops !
airlied: that bit mostly works already on panic.
benh: he has a rv350 nowadays !
benh: ah cool
airlied: the kernel error paths are bit divergenet
benh: I might put back my hack to also pump up the backlight :-)
airlied: need to probably overhaul those after upstream as well.
airlied: jbarnes is looking at that stuff
chithead: mach64 is not really fun until someone pushes the mach64 drm code to the kernel
airlied: you think it'll be more fun with a drm :)
airlied: granted a mach64 modeseting driver wouldn't be totally crazy...
benh: yeha, atyfb sucks
benh: the X code works a lot better for all chips I've seen
airlied: granted I just have to make kms not hang on a few chips I have here.
airlied: probably should have enabled EXA by default a long time ago
airlied: running the 3D engine the whole time seems to bring out the stability monsters
benh: well, last I tried enabling even just 2D+CCE on the Bimini it would lockup
benh: that wasn't long ago
benh: (on the r5xx)
benh: after a while
benh: ie, a few minutes -> boom
airlied: benh: yeah its wierd, you probably should have shipped me one of those :)
benh: but then, that was before glisse came up with all sort of explanations about CCE lockups & alignment etc...
benh: haven't tried since then, did he push some fixes ?
benh: airlied: I probably still can but then, you can put the 1650 in your G5 no
airlied: benh: I still have reports of the drm fail on them.
benh: very similar chipset
airlied: benh: the problem is my G5 won't boot without a monitor plugged into the nv card
airlied: any ideas what incantation fixes that?
benh: appart from booting OS X and checking for possible FW updates ? no idea other than just removing the nv card :-)
benh: and booting blind
airlied: benh: yeah blind booting ftl until I can post the card :)
airlied: tries posting using latest userspace driver
benh: and I suppose you don't have 2 monitors ? :-)
benh: I always have a spare :-)
chithead: or use a kvm switch which emulates a monitor
airlied: benh: I have a big KVM remote switch
airlied: I even have remote power :)
airlied: dang G5 has forgotten auto poweron after poweroff, time to boot macosx
benh: so you should be able to have both cards in the G5 connected to 2 KMV things no ?
benh: airlied: heh, I reverse engineered how to do that in linux ! (the auto-poweron)
benh: airlied: there's a tool floating around somewhere ...
airlied: benh: yup I only have one USB KVM thingy though, the other is PS2 and it powers off a PS2 port :(
airlied: so I have to hook up another machine to power it :)
airlied: I can just plug a DVI monitor into the machine, but its nice to see the nv output for the oops :)
benh: I have a belkin DVI KVM at home, it's quite nice
airlied: this one is handy in that I have remove video to all the machines in my lab.
airlied: and remote power so I don't really have to go up there often.
airlied: benh: its even an IBM :)
benh: my "lab" is just an inset wardrobe turned into a study nook :-)
benh: at home that is, most machines are stored in the garage taking rust
benh: at work, my desk's still as messy as usual :-)
airlied: agd5f: ping, so TX_INVALTAGS shuold we be doing that before changing any TX regs
airlied: or just TXENABLE?
airlied: hmm moving TXINVALTAGS earlier didn't fix it.
airlied: damn rs690.
Kano: hi agd5f , airlied
Kano: when do you think you will release 6.9.1 or 7.x?
spstarr: hullo MAD
MostAwesomeDude: spstarr: Howdy.
MostAwesomeDude: Kano: Is there some stuff that needs to be released?
airlied: we should really do one soon.
airlied: I think Alex has been cleaning up some bugs first.
Kano: MostAwesomeDude: well lenny will be released soon and it still has 6.9.0 which does not fix my rv410
Kano: i had 2 of em,but one is dead now...
Kano: but the system is unstable as hell compared to my nvidia cards, does not matter if i use fglrx or ati
Kano: i get often locks when i can still move around the mouse cursor but no input possible from keyboard, nothing responding
Kano: accidently i saw this:
Kano: seems that somebody has similar problems
Kano: just with a mobility, i have got a x700 pro now
Kano: i guess using flash 10 and switching fullscreen<>windowed accellerates a lockup
Kano: system has VIA P4M890 + Pentium D 820
airlied: christ rs690 ... stop that locking up already.
airlied: agd5f: so NOPs on the rs690 any errata I want to know about, if not NOPs, anything on updating COLORPITCH or COLOROFFSET
agd5f: TX_INVALTAGS invalidates the texture cache so anytime you change the cache layout or or change textures
airlied: agd5f: so I've written a kernel ring and ib dumper for /proc for kms :)
benh: airlied: why /proc ?
benh: airlied: why not debugfs or sysfs ?
airlied: benh: we already have a load of support code for files in /porc
airlied: a lot easier to reuse it than write a whole new interface.
benh: still :-0
airlied: sysfs = no use.
airlied: debugfs = nobody has it mounted
airlied: so if I want users to ever report the results proc it is.
benh: why sysfs = no use tho ?
airlied: one value per file kinda sucks.
benh: but that's on paper :-)
airlied: when you want to dump 1MB of ring
benh: I mean ... if you're going to stick something in /proc you may as well do a big binary file in /sys
airlied: benh: well I'd have to write sysfs code then, I already have the dri proc code :)
benh: you got yourself a ticket for staging :-)
airlied: eventually I'll migrate them all to debugfs when distros start taking it sreious.
airlied: does sysfs have seq_file stuff now?
agd5f: airlied: I'll dig around for IGP, but IGP info is like hen's teeth
airlied: benh: I could hang it off the X proc info :)
airlied: agd5f: yeah I've seen a few different hangs now, one programming VAP, one on programming COLOROFFSET0 and one in interrupt emit :)
airlied: now I seem to be stuck in a wierd irq emit world.
benh: building the radeon driver on this 440 at 600Mhz with L2 cache not enabled with NFS root over a 100bT link requires ... patience :-)
benh: I need to remember the trick to make NFS fast again ... it got dead slow since recent kernels due to some new extra "coherency" stuff
agd5f: airlied: I still think we should use one IB per command sequence instead of using up the buffers completely and possibly splittign them in bad places
airlied: agd5f: yeah I just think the overhead would be extereme.
airlied: we do a lot ot operations, it would kill the CPU
airlied: I think maybe fixing EXA to pass us some more info might help (or pulling EXA into the driver :)
agd5f: I'm doing it for r6xx and it doesn't seem that bad
airlied: you don't have CS in the kernel yet.
airlied: or are you doing this on top of KMS?
agd5f: no, against the old drm
airlied: yeah the old drm doesn't do any validation
airlied: so the overhead is a lot less
agd5f: grab an IB in prepare(), fill it up, submit and discard in done()
airlied: building relocs and buffer validation takes up CPU
airlied: how full does it ever get?
airlied: most composite ops I see are prepare/op/done
agd5f: not very, but I use it for vertex buffers as well
agd5f: I could probably cram shaders in there too
airlied: the other option would be to prebuild the operation
airlied: and memcpy it into the IB in Done if there is space
airlied: that might work okay.
airlied: might give the best of both worlds
agd5f: easier to support MMIO as well if we care
airlied: yeah I think I'll support MMIO using shadowfb :)
airlied: like really, get a drm already.
airlied: yes it means we have to fix the drm/DDX to not crash but we should have done that from the start
airlied: agd5f: did you mention you thought using VBOs on r300/500 might be stabler than inline vertices?
agd5f: hw folks seemed to think so
MostAwesomeDude: So switching to a system which is both faster and cleaner might also be be stabler?
MostAwesomeDude: That's like, take three, pick three. :3
MostAwesomeDude: How would we do that for EXA, though?
agd5f: MostAwesomeDude: use part of the IB or grab another one
MostAwesomeDude: Wait, how are VBOs done, then? I think I missed something.
agd5f: put them somewhere in MC addressable memory
agd5f: tell teh CP to render using a vertex buffer
agd5f: instead of inline data
MostAwesomeDude: So EXA and Xv would continue to use IB and Mesa would use VBOs?
airlied: MostAwesomeDude: a VBO is just a buffer with vertex data in it
agd5f: MostAwesomeDude: you'd just accumulate primitives in a buffer and then submit it when you are ready to draw
airlied: MostAwesomeDude: an IB is just a buffer with commands in it.
airlied: MostAwesomeDude: currently IBs are just DMAable regions the GPU can access.
agd5f: so rather than issuing tons of draw commadns with one set of vertices, you build a buffers of vertices and idssue one draw command
airlied: with kms however IBs aren't actual DMA buffers so I'd have to copy them in the kernel
airlied: and relocate it
airlied: I suppose I could just allocate some GART object
airlied: contemplates doing it tomorrow in the hope of making things work stabler
MostAwesomeDude: Hm. Well, sounds cool, at leat.
MostAwesomeDude: *at least, even.