Announcement

Collapse
No announcement yet.

Details On The AMD Linux Graphics Driver Ported To Windows

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

  • Details On The AMD Linux Graphics Driver Ported To Windows

    Phoronix: Details On The AMD Linux Graphics Driver Ported To Windows

    Earlier this month I wrote about the AMD porting their open-source Linux graphics driver to Windows EC7. Here's a few details that were learned in the past two weeks...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    How does this affect the ReactOS project?

    Comment


    • #3
      Originally posted by ethana2 View Post
      How does this affect the ReactOS project?
      not at all, I'd guess.

      Comment


      • #4
        Originally posted by NeoBrain View Post
        not at all, I'd guess.
        I would hope to disagree. They could use the OSS driver and maybe only have to reimplement the required windows glue.

        Comment


        • #5
          A very good news in my opinion.
          This means more ressources will be put on the open source driver, as AMD had better keep a common code base as much as possible between the two ports. And that means more features will come quicker.

          Comment


          • #6
            Originally posted by rvdboom View Post
            A very good news in my opinion.
            This means more ressources will be put on the open source driver, as AMD had better keep a common code base as much as possible between the two ports. And that means more features will come quicker.
            ^ This.

            I hope that slowly but surely pieces of fglrx can be replaced by this.

            I also hope OpenGL is correctly implemented without duct tape so that PC graphics will actually be faster than consoles and so that we will not have to deal with shitstorms like RAGE anymore...

            Comment


            • #7
              Is that meant to replace the normal windows drivers someday later (in the far future)?

              So that you really would have one driver for windows and linux with some bits of plattform specific code? We are talking here about gallium3d right?

              If I did understand it right, thats great. the opensource driver should become THE full driver in the long run, stable featurereach and fast and free, that would be great.
              Last edited by blackiwid; 24 October 2011, 04:39 PM.

              Comment


              • #8
                Originally posted by V!NCENT View Post
                ^ This.

                I hope that slowly but surely pieces of fglrx can be replaced by this.

                I also hope OpenGL is correctly implemented without duct tape so that PC graphics will actually be faster than consoles and so that we will not have to deal with shitstorms like RAGE anymore...
                As long as the fundamentally-flawed-by-design OpenGL API continues to exist, we will always have to deal with shitstorms like RAGE.

                Of course, a developer that actually tests their code against systems that people run in the wild can ameliorate a large part of the problem, but it's a very expensive investment to make a game's OpenGL code compatible with a wide variety of OpenGL implementations.

                The OpenGL "standard" is about as standardized in practice as the English language as spoken globally. We all use the same words, but half the time we don't mean the same thing!

                Comment


                • #9
                  I'm not even talking about the bugs. I am talking about a specification that sais: "A will do B an returns", which is implemented as "When C notices a, it will pass D though E and puts F into B, which will return B".

                  Hack and slash. Per-pixel-lookup first has to load a tile into texture, so that texture loads, pixel can be found and returns pixel, while what you want is blit.

                  Where do you think the texture popping comes from?

                  Comment


                  • #10
                    I'm not even talking about the bugs. I am talking about a specification that sais: "A will do B an returns", which is implemented as "When C notices a, it will pass D though E and puts F into B, which will return B".

                    Hack and slash. Per-pixel-lookup first has to load a tile into texture, so that texture loads, pixel can be found and returns pixel, while what you want is blit.

                    Where do you think the texture popping comes from?

                    Edit: Carmack has an entire series of complaints about the AMD and nVidia OpenGL implementations. It advertises functionality, and for a programmer it appears to be working, but it does nothing directly and the way it is advertised. This leads to completely random bugs and horrible performance.

                    Comment

                    Working...
                    X