I seem to remember a discussion about this a long time ago, but I can’t find it. I have a very poor recollection of how this all works, and haven’t touched OpenGL in a year.
There is no way to avoid the driver keeping a copy of resources in system memory, right?
Given a hypothetical 512MB card with all memory used (textures, FBOs, VBs)
Does a process incur a 512MB cost in system memory?
Does the process have to use an additional 512MB to address the video memory?
The OS already reserves some 512MB of address space to address video memory, right?
Depends upon the driver. My guess is in almost all cases yup.
only if the driver lets you directly access VRAM. This can cause resources to be LOCKED in VRAM so most of the time they will keep you from accessing VRAM directly. I believe most drivers will probably only let the kernel have VRAM mapped into its address space.
It depends upon a few things:
i) How much VRAM is physically accessible by the CPU.
ii) How much address space the kernel can actually allocate to VRAM. XP only has 1GB of address space for the kernel so it has to be frugal.
iii) What NEEDS to be CPU accessible in VRAM.
You will need space for the GART table and the display memory and maybe some area for commands/data to send to the GPU but overall, not very much will be mapped into the kernel at any one point in time.
I would not think so as sometimes it is better to have the CPU updating objects when it can so that the GPU does not get too bogged down. Updating portions of buffers should be done on the CPU if the object is not being referenced by the GPU and requires no synchronization. There are plenty of other cases where it may be preferable to have the memory in your address space to make CPU optimizations faster.
The backing stores will at least exist in system memory. Some drivers may not have them in your address space, but that does not mean they do not exist.
The backing stores will at least exist in system memory. Some drivers may not have them in your address space, but that does not mean they do not exist.
DX allows allocation of buffers which are not explicitly backed by the system memory although they might be allocated in the AGP accessible memory instead of the video memory if the driver decides so. Because they are not backed by system memory, theirs content might become lost in some situations and the application needs to recreate them explicitly if that happens.
I have always wondered about FBOs… if they are not backed up, then they may be lost? So the logic dictates that they are backed up, still, I don’t imagine how this can be done effetively.
I’d expect (and this is a complete guess, BTW) that modern drivers only backup what they have to - if something needs to be swapped out, it will be backed up to system RAM. Keeping a backup of everything is unnecessary, since the driver knows what’s going to be swapped out.
PCI express allows two-way communication, so the driver can backup one region of VRAM at the same time it’s writing another, so the performance impact of the backup-as-needed method should be minimal.
FBOs are just specific mips/faces/slices of a texture(s). They add almost no more complexity to the paging path of a driver than anything else. If a texture has a TexSubImage operation or CopyTexSubImage performed, they are going to somehow mark the vram copy as more up to date than the system memory copy. The same holds for FBOs. The driver will flag the specific mip/face/slice as more up to date in vram than system memory when it is bound as a FBO attachment. The granularity of this book keeping is dependent upon the driver, i.e. do they mark individual slices of a 3d texture as dirty or the entire mip level. Later on the driver detects that it needs to evict this texture from vram to make room for something else. A routine will check whether any part of the vram copy is more up to date than the system memory copy. If so, the backing store is mapped into GART and a blt or transfer is queued up to copy the vram version back to the system memory copy. Now both vram and system memory are the same so the vram can be deallocated without any data being lost.
So every frame when you update a FBO, it will download the texture to RAM. It would be nice to turn off this feature and see what performance I can gain.
That could explain why a program I wrote a year ago only worked when I re-specified the attachments after every FBO bind. It seemed to occasionally “forget” what was bound to it. Not always, but enough.