| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Old news
Old news
Posted Feb 12, 2008 17:47 UTC (Tue) by flewellyn (subscriber, #5047)In reply to: Old news by kmike
Parent article: AMD's open GPU documentation site
Well, that's disappointing. I suppose we'll have to wait some more for documentation enough to make a full driver, eh?
Surely they have their own documentation for their own driver writers, though!
(Log in to post comments)
Old news
Posted Feb 12, 2008 18:45 UTC (Tue) by vmole (subscriber, #111) [Link]
Don't count on it. The existing "documentation" might well be an overview ("here's the new stuff since R300") and lots of e-mails and phone calls.
You can be sure they don't
Posted Feb 12, 2008 21:41 UTC (Tue) by khim (subscriber, #9252) [Link]
I'm pretty sure that's bunch of presentations, architecture overviews plus some e-mails. In-house driver writers can always just ask guys who develop hardware about details...
You can be sure they don't
Posted Feb 12, 2008 21:45 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
Well, that's...unsettling.
You can be sure they don't
Posted Feb 13, 2008 15:13 UTC (Wed) by liljencrantz (subscriber, #28458) [Link]
It would explain the quality level of the ATI drivers, though.
You can be sure they don't
Posted Feb 14, 2008 17:56 UTC (Thu) by iabervon (subscriber, #722) [Link]
It's not unusual that the knowledge about how hardware works is codified in QA procedures, designer knowledge, and a lot of notes that don't form a coherent document. The economics of this particular market is that there really isn't time to write up documents that will explain how to use the hardware to an outsider before the device needs to have drivers already written and available to the public, and there's been little reason to write up such documents after the driver is written. Furthermore, there are a lot of corner cases, where the vendor driver doesn't try doing something, and the hardware designers didn't except the driver writers to try it, and so nobody's bothered to figure out if it would cause problems or not. They avoid trying to evaluate a combinatorial explosion of unknown interactions by only checking the ones that people are interested in, which is a big help in getting work done in a reasonable amount of time, but only if the process is interactive. (And it's likely that a different implementation of high-level 3D operations on the low-level units they have would hit different combinations than the ones that the designers have verified to work together)
You can be sure they don't
Posted Feb 14, 2008 19:38 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
From the sound of things, they'd benefit hugely from an open development model. :-)
You can be sure they don't
Posted Feb 13, 2008 10:09 UTC (Wed) by forthy (guest, #1525) [Link]
I'm not sure if you can develop such a complex piece of hardware with such a lousy procedure. I'm developing hardware, simpler one than ATI graphics cards, and we certainly have internal documentation, most of them on a Wiki. We also have people who write documentation for people outside the company, they take the information from the Wiki, polish it up, and delete those parts of the interface that's only used for debugging ;-). And even our largest projects have only a few people involved.
Speaking for me: Even when I do all the things as a one-man show, i.e. designing the hardware, creating the address map and the registers, and writing the software, I'm still writing documentation as well. I don't want to dig into several Verilog files, documentation should not only be inside those files. I sometimes even use literate programming style to get documentation and source together, where it's needed.