If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
NVIDIA, Red Hat Partner Up For New Graphics Project
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?
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?
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?
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.
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?
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.
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