Radeon IRC Logs For 2008-10-24

s0nix: Hi
s0nix: is someone could help me a little bit with a dual-head setup using radeon driver ?
s0nix: i get just one problem.
glisse: s0nix: ask
s0nix: we’re not able to configure dual-head….. we always get clone
s0nix: we tried mergefb, xinerama.
s0nix: laptop + lcd monitor.
s0nix: the card is a ati 9200.
glisse: s0nix: you want 2 different desktop ?
glisse: i think this is not possible yet with randr
s0nix: dual-screen in fact. not 2 desktop
glisse: as i own only one screen i have never been a user of this kind of feature, even though if i do the code for it 😀
glisse: ie a big desktop spanned accross 2 screen ?
glisse: if so then try virtual in xorg.conf
glisse: man xorg.conf
glisse: to see how to do that
glisse: then you should be able to do what you want
s0nix: here’s the tuto i followed: https://help.ubuntu.com/community/BinaryDriverHowto/ATI
glisse: see http://intellinuxgraphics.org/dualhead.html
s0nix: try virtual in xorg.conf ?
agd5f: s0nix: http://wiki.debian.org/XStrikeForce/HowToRandR12
glisse: s0nix: don’t know if closed source driver work with this
glisse: open source here 🙂
s0nix: radeon is the OS no ?
glisse: s0nix: yup but the link you just gave is about closed source driver
s0nix: ha
s0nix: so….. it detect only one screen.
s0nix: but… it told me that the max is … 2340x…
s0nix: and i want my laptop resolution to 1280×800 and my lcd to 1440×900
glisse: s0nix: you can make one desktop above the others
glisse: but we don’t infrastructure to go above hw limit yet
glisse: and you hw limit is likely 2048 or somethings like
s0nix: WOW, this work.
adamk: Well certainly that’s only true for 3D acceleration, right? For 2D, the limit should be much higher than 2048, right?
s0nix: thanks you very much guys. all work with xrand.
glisse: adamk: yup for 2d only it should be up to 4096 iirc
MrCooper: 8192
glisse: but as exa is using 3d i don’t remember if we have code to disable this in that case
MrCooper: the EXA code supports up to the respective limit depending on the operation
s0nix: last question ;), i want to put my second screen in 1280×800, but it always use 1024x.. what this means ?
s0nix: i tried to do a xrandr –addmode VGA-0 1280×800 .. i see this mode in the `xrandr` output VGA-0 list but… not working.
jcristau: s0nix: –addmode just adds it to the list. xrandr –output VGA-0 –mode 1280×800 actually changes it
s0nix: yes, i always retyped this command.
logari81: s0nix: can you try do a VT switch after you set the resolution and see if it changes?
logari81: s0nix: I have this bug and try to find someone else with the same bug to verify it
logari81: s0nix: with VT switch I mean Alt+Ctrl+F1 and then Alt+Ctrl+F7 again
s0nix: a VT switch ?
s0nix: ha
s0nix: just did it. nothing more.
logari81: s0nix: ok thnx, I thing I am the only person on the planet with this bug, anyway I have a different card as yours
s0nix: emm
s0nix: anyone else has always got this problem ?
s0nix: ok i got it. my height was too small in the virtual setting. thanks.
AbuYusuf: i need help, Any one there ?
mattmatteh: AbuYusuf, this isnt paid tech support
mattmatteh: AbuYusuf, if you have a question then ask.
AndrewR: agdf5, in case you still worry about textured xv and xdtv on rv280: it was application bug, i comment out one line in xdtvrc (# blackborder = 100) and now it works fine ….
sebos69: Hi!
MostAwesomeDude: Hi.
sebos69: I have a new laptop with a Radeon card. lplci says:
sebos69: VGA compatible controller: ATI Technologies Inc Device 95c2
AndrewR: http://pastebin.ca/1236058 (testing radeon-modesetting, xv-related error + mics info, rv280/AGP)
AndrewR: MostAwesomeDude, hello!
MostAwesomeDude: AndrewR: Afternoon.
sebos69: why the name of the chipset is not displayed?
MostAwesomeDude: sebos69: Dunno.
MostAwesomeDude: But it’s a Mobility HD 3430 (RV620).
MostAwesomeDude: In case you were wondering. :3
sebos69: OK, that what I was wondering. Thanks!
protocols: is anybody experiencing problems with randr + dual-head config and disordered gnome windows?
AndrewR: about newest cards (r6xx … ) i don’t have any of them, but can i speed up development with something like mmio-tracing? (preparing kernel 2.6.27.3 for this purpose)
MostAwesomeDude: AndrewR: None of us are doing any RE. r6xx DRI has been started, and won’t be released until the docs are public.
AndrewR: MostAwesomeDude, but i don’t know how long everyone must wait before docs will be ready for opening/publication .. sorry for impatience
yangman: bridgman has already said code may release before the docs if they’re cleared. these things are impossible to schedule. it’ll happen when it happens
libv: yangman: does he still say that?
yangman: hm… actually, don’t quote me on that. still trying to find the source
yangman: maybe I’m just imagining things. it’s been a long day
libv: well, i think the line has changed already, not sure what the current line is though
bridgman: really misses cbrill’s logs with the nice timestamps so I could see if a question was asked 5 minutes or 12 hous ago
MostAwesomeDude: bridgman: Howdy.
bridgman: re: 6xx/7xx, plan is still to release code before docs; I think we will get through the IP review and have some initial working drivers at about the same time, which is pretty much ideal from a “get stuff into users hands quickly” POV even if it sucks from a “let people see progress” POV 😉
bridgman: ‘Dude: Hi
bridgman: I lost track of the “fog wars” – seemed like you were winning for a few hours ?
bridgman: or was that another will ‘o the wisp ?
MostAwesomeDude: Well, I figured out that just putting the fog as-is in the vertex memory seems to workish.
MostAwesomeDude: But it doesn’t get routed for fragment programs.
bridgman: There are a couple of things where I’m thinking we need to go find out what the closed drivers do; fog was one, I guess occlusion queries were the other
MostAwesomeDude: I’ve decided henceforth to just wait until fglrx supports X 1.5, at which point I will revenge each and every single fog case and get it once and for all.
bridgman: they both seem to involve doing unusual things to the chip
bridgman: I thought fglrx was at 2.something already (except for Kano’s 2 point sprite tests)
MostAwesomeDude: Occlusion queries look pretty straightforward, now that I’ve perused the docs. The only tricky part is getting some info from kernelspace.
bridgman: our closed drivers have a drm-like component (central memory manager & queue server) which probably has the same challenges – how do you read back something from an essentially write-only DMA path ?
bridgman: … but I’m pretty sure we are doing occlusion queries for both DX and OpenGL
MostAwesomeDude: Well, as I understand, we use GEM to allocate a page of VRAM, then map it back to kernelspace and use that as the target for occlusion query results.
MostAwesomeDude: So we have to ask the kernel for each query result. Not optimal, but not surprising, either.
RTFM_FTW: yep we do occlusion query
bridgman: I haven’t really gotten my head around how big the results should be – for some reason I keep thinking there should be gigawatts of result
RTFM_FTW: and its a total PITA 😀
MostAwesomeDude: At least we’ve got HW support. Intel needs to count the samples by hand. :3
bridgman: Oh good, at least it’s consistent
MostAwesomeDude: Well, we get one result per pixel pipe. Add those together and we should be set.
bridgman: ewww
MostAwesomeDude: If we really wanted to be fancy, we could disable all but one pipe, put the query down that single pipe, then restart rendering as usual. Distribute queries across pipes, and we could theoretically run multiple queries safely at once.
bridgman: starts shivering…
RTFM_FTW: hahah
MostAwesomeDude: But of course right now the important thing is to get it working, period.
bridgman: all I know is that in my copy of the unofficial 6xx acceleration documentation (go Alex !) the occlusion query stuff is highlighted and flagged with a “need to understand this $%#&^” comment
MostAwesomeDude: XD
bridgman: we don’t call it occlusion query, it has some kind of nondescript name – I had to ask Alex and Richard what the heck this was used for and whether we even needed to document it
bridgman: But we need it for some 1.x level of GL compatibility, right ?
MostAwesomeDude: OGL 1.5, yes.
MostAwesomeDude: And it’s called zpass in r5xx docs.
bridgman: Ah yes. I remember doing a Google search for occlusion query and running into a wonderful term… “triangle soup”. Seemed like something that should either end up in a sig line or a patent application one day
bridgman: I keep thinking there should be a less painful way to do this but it hasn’t occurred to me yet
spstarr: hello bridgman 🙂
spstarr: bridgman: we should setup a lunch meet up
spstarr: be fun
bridgman: agreed. Give me a week until I stop coughing up lung parts; right now I am only spending time with people I don’t like
spstarr: some bug is running around?
spstarr: remains vigilant on the bug watch, touch no door handles when possible
spstarr: ban people from touching my keyboard /mouse
rbrett: bridgman: I know the docs are in constant legal review, but standing on the outside looking in, it seems like the process is more about trial and error. In other words, do you guys know what parts you need to omit before submission to legal review?
bridgman: It
bridgman: whoops
bridgman: it’s not legal review, it’s technical review through our top technical folks, against a set if issues & concerns defined by legal
bridgman: there is a certain amount of trial and error, sort of goes like :
bridgman: – here’s the stuff we want to release
bridgman: – here’s why we don’t think it’s a problem for digital rights management
bridgman: – here’s why we don’t think it’s a problem for security of future OSes
bridgman: questions come in – what about X, what about Y ?
bridgman: – if we can come up with answers for all the questions we go ahead and release
RTFM_FTW: yep these things take time
bridgman: – if not we go off, adjust what we plan to release, try to come up with ways to protect.. um.. Z, then go back and try again
bridgman: so far so good
bridgman: answers for all questions raised so far
bridgman: when nobody has any more questions we wait a couple of days for new issues to come up then release
bridgman: I wish it were more scientific but this is the best we have come up with so far
bridgman: the guiding principle is “don’t f*** up and wind up with a $100M lawsuit”
bridgman: translating that into specific registers is hard 😉
bridgman: the challenge is to come up with a set of IP to release (enough to make a good, working driver) without straying too far into territory which could get us in big trouble
bridgman: little trouble is OK
rbrett: I see, though are we drawing to close? do you problems and not yet solutions to X and Y for example. Is there hope of the docs coming out before 2009 😛
bridgman: but we have to consider things like “if we document this, that moves the starting point for reverse engineering, given the abilities and available resources what is the likelihood of RE’ing getting to a point that hurts us badly ?”.
bridgman: I think we are pretty close, >90% chance of getting out in 2008
bridgman: each time there is less area where something could blow up
bridgman: if it were just getting past lawyers that would be easy 😉
RTFM_FTW: heh
rbrett: I can understand the complexities, and I’m not really impatient, it’s more lack of “seen progress” as opposed to actual progress
bridgman: Agreed. One of the nice things about 5xx was that some parts of the chip were identical to previous generations so all kinds of good things could happen in parallel with the last IP bits. With the 6xx it’s one engine that does everything. The difference is that development is happening in parallel with IP review to a much greater extent than with 5xx…
bridgman: and it’s a big honkin’ virtualized engine that is damn near impossible to debug when it locks up… but once we get it working… look out 😉
bridgman: … and we got it working 😉
rbrett: nice
RTFM_FTW: mmm the 2D engine will be missed 😀
bridgman: yeah, everyone (ie not just ATI) is struggling a bit with getting decent 2D performance out of 3d-only hardware. Good news is that it seems to be easier on Linux than on at least one of those other OSes
rbrett: Can we expect r6xx and r7xx docs at the same time, seeing how they are similar? or do you think you’ll produce a differences document?
bridgman: I think we will release code before docs, and the code will work on both 6xx and 7xx
bridgman: we had actually planned to do more code than docs for all of 3D – Alex just came up with a real nice 5xx doc and figured it would help with 3xx and 4xx as well, so…
bridgman: for 6xx and 7xx we`re kinda going back to the original plan
RTFM_FTW: the R5xx documentation was pretty good IMHO
rbrett: And sorry for all the questions but will the r6/7xx docs make releasing future docs r8/9xx easier because they may share IP?
bridgman: Yes, definitely. The big jump going to 6xx was virtualizing the hardware, so we can redesign the logic completely underneath without changing the programming model much. Makes debugging without a $25M emulator a big pain in the butt but should make future driver development much easier. It has worked out well so far.
bridgman: with 7xx
bridgman: the problem with defining a new programming model for the next N years is that you need to be really careful about what you publish, `cause some of it is there for the future and you don`t want it getting out too soon
bridgman: since there is this whole competitive thing going on, y`know 😉
rbrett: Indeed, well thank you very much your answers, I appreciate the work you guys are doing, here’s hoping tech review is satisfied next time 😛
AndrewR: bridgman, thanks, now it more clear [for me] why we still must wait a bit more ..
bridgman: I`m keeping my fingers crossed. Makes it hard to type 😉
MostAwesomeDude: Wow, quite the log I missed. :3
bridgman: nothing you don`t already know 😉
spstarr: bridgman: but people will reverse engineer it anyway 🙂
bridgman: that`s one of the hardest parts… we need to figure out how far reverse engineering is likely to go (skills, available time, interest, tools etc..) and keep what we release sufficiently far back that nobody is likely to reverse engineer us into trouble. Fortunately most of the folks who have the skills to do reverse engineering have little real interest in the things that would get us in trouble so it works out pretty well…
mattmatteh: bridgman, sorry for an off topic question, are you familar with ahci on sb750 ?
bridgman: isn`t sure, plugs ahci into google…
bridgman: hard disks, isn`t it �
libv: usb
mattmatteh: i meant the sata
libv: uhci, ehci were the usb 1 competing standards, ahci is the single one for usb 2
bridgman: Geez, are you up early or up late �
libv: or i am messing the three together.
bridgman: it seems like `advanced sata“
mattmatteh: i have read that sata performance was terrible on sb750
orkid: ohci ?
bridgman: my keyboard is seriously messed up
mattmatteh: wasnt sure if you knew anything about that
libv: ah, no, it’s uhci, ohci and ehci being the usb2.0 one
bridgman: sounds right… ahci seems like a protocol spec for doing fancy stuff over sata
bridgman: so, no, I don`t know squat about it 😉
mattmatteh: native command queuing
mattmatteh: oh
bridgman: the southbridge folks went over to the cpu side
bridgman: and we don`t talk to them much these days
bridgman: although they still sit in the same desks… sad really 😉
mattmatteh: i have been researching for new computer.
bridgman: I can probably wander over and ask, so if you have questions I can understand go ahead
mattmatteh: was interested in a board with sb750 till i read that hard disk access was really slow
bridgman: on all OSes or just Linux �
bridgman: where you see � assume I typed a question mark
mattmatteh: bridgman, well, it seems that its all. but that is kinda my question
mattmatteh: ohh, ok
mattmatteh: i was wondering about that funky letter
spstarr: hmm
mattmatteh: bridgman, i have read several benchmarks of amd boards where sata speed is not up to par
mattmatteh: bridgman, if that is the case, it means i would have to get a sata pci card, which increases the total cost and power consumption, or get a board with nvidia
mattmatteh: right now i am researching the nvidia option so i dont need a separate card for the hard drive
orkid: go with intel 🙂
bridgman: there`s a good chance the answer will be `yeah if drives were infinitely fast those benchmarks would matter but with real world drives and real world usage it doesn`t make any difference` then I won`t know what to say 😉
spstarr: bridgman: what about tv tuner support?
spstarr: bridgman: I’d love to use my 9800 for TV *in*
spstarr: 🙂
bridgman: the tuner IP is not ours but I am (in the rare moments of free time) trying to dig up contact info and available tuner docs from the tuner vendors
mattmatteh: bridgman, http://techreport.com/articles.x/15256/9
bridgman: you need tuner IP and capture (rage theater-type stuff) info. Capture is a bit tricky because there is a bunch of drm-related input detection stuff we have to protect… macrovision, future broadcast flag etc…
mattmatteh: bridgman, if someone else is there with you that would be familiar with sb750, perhaps you can ask why hard disk speed is crappy
bridgman: biggest problem is that what everyone ends up doing is asking about TV tuners then saying they don`t care about that stuff and what they really want is open cable… and we can`t go there
spstarr: bridgman: i have some specs from chips available
bridgman: mattmatteh; they`re not actually at my house 😉
bridgman: but will ask next week
mattmatteh: bridgman, oh, i thought you were at work
mattmatteh: sorry
bridgman: nah, 11pm on a Friday night is too late for me. On a Tuesday night, possibly…
mattmatteh: bridgman, not sure where you are or what timezone
mattmatteh: oh
bridgman: understood; 60 km northeast of Toronto, snow on the ground, gets dark real early, Eastern timezone
mattmatteh: ohhh
mattmatteh: far but not too far from me
mattmatteh: i am near chicago
bridgman: nice place
bridgman: more fun than Toronto
RTFM_FTW: heh
mattmatteh: bridgman, do you know much about xv support ?
MostAwesomeDude: bridgman: Well, the things that are going to be RE’d are already known, really. Tex filter bits, same as the other Radeon drivers.
mattmatteh: with 6xx or 7xx
MostAwesomeDude: UVD might be reversed at some point, but really, it’s not a priority.
mattmatteh: is xv part of uvd
bridgman: mattmatteh: Alex thinks he has all the programming sequences worked out except for colour space conversion, and one of our other devs (Richard) wrote the first video processing routines for R300 so he`s going to handle that part
spstarr: bridgman: so but hasn’t macrovision been broken anyway? 🙂
bridgman: on previous GPUs the texture engine could do YUV to RGB conversion in hardware, but starting with 6xx we need to do that in shaders
spstarr: bridgman: the 7500 AIW had macrovision?
mattmatteh: bridgman, that is the older gpu’s ?
bridgman: whether something has been broken or not doesn`t matter unfortunately, we still have to protect it
MostAwesomeDude: spstarr: So has CSS, but that doesn’t make it legal. :c
spstarr: if it did, the tuner works for me watching TV in overlay, the km driver i dont bother using
bridgman: exactly
spstarr: but, recording tV channels is legal still
bridgman: mattmatteh: everything up to 5xx could accept YUV textures; starting with 6xx we`re doing it in shaders
RTFM_FTW: its not bad at all to do this in shaders
mattmatteh: bridgman, are you familiar with how well it works with fglrx ? perhaps thats off topic here
mattmatteh: bridgman, at the moment i was more interested if it worked.
RTFM_FTW: RGB <-> YUV is a pretty trivial algorithm 🙂
bridgman: fglrx is a bit different because we used the opengl driver for video; works ok but means we can`t composite the output until we have DRI2 or equivalent
mattmatteh: bridgman, sorry for all the questions, just trying research before i buy. buying something that doesnt work is pointless
bridgman: so video flickers under compiz
mattmatteh: i dont use compiz
bridgman: mattmatteh; no worries about questions, go ahead
bridgman: you will 😉
mattmatteh: i was just hoping to pop in a dvd and be able to watch it
yangman: modern CPUs are plenty fast enough to decode and render DVD videos
yangman: without any acceleration
bridgman: this gets into all kinds of interesting legal nuance
bridgman: I agree with yangman though… 480i mpeg2 is a no-brainer for modern CPUs
spstarr: bridgman: well, the tuner almost works on the 9800 AIW but there’s no picture i can see
yangman: I’ve been watching DVDs on my Core Duo laptop ages before r5xx DRI got implemented 😉
bridgman: in terms of 6xx�7xx accel release, the sequence will probably be basic EXA first, then Xv, then 3D, simply because the code for each one is bigger than the one before
MostAwesomeDude: The only reason to offload MC and iDCT to cards is to further reduce CPU load in most cases, not to magically make everything faster.
MostAwesomeDude: It’s not necessary, but it’s nice.
yangman: radeon doesn’t already have r5xx video overlay bits in it, does it?
bridgman: We`re not using the overlay right now, just textured video
spstarr: bridgman: also, if we are just supporting overlay you can’t record that
yangman: ok. I was thinking of playing with the overlay in radeonhd
bridgman: based on what I have seen over the last couple of weeks it seems like using the overlay just for pageflipping synced to vblank might be worth doing until we have proper synchronization between vblank and specific blit commands queued to the GPU
spstarr: bridgman: so i wouldn’t see a problem with AMD helping support overlay tv support?
bridgman: nope… if you look in the M56 docs all the registers are there… plus we have some extremely detailed but obsolete documentation we can use to help figure out what`s happening if it doesn`t work
bridgman: nope as in no problem, not as in nope we won`t help
bridgman: I think it would be a good thing
orkid: any clues on why ati hasn’t done tear free xv yet in their closed source driver?
orkid: any technological reasons that would keep it from happening on r6/7 quickly also?
yangman: orkid: the short answer is, it’s hard
bridgman: yeah, right now everyone is so damn busy supporting new chips that we don`t have a lot of free time to spend on new features
bridgman: we use a bit of the opengl stack for video rendering in fglrx; the downside of that is that it`s harder to redirect for flicker-free compositing, but the upside is that we might be able to take advantage of the opengl vsync capability to get tear free xv
MostAwesomeDude: bridgman: At some point, we wanna do r5xx page flipping.
MostAwesomeDude: :3
bridgman: I`ve been off semi-sick with some kind of black death bronchitis thing so haven`t spent a lot of time wandering around talking to people over the last couple of weeks
orkid: i understand. seems like new chips are coming out really quickly and nonstop
spstarr: bridgman: if something gets into my sinuses then –> bronchitis
bridgman: Most Awesome Dude; I think all the info for page flipping is already out there and known; the problem is flow control going back from the compositor to the individual applications
bridgman: orkid: the new chips come in waves; think the current wave has almost passed
MostAwesomeDude: Right. Gotta figure out how to make all that work. I think it might have to wait until mem management is more solid.
orkid: btw a bit ot, u know someone by the name of aleksic? senior engineer for gpu design i think
bridgman: spstarr: yep, doesn`t take much; local doctors seem to be prescribing wussy antibiotics, I miss the good old `take these until everything has been killed, then keep taking them for another week`days
bridgman: orkid: mickey �
bridgman: � = question mark
orkid: i dont know his first name. but i went to uni with his son marko
bridgman: yeah, I probably know him but not well
bridgman: don`t know his son 😉
bridgman: we sort of know everyone on the same floor, and I think he`s one floor down
orkid: so ati isnt that big after all! 🙂
spstarr: bridgman: touch no door handles 🙂
bridgman: during the SARS scare all the locked doors were propped open, so all the goblins came in and stole our laptops
bridgman: orkid: first time I went to England I was talking to some folks at the airport… they said `you`re from Canada, do you know xxxx`�
bridgman: … and I did.
orkid: lol
bridgman: talk about statistically unlikely
yangman: that’s amazing
yangman: although I’ve had friends meet people from their old schools or neighbourhood while touring around Europe 😉
orkid: yea. i have
orkid: kind of weird… i mean, what ar ethe chances.. are there really that little people doing it ?
spstarr: bridgman: so when you get time, if you can provide info on how tv overlay works on the 9800 AIW i’d be greatful 🙂
spstarr: then i can fix the existing gatos code
bridgman: orkid: when I was getting started in hi tech back in the 80s I used to be friends with one of the Intel reps; we figured that there were maybe 100 people in Canada who mattered in high tech and we knew pretty much all of them
bridgman: spstarr: the overlay should already be pretty well known – isn`t the open issue how to set up the tuner and how to grab digitized data from the tuner �
bridgman: as always, � is a question mark ;(
orkid: do you know someone by the name of john.. spizanelli.. or something like that?
orkid: boy, maybe i should stop asking about everyone i know at ati
orkid: (but i think that’s all)
bridgman: yeah, you got lucky the first time but SOL the second 😉
orkid: worked on mac drivers or something like that … last i heard.. but eh, not as senior as aleksic, just out of school a few years back
RTFM_FTW: hmm what is the name?
spstarr: bridgman: what is E
spstarr: bridgman: it attempts to but i see a moving faint picture on the 9800 AIW
bridgman: � is a question mark. My keyboard is all screwed up
spstarr: hehehe
orkid: john spitzarelli .. but not sure of the last name. .. sounds like..
spstarr: bridgman: what makes no sense is those tv tuner chip specs are on the web freely available no NDA
bridgman: exactly… so I don`t know why everyone keeps asking us for them, it`s not our IP
spstarr: but the glue is what we’re missing
bridgman: exactly… but as long as everyone is asking for tuner specs nothing will change
bridgman: you need capture hardware info, and that`s what I`m trying to dig up
spstarr: ya 🙂
spstarr: well, unless that capture info also is for the overlay?
bridgman: not much is going to happen in the next month or two because there are higher priorities but we will try to dig up the info for capture; again, problem is that there are some nasty liability issues
bridgman: capture and overlay are different; capture gets info from the tuner into the chip, overlay lets video info be displayed on the screen
bridgman: overlay stuff is low risk, so if there are problems there we can probably do something easily
spstarr: yes thats what i need only overlay 🙂
orkid: tv out ?
spstarr: tv in
bridgman: tvout is different again; in theory we know how to program it, in practics it doesn`t work
bridgman: so it`s on the queue of things to figure out
bridgman: what spstarr said; we`re talking about tvin here
orkid: i don’t understand.. i dont’ mean to be rude, because i don’t know how this whole process works.. but you work for ati right? how come you need to figure things out.. since ati makes the chips ?
orkid: must not have some important piece of information as to who knows what
spstarr: bridgman: i think a lot of people would be happy to have tv in with overlay working on the other rxxx AIW cards
bridgman: nope, fair question. HW and SW devs work together to get everything working; results end up in about 30 million lines of code. All we have to do is pick through the 30 million lines of code to find out how things work. Should only take about FIVE HUNDRED YEARS. So there`s a bit of trial and error.
orkid: but dont you make that 30 million lines of code collectively?
orkid: and people have responsibilities and understanding of various sections..
bridgman: Yes, but responsibilities change over time and understanding of hardware tends to fade after everything is working. There`s a lot of accumulated knowledge (several thousand man-years) in the driver code and right now we are playing catch-up. Going forward it will be a lot easier.
RTFM_FTW: umm a modern GPU driver is an insanely complex device from a code standpoint
orkid: oh i see.. that makes sense to me now
bridgman: People also leave, which is a huge pain in the ***. I think they should have to leave their brains in glass jars, but apparently Ontario labour law does not allow us to enforce that. I think it`s different in the US.
spstarr: bridgman: i assume newer cards will separate any ugly DRM/macrovision stuff out so it can be modularized?
MostAwesomeDude: Bit rot isn’t about bits disintegrating, it’s about the *understanding* of what those bits do, vanishing…
RTFM_FTW: and dramatically different going from platform to platform
spstarr: hullo MAD
MostAwesomeDude: spstarr: Yo.
RTFM_FTW: and API to API of coursew
RTFM_FTW: all of this makes figuring out *anything* a total bitch IMHO 😀
spstarr: RTFM_FTW: nobody said video card design was easy 🙂
orkid: it’s too bad really, people coming and going… much more could get done if that wasnt the case i bet
RTFM_FTW: spstarr imagine that
RTFM_FTW: heh
spstarr: it would be nice to get us to the point that the intel folks are doing with drivers
spstarr: resources 😉
terracon: here here
spstarr: bridgman: if I could convince my company to switch some resources to driver development 😉
spstarr: if pigs could fly
terracon: I thought Intel was going to put out a stand alone card. Like a pcie card you can pop in
bridgman: this will all work out; we were one of the first companies to get heavily into supporting open soruce, but pulled out around the R300 timeframe because the costs and risks were getting too high; Intel stayed in and has done well because of it (in fairness it was easier for them) but once we get caught up (soon) this will all seem a lot easier
spstarr: bridgman: i agree
bridgman: terracon: I imagine there will be Larabee cards; don`t think they will be cheap though
spstarr: the economy doesnt help though :/
terracon: yes that’s it Larabee
spstarr: has done his part though, i have all ATI cards in my systems 😉
bridgman: spstarr: everyone was way too optimistic before; now they`re too pessimistic… close your eyes, bow your head, wait for the ricochet
spstarr: yes
terracon: I’ve been ati since mach 32
spstarr: I wish I could help more than just test drivers
spstarr: there’s no good books on writing graphics drivers anywhere?
spstarr: concepts etc?
spstarr: looks at MostAwesomeDude
spstarr: how’d you learn graphics drivers
terracon: looks at spstarr
bridgman: not much that is current; Michael Abrash wrote some good books but they were kinda pre-GPU
yangman: it’s just software
yangman: :p
MostAwesomeDude: I learned OGL from the Red Book, and I learned GPUs from reading Mesa source and poking glisse and airlied a lot.
spstarr: yangman: but you gotta understand the concepts
spstarr: MostAwesomeDude: that’s a lot of poking 😉
MostAwesomeDude: Oh, it was. It was.
bridgman: spstarr: seriously, you just do it.. every driver has some simple parts, just move the screen over 32 pixels or something then move up from there
MostAwesomeDude: But the biggest parts of the GPU map directly to the parts of the OGL pipeline, so knowing how OGL works is a good start.
spstarr: bridgman: shifting the stride ? heh
bridgman: or the offset, yep
yangman: and, yeah, poking people alot 😉
spstarr: well i did add EXA support to an old S3 ViRGE card with help, i have the code
spstarr: not full EXA
spstarr: but those are old video cards
spstarr: not as complex as modern GPUs
spstarr: converting XAA to EXA isn’t exactly useful now is it? 🙂
bridgman: modern GPUs are harder, but that just means you probably can`t write the initial driver support…
spstarr: true, its out of my range for now
bridgman: converting xaa to exa is really useful because (a) exa used to suck but keeps getting better as the infrastructure improves and (b) it means you understand something and can apply that knowledge to other gpus or to something slightly more complex on the same gpu. Repeat.
spstarr: that helps yeah
spstarr: but all rxxx drivers have EXA now
bridgman: initial 6xx and 7xx will probably just have solid fill and copy, not all the rops; you could add stuff there (if we tell agd5f to back off for a minute ;))
spstarr: heh
spstarr: i have to understand the other render operations i only implemented copy
MostAwesomeDude: The actual Render stuff isn’t too bad. It’s much like Xv.
MostAwesomeDude: But if there’s buggies, they can be quite subtle…
spstarr: assuming i can find the code ;/
bridgman: seriously, it doesn`t matter what you do… just go change stuff and see what happens, and over time it all becomes clear
spstarr: bridgman: so as long as it doesn’t physically blow up a gpu 🙂
MostAwesomeDude: Except for fog, which is, appropriately, foggy. :3
bridgman: anyways, you probably should be doing gpgpu stuff, which is just blowing arrays through the 3d engine and reading back the results
spstarr: ehehe MAD
orkid: it would be nice to speed that process…. of recompiling rerunning again.. sigh. if only there was a way
bridgman: yeah, fog is different
spstarr: orkid: well if we get GPU reset support from AMD 🙂
spstarr: bridgman: that would be something we’d really like to have to speed up dev
orkid: how so.. wouldnt you still need to recompile, reload driver, restart X ?
yangman: spstarr: I spent 3 weeks getting my GPU into completely broken voltage and clock states. they’re pretty resillent 😉
spstarr: and it still works?
yangman: *resilient
spstarr: true
yangman: sure. it’s my only machine
spstarr: but gpu reset would help us in that i wouldn’t have to restart to break a gpu wedge
bridgman: let me see what I can do re: GPU reset… although in some cases you just have to yank power and there aren`t a lot of alternatives. That`s the problem with driver developent… `we want to be able to control everything… we don`t want anything between us and the hardware… oh damn the GPU is wedged, you guys suck…
spstarr: ehehe
spstarr: well reducing wedges is a good thing
orkid: if there was a way to more quickly test the changes… without having to reload/restart/reset things
orkid: that would be swell 🙂
orkid: i’m dreaming
bridgman: we are putting some time into software emulation of the GPUs to simplify driver development, but making restarts faster has the cost of making everything else slower…
orkid: slower in production version, or just for the time being during debug
spstarr: bridgman: I would have though resetting the gpu would be just a matter of sending a command to break it out of its tight loop
bridgman: in all seriousness, I think what we are doing with 6xx and 7xx will work out well… we`re getting the basic programming sequences out and going through hell to get there… once those are working you can always come back to working code and most of the really ugly uysteries should be out of the way
spstarr: then the driver would re-init the card
yangman: spstarr: but, it’s stuck. how will it get the command? 😉
spstarr: bridgman: but the older r3xx, r4xx are causing grief
bridgman: there aren`t commands to say `yo gpu, last command I gave you was bogus, fuggedaboutit`
bridgman: yangman: right
spstarr: yangman: well, you have a reserve way of sending something like OOB commands to the card to kick it?
spstarr: (out of band)
bridgman: spstarr: what is the grief with the older GPUs � glisse and airlied are working on fixing the borked drm code and using the gpu the way it was intended, with timestamps and fences and all that whizbang stuff
orkid: you can’t just create a dev board and set it up so that you can just cut the power to the chip and bring it back online and reinit?
spstarr: bridgman: so the newer GPUs use different mechanisms?
orkid: knows next to nothing about what gpus require.. maybe he should think a bit more about it
yangman: orkid: you have to remember things like bus and controller init. it’s not just a single component: it’s a network
bridgman: sure we can create dev boards, but we have room-sized hardware emulators so why bother �
spstarr: i guess as graphics cards progress programming them changes more and more over time so the lessons learned from the r3xx and what was successful and not
yangman: it’s the classic Throw More Hardware At It solution
bridgman: most of this is worked out on the emulators before we even tape out the silicon, it`s only the escapes that are a big pain in the &*?*?&
spstarr: bridgman: it just seems that the newer GPUs have a better design vs the older ones? or is it just the code itself?
spstarr: bridgman: given the r3xx was reverse engineered (more of it) vs the r5xx+ DRI code
bridgman: I think that`s the main point; 3xx was reverse engineered, 5xx had some docs. The more recent GPUs have it easier because we were running on emulators before we taped out, but every generation is also more complex so it kinda balances out
bridgman: constant pain
bridgman: but the chips keep getting better
spstarr: bridgman: would it make sense to redo the r3xx code ?
bridgman: already being done; glisse & airlied`s cs code, plus the bufmgr work nha and others are doing…
spstarr: ah
spstarr: so it being refactored
spstarr: its
bridgman: yep, with a dull refactorer…
bridgman: that didn`t come out right, I was trying to say that it was painful not that the devs were dull…
spstarr: 🙂
spstarr: well i can see the pain from testing
spstarr: but it doesnt help that the DRI design has some holes hopefully DRI2 plugs, but given DRI is ‘old’ they could not have known any of the pitfalls we see today
bridgman: yep, new stuff is always extremely painful; it would be nice to wait until everything sorta works but someone has to get it there…
spstarr: well, kms works on my rv350, r300, but i understand there’s still a lot to do
bridgman: there are so many things broken in the current X & DRI that it`s best not to think about it… the good news is that for every ugly someone is working on it, and I think this is the first time we have been able to say that for a long time
spstarr: yes, very true
bridgman: it`s a pretty cool time to be involved, it`s just kind of daunting
spstarr: its quite a massive endeavor
spstarr: and then where Gallium 3D fits into that
bridgman: in some ways Gallium is easier to handle – it`s further up the stack so if something goes wrong it`s more likely to do the wrong thing than lock everyhing up and require you to shake the etch-a-sketch
spstarr: (like now 😉
spstarr: I’m confident in those who are working on the the stack
spstarr: its just been an awful painful (learning) process to get us to where we want to go
spstarr: bridgman: a friend of mine @ work who used to work in IBM for their graphics division told me, he doesn’t understand why we try to ‘workaround X’ by writing all this code over top of it
bridgman: two words. three dee
spstarr: at least for the GLX
spstarr: yes
spstarr: but he thinks we should’ve just dropped it it altogether
bridgman: although I have actdually asked the same question. The overhead from indirect rendering is down to maybe 5% these days, problem is that apps all stubbornly use direct rendering so we need RDR, which needs DRI2, which needs TTM or GEM, to deal with them. If the apps would just say that they wanted indirect rendering this would all be a lot easier
bridgman: so basically I agree with your IBM friend
spstarr: what I’d love to see would have been to do a new graphics UI but have the x protocol an addon
spstarr: bridgman: yeah
bridgman: that`s sort of the idea with gallium; start with a low level protocol then build a bunch of sh** on top
spstarr: so you think gallium is the beginning of the replacement of the X server itself?
spstarr: so we can then offload X protocol into a modular thing
bridgman: nope, it`s just that low level protocol you were looking for 😉
spstarr: hmm
spstarr: bridgman: sort of what the old Berlin Consortium was doing with their display UI
bridgman: x isn`t the problem – the problem is that we have 20 million lines of graphics environment and 20 people working on it
spstarr: bridgman: yeah, lack of resources
bridgman: hey it`s all free, right �
bridgman: � is question mark ;(
yangman: bridgman: you should get that fixed 😉
spstarr: when you think about it though, why couldn’t we drop X as a display UI and just shuffle it off into a module for X compatibility so that we don’t lose X but we gain a better graphics framework above it?
spstarr: kms seems to get us in that direction
bridgman: kms and gallium are the two magic bullets… once you have those you can build anything on top
spstarr: aha
spstarr: i thought so 🙂
bridgman: the issue is that most of the stuff on top works pretty well
spstarr: well, X does in general yes
bridgman: but everyone wants to replace it because they think writing something from scratch will be easier than fixing it
bridgman: yeah right
spstarr: bridgman: but if thats where we want to go in terms of what Mac OS X did for their UI we can
spstarr: X itself is ingenious
spstarr: but the X server itself that is hurting us
bridgman: not sure I agree… I think quartz is more of a cairo-thing than an X-thing

Radeon IRC Logs For 2008-10-24

Rig Lab Hardware

You Might Also Like

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

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

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