Announcement

Collapse
No announcement yet.

RadeonSI Adds Zeroing vRAM Workaround To Help Rocket League Players

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

  • RadeonSI Adds Zeroing vRAM Workaround To Help Rocket League Players

    Phoronix: RadeonSI Adds Zeroing vRAM Workaround To Help Rocket League Players

    For those annoyed by random textures appearing when launching the popular Rocket League game with the RadeonSI Gallium3D driver, a workaround has landed in Mesa 19.3-devel Git while also marked for back-porting to currently supported stable series...

    http://www.phoronix.com/scan.php?pag...et-League-vRAM

  • #2
    if some mesa dev is reading, why isnt zeroing vRAM the default behaviour?

    Comment


    • #3
      Originally posted by davidbepo View Post
      if some mesa dev is reading, why isnt zeroing vRAM the default behaviour?
      It's not required by the APIs. The driver has the send commands to the GPU to do this. That adds latency and reduces performance.

      Comment


      • #4
        So basically, on linux, I could right now write a program that allocates some vram, reads its contents, and runs it through text detection ? Wrap that into a nice daemon that runs every few seconds and send results to some server somewhere... Perhaps not passwords, but maybe credit card numbers, social security numbers and other data for identity theft ?

        So yeah, why is not zeroing the VRAM default behaviour ? Performance issue ?

        Comment


        • #5
          Originally posted by agd5f View Post

          It's not required by the APIs. The driver has the send commands to the GPU to do this. That adds latency and reduces performance.
          None of that prevents the driver from doing it anyway, if it's determined to be a better default.

          Yes, it's potentially a negative performance impact, but the proprietary drivers from both AMD and NVidia appear to be doing it without any problems.

          Vulkan is a low-level API that expects users to tell it what to do, so if Mesa devs really cared about allowing apps to access memory without zeroing it out, they could add an extension apps could use to enforce that behavior and still make the default safe.

          I'd argue the same mistake is being made in the OpenGL drivers with the allow_glsl_extension_directive_midshader option, with even less reason for breaking compatibility with what devs expect.
          Last edited by smitty3268; 10-08-2019, 09:31 PM.

          Comment


          • #6
            Originally posted by agd5f View Post

            It's not required by the APIs. The driver has the send commands to the GPU to do this. That adds latency and reduces performance.
            I am curious to know (and understand) how much of a performance impact is it? Is it not a once off cost paid upfront when launching the game? or is it per allocation? object upload?

            Comment


            • #7
              Originally posted by boxie View Post

              I am curious to know (and understand) how much of a performance impact is it? Is it not a once off cost paid upfront when launching the game? or is it per allocation? object upload?
              If you want something zero'd, you do it manually per spec. The driver zeros everything now, against spec, and every call. It's not a huge performance hit really, but it's spec to do it yourself, and the game breaks spec and this is all shitty to even have to look into.

              Mesa shouldn't have to fix this. They also don't want to, as it hurts performance and can break stuff later. But they do to make sure it works better now, so it's whatever. Good it works, bad any of this is required.

              Comment


              • #8
                Originally posted by abott View Post

                If you want something zero'd, you do it manually per spec. The driver zeros everything now, against spec, and every call. It's not a huge performance hit really, but it's spec to do it yourself, and the game breaks spec and this is all shitty to even have to look into.

                Mesa shouldn't have to fix this. They also don't want to, as it hurts performance and can break stuff later. But they do to make sure it works better now, so it's whatever. Good it works, bad any of this is required.
                I understand that this is one of those "A plan never survives contact with implementation" things, just wanting to know what the perf impact is.

                Comment


                • #9
                  Could this feature be extended into other areas as well?
                  I notice this oftentimes when I start new browser windows or applications, junk in the vram from previously running windows appear momentarily before being redrawn on sway, but I don't know how much influence the GPU driver has there.

                  Comment


                  • #10
                    I see this crippled output from previous applications whenever I start games with XWayland...

                    Shouldn't this be fixed too?

                    Comment

                    Working...
                    X