Announcement

Collapse
No announcement yet.

RadeonSI Gets Patches For OpenGL 4.5 Compat, Workaround For No Man's Sky On Steam Play

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

  • #11
    Originally posted by dungeon View Post
    fglrx had 3.3 compat 6+ years ago
    I know, but that's not what I'm asking about...

    The real question should be - does anybody care to bring 10+ years old hardware to 3.3 compat?
    I know. That's what I'm asking about...

    Comment


    • #12
      Originally posted by GruenSein View Post
      ...I can't help but wonder if it wouldn't make sense to "port" it to PAL or even make a PAL-based open source GL driver. That way, it could be used on all platforms.
      We spent some time looking at that. Nicolai or Marek know a lot more details than I do, but quick answer is that PAL isn't a good match for OpenGL, and that trying to run OpenGL over PAL would result in a lot of extraneous pipeline rebuilds and poor performance... or something like that.
      Test signature

      Comment


      • #13
        Originally posted by bridgman View Post

        We spent some time looking at that. Nicolai or Marek know a lot more details than I do, but quick answer is that PAL isn't a good match for OpenGL, and that trying to run OpenGL over PAL would result in a lot of extraneous pipeline rebuilds and poor performance... or something like that.
        This might sound absurd, so please bear with me, but I was wondering if AMD has ever taken in consideration choosing mesa(RadeonSI/RADV) + NIR + LLVM as multiOS stack for OpenGL and Vulkan? There are some efforts to also keep windows builds in a working state.

        One could argue that this means giving up to it's own set of 'known bugs' for a potential different set of 'unknown bugs' but mesa is pretty mature and opengl/Vulkan conformant implementation + there is a great community support, and might even benefit from features/bugfixes for free from the work of other vendors.

        A bit cumbersome would be the fact that there is a learning curve involved for the current AMD developers, it won't be just weekly code drops, but instead they would have to integrate in the mesa community. Same thing as it was with DAL/powerplay. But, look how good the situation has improved now.. some patches might take longer to be accepted and perhaps that would slow down things a bit, but I presume that is also a good things, because more people might have better ideas and as positive side effect, it increases the quality.

        So, did anyone just briefly considered if this could be feasible as a long term strategy?

        Thanks!

        Comment


        • #14
          Originally posted by xxmitsu View Post
          This might sound absurd, so please bear with me, but I was wondering if AMD has ever taken in consideration choosing mesa(RadeonSI/RADV) + NIR + LLVM as multiOS stack for OpenGL and Vulkan? There are some efforts to also keep windows builds in a working state.

          One could argue that this means giving up to it's own set of 'known bugs' for a potential different set of 'unknown bugs' but mesa is pretty mature and opengl/Vulkan conformant implementation + there is a great community support, and might even benefit from features/bugfixes for free from the work of other vendors.
          It has definitely been considered, and might be a possibility for OpenGL IFF we are able to make Mesa run as well as our closed source driver on traditional CAD workstation apps (which are the main reason we keep working on the closed source GL driver).

          There is much less chance of that happening for Vulkan though, since the PAL layer also supports a number of other APIs and so most of the work has to be done anyways even if we were not taking advantage of that work for Vulkan on Windows.
          Test signature

          Comment

          Working...
          X