Announcement

Collapse
No announcement yet.

NVIDIA, Red Hat Partner Up For New Graphics Project

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

  • #11
    Originally posted by robclark View Post
    Well, as I understand it, maybe calling it a hw solution vs sw solution is a bit of a misnomer.. as they both require some hw and some sw to make it work. So maybe the AMD solution is the *more* hw solution.

    At any rate, the patchset that Jerome is working on is intended to provide what would be needed for both AMD and NV.
    Hmm, I was a bit uncertain about that do thanks for your insights.
    BTW, did you ever receive my pm?

    Comment


    • #12
      Can someone explain to me how this whole "no copy" thing even works? I mean for the GPU to operate on data, it has to be resident in VRAM right?
      How can you circumvent a copy if this RAM -> VRAM transfer is still there? Does the GPU read directly from RAM?

      Comment


      • #13
        Originally posted by Ancurio View Post
        Can someone explain to me how this whole "no copy" thing even works? I mean for the GPU to operate on data, it has to be resident in VRAM right?
        How can you circumvent a copy if this RAM -> VRAM transfer is still there? Does the GPU read directly from RAM?
        Yes, the GPU can read the CPU address space.

        Comment


        • #14
          Originally posted by MPF View Post
          Yes, the GPU can read the CPU address space.
          So, basically, we don't need glTexImage anymore?

          Comment


          • #15
            Originally posted by Ancurio View Post
            So, basically, we don't need glTexImage anymore?
            well, the gpu is still not synchronous, but the symantics of glTexImage are synchronous. So you either need a copy there, or some GL extension that lets the driver hold on to those pages until some time after.

            Also, frequently drivers will convert the texture into some internal tiled format for better memory access efficiency. Which at least makes sense if you are going to use the texture multiple times.

            Comment


            • #16
              Originally posted by robclark View Post
              well, the gpu is still not synchronous, but the symantics of glTexImage are synchronous. So you either need a copy there, or some GL extension that lets the driver hold on to those pages until some time after.

              Also, frequently drivers will convert the texture into some internal tiled format for better memory access efficiency. Which at least makes sense if you are going to use the texture multiple times.
              Huh.. that's a bit of a shock to be honest. I was always under the impression that such memory had to be uploaded into VRAM (via memcpy'ing into mapped memory regions I presumed) to be accessible to the GPU. Or am I misunderstanding something?

              Comment


              • #17
                Originally posted by Ancurio View Post
                Huh.. that's a bit of a shock to be honest. I was always under the impression that such memory had to be uploaded into VRAM (via memcpy'ing into mapped memory regions I presumed) to be accessible to the GPU. Or am I misunderstanding something?
                operating from VRAM is much faster for a gpu than operating from system ram.. so for one time use, it might be more overhead to transfer from system memory to video memory, but if you know you are going to use that data multiple times, you probably want it in VRAM.

                Jerome's proposal should actually make it possible to migrate pages to VRAM (and then migrate back to system memory on CPU page fault from accessing pages that were previously migrated to VRAM). Obviously you don't want a lot of thrashing because moving things back and forth between system memory and video memory can defeat the advantages of operating from video memory.

                Comment


                • #18
                  Originally posted by robclark View Post
                  operating from VRAM is much faster for a gpu than operating from system ram.. so for one time use, it might be more overhead to transfer from system memory to video memory, but if you know you are going to use that data multiple times, you probably want it in VRAM.

                  Jerome's proposal should actually make it possible to migrate pages to VRAM (and then migrate back to system memory on CPU page fault from accessing pages that were previously migrated to VRAM). Obviously you don't want a lot of thrashing because moving things back and forth between system memory and video memory can defeat the advantages of operating from video memory.
                  Ah, I see, it's no black and white situation with memory access. This makes sense. Thanks for the explanation!

                  Comment

                  Working...
                  X