Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Open-Source Still A Mess

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

  • #31
    Hmm, wouldn't it have been easier if the code was documented as it was written, by those who wrote the code in the first place? It doesn't sound like a very difficult thing to do. Now when it's incredibly complex, I can see it being a problem, but it makes me wonder if it's a problem just because of poor coding habits...

    Comment


    • #32
      Originally posted by entropy View Post
      Maybe it's just me, but I'd say it's really the complexity which keeps people from contributing.
      The threshold to enter that business seems rather high.
      I can tell you from my experience that all you need to know is OpenGL and GLSL and you need to know them really well. Then there's only the will to contribute. There are also plenty of useful papers, articles, and conference slides about how to efficiently program for GPUs with APIs like OpenGL and Direct3D on both major vendors' websites. I think anyone who can write a decent game rendering engine (that's why you learned OpenGL in the first place, right?) has already enough knowledge to write GPU drivers. The rest can be learned on the job.

      I doubt any kind of documentation for new GPU driver developers will be worth the invested resources its authors will put into it.

      Looking back, I think the most difficult thing for me was building and installing Mesa for the first time. At least that should be documented somewhere.

      Comment


      • #33
        Originally posted by GreatEmerald View Post
        Hmm, wouldn't it have been easier if the code was documented as it was written, by those who wrote the code in the first place? It doesn't sound like a very difficult thing to do. Now when it's incredibly complex, I can see it being a problem, but it makes me wonder if it's a problem just because of poor coding habits...
        The problem is that most of the open source driver code wasn't written as a "one time top down project" where doing design documentation up front would be an obvious expectation. A lot of the big changes were made incrementally as time permitted over a few years, as bits of time became available. That makes it hard to keep detailed design documentation current.

        In some cases (eg r600g shader compiler) the code was known to be temporary when it was written so it would be hard to justify requiring high quality documentation for the initial code (which is also the current code). I haven't asked him, but I imagine Jerome would have wanted to spend any time he had for documentation on the "final" design he had been working on, not the initial "write this so we can get the rest of the stack running" code that runs today.

        Another challenge is that the underlying hardware is constantly evolving, so even the line between hardware and software keeps changing. That, in turn, drives change all through the stack and makes the old "a job done right never needs to be done again" line into a bit of a joke.

        There probably are some sections of the code which the developers expect to keep around for a while and there's no reason why those sections couldn't / shouldn't be documented, but you might be surprised how many bits of the current driver stack the devs expect to have to rewrite in the next couple of years. That's why I think staying with higher level documentation (basically enough to get new developers to a general area of code and give them an idea about how that code relates to the rest of the stack) is the most likely to be successful for the near future.

        Comment


        • #34
          Originally posted by marek View Post
          I can tell you from my experience that all you need to know is OpenGL and GLSL and you need to know them really well.
          Yep. It's hard to find experienced graphics driver developers, so for new developers we end up looking for people who know OpenGL details (and/or DX for the Windows world) well enough that following the GL commands down to hardware doesn't seem like much of a stretch.

          If you're trying to learn graphics *and* hardware/drivers at the same time, it's really difficult and IMO no documentation in the world is going to make that easy.
          Last edited by bridgman; 11-25-2012, 05:46 PM.

          Comment


          • #35
            Last time I checked trying to do so would result in basically garbled output with the flash plugin.


            Comment


            • #36
              Originally posted by marek View Post
              I think anyone who can write a decent game rendering engine (that's why you learned OpenGL in the first place, right?) has already enough knowledge to write GPU drivers.
              I laughed when I read this. A lot.

              For one, you don't learn OGL to make game rendering engines. More often, its for working on some CAD program.

              Secondly, writing hardware drivers is a totally different beast then working within the confines of some stand alone program. I've worked on systems where you have to send some I/O directly to the H/W. In this realm, we CARE that it takes some switch inside the H/W some amount of time to fully settle, and this drives how the S/W is developed. We care that it might take x amount of time to access some data if its located in RAM. And so on. To an application developer, all this is invisible, because its all handled for you driver side.

              Comment


              • #37
                Originally posted by bridgman View Post
                the "final" design he had been working on, not the initial "write this so we can get the rest of the stack running" code that runs today.
                Any news on that, BTW?

                Comment


                • #38
                  Tom and others have been doing a lot of work on enabling the new LLVM-based shader compiler for r6xx through NI hardware, so if that works out OK then there's probably no need for anything else.

                  I haven't discussed it with Jerome, but I imagine he is torn between hoping the LLVM stack succeeds so he doesn't have to write a new shader compiler and hoping it fails so he does have a good excuse to write a new shader compiler

                  Comment


                  • #39
                    Originally posted by gamerk2 View Post
                    For one, you don't learn OGL to make game rendering engines. More often, its for working on some CAD program.
                    This is interesting. I've met tens of people in person who had learned OpenGL through game development (and some later got a job in the industry). I have never met anyone who had learned it through CAD.

                    Originally posted by gamerk2 View Post
                    Secondly, writing hardware drivers is a totally different beast then working within the confines of some stand alone program.
                    I would beg to differ. It's mostly software development like anything else. You don't always have to mess with hardware at the lowest level. Some core Mesa developers don't even know the hardware and they've done an amazing job.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      Originally posted by Hamish Wilson View Post
                      I am interested in the word "we're" in your statement. What exactly is your involvement with the driver?
                      Other than the shader compiler Michel pretty much wrote radeonsi. Everyone helped with testing and debugging the driver but MrCooper (that's just his IRC handle BTW) drew the short straw for initial SI userspace support.
                      LOL, glad to see that someone else was thrown for a loop too..I thought it was Alan Coopersmith (Oracle) at first ... did a search through his old posts for hints/clues and was left just unclear and wondering. Mystery solved

                      Comment

                      Working...
                      X