Announcement

Collapse
No announcement yet.

Open ATI R600/700 3D Graphics For Christmas?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • I can appreciate that. I have a question about the IP review...

    Internal documentation that AMD uses to develop their binary drivers. This documentation is likely put together by a core of engineers during the design phase right? If so what would it take to get this initial documentation for future products modularized to support a core set of functionality that can easily be released to the public from the get go?

    I realize that there is nothing that can be done for current releases, but maybe future products...
    Last edited by duby229; 29 November 2008, 12:53 PM.

    Comment


    • Two part answer:

      1. The documentation written during design is not really the kind of docco needed by driver developers... it's more along the lines of "the XX block is divided into sub-blocks a,b,c,d,e. Sub-block a breaks incoming vertex information down into 5 parallel streams and connects to sub-block b via a 1072-bit parallel bus running at 1/2 the engine clock rate...". There are some rudimentary programming docs written but they happen later in the process and are generally not real detailed because the hw and sw teams are colocated.

      2. That said, with each new generation we are trying to improve the quality of programming documentation written during hw development. The first step, starting with 7xx, was to have all the different component teams contribute to the same document so we had more commonality in terms of level of detail and documentation style. We were actually able to get the 7xx running before the 6xx, and used that as a stepping stone to get 6xx working.

      EDIT - make that a three part answer

      3. The internal docs will still be written for internal use, ie no attempt to consider IP issues and only include stuff we can push out to the general public. There is just too much documentation required (maybe 10,000 pages or more) for a modern GPU to constrain all the engineers with IP issues. In other words, we will still have to go through the sanitizing and review process after the doc is written -- the big difference is that we hopefully won't have to write the doc in the first place.
      Last edited by bridgman; 29 November 2008, 01:13 PM.
      Test signature

      Comment


      • Originally posted by bridgman View Post
        Two part answer:

        1. The documentation written during design is not really the kind of docco needed by driver developers... it's more along the lines of "the XX block is divided into sub-blocks a,b,c,d,e. Sub-block a breaks incoming vertex information down into 5 parallel streams and connects to sub-block b via a 1072-bit parallel bus running at 1/2 the engine clock rate...". There are some rudimentary programming docs written but they happen later in the process and are generally not real detailed because the hw and sw teams are colocated.

        2. That said, with each new generation we are trying to improve the quality of programming documentation written during hw development. The first step, starting with 7xx, was to have all the different component teams contribute to the same document so we had more commonality in terms of level of detail and documentation style. We were actually able to get the 7xx running before the 6xx, and used that as a stepping stone to get 6xx working.
        That's actually pretty dang neat. At least that way you can be assured of a decent amount of consistency. The only problem I can think of is how do you strip out the parts that shouldn't be public from the rest of it? Especially in such a tightly integrated document.

        RE 2, do you think it will be possible to maintain that level of consistency in the documentation while making it easier to strip out sensitive information?

        Edit: you've answered my question with your edit.

        Comment

        Working...
        X