1
\$\begingroup\$

I'm wondering if whether it's a good idea or not to keep a copy of vertex data in the main memory or just read it back via glGetBufferSubData (or glMapBuffer/glMapBufferRange).

The reason why I'd do this is so that I can keep only what's needed in the VRAM (and resource which may be needed very soon in the main memory) but not have to go back and load the resource from the disk again.

The concern that I have is that, with the draw optimized flags (GL_XXXX_DRAW) is that they aren't optimized for reading back (since there's a seperate flag for that). So if it's not very fast, it kinda defeats the whole purpose.

The other option is storing a second copy and just delete the VBO when I'm done (no reading it back), but I dislike this because it requires more memory usage than might be necessary.

Which option is preferred? Is there another way? Maybe something I'm missing?

\$\endgroup\$
2
\$\begingroup\$

VRAM management is between the GPU and the GPU driver. The driver could do a few things, it could throw an error when it doesn't have VRAM to do an operation, or it might just start streaming from the system RAM (avoiding the main issue, and possible game crashes.)

Streaming from the system RAM is the more likely solution, however communication between the GPU and CPU can be extremely slow in the context of a game environment.

Because of that communication cost, for performances sake, you should also avoid reading data from the GPU (or wherever else the GPU driver has it) if possible. That would mean keeping a copy of critical data locally, and deleting the GPU side of the data as needed. So, yes, it is a good idea to keep copies of the data locally.

The problem with that, is that you could start running into issues with not having enough system RAM. However, that can be avoided with temporary files. If you create a "raw data dump", type of file, you can parse your game files, and then literally just store little used data straight into a disk file.

As a temporary raw data file, you don't need to parse it again. However, possibly machine specific (I'm thinking specifically of architecture endianness here.)

Disclaimer: All of this is assuming VRAM is an issue. If it's not giving you a problem, don't fix it. If your worried about the consumer market, calculate out how much VRAM your application is using, decide what your "Minimum requirements" are, then fix the issue if present.

\$\endgroup\$
0
\$\begingroup\$

the openGL driver will unload stuff from vram on its own as needed (most of the time).

And if you are ready to remove the mesh from vram then you should be sure you are not going to needed it for a minute. When reloading it you might as well read it back from disk.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.