Announcement

Collapse
No announcement yet.

AMD Open-Sources "Addrlib" From Catalyst

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

  • #21
    Right. There are a few areas of the HW that are really complex & fiddly, and that eat a lot of developer time for each new HW generation. Sharing the addrlib code means one less thing we have to implement twice.
    Test signature

    Comment


    • #22
      Originally posted by Ericg View Post
      Alex correct me if I'm wrong, if the situation has changed, or if this isn't what i think it is, but I thought one of the disadvantages that the OSS stack had vs Catalyst was that the memory allocater and the texture allocater were not as smart as Catalyst's and therefore would run into issues with games that filled the gpu memory with textures. Is this not the catalyst texture allocater? If I am wrong then -please- correct me as I don't want to have the wrong information.

      PS: is it allocater or allocator? Firefox hates both.
      addrlib does not have anything to do with memory allocation or management or paging. It's purely for calculating the alignment requirements of buffers so the drivers can request that alignment when they allocate memory. E.g., if you are requesting memory for a 2D tiled texture with mipmaps, the base address of the mip tree needs to be 256 byte aligned at a minimum, plus a multiple of the memory channel width, plus a multiple of the tile size, plus etc., etc.. Next you need to align the stride of the buffer, and make sure the various tiling parameters are set correctly based on the size of the texture and the selected tiling format. If you don't get the alignment correct, you can get visual corruption, or GPU segfaults which may result in GPU hangs, etc.

      Comment


      • #23
        @bridgman/agd5f:

        Thanks for chipping in. Sounds like this being open sourced is pretty damn good news then.

        Does the code drop also cover pre-GCN GPU archictectures? The mention of radeon/radeonsi not using it yet suggests this to be the case? Is there any potential value to be had by porting radeon/radeonsi to use it as well at some point in the not-to-distant future?

        In one of my rigs I'm rocking an old HD4850 512MB with a custom cooler and a modified BIOS (wanted to downclock and downvolt it when in the 'low' power state) and I also have a couple of HD7970s which will likely be promoted from my Windows box to a Linux box later this year, so I'm assuming that I would benefit from it if it were to happen...

        EDIT: Ooops, missed this post:

        Originally posted by agd5f View Post
        It's only applicable to CI and VI on amdgpu at the moment. It could be extended to older asics, but we didn't want to potentially destabilize radeon while working on amdgpu.

        Comment


        • #24
          Originally posted by agd5f View Post
          addrlib does not have anything to do with memory allocation or management or paging. It's purely for calculating the alignment requirements of buffers so the drivers can request that alignment when they allocate memory. E.g., if you are requesting memory for a 2D tiled texture with mipmaps, the base address of the mip tree needs to be 256 byte aligned at a minimum, plus a multiple of the memory channel width, plus a multiple of the tile size, plus etc., etc.. Next you need to align the stride of the buffer, and make sure the various tiling parameters are set correctly based on the size of the texture and the selected tiling format. If you don't get the alignment correct, you can get visual corruption, or GPU segfaults which may result in GPU hangs, etc.
          Gotcha, okay, that makes more sense. Thanks for correcting me

          And as always: Thanks go out to you and the rest of the team for all the hard work you guys do.
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #25
            It's rare, but sometimes really good threads can happen in these forums. This was one of them.

            Comment


            • #26
              Originally posted by agd5f View Post
              It means not having to write and maintain code to deal with all of the alignment requirements directly. As an added bonus, the code is validated on other platforms as well so there is less chance for errors in alignment that can lead to GPU segfaults or hangs.
              They actually left MacOSX and Windows compiler instructions in the code, looks like minimal cleanup was done.

              Would this help with opengl 4? It does seem to have specific ways to account for the GPU and memory size and bus width.

              Comment


              • #27
                Originally posted by toyotabedzrock View Post
                Would this help with opengl 4? It does seem to have specific ways to account for the GPU and memory size and bus width.
                Not directly. As I said before, it's just for buffer alignment which is board dependent (e.g. based on the memory config for example).
                Last edited by agd5f; 21 April 2015, 08:16 PM. Reason: typo

                Comment

                Working...
                X