Announcement

Collapse
No announcement yet.

Mesa 21.3 RADV Vulkan Driver Lands Ray-Tracing Support For Older AMD Radeon GPUs

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

  • #11
    You gotta check if rBAR leads to actual performance gains on your specific card. I lose 3000FPS in glxgears and 2-10% in games on my Vega 56 when forcefully enabling it. IMO Mesa got sane defaults for which products to automatically enable/disable it.
    Last edited by kiffmet; 04 October 2021, 11:37 AM. Reason: clarification

    Comment


    • #12
      Originally posted by jrch2k8 View Post

      One thing have no relation to the other and may not even be done by the same developers, remember this is FOSS which means there is no central authority telling developers what goes and in what order. I mean i can come with a patch to lower the precision of raytracing calculations so my RX470 can have more RT performance at the cost of quality because that is the hardware i have and what i wanna do and it would be completely unrelated to Valve/AMD plans since all i need is Mesa to accept my patch not Valve/AMD.

      Understand now?
      Extremely well said... And hey, uh... can you share that patch?? 🤣🤣 Being serious.

      *Huge* thank you to everyone who made this happen!!

      P.S: I've been running oibaf ppa lately, and all is gravy. Give it a try.

      Comment


      • #13
        can be this add to intel drivers ?

        Comment


        • #14
          Originally posted by aufkrawall View Post
          This would probably be futile with PCIe bandwidth, as realtime RT is highly dependent on temporal data like previous frames etc.
          Well it's not like 100% of all the frame data needs to be re-transmitted per-frame. Stuff like textures and meshes would already be stored in VRAM on the secondary/RT GPU, thereby dramatically reducing the load.

          Comment


          • #15
            Originally posted by schmidtbag View Post
            Well it's not like 100% of all the frame data needs to be re-transmitted per-frame. Stuff like textures and meshes would already be stored in VRAM on the secondary/RT GPU, thereby dramatically reducing the load.
            There'll be big caveats. Also everything that wasn't on-chip has died miserably so far. Future chiplet designs will be interesting, but I suppose scalability is also more appealing here vs. asymmetric designs. And after all RT cores in RTX GPUs aren't that wasteful with space and real world RT performance is heavily impacted by general 3D denoising load.

            Comment


            • #16
              tested it on a weaker polaris card, it does indeed work , but with the rt demo I used its getting <1fps with a 512x448 window size, so needless to say, unless there are optimizations to be done, even if the card you are using is something like a vega 20, its going to be running at like <10fps best case for a very small number of pixels . probably not very useful for anything other than gpu accelerated still renders.

              Comment


              • #17
                Originally posted by Quidnam View Post
                I assume at least part of the reason AMD doesn't enable these features on the Windows side is because of driver certification requirements?
                i heard it required changes to windows

                Comment


                • #18
                  Now AMD & RT team just need to optimise the HELL out of the RT method for AMD GPU's because NVIDIA is flogging AMD in the RT department, real hard. Makes it almost impossible to believe that RDNA3 could have that much better RT support because they'd almost need to hit %1000 faster performance then how it is atm!

                  Comment

                  Working...
                  X