OpenGL 3 Updates

[V-man]

I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

[Rob Barris]

I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

V-man, what are you referring to ?

[knackered]

So that's not happening then. It was something alluded to by barthold in a thread many moons ago, when the summer days were longer and coke tasted nice.

[Korval]

Currently, there is no way to "force" a texture or VBO in VRAM and let the application do its own memory management. Some will argue that this kind of low-level control should not be exposed, but in real-time application where avoiding glitches is a must, such a scheme would provide a way to garantee a glitch-free operation. Simply hoping that the driver makes the right decision as to which object to keep in VRAM is not an option.

To be honest, I wouldn't expect anything like that. The best you could hope for is keeping the priority mechanism.

Not to mention the simple fact that I can't imagine how an application could expect that to work. I mean, the GL spec can only enforce behavior, not performance. You could have a function that says, "put this into video memory," but there's no way to tell if the driver is lying to you if it says, "OK." After all, it's your only interface to video memory, so it can lie to you on query functions too. And you can never know if a hitch in the rendering is due to paging something in or some other issue without significant diagnostics tools.

It also doesn't make sense if the Operating System virtualizes video memory (like MacOS and Vista), as the graphics driver literally has no control over what is and isn't in video memory.

This is impossible since the texture is only sent to VRAM as a whole chunk when it is first used.

Actually, you don't know that. You're assuming that, possibly with some evidence, but it may be different in the next driver version.

Ideally, a mechanism for casting a surface from says a 1MB RGBA texture to a 1MB DXT texture would be great since a bunch of them could be created during initialization and always reused.

I'm pretty sure you can forget that one. Don't even dream about it; it ain't gonna happen.

The simple fact is this: OpenGL and D3D are abstractions, not memory managers. Their job is to actively prevent you from doing those things.

[Komat]

You could have a function that says, "put this into video memory," but there's no way to tell if the driver is lying to you if it says, "OK." After all, it's your only interface to video memory, so it can lie to you on query functions too.

Yes drivers lying and optimizing to gain few fps in benchmarks is problem which the API can not directly solve. The only thing the API can do is provide strong mechanism for specifying the program intentions to the driver (e.g. This uniform is changed offten, do not optimize. Try to keep this shadowmap in the fastest memory at all costs even if I will not use it for some time.) so reasonable driver does not have to gues the intended behavior.

It also doesn't make sense if the Operating System virtualizes video memory (like MacOS and Vista), as the graphics driver literally has no control over what is and isn't in video memory.

I think that the virtualization is always done with cooperation with the driver because only the driver knows what can be safely moved to different memory. So the driver should have at least some control about what is removed.

[Komat]

Ideally, a mechanism for casting a surface from says a 1MB RGBA texture to a 1MB DXT texture would be great since a bunch of them could be created during initialization and always reused.

The reall memory size and other requirements put on the texture memory might change in unexpected (for external observer) ways between formats or texture sizes depending on what the hw requires. Even the DX10 which allows for accessing the resource using different formats is very strict and limited in what types are compatible for this purpose.

[bertgp]

I think that the virtualization is always done with cooperation with the driver because only the driver knows what can be safely moved to different memory.

I strongly disagree with this statement. Only the application, with its knowledge of how it will use resources can effectively make appropriate decisions as to what to prioritize. I do agree that there are cases where the driver, because of the underlying hardware implementation, will be more apt to choose the right behavior. However, this should not be an excuse to give absolutely no control to the application over memory usage because then the application cannot ever guarantee 100% glitch-free operation (think real-time app).

The current priority mechanism is either not really enforced or outright ignored by the driver. At the very least, can we please _enforce_ it in the spec (not just provide idiotic "hints" that the driver can ignore!!) so a higher priority texture is never kicked out of VRAM when a lower priority one is not currently used?

After all, it's your only interface to video memory, so it can lie to you on query functions too. And you can never know if a hitch in the rendering is due to paging something in or some other issue without significant diagnostics tools.

This is impossible since the texture is only sent to VRAM as a whole chunk when it is first used.

Actually, you don't know that. You're assuming that, possibly with some evidence, but it may be different in the next driver version.

Having had access to driver source from one major vendor (and one minor) and spending a few weeks investigating the other major vendor's driver, I can say with confidence that this is what happens. One way or the other, don't you agree that not being able to easily pinpoint the source of a glitch is unacceptable? Even worse, in the case of memory management, not being able to effectively remedy it? Worse still, having to redo all the investigation work from one driver version to the next?

The reall memory size and other requirements put on the texture memory might change in unexpected (for external observer) ways between formats or texture sizes depending on what the hw requires. Even the DX10 which allows for accessing the resource using different formats is very strict and limited in what types are compatible for this purpose.

You are right that a 1024x1024 texture does not have the same VRAM size depending on its format. Also, the hardware does some tiling to optimize the memory access pattern of textures which is not necessarily compatible across texture types. Straightforward "casting" of one texture surface type to another would probably not work. However, as you mentioned, some types can be safely casted into other types. This should be available.

Also, imagine a 1024x1024 texture is divided in 4 512x512 tiles and each of those is further divided down to some limit size. It would be nice to be able to take advantage of this and be able to create 4 512x512 textures from a 1024x1024 texture.

[V-man]

I just want GL3 to offer volatile textures. If the driver decides to kick the texture out of vram, then I'll decide whether to keep a copy in ram, or recreate the texture on the fly. And surely this must be a simple thing to do. Although vitualising vram may have thrown a spanner in the works...

That will be offered. This is good since the driver won't store backups in RAM.
You can also tell it to keep a backup for people who want the old GL behavior.

V-man, what are you referring to ?

Currently, drivers keep a copy of the texture in RAM do they not?
This is just in case Windows destroys your texture. The driver gets a notification from Windows, so it reuploads the texture when it gets needed.
GL3 was suppose to offer a feature where we can tell the driver to not keep copies in RAM.

Boring story ahead!
With one project of mine, I added the ability to not initialize GL because it was consuming a ridiculous amount of RAM (according to task manager). Memory usage came down to 24MB. With GL, it went above 100MB. My project was using textures, VBOs, FBOs. I did keep a copy of the textures in RAM when GL was initialized but memory usage should have been around 20MB. The extra 50MB, 60MB, 70MB was probably the GL driver.

[Mars_999]

Oh yeah, it's like X-Mas now. Siggraph is less than a month away. Let the count down begin.

[Mark Shaxted]

Basically, my requirements are for displaying thumbnails of photographs. I want to use the following strategy:-

vram: 8192 64x64 6:1 compressed thumbs (total 16mb forced into vram - ie a high priority)
vram: 256 thumbs of a given size converted into monitor colour profile (volatile)
system ram 1024 jpeg thumbs.

So, in an ideal world, I'd say if the high res thumb exists render with that. If that fails use the crappy low res version, and in the background decompress the jpg, then upload it.

However, as it stands now, all the compressed thumbs, and the hgh res version will exist in vram AND system ram. And for my type of app, memory is always a scarce commodity.

Surely, even with virtualised vram, the driver must know when a txture is about to be paged out. All I want is for the driver to say "no need, I'll just delete it", and return an error when you try to use it. Then *I* can deal with the consequences.