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

  • mannerov
    replied
    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.

    Leave a comment:


  • tuxd3v
    replied
    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

    Leave a comment:


  • nhaehnle
    replied
    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.

    Leave a comment:


  • mannerov
    replied
    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...

    Leave a comment:


  • tuxd3v
    replied
    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..

    Leave a comment:


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

    Leave a comment:


  • andrei_me
    replied
    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?

    Leave a comment:


  • nhaehnle
    replied
    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.

    Leave a comment:


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

    Leave a comment:

Working...
X