Announcement

Collapse
No announcement yet.

The Issues With The Linux Kernel DRM, Continued

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

  • #31
    Ok

    So how does AMD's Windows division write their drivers?

    Are there test plan's, deliverable documents that have to be written explaining timings, mode setting and caveats? Do developers have deadlines and code freezes?

    Does Microsoft allow you to change their APIs?

    Comment


    • #32
      Originally posted by squirrl View Post
      So how does AMD's Windows division write their drivers?

      Are there test plan's, deliverable documents that have to be written explaining timings, mode setting and caveats?
      From what I understand, yes. The hardware team creates two sets of documents: the internal-only documents that contain full disclosure, including all the info about the parts they will never reveal in open documentation (e.g. UVD); and, later on, a set of sanitized documents for the general public and their open source developers to use to write their drivers.

      Originally posted by squirrl View Post
      Do developers have deadlines and code freezes?
      Yes, because they are responsible for delivering a product targeted at end-users of a commercial product (i.e. Windows).

      Originally posted by squirrl View Post
      Does Microsoft allow you to change their APIs?
      No, because they actually have an API (e.g. WDDM 1.1 in the kernel and Direct3d in userspace) that is sufficiently expressive to allow most modern graphics hardware to at least be shoehorned into this mold. Aside from that, consider these other factors:

      *While WDDM is being developed, many many ATI, Intel and Nvidia engineers are constantly involved in meetings with Microsoft to work out what APIs will be acceptable for them. Microsoft didn't just go and develop it in a vacuum; it's a custom-fit API to work with the hardware that the companies are building. These meetings and associated engineering work involved manpower on a scale that makes FOSS graphics engineering look picayune by comparison.
      *WDDM is a finished product now. Developing a new driver or maintaining an existing driver to add new features/ASICs is much, much easier when you have a graphics driver infrastructure that is proven to work well with previous generation hardware.
      *Because WDDM is so prevalent, it gets special treatment at a very low level: hardware designers intentionally build hardware that they think might work well with the operating principles of WDDM, and vice versa. The sheer popularity of WDDM (via the popularity of Windows) is an impetus for ensuring that the API and the hardware will match up well -- a convenience we lack in the free world.
      *All the patent deals needed are licensed way ahead of time, so the engineers don't have to have any heartburn about dodging patents left and right in the specs they're implementing.

      Just because something works well in one set of circumstances doesn't mean it can work well in another set of completely different circumstances.

      Comment


      • #33
        Originally posted by allquixotic View Post
        From what I understand, yes. The hardware team creates two sets of documents: the internal-only documents that contain full disclosure, including all the info about the parts they will never reveal in open documentation (e.g. UVD); and, later on, a set of sanitized documents for the general public and their open source developers to use to write their drivers.
        One minor tweak - the hardware team creates documentation about how the hardware is implemented (which gives some information on how to program it) and writes diagnostic programs - proprietary driver/VBIOS software teams work with hardware teams to create and document the software design, then open source team (primarily agd5f) creates sanitized programming info based on internal HW doc + diags + info from VBIOS & driver teams.

        We have tried a few different approaches for getting the *right* information into developer's hands and have concluded that getting basic driver code working before writing docs is the most effective way - otherwise we spend a lot of time writing & reviewing docs only to find that the information was wrong.

        Comment


        • #34
          Stinkin' edit limit...

          Now that development is mostly "caught up" with new hardware development (at least we're starting less than a year after the proprietary driver team now) we're trying to piggyback open source design & planning onto the proprietary driver work. We won't be able to do this fully for the next generation of parts but hope to be in sync after that.

          Comment


          • #35
            Originally posted by bridgman View Post
            Stinkin' edit limit...

            Now that development is mostly "caught up" with new hardware development (at least we're starting less than a year after the proprietary driver team now) we're trying to piggyback open source design & planning onto the proprietary driver work. We won't be able to do this fully for the next generation of parts but hope to be in sync after that.
            Please cite for the interwebs, which next generation are we talking about?

            Comment


            • #36
              Originally posted by curaga View Post
              Please cite for the interwebs, which next generation are we talking about?
              The "next generation" is the one we aren't talking about yet, other than acknowledging that we are in fact continuing to design new GPUs

              We were not able to start at the same time as the proprietary driver folks for that generation but at least they are still working on it. The generation *after* that is the first where we are able to design & plan the open source support at the same time as the proprietary driver support.

              Comment


              • #37
                http://phoronix.com/forums/showthrea...ht=#post187364

                Comment


                • #38
                  Originally posted by bridgman View Post
                  The "next generation" is the one we aren't talking about yet, other than acknowledging that we are in fact continuing to design new GPUs

                  We were not able to start at the same time as the proprietary driver folks for that generation but at least they are still working on it. The generation *after* that is the first where we are able to design & plan the open source support at the same time as the proprietary driver support.
                  No, no no, in abstract terms at least. I'm unsure whether you're talking about hd7xxx, hd8xxx or hd9xxx, or even something else.

                  Comment


                  • #39
                    Thanks

                    Thanks for all the information guys.

                    Comment


                    • #40
                      Originally posted by curaga View Post
                      No, no no, in abstract terms at least. I'm unsure whether you're talking about hd7xxx, hd8xxx or hd9xxx, or even something else.
                      Marketing names get picked pretty late in the game, but if the same pattern holds then we're starting to look at what you would call hd7xxx but that's still almost a year behind the earliest proprietary driver design work.

                      What you call hd8xxx is the first generation where we can start open source driver design efforts more or less in sync with hd8xxx.

                      They could end up being called something completely different from hd7xxx and hd8xxx, of course.

                      Comment


                      • #41
                        Originally posted by squirrl View Post
                        Thanks for all the information guys.
                        +1
                        There's some very important - and necessary, it seems - discussion going on here.

                        Very interesting to read as well!

                        Comment


                        • #42
                          Thanks bridgman, that was exactly what I wanted to know.

                          Comment


                          • #43
                            Glisse,

                            You mentioned several times now that you would communicate differently with the hw if you were to write radeon kms now in order to have better performance.
                            Are you planning to do this? Do you think Linus "will allow" breaking the API once? Or is it possible to do this change in a backward compatible way?

                            Thanks for the info in advance!

                            Comment


                            • #44
                              Originally posted by HokTar View Post
                              Glisse,

                              You mentioned several times now that you would communicate differently with the hw if you were to write radeon kms now in order to have better performance.
                              Are you planning to do this? Do you think Linus "will allow" breaking the API once? Or is it possible to do this change in a backward compatible way?

                              Thanks for the info in advance!
                              I have got ideas, doesn't means they good, cs ioctl seemed like a good idea when i came up with it. No much point in talking about this until i got something that works.

                              Linus won't allow breakage so solution would either be like what we did with kms bump major version and explicitly says that we are not backward compatible or use a different driver name. Anyway none of this can happen if others involved don't think it's a good idea ie that the pain of switching to another paradigm is worth it.

                              Comment

                              Working...
                              X