Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: NVIDIA, Red Hat Partner Up For New Graphics Project

  1. #11
    Join Date
    Jan 2009
    Posts
    1,478

    Default

    Quote 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?

  2. #12
    Join Date
    Aug 2011
    Posts
    558

    Default

    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?

  3. #13
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote 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.

  4. #14
    Join Date
    Aug 2011
    Posts
    558

    Default

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

  5. #15
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote 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.

  6. #16
    Join Date
    Aug 2011
    Posts
    558

    Default

    Quote 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?

  7. #17
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote 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.

  8. #18
    Join Date
    Aug 2011
    Posts
    558

    Default

    Quote 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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •