Announcement

Collapse
No announcement yet.

RADV Driver Switches To 100% Dynamic Rendering

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

  • RADV Driver Switches To 100% Dynamic Rendering

    Phoronix: RADV Driver Switches To 100% Dynamic Rendering

    Last month I wrote about the work being done by Jason Ekstrand for switching RADV completely over to dynamic rendering. That work has now panned out and as of a few minutes ago the transition to "100%" dynamic rendering for RADV has landed in Mesa 22.3...

    https://www.phoronix.com/news/RADV-1...amic-Rendering

  • #2
    What does this mean for RADV users?

    Comment


    • #3
      Originally posted by tachi View Post
      What does this mean for RADV users?
      Nothing, it means for those who want to write more simple Vulkan code.
      Vulkan from the start was way too meticulous and verbose and it cared more about graphics drivers developers rather than software devs who would write Vulkan code. As years go by part of this problem is being rectified.

      For example:
      The naming in Vulkan should be geared towards users of Vulkan rather than creators of graphics drivers, e.g.
      colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
      colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE;

      should rather be named like:
      colorAttachment.beforeRendering = VK_CLEAR_ATTACHMENT_DATA;
      colorAttachment.afterRendering = VK_KEEP_ATTACHMENT_DATA;
      Last edited by cl333r; 09 September 2022, 08:54 AM.

      Comment


      • #4
        So what is dynamic rendering? What is it good for? This is not explained by the article.

        Comment


        • #5
          Dynamic rendering, in this case, means that you don't need to construct render pass objects to do rendering. The information that would normally go in VkRenderPass and VkFramebuffer is now recorded at command buffer recording time.

          As for the driver making this change: my understanding about AMD devices supported by RADV, is that none of them are tiled renderers, so in their case any infrastructure around first class render passes is basically wasted. When they say "100% dynamic rendering" I think they mean they are replacing first-class VkRenderPass and VkFramebuffer with emulators: compatible, but inside they have no special purpose.

          My understanding is that VkRenderPass and VkFramebuffer may still be useful on tiled architectures, but they are essentially pointless on non-tiled ones.
          Last edited by microcode; 09 September 2022, 09:23 AM.

          Comment


          • #6
            Also relevant in the context is how fast dynamic rendering actually is: https://www.supergoodcode.com/sp33d2/

            Comment


            • #7
              Originally posted by microcode View Post
              is that none of them are tiled renderers, so in their case any infrastructure around first class render passes is basically wasted.
              They say all modern GPUs are tiled. AMD starting from Vega.

              Comment


              • #8
                Originally posted by mcloud View Post
                Also relevant in the context is how fast dynamic rendering actually is: https://www.supergoodcode.com/sp33d2/
                Do note though that this is not the same thing:

                Mr. Blumenkrantz is writing about VK_EXT_vertex_input_dynamic_state, whereas this change here is about VK_KHR_dynamic_rendering.

                Comment


                • #9
                  Michael

                  Grammar

                  "frustrated in the render pass interface" should probably be "frustrated with the render pass interface"

                  "this move is about restructuring the driver to a dynamic rendering model in full". As written, it's unclear what is meant. Perhaps "this move is about restructuring the driver to a completely dynamic rendering model".

                  Comment


                  • #10
                    Originally posted by cl333r View Post
                    Nothing, it means for those who want to write more simple Vulkan code.
                    Vulkan from the start was way too meticulous and verbose and it cared more about graphics drivers developers rather than software devs who would write Vulkan code. As years go by part of this problem is being rectified.

                    For example:
                    The naming in Vulkan should be geared towards users of Vulkan rather than creators of graphics drivers, e.g.
                    colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
                    colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE;

                    should rather be named like:
                    colorAttachment.beforeRendering = VK_CLEAR_ATTACHMENT_DATA;
                    colorAttachment.afterRendering = VK_KEEP_ATTACHMENT_DATA;
                    I get what you mean, but IMHO good naming is to name stuff after what it does and not after how it is typically used. In assembly language a Load operation is not called "GetDataBeforeCalculation" and Store is not called "SaveDataAfterCalculation".

                    Also the constants seem to be named pretty consistently with scoping/applicability in mind and with Most Significant First order (e.g. CLEAR which is applicable for the LOAD_OP for ATTACHMENTs in VK). In your example the applicability of the constants is not obvious and they could easier be used in the wrong place. (This would of course be a non-issue in a language with stronger typing...).

                    To me it seems the Vulkan designers did a good job. But we can of course all argue about the color of the bike shed

                    Comment

                    Working...
                    X