Radeon IRC Logs For 2008-5-19

MostAwesomeDude: We can’t put to the output fifo from a tex inst.
airlied: nope can’t do that.
MostAwesomeDude: But that’s not the problem on texrect.
airlied: yeah wierdly stopping that breaks texrect more wierd:)
spstarr: enjoys a long weekend
spstarr: airlied: are you in .au ?
spstarr: does the .au get today off?
airlied: spstarr: nope no off today..
MostAwesomeDude: spstarr: Wait, who gets the day off?
spstarr: :/
spstarr: It’s Victoria Day
MostAwesomeDude: Oh. So it is.
airlied: MostAwesomeDude: yeah the whole Output replacement needs redoing.
airlied: MostAwesomeDude: as if we have two output writes it’ll get busted.
airlied: but granted why texrect gets even more broken is wierd.
MostAwesomeDude: airlied: Yeah, we need to have emit_alu. I’m workin’ on it right now.
airlied: MostAwesomeDude: excellent, I’ll just hack about..
eboettcher: arg
MostAwesomeDude: eboettcher: ?
eboettcher: been reading TTM & GEM discussions which in some way are helping me
eboettcher: and in other ways are confusing me 😛
eboettcher: mostly the total lack of context with GEM is hurting me
eboettcher: there we go, found Keith’s announcement… if it ever resolves…
MostAwesomeDude: airlied: Initial emit_alu stuff is successful.
MostAwesomeDude: Right now, it’s just deciding whether or not it’s OUT or ALU.
MostAwesomeDude: But it cleans up texrect very much.
MostAwesomeDude: …And breaks mednafen, mplayer, and seccolor even more.
MostAwesomeDude: Interestink.
bridgman: spstarr: Victoria Day is a Canadian holiday; in the UK the holiday is in June, presumably
bridgman: because it takes longer to get “warm enough for a holiday” there
spstarr: heh
spstarr: its damin cold here
MostAwesomeDude: bridgman: Oh. No wonder we don’t have it here.
spstarr: Queen Victoria was the longest(?) reigning monarch though
spstarr: she was quite a powerful Queen
bridgman: spstarr: must have been; we celebrate Queen Elizabeth’s birthday (Apr 21) on Victoria’s b’day
spstarr: ah
bridgman: Australia also celebrates in June; apparently start of the official snow season 😉
bridgman: Dave, you also have Empire Day there on Victoria’s b’day (May 24), don’t you ?
bridgman: eboettcher: seems like 2 issues with GEM vs TTM :
MostAwesomeDude: airlied: Okay, this should improve texrect, yuvrect, yuvsquare, but badly breaks what little worked in mplayer/etc.
bridgman: 1. GEM doesn’t try to do so much, it’s just a memory manager
airlied: MostAwesomeDude: break away 🙂
airlied: no idea I have a holiday in June..
airlied: but thats all I know 🙂
MostAwesomeDude: airlied: It’s pushed. Check it out.
airlied: .au has lots of hols..
bridgman: 2. GEM adds pwrite/read and avoids need to map vram, presumably could be easily added to TTM
bridgman: airlied: a little bit of Germany in the southern hemisphere ? 😉
spstarr: when is TTM love coming to radeon? 🙂
airlied: bridgman: well I don’t get the 4 weeks hols in a row 🙁
spstarr: I keep hearing intel this and intel that 🙁
airlied: spstarr: when someone gets time.. and we’ve finished lots of other things.
spstarr: 🙂
airlied: MostAwesomeDude: you messed up the | ordering 🙂
airlied: MostAwesomeDude: emit_mov will overwrite emit_alu
airlied: actually ighnore me 🙂
airlied: it won’t 🙂
MostAwesomeDude: airlied: Not quite. I changed emit_mov.
MostAwesomeDude: XD.
airlied: hmm so I’m seeing lots of nothing now 🙂
MostAwesomeDude: emit_mov is just convenience for the few functions that use it.
MostAwesomeDude: airlied: On what? gears?
airlied: hehe.. you changed the last bit wrong I think 🙂
airlied: still getting inst0 & 0x3 == 0 instructions
MostAwesomeDude: Oh man, I did. Ooops….
MostAwesomeDude: :3
airlied: ^Index^file
airlied: ^Index^File
airlied: in emit_alu
airlied: ouch..
eboettcher: inded
eboettcher: indeed*
MostAwesomeDude: airlied: Death and destruction.
eboettcher: so we saw 😛
MostAwesomeDude: Or rather, refcounting locked my card hard.
airlied: MostAwesomeDude: did you see what I said?
airlied: MostAwesomeDude: emit_alu ^Index^file
airlied: MostAwesomeDude: emit_alu ^Index^File
MostAwesomeDude: …
MostAwesomeDude: airlied: We seem to have a problem.
eboettcher: and what problem is that?
MostAwesomeDude: Hardlocks.
MostAwesomeDude: The first one was after some modifications, but now they’re rather reliably constant.
MostAwesomeDude: And I think it’s ’cause I messed up on the last commit.
airlied: MostAwesomeDude: emit_alu ^Index^file
airlied: did you read that?
airlied: you keep disappearing before you fix it 🙂
MostAwesomeDude: XD
airlied: MostAwesomeDude: emit_alu ^Index^File
airlied: is actually the correct fix.. my typing is for crap.
MostAwesomeDude: Oh God. That’s a messup of epic proportions.
MostAwesomeDude: airlied: You think your typing is bad, look at what I do.
MostAwesomeDude: git log | grep -C5 -i corbin | grep -i oops
MostAwesomeDude: Or better, git log | grep -C5 -i corbin | grep -i fix
eboettcher: airlied: I was sure he caught it the second time around 😛
airlied: MostAwesomeDude: hehe..
MostAwesomeDude: eboettcher: No, I thought it had to do with changing when R500_INST_LAST was being put in.
airlied: MostAwesomeDude: can you look at the r300 cmp comment and see if we suffer from a similiar problem in r500?
MostAwesomeDude: Sure, one second.
eboettcher: so one of the targets I see for my gsoc work for this first half is improving error handling
eboettcher: from what I’ve been seeing it’s not there…
MostAwesomeDude: XD!
airlied: MostAwesomeDude: also I think dest handling for tex in the output case is busted.
eboettcher: my tired eyes are having trouble telling what are visited linked and what are not :/ I can’t find the bug that http://bugs.freedesktop.org/attachment.cgi?id=15628 is attached to!
airlied: we might be overwriting the wrong register
MostAwesomeDude: airlied: Wow. I didn’t even think about that.
MostAwesomeDude: I just assumed that the hardware would follow a ? b : c
MostAwesomeDude: Fixing now.
airlied: MostAwesomeDude: code review == good 😉
MostAwesomeDude: airlied: I have the arb_f_p sheet sitting on my desktop.
MostAwesomeDude: I can’t believe I misread that.
MostAwesomeDude: But what’s strange is how close it looks to the correct render on tri-cmp.
eboettcher: heh, funny, just got X to crash
MostAwesomeDude: eboettcher: I wish I had that problem.
eboettcher: MostAwesomeDude: which problem?
eboettcher: well the crash comes from dragging my xv using mplayer window to the edge of the screen
MostAwesomeDude: eboettcher: X crashing. My problems are usually card lockups.
airlied: MostAwesomeDude: found another mistake mine this time 🙂
airlied: MostAwesomeDude: << 14 for output mask should << 15 I think
MostAwesomeDude: airlied: You make mistakes?
MostAwesomeDude: Whoa, wait.
MostAwesomeDude: No way.
arekm: video cards should have rs232 onboard with debug console attached 😉 like on many storage raid controllers
MostAwesomeDude: airlied: That could explain nearly everything.
airlied: arekm: it would be nice if it could print out the fragment values 🙂
airlied: MostAwesomeDude: dream on 🙂
eboettcher: airlied: I hear nVidia has some powerful debugging stuff on the horizon…
eboettcher: (for shaders that is)
MostAwesomeDude: eboettcher: I also hear they have an onboard H264 decoder and cancer-curing rays.
MostAwesomeDude: But seriously, we would never know.
MostAwesomeDude: Not unless it’s easily accessible.
eboettcher: well can someone name an xv using app besides my favorite media player?
MostAwesomeDude: eboettcher: VLC, Snes9x
eboettcher: I want to make sure I can get it to crash with another app first.
airlied: MostAwesomeDude: you fix the << 14 one?
airlied: MostAwesomeDude: my tree is an unholy debugging mess.
eboettcher: hm… I have a backup of some of my cousin’s old roms, snes9x will work 😛
MostAwesomeDude: airlied: Oh, one second.
MostAwesomeDude: Got the CMP, though.
airlied: cool..
eboettcher: radeon_drv.so(RADEONCopyData+0xc8) <– apparently I need to look into why there is no checking of said paramaters here
MostAwesomeDude: airlied: Pushed. tri-depthwrite and tri-depthwrite2 work now.
MostAwesomeDude: Also yuvrect just rebroke?
rx__: typo of epic proportions
rx__: amusing
MostAwesomeDude: rx__: It was a fairly epic typo, I think.
eboettcher: O.O neither RADEONPutImage() nor RADEONCopyData() check that they’re actualy putting data in the screen area. I don’t know if I should add checks to both, only RADEONPutImage() [exported in XF86VideoAdaptorPtr], or only in RADEONCopyData() [only used by RADEONPutImage()]
MostAwesomeDude: eboettcher: No such thing as being too careful, but I would probably make the lower-level one check, unless it would require additional resources to do so.
eboettcher: MostAwesomeDude: just some numbers saying how much of the image is cut off from the screen 🙂
bridgman: guys, would the GPU Shader Analyzer be useful for generating some known good shader
bridgman: speaking of debugging…
airlied: bridgman: oh that sounds interesting, a tool we could feed the fp too and it would tell us what we did might be nice if it existed 🙂
eboettcher: beyond a memory manager, where else does radeon fall short of DRI2?
airlied: eboettcher: having a Mesa driver that runs on the memory manager 🙂
eboettcher: that’s quite a task 😛
airlied: and maybe a DDX that runs on a memory manager…
airlied: DRI2 is one of those things for a driver is easy if it has a memory manager..
airlied: and FBOs of some sort.
airlied: which is rely on a amemory manager.
airlied: ah well going home.. no idea why secondary color is so busted.
airlied: MostAwesomeDude: might bbl, but that was productive enough, I can see a texture in texrect even it looks lame 🙂
MostAwesomeDude: airlied: XD, me too.
MostAwesomeDude: bridgman: That would be sooo cool.
eboettcher: hrm…
eboettcher: it seems something is astray
eboettcher: I see radeon_crtc_clip_video()
eboettcher: and wonder why it isn’t used
MostAwesomeDude: XD
bridgman: MostAwesomeDude: what does XD stand for ?
eboettcher: or at least is failing to be used
eboettcher: bridgman: a smiley face
eboettcher: very happy/excited
bridgman: BTW I’ll try downloading the shader analyzer and see if it helps
bridgman: latest version is supposed to support arb_f_p directly so…
MostAwesomeDude: bridgman: It’s a smiley of a guy cracking up.
MostAwesomeDude: It’s meant to express me grinning, to the point of laughing out loud and waking up my roommates.
bridgman: I don’t see it… then again I have trouble with those 3d prints some days too 😉
bridgman: but I can remember it anyways 😉
MostAwesomeDude: Yeah, some people don’t see it. It’s a new-millenium smiley. All the rage with kids these days, I’m told.
eboettcher: fsck… bash completion + nfs server dying == ugly :/
MostAwesomeDude: eboettcher: Ctrl+C…
eboettcher: MostAwesomeDude: but then I lose that awesome one-liner spanning the entire screen!
MostAwesomeDude: True.
eboettcher: so on my laptop it behaves as expected
bridgman: is there a useful little arb_f_p program I could run through as a start ?
eboettcher: so a recent change caused this xv-dragging-past-the-edge issue
MostAwesomeDude: bridgman: It takes the dwords directly, as input?
bridgman: I think it takes the arb_fp ascii source as input and generates opcodes for specific GPU
MostAwesomeDude: Ah.
MostAwesomeDude: Okay, one second.
MostAwesomeDude: !!ARBfp1.0
MostAwesomeDude: MOV result.color, fragment.color;
MostAwesomeDude: END
MostAwesomeDude: Dumb, no-tex shader.
MostAwesomeDude: Should put out one inst, a CMP or MAD that moves from input to output.
bridgman: OK, just VPN’ing into work system. The analyzer is 23MB download, or about 3 years
bridgman: at dial-up speeds
MostAwesomeDude: Oh man.
bridgman: that’s OK, I have about a bazillion MB/s at work, so it balances
MostAwesomeDude: Yeah, that’s what Comcast tells me, too.
bridgman: Nuts, I need to upgrade DirectX on my work system; means a reboot then I have to
bridgman: be there to push the ^%$@#$ F1 key
bridgman: Guess I might as well download to my home system; it’s 3:40 AM anyways…
eboettcher: I’m so glad I can just change out my libGL right under the nose of my window manager…
bridgman: it doesn’t really take 3 years; probably about 3 hours
MostAwesomeDude: bridgman: I know the feeling. If my internet goes out after 5:00 PM, I’m not getting it back until 8:00 AM because comcast is lazy.
MostAwesomeDude: eboettcher: Yeah.
eboettcher: or at worst stop X to rmmod radeon, then modprobe the new one
eboettcher: (well that is until a hard lock)
MostAwesomeDude: eboettcher: Icky.
MostAwesomeDude: I do /etc/init.d/xdm stop; sleep 1; modprobe -r radeon; modprobe -r drm; modprobe radeon; sleep 1; /etc/init.d/xdm start
eboettcher: is there any bus level power management or anything of that sort that could be used to completely reset a hard locekd card?
MostAwesomeDude: My VTs get corrupted when X starts, so I can’t use them.
MostAwesomeDude: eboettcher: Yes, if you have a switch on your PSU.
bridgman: there are some pci-level tricks; glisse is trying them out
bridgman: we’re not sure they’re a good idea yet though, so…
eboettcher: somehow I’ve only killed this card twice in the past week…
eboettcher: but the machine has always stayed up and stable (AMD 790FX chipset)
eboettcher: I know the chipset facilitaties GPU<->GPU communication, but we have yet to see any crossfire docs whatsoever…
eboettcher: is anybody even experimenting with it?
bridgman: we don’t actually need much GPU/GPU through the chipset; we have dedicated connectors
bridgman: over the top of the cards
MostAwesomeDude: bridgman: Do say. :3
bridgman: SLI needs more chipset-specific stuff than Crossfire
eboettcher: bridgman: yes for 2x
MostAwesomeDude: bridgman: So it’s more like getting one GPU into master mode, or getting the other into slave mode?
eboettcher: but in a 4x CF setup there’s more going on 🙂
MostAwesomeDude: I mean, is it like SMP?
MostAwesomeDude: I really don’t know much about it other than that you can’t have SLI and CF on the same motherboard.
bridgman: master and slave are just determining who assembles video from the other cards
MostAwesomeDude: Ah.
eboettcher: I was excited when I got this board about it being shipped with two crossfire connectors. In the docs they make it clear what they want you to waste our coal and oil resources on….
bridgman: well boards are mostly made from sand and we got lots of that
eboettcher: bridgman: refering to the power used by four video cards…
bridgman: ah yes, you have to pedal really fast for a 4x rig 😉
eboettcher: OLPC has some sort of power source from cows that I can use.
bridgman: you need a big circular area so the cow can walk around; I was trying to come
bridgman: up with a similar arrangement at work using project managers
MostAwesomeDude: starts slow clap
bridgman: seriously, in principle crossfire and sli are both pretty simple; divide the work
bridgman: across cards and assemble the results into a single frame you can look at
eboettcher: 🙂
eboettcher: divide the work?
eboettcher: how do you propose doing that with immediate mode rendering?
bridgman: intercept the operations in the driver, decide where to send them; some go to both
bridgman: cards, some go to just one
bridgman: when game devs just drew triangles it was a lot easier; as you add lighting effects
eboettcher: I’m starting to strongly dislike the very linear view of graphics I have from the GL as I see multi-cpu and multi-gpu stuff get more popular.
bridgman: and post-render passes it gets a lot more exciting; fancy AA modes don’t help
bridgman: either
bridgman: eboettcher: true, but I’m constantly amazed how much you *can* do in GL
eboettcher: indeed
bridgman: and that it can be done without jumping through half the hoops I would have expected
bridgman: the cool thing about GPUs is that so far we have been able to hide all the parallelism
eboettcher: well I think GL can survive multi-gpu paradims.. it’s just a client may start to have more than one context….
bridgman: (both within a GPU and across GPUs) from the game developer
eboettcher: to fully take advantage that is
bridgman: It’s a tough call; you know what a tough time CPU vendors are having getting
bridgman: devs to take full advantage of even a few cores; the nice thing about graphics
MostAwesomeDude: Okay, so that didn’t work.
bridgman: is that you essentially have an interpreted language and enough time to stuff it in
bridgman: a big fifo so a sufficiently complex driver can look at a lot of work at once
bridgman: and figure out how best to handle it; handy for game devs but kinda hard on driver
bridgman: developers
bridgman: what didn’t work ?
MostAwesomeDude: bridgman: SGE. I’m learning how to do a pre-op.
MostAwesomeDude: But I forgot to increment the program counter, so I locked the card.
bridgman: the gpu shader analyzer might be useful there; it seems to have our
bridgman: shader compiler built in so is able to show exactly what we stuff into the
bridgman: shader cores
bridgman: and no we aren’t releasing the shader compiler
MostAwesomeDude: Awww.
bridgman: sorry
bridgman: 😉
MostAwesomeDude: Nah, no worries.
bridgman: You have to increment the program counter ?
MostAwesomeDude: bridgman: We process opcodes in a massive loop. Each time around, for each op that’s put into the compiled program, we increment the total number of instructions.
MostAwesomeDude: For example, SCS takes three ops, so we increment three times.
MostAwesomeDude: I just forgot to not put in an increment, so I ended up sending 6 dwords of 0x0 to the card.
MostAwesomeDude: And it (understandably) locked up.
bridgman: ahh, when writing the instruction. Got it
bridgman: OK, download should be finished in a couple of hours. Think I’ll toss some more
bridgman: wood on the fire and grab some sleep
bridgman: back later
MostAwesomeDude: Good plan.
airlied: hmm I wonder about the number of instructions we emit.
MostAwesomeDude: airlied: I’ve checked it; it seems solid.
MostAwesomeDude: I just had an extraneous counter++;
airlied: cool.. just trying to write a small decpde function 🙂
airlied: MostAwesomeDude: http://people.freedesktop.org/~airlied/r500_dumper.patch
airlied: somethingf I’ve bene playing with.
MostAwesomeDude: airlied: Rock!
MostAwesomeDude: Found a few bugs in the dumper, fixed ’em.
MostAwesomeDude: alpha ops use a different table, ops are 0xF bits big, not 0x7, etc.
airlied: MostAwesomeDude: oops.. feel free to check it in if you think its useful
MostAwesomeDude: airlied: Would love to. What’s an appropriate way to mask off debugging info?
airlied: MostAwesomeDude: one of the RADEON_DEBUG variables
MostAwesomeDude: ‘k.
tormod: hi, got glxgears working on my X700 (RV515) today! 3D HAHAHAHAHA!! 🙂 Thanks a lot.
tormod: oops, X1300 I mean
MostAwesomeDude: Sleeptime. Night.
gusta1: I just ran ‘compiz’ for fun, to see what happens with -ati and the r500 dri in the kernel. I get a couple of lines I really don’t like.
gusta1: The first one will probably be fixed one day: “unknown chip id 0x71c6, can’t guess.”. I wonder if this is a DRI issue or just me running a too old mesa.
gusta1: This line however gets me nervous: “Comparing resolution (3200×1200) to maximum 3D texture size (2048): Failed.”
airlied: gusta1: too old mesa.
prahal_: gusta1: 3200 is way beyond the max texture size supported bv the card
airlied: r500 has 4096 textures.
prahal_: oups sorry good to know
airlied: but we only fixed that recently in r500-support.
gusta1: ok, so 3200×1200 will work for 3D when -radeon has implemented all the necessary bits?
gusta1: (or when I upgrade mesa)
airlied: gusta1: most likely when the mesa driver works.
gusta1: cool
gusta1: how’s all the 3D-stuff working btw? I haven’t seen much news in git over the last weeks but I assume you guys are working on it?
airlied: gusta1: lots of work on it..
airlied: gusta1: read the channel logs 🙂 we are still missing working texturing, but it sorta works 😉
gusta1: awesome.. you get much help from the docs, or is it still lots of “trying to figure out what the card does”?
airlied: its all docs based.
airlied: we are just writing the fragment shader really as that is all that has changed in a major way.
gusta1: ok. well that sounds just great. you seem to be working fast
prahal_: airlied: long time ago you told me that bios post code was to be migrated to the kernel . Looked at radeon-gem-ms and nothing is showing up . Should I attempt to complete my attempt at porting this bios post code to radeonfb or are there other plans for it ?
tormod: gusta1: btw, which distro are you on?
gusta1: debian sid (amd64)
airlied: prahal_: its planned to go in with kernel modesetting
airlied: prahal_: like you could do it with radeonfb but it’ll be mostly wasted effort.
gusta1: when you people say “modesetting” you mean setting up proper resolution/frequencies etc for the monitor, right?
tormod: gusta1, if you’re interested I have deb source packages for latest mesa git (and libdrm) on https://launchpad.net/~xorg-edgers/+archive if you’re interested. They should build on sid, but I haven’t tested, and would be curious to know.
airlied: gusta1: I mean putting the graphics drivers into the kernel..
gusta1: what exactly is libdrm? is that the part that is now in the kernel? cause I run 2.6.25, so I already have that. but I could try the latest mesa.
tormod: gusta1: libdrm is the user library for talking with the kernel drm, I believe.
gusta1: ah ok
airlied: for r500 you’ll need to install a new dr and libdrm headers as r500 stuff isn’t release yet
gusta1: but mesa?
tormod: gusta1: maybe you can even install the amd64 mesa deb from my archive (it’s from the r500-support branch)
gusta1: I upgrade my -ati about once a week to latest git, so that’s probably fine…
gusta1: tormod: do I need the mesa-swx11 packages?
gusta1: ok, time for restart-x-test
gustaf1: hmm
gustaf1: $ glxgears
gustaf1: Warning, RV530 detected, 3D HAHAHAHAHA!!.
gustaf1: Error: couldn’t get an RGB, Double-buffered visual
airlied: ah you need a new server currently which is a pain and aiglx.
airlied: night… zzz.
gustaf1: compiz doesn’t complain that my PCI id isn’t recognized, so that’s a bonus.. but still too small texture size in your packages tormod
gustaf1: heh ok
gustaf1: i’ll wait for debian sid or experimental
tormod: gustaf1: sorry I was way, no, you need only -dri -glx -glu1 and -utils.
gustaf1: i’m running them now
gustaf1: took the amd64-packages directly.
tormod: gustaf1: great. I am using the 1.4.1~git20080131 server and that worked.
gustaf1: however, according to airled I need newer xserver to get glxgrears to work
gustaf1: i’m running “7.3+10”
gustaf1: uh never mind. i’m running 1.4.1~git20080517-1
tormod: I mean glxgears worked. AIGLX and compiz not.
gustaf1: my glxgears says “Error: couldn’t get an RGB, Double-buffered visual”
tormod: gustaf1: there’s 1.4.99 in debian experimental
gustaf1: yeah, i’ve been thinking of maybe trying it out, but it scares me for some reason..
gustaf1: 1.4.99 can’t be installed, since it will remove all xserver drivers (input, video etc)
tormod: gustaf1: that is scary 🙂
gustaf1: what is x11proto-dri2-dev for? there’s not binary package, just this -dev with headers.. do I need it?
tormod: gustaf1: no, it’s used for building. the archive builder needs it.
MrCooper: agd5f: if you’re going to drop the FGL_LINUX define, please also fix the problems that generate compile warnings when it’s not defined
agd5f: MrCooper: ok
MrCooper: thanks
agd5f: otaylor: the r300 “REPEAT_NONE unsupported for transformed xRGB source\n” fallback breaks rotation on r3xx/r4xx/r5xx. do you have any more info this? we we really need to fallback there? neither r1xx ir r2xx do
otaylor: agd5f: I don’t quite understand the question. (r1xx and r2xx I think are definitely broken for some cases)
agd5f: otaylor: I’m trying to get get rotation fast again
agd5f: I don’t follow the fallback
otaylor: agd5f: Do you understand the RENDER behavior for REPEAT_NONE?
agd5f: otaylor: no, where should I look?
otaylor: agd5f: It should be in the RENDER spec, but it’s pretty simple … it’s supposed to act as if the texture is infinitely extended with alpha=0 pixels
otaylor: agd5f: You can’t get that for r3xx=>r5xx because the border color register has the same format as the texture source
agd5f: ah
otaylor: agd5f: It’s theoretically possible with the r1xx/r2xx, since the border color register is fixed ARGB, but it doesn’t work well since r1xx/r2xx do a real crappy job with the border color .. they don’t interpolate to it smoothly
otaylor: agd5f: so techniques to get things working well I know of:
otaylor: – Do the bilinear filtering *in* the fragment program (unattractive without better tools for writing and managing fragment progrmas)
otaylor: – Copy the source to a temporary ARGB texture
otaylor: – Do the source transform in software to a temporary, and then composite in hardware, to avoid migration penalities
agd5f: does a lot of stuff rely on those semantics? I don’t notice any rendering issues with basic desktop usage. I suppose I could also special case the rotated blits for rotation
otaylor: agd5f: Well, hard to say what relies on them. I think it’ very dangerous to do RepeatNone as RepeatPad since it means people will encode dependencies on that into their programs, and get surprised on other hardware or when we fix stuff
otaylor: agd5f: RepeatPad is the more useful behavior than RepeatNone, but it’s *very* badly implemented in Xorg, and cairo never tries to use it at the moment
otaylor: agd5f: Where are you hitting a slowdown from this? (scaled images in firefox is certainly one place :-()
agd5f: otaylor: xrandr rotation
otaylor: agd5f: oh, that one should be easy to fix
otaylor: agd5f: if the transformation takes pixels to pixels exactly and there is no sampling outside the bounds, then you don’t have to worrry about border behavior
agd5f: yeah, it’s just rotated blits of damaged regions
otaylor: agd5f: I didn’t try to special case 90 degree rotations and flips in the server, but it’s not hard to do
agd5f: otaylor: besides xrandr rotation, do you have any simple tests for 90 degree rotations?
otaylor: agd5f: it’s generally very easy to create this kind of thing with pycairo, if you need one, I could certainly come up with one, or modify an existing test case
agd5f: otaylor: sure, that’s be great if you have time
otaylor: agd5f: actually, hmm, the slightly tricky thing about this is the way that exa works .., you first get the setup call, which doesn’t include any indication of the area, and then you get the actual composite calls…
otaylor: agd5f: so you have to clip rendering to the transformed bounds of the source area at some point for the pixel-exact case
agd5f: otaylor: hmm… might be easier, at least for the rotation case, to just check if the destination if the rotation shadow pixmap
otaylor: agd5f: ugh 🙂
agd5f: otaylor: in teh driver
agd5f: 🙂
BBishop: anyone care to take a look at https://bugzilla.redhat.com/show_bug.cgi?id=446398 ? 🙂
agd5f: although, that would preclude accelerating other cases
otaylor: agd5f: I think it’s 10-20 lines of code to do it right
otaylor: agd5f: You need a function that identifies pixel-exact transformations … that means Picture->transform is None or Picture->transform.xx/xy are are zero and xy/yx are +/- 0x10000 or vice versa and the translation components are integral
otaylor: agd5f: then for the source and the mask, you need to identify a clip rectangle that is the preimage of the source under the transform (since the transform takes dest pixels to source pixels)
otaylor: agd5f: in the case where the source (resp. mask) is RepeatNone and the transform is pixel exact
otaylor: agd5f: if this applies to both the source and the mask, then you need to take the intersection of the two rectangles
otaylor: agd5f: then in RadeonComposite,you need to intersect the dstX,dstY,width,height with that rectangle, and adjust srcX,srcY , maskX,maskY accordingly
otaylor: agd5f: Simplification here to avoid extra code paths and flags is to start off with an “infinite rectangle” that’s bigger than the possible rendering region and just intersect it down
otaylor: agd5f: I’ll see if I can spend a few minute coming up with test cases later today
agd5f: otaylor: ok. thanks. It’ll probably take a bit for me to digest all that 🙂
otaylor: agd5f: I’d look at creating a patch, but I’ve sworn off X hacking at least until after GUADEC ;-(
agd5f: otaylor: no worries, I need to learn this stuff better myself, I was just never very good at linear algebra
MostAwesomeDude: otaylor: We have MDH and MDV in hardware, so it’s possible to do both DX/DY stuff like in nv_f_p and also antialiasing.
otaylor: MostAwesomeDude: MDH? MDV?
MostAwesomeDude: bridgman was saying a couple days ago that fglrx does antialiasing in the frag prog since it’s broken on-chip.
MostAwesomeDude: otaylor: M() Difference Horiz/Vert, I think.
rzr: agd5f: hi, i paged you yesterday,
MostAwesomeDude: Operates on a quad of pixels, and gives differences in vertical or horizontal pixels.
rzr: agd5f: can i help on the tv issues regarding atidriver ?
MostAwesomeDude: rzr: Please do.
agd5f: rzr: sure
rzr: i dont have many time for that, but i’d like to do my best to learn at least
rzr: should i warm my debugger at first ?
agd5f: rzr: for tv-out it’s really an issue of the pixel pll and the tv pll
agd5f: the general idea is that the tv encoder is a accumulator or sorts and you basically want to match frame ends in both clocks
rzr: humm … did i say that i am more confortable w/ code than hardware ? 🙂
agd5f: rzr: it’s mostly magic 🙂
agd5f: what problems are you having and wht chip do you have?
rzr: https://bugs.freedesktop.org/show_bug.cgi?id=12007
rzr: igp 320 m
agd5f: rzr: ok. in your case, the issue is the ref clock. you need to figure out the proper pixel pll dividers to since the current code only works on 27 Mhz clocks
agd5f: and the IGP chips use 14 Mhz clocks
agd5f: rzr: also, are you pal or ntsc?
rzr: pal
rzr: secam actually
otaylor: MostAwesomeDude: Hmm, not sure that useful for fragment program bilinear filtering, offhand
MostAwesomeDude: otaylor: I don’t know. I have no idea how fglrx actually does it.
otaylor: MostAwesomeDude: are you srure also that bridgman was talking about filtering rather than antilaised primitives?
otaylor: MostAwesomeDude: filtering seems a little unlikely to me especially once you add in anisotropic filtering … you’d be increasing the number of texture references and texture program complexity hugely if you couldn’t do that with specialized hardware
MostAwesomeDude: otaylor: I was fiddling with GB_AA_CONFIG in order to avoid the fallback on ctx->Line.SmoothFlag and he remarked that he seemed to remember that it was broken on hardware.
MostAwesomeDude: I can only tell you for sure that GB_AA_CONFIG doesn’t work as expected on r5xx.
otaylor: MostAwesomeDude: Yeah, that’s someting different 🙂
MostAwesomeDude: otaylor: Am I massively missing something?
MostAwesomeDude: The docs suggest that all you have to do for antialiasing is write to that reg and then wait for current quads to clear before new quads will be processed.
bridgman: It was actually airlied who said fglrx did something different for smooth lines
bridgman: I do remember one of our devs mentioning a workaround but don’t know details,
bridgman: will ask tomorrow
MostAwesomeDude: I remember somebody saying something about FP being used.
bridgman: MAD: yeah, pretty sure it was airlied
glisse: MostAwesomeDude: for smooth line fp is used
bridgman: or glisse ;)\
glisse: MostAwesomeDude: iirc this isn’t the case for smooth polygon
glisse: smooth line specification are bit complexe
bridgman: yep. the workaround had something to do with transitioning between smooth line & poly
glisse: AA is for fullscreen antialiasing
MostAwesomeDude: Okay
MostAwesomeDude: So the fallback is correct, then.
bridgman: I remember seeing discussion somewhere that the fallback was too aggressive, ie it
bridgman: fell back to software even when just doing polygons (which don’t need the fallback)
glisse: bridgman: fallback impacted googleearth
bridgman: not sure if it is possible to discriminate between line & poly though, is it ?
MostAwesomeDude: bridgman: From what I understand in the code, no.
glisse: and a smooth or not line isn’t that much of a difference to most user
bridgman: yeah, that’s what the discussion was about — not sure if GE used lines or polys
glisse: line
glisse: well not anymore
bridgman: yeah, it’s too bad we can’t have an option to ignore smooth line 😉
otaylor: MostAwesomeDude: I think everything you are saying is coherent, it’s just somtehing different than what I was discussing with agd5f, which was how to do modified bilinear sampling from textures to meet the requirements of the RENDER specification
MostAwesomeDude: otaylor: Ah.
otaylor: (and you don’t actually even need to do modified sampling, you just need to multiply the sampled textures against a factor that goes to zero smoothly at the edges)
MostAwesomeDude: Pushed better OUT handling for texs. Also SGE and SLT, although they don’t work yet.
MostAwesomeDude: Gah, freakin’ SIN/COS not working.
agd5f: otaylor: http://www.botchco.com/alex/xorg/radeon_pixelexactxform.diff
agd5f: I don’t follow the clipping stuff exactly though
otaylor: agd5f: hmm. stylistically I don’t like having the ->repeat and ->format in that same function, because it makes it unclear what it is doing, and maybe it would eventually be uesd for other things as well.
otaylor: agd5f: The matrix stuff mostly looks looks right to me, but you also need to check the translation elements
otaylor: agd5f: I’m not sure offhand if that’s [2][0] [2][1] or [0][2] [1][2]
otaylor: agd5f: (I detest multidimensional arrays in C, and it also depends on conventions)
otaylor: (looking at pixman very briefly I think it’s [2][0] and [2][1])
otaylor: agd5f: So, you need to check that they are integral – so transform->matrix[2][0] & 0xffff == 0 same for [2][1]
agd5f: otaylor: that jives with what I’e seen in the transform dumps
otaylor: So, on the clipping:
otaylor: Even if we have a pixel exact transform, there may still be pixels in the output that correspond to source or mask pixels that are outside of the source or mask
otaylor: agd5f: but for many (not all) operators, if a pixel is outside the mask or outside the source, then we don’t need to render it
agd5f: otaylor: Ah, I think I see what you are getting at. you may have non-overlapping areas after the xform
otaylor: (oh, ugh, the way I’m describing this it’s not going to fix your xrandr case because it probably uses SOURCE, but let me continue…)
otaylor: agd5f: yeah, e.g., the source is at +10+10x20x20, but we are rendering the region from +0+0x50x50
otaylor: agd5f: if we know that the operator is “bounded” by the source and mask – then we can simply render the affected pixels and ignore the rest
otaylor: agd5f: The most common operator “over” – is bounded inthat way .. .if a pixel is outside the source or outside the mask, it won’t render, so we only need to render the region from +10+10x20x20
agd5f: shouldn’t the server take care of that for us?
agd5f: I guess not
otaylor: agd5f: You could definitely argue that a lot of this should be at a higher level … though it might be hard to do without exa echanges
agd5f: yeah
otaylor: agd5f: So, what I was talking about about inverse transforms and preimages:
otaylor: agd5f: source->transform is the transform that we need to use to find the source coordinates when given a destination coordinate
agd5f: ok
otaylor: agd5f: So to find the rectangles we need to clip to, we actually need to use the inverse of that matrix
otaylor: (yikes, pixman doesn’t seem to have that operation… well, inverting an affine is a pretty well documented thing and not hard :-()
otaylor: agd5f: That could fail if the matrix is “singular” …; in which case, I’d recommend just falling back, it’s not a normal case
otaylor: agd5f: once you have the inverse, you transform the corner points of the source or mask through it and that gives you a rectangle in destination space
otaylor: that’s all in the setup phase … =then you get to RadeonComposite() .. and there you have xSrc,ySrc,xMask,yMask,xDst,yDst,width,height
agd5f: otaylor: ok
otaylor: agd5f: and you have 0, 1 or 2 clip rectangles from the source and the mask
otaylor: Now, the somewhat confusing thing here are the xSrc,ySrc,xMask,yMask
otaylor: how they relate the the transform … the trnasform, as you recall gives a way of going from a point in destination space to a point in the source space
agd5f: yup. got that
otaylor: how xSrc,ySrc play in is that they are actually locations in destiination space
otaylor: Let me make that concrete with an example … say that our source transform is {2,0,0,2,0,0} … we scale all coordinates by two
agd5f: otaylor: ok
otaylor: say that xDst=yDst=20, xSrc=ySrc=10, then to find the source coordinates for the point 25,25 we subtract out xSrc,ySrc and get 15,15 … then multiple by two – so we sample at 30,30
otaylor: xSrc,ySrc are in other words the point in destination space that corresponds to the upper left corner of the source texture
otaylor: when we compute our preimage clip rectangle (through the inverse transform) we assumed that was at 0,0
otaylor: So, to clip the xDst,Dst,width,height against our clip rectnagle ,we need to first subtract off xSrc, ySrc, intersect with the source clip rectnagle, then add xSrc, ySrc back
otaylor: And then repeat the same for the mask clip rectangle
otaylor: I dont’ know if rectangle intersection is anywhere in the server (other than regions) … as per usual, it’s usual easiest to convert from rectangle form to ‘box” form … x1,x2,y1,y2 and do the intersection that way, then convert back
agd5f: otaylor: right
otaylor: I think that’s a complete (if perhaps not 100% clear 🙂 description of the clipping process. The other question is that of “bounded” operators and what to do about non-bounded operators
otaylor: Simple examples: Over (normal compositing) is bounded .. because if a pixel is outside the source and outside the mask the result doesn’t change the destination
otaylor: Source (probably what is being used for xrandr) is not bounded … if a pixel is outside the source and outside the mask, then the result pixel ends up as 0
otaylor: There are a lot of render operators, some bounded, some not bounded. You can go through the math in the render spec and figure out which is which, but if you get in,add,over (bounded) source,clear (not bounded) you’d cover 99.9% of all cases
agd5f: otaylor: cool. I’ll see what I can come up with. thanks for your help
otaylor: the xrandr case is interesting … because when the destination surface *doesn’t* have alpha, then all the pixels outside the source end up as black
otaylor: if the operator the source … so, in that case … we can actually just go back and use the border color instead of clipping
agd5f: otaylor: yeah, it’s using src
otaylor: and that should apply whether or not you are pixel exact … at least on r3xx+, etc. On r1xx,r2xx border colors should only ever be used in pixel exact cases from my testing
otaylor: agd5f: So, actually, your particular thing you were trying to fix probably had an easy fix … if the operator is source and the destination doesn’t have alpha, then you can just skip the fallback
otaylor: agd5f: http://fishsoup.net/tmp/rotate-image-90.py (http://fishsoup.net/tmp/rotate-image-90.png for the expected result) is a simple test case in pycairo
airlied: uggh clean reboot, gears hangs machine.
airlied: agd5f: (or bridgman if in logs), can you clarify section 9.2.2 for me?
airlied: does the R500 have a baseline RS_COUNT?
airlied: I’m not sure what it means by having a baseline value of 1..
airlied: I think fglrx seems to set it to only 1 color for secondary color.
timofonic: Hello
timofonic: I’m not sure if this is the correct channel about radeonfb, is it?
airlied: timofonic: there is no radeonfb channel really ..
timofonic: airlied, 🙁
timofonic: I compiled it into the kernel and put the right parameters to grub.conf but not works. People says the config is right…
timofonic: airlied, and a fbdev channel?
airlied: timofonic: what card?
airlied: timofonic: don’t think there is an fbdev channel
timofonic: airlied, Radeon X700
timofonic: airlied, sadly it seems fbdev is underworked 🙁
airlied: timofonic: yes kernel modesetting will replace it on some cards like radeon when we get to it.
timofonic: And directfb is going closed-source at least for some time…
timofonic: airlied, so kernel modesetting does more than changing the resolution?
airlied: directfb isn’t closed source and has no drivers in it,, it justs uses the kernel oens.
airlied: timofonic: it’ll set the resolution mainly..
timofonic: airlied, in the directfb.org site says that certain code parts remain closed-source
timofonic: re
timofonic: airlied, not runs even eliminating all extra arguments and only putting video=radeonfb. This is weird 😛
airlied: timofonic: it might not have pciids for that card
timofonic: airlied, about radeonfb or xorg? xorg 7.3 detects it, Radeon X700 (RV410)
airlied: radeonfb..
timofonic: airlied, oops
timofonic: I’m using my old xorg 7.2 config under a nivel install, looks like trying to boot but finally my vga screen goes like no video signal so I neet to push ctrl+alt+backspc. Here is my xorg.conf http://rafb.net/p/h24kD175.html and here is Xorg.0.log http://rafb.net/p/dE1W9U12.html
timofonic: This is xorg 7.3
timofonic: airlied, how to know if it’s missing from the pciids?
airlied: timofonic: look at the pciid for your card and look at the radeonfb source.
airlied: I suspect nobody adds suppoer to it anymore.
timofonic: airlied, what command to use for that?
airlied: timofonic: lspci look for the slot, then lspci -n and find the corresponding numberic idds
timofonic: airlied, weird as it seems identified two times http://rafb.net/p/gRMQX234.html
airlied: yeah thats standard.. 0x5e4d is the one you want to find in the radeonfb sources
timofonic: airlied, where it can be? I can’t locate it in /usr/src/linux/drivers/video/
timofonic: I see.. /usr/src/linux/drivers/video/aty/radeonfb.h
timofonic: airlied, you are right /usr/src/linux/drivers/video/aty/ati_ids.h not has the id 🙁
timofonic: airlied, there’s patches out there but never went into main tree 🙁
timofonic: airlied, http://lwn.net/Articles/215965
timofonic: airlied, what to do?
airlied: timofonic: hand patch or give up and wait for modesetting to work 🙂
timofonic: airlied, will modesetting add missing stuff from fb like IDs and such too? When it will get released?
airlied: timofonic: not for a while.. you could just vesafb for now.
timofonic: airlied, ok thanks
timofonic: airlied, it seems like fbdev needs a change and a more active development team 🙁
airlied: timofonic: well fbdev isn’t really used outside of non-x86 arches and embedded people.
airlied: and everyone knows kernel modesetting will replace the radeonfb driver
timofonic: airlied, but how a “kernel modesetting” can replace a framebuffer driver? Because it’s modesetting plus a new radeon fb driver? 😛
timofonic: airlied, sorry a lot if I’m annoying. I STFU now 😛
airlied: timofonic: we have an fb driver that sits on top of the kernel modesetting work.
airlied: agd5f: still missing some init somewhere..

Radeon IRC Logs For 2008-5-19

Rig Lab Hardware

You Might Also Like

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

RadeonHD.org | Radeon IRC Logs For 2008-3-02

RadeonHD.org | Radeon IRC Logs For 2008-3-17