Page 1 of 2 12 LastLast
Results 1 to 10 of 11

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,820

    Default 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...

    http://www.phoronix.com/vr.php?view=MTAwNTA

  2. #2
    Join Date
    Jun 2007
    Location
    The intarwebs
    Posts
    385

    Default

    How does this affect the ReactOS project?

  3. #3
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    Default

    Quote Originally Posted by ethana2 View Post
    How does this affect the ReactOS project?
    not at all, I'd guess.

  4. #4
    Join Date
    Jan 2007
    Posts
    418

    Default

    Quote 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.

  5. #5
    Join Date
    Jan 2008
    Posts
    155

    Default

    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.

  6. #6
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote 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...

  7. #7
    Join Date
    Jul 2008
    Posts
    837

    Default

    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; 10-24-2011 at 04:39 PM.

  8. #8
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote 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!

  9. #9
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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?

  10. #10
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •