Announcement

Collapse
No announcement yet.

AMD Mesa Stack Getting Runtime Linker For Better LLVM Integration

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

  • AMD Mesa Stack Getting Runtime Linker For Better LLVM Integration

    Phoronix: AMD Mesa Stack Getting Runtime Linker For Better LLVM Integration

    Longtime Mesa developer Nicolai Hähnle of AMD has sent out a big patch series today introducing a real runtime linker for the RadeonSI Gallium3D driver and hopefully to be used by the RADV Vulkan driver as well...

    http://www.phoronix.com/scan.php?pag...Runtime-Linker

  • #2
    nhaehnle what are the expected benefits of using a more "standard" ELF format in the driver/LLVM? Less bugs? Less VRAM consumption? Better debugability?

    Comment


    • #3
      One of the benefits is that sometimes shaders contain tables of constant data, which Mesa currently places into uniform buffers causing overhead elsewhere in the driver. Putting them into .rodata will be more efficient.

      This patch series doesn't do that, but it lays the necessary groundwork.

      Comment


      • #4
        nhaehnle another question, AFAIU, it is something related exclusively at how AMD's drivers utilizes the LLVM, does any other driver do what you are changing RadeonSI/RADV to do?

        Comment


        • #5
          Other drivers could do similar things, but we're the only ones using ELF in this way.

          Comment


          • #6
            Originally posted by nhaehnle View Post
            Other drivers could do similar things, but we're the only ones using ELF in this way.
            For what I understood, this will try relocation's, and doing so will turn the code to be linked at runtime, like a shared Object,
            So this will use a internal Dynamic Linker, instead of calling the Operating System Dynamic Linker?
            All code generated will be of type 'ET_DYN'

            Does this code be in compliance with a security feature ASLR( Address Space Layout Randomisation ), for what it seems to me?
            Last edited by tuxd3v; 05-03-2019, 04:05 PM. Reason: Update..

            Comment


            • #7
              Originally posted by nhaehnle View Post
              One of the benefits is that sometimes shaders contain tables of constant data, which Mesa currently places into uniform buffers causing overhead elsewhere in the driver. Putting them into .rodata will be more efficient.
              Why would it be more efficient ? Should it be equivalent ? In both cases you have to access memory...

              Comment


              • #8
                If the tables are in a uniform buffer, the driver (well, state tracker) ends up spending time to copy the data around every time a uniform changes.

                Comment


                • #9
                  Could be that you can share this relocated code in another shaders?
                  In that way will then be used less memory?
                  I am sorry for the questions, only trying to figure out, this, but it seems a good idea

                  Comment


                  • #10
                    Originally posted by nhaehnle View Post
                    If the tables are in a uniform buffer, the driver (well, state tracker) ends up spending time to copy the data around every time a uniform changes.
                    It could be two uniform buffers, the constant ones, and the non-constant ones... Seem to me pretty equivalent to what is going to end up with the rodata, except the data will end up being stored next to the shader instead of an alternative buffer which could be reused if changing a small part of the shader (like is done currently with non-mono shaders).

                    But maybe I misunderstood something ?
                    Last edited by mannerov; 05-03-2019, 05:54 PM.

                    Comment

                    Working...
                    X