Announcement

Collapse
No announcement yet.

Radeon R600 Gallium3D NIR Backend Continues Advancing

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

  • #21
    Originally posted by Dukenukemx View Post
    Whatever happened to FP64 support so some of us can go beyond OpenGL 3.3?
    Yeah, I've been wondering about that as well. It's a shame that most R600 cards (with exception of the few ones that supported FP64 in hardware) never were able to advertise OpenGL 4+ support. Looking at mesamatrix.net, FP64 softfloats support is the only thing keeping all R600-based graphics cards from fully supporting OpenGL 4.5 in Linux!

    Also, it would be cool if someone with the necessary knowledge and interest would take a stab at the development of a Vulkan driver for R600 graphics cards. From what I've understood, this should theoretically be possible, since R600 GPUs support compute shaders.

    Heck, someone has been writing a Vulkan driver for the VC4 GPU in the older Raspberry Pis (everything before the Pi 4), and that GPU doesn't even support OpenGL 3! So if even that can be done, then surely it could be done for the R600 generation of graphics cards as well.

    Of course, as such older graphics cards get older and less used, there are also less volunteers out there (let alone sufficiently skilled and patient ones) to maintain graphics drivers for them. However, It would still be fun to see what these old beasts are capable of, with well-optimized modern open source drivers.

    Comment


    • #22
      Originally posted by SteamPunker View Post

      Yeah, I've been wondering about that as well. It's a shame that most R600 cards (with exception of the few ones that supported FP64 in hardware) never were able to advertise OpenGL 4+ support. Looking at mesamatrix.net, FP64 softfloats support is the only thing keeping all R600-based graphics cards from fully supporting OpenGL 4.5 in Linux!
      That will come with the NIR backend being discussed in this article. I'm not sure if it's currently enabled, but I know Gert was testing it at one point. No one is adding it to the old backend.

      The other thing holding back 4.4+ support is that Khronos added additional testing requirements and the r600 driver in it's current form is unlikely to pass the certification tests. I don't know if the NIR driver backend will ever get there either, so 4.3 may be the most you can legitimately hope for out of the box. I don't know what Gert's plans are for that. If you don't care about the default, you can set a couple environment variables and it will claim support for everything - that shouldn't be a problem since no games end up actually using fp64.

      Also, it would be cool if someone with the necessary knowledge and interest would take a stab at the development of a Vulkan driver for R600 graphics cards. From what I've understood, this should theoretically be possible, since R600 GPUs support compute shaders.
      I think the main limitation there is actually the ability to have virtual memory addressing, not compute shaders. That's something that was only first introduced in the 6900 cards. It's pretty unlikely anyone will add a vulkan driver just for the couple of Cayman cards.

      Although it's not clear to me if that's a hard blocker, or just an annoyance that would have to be worked around.
      Last edited by smitty3268; 07-21-2020, 07:11 PM.

      Comment


      • #23
        Originally posted by smitty3268 View Post
        I think the main limitation there is actually the ability to have virtual memory addressing, not compute shaders. That's something that was only first introduced in the 6900 cards. It's pretty unlikely anyone will add a vulkan driver just for the couple of Cayman cards.

        Although it's not clear to me if that's a hard blocker, or just an annoyance that would have to be worked around.
        There are 3 major challenges to supporting vulkan on pre-GCN hardware:
        1. Lack of virtual memory support
        2. Lack of memory based resource descriptors
        3. Lack of asynchronous compute queues

        Comment


        • #24
          Originally posted by agd5f View Post

          There are 3 major challenges to supporting vulkan on pre-GCN hardware:
          1. Lack of virtual memory support
          2. Lack of memory based resource descriptors
          3. Lack of asynchronous compute queues
          Could those be worked around? Or avoided, by implementing only a subset of Vulkan (enough of it to be usable in at least some games, as well as GNOME and Firefox Webrender and such)?

          How was this handled when Vulkan support was implemented for the Intel integrated graphics in Ivy Bridge CPUs? You still see a warning on the console about Vulkan support being incomplete in that implementation, but it's not clear exactly what's missing from the spec and how it affects real-world compatibility with many games and other software.

          And how about the VC4 GPU in the older Raspberry Pis? Those are even more primitive than the AMD TeraScale era GPUs, yet someone is working on a Vulkan driver even for that.

          Comment


          • #25
            Originally posted by SteamPunker View Post
            Could those be worked around? Or avoided, by implementing only a subset of Vulkan (enough of it to be usable in at least some games, as well as GNOME and Firefox Webrender and such)?
            Sure, it just makes it harder.

            Comment


            • #26
              Originally posted by agd5f View Post

              Sure, it just makes it harder.
              "So you're telling me there's a chance? Yeah!" (from the movie Dumb and Dumber)

              Comment

              Working...
              X