Announcement

Collapse
No announcement yet.

RadeonSI ARB_sparse_buffer Lands For Mesa 17.1

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

  • RadeonSI ARB_sparse_buffer Lands For Mesa 17.1

    Phoronix: RadeonSI ARB_sparse_buffer Lands For Mesa 17.1

    AMD developer Nicolai Hähnle has landed ARB_sparse_buffer support within the RadeonSI Gallium3D driver. RadeonSI is the first Mesa/Gallium3D driver supporting this OpenGL extension...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is there any need to have large object that is so large that the entire video memory does not fit it?
    What scenarios are this for?
    What kind of objects are this for?

    Comment


    • #3
      Originally posted by uid313 View Post
      Is there any need to have large object that is so large that the entire video memory does not fit it?
      What scenarios are this for?
      What kind of objects are this for?
      id Software's MegaTexture technology comes to my mind as an example, but I am not sure if this is an actual use case.

      Comment


      • #4
        Originally posted by uid313 View Post
        Is there any need to have large object that is so large that the entire video memory does not fit it?
        What scenarios are this for?
        What kind of objects are this for?
        Textures, it's in the name. PRT = partially resident textures.
        it's the hardware version of Carmack's megatexture.
        see here for detailed explanation:

        Comment


        • #5
          Originally posted by uid313 View Post
          Is there any need to have large object that is so large that the entire video memory does not fit it?
          What scenarios are this for?
          What kind of objects are this for?
          This is also great for GIS, satellite terrain data, UHD HDR texturing and it should help a lot frame times in some since is cheaper than streaming several textures over and over again if you have low vram etc, etc.

          Comment


          • #6
            For large textures, there is GL_ARB_sparse_texture, though.

            Comment


            • #7
              Originally posted by orome View Post
              it's the hardware version of Carmack's megatexture.
              Sparse textures are quite limited in that regard as their maximum size is (somewhat obviously) no bigger than the size of regularly allocated textures. That's 16384x16384 pixels on modern GPUs. They are much more useful for sparsly allocated subresources, i.e. texture array layers and mipmap levels.

              Comment


              • #8
                Sparse buffers are the foundation for sparse textures, and one of the AZDO techniques is to have a sparse texture array in which layers (and levels thereof) can be dynamically streamed. I.e., the basic idea is something like: if you have 1000 models, but not all of them are simultaneously used, you allocate a sparse array texture with 1000 layers, with each layer providing the skin for one model, but only the layers for models in the current scene are resident/committed.

                For sparse buffers themselves, the use case is less clear. Maybe somebody wants to do GPU raytracing with a huge voxel tree in a gigantic sparse buffer, and only the currently visible parts of the tree are committed to memory? It'd be cool to see stuff like that.

                Comment

                Working...
                X