6 replies to this topic

[Lil_Lloyd]

Hello again true believers. 

 

I have possibly a very simple question. When I generate vertices for a heightmap, for example, then copy the vertices to the video memory using glBufferData() I usually delete the copy of the original vertex data afterwards, e.g

 

//psuedo code!

generate vertex data

copy to video memory using glBufferData

delete [] vertex data

 

However, if I wanted to access specific locations in the video memory buffer to access a vertex on the host/cpu side, is this possible? Or will I need to keep the vertex data around in host memory on the cpu side? Of course this brings up questions regarding performance - there will be a long delay reading from video memory or is this around the same delay as a normal cpu cache miss anyway?

 

This question extends to accessing normal data, texture coord data or anything else you feel fit to store on the video memory.

[RobTheBloke]

glMapBuffer.

 

 

For lots of random access, it's going to be much slower than a local copy. For occasional access of specific chunks (rather than individual verts), it *may* be acceptable, but that depends on your needs.

[irreversible]

You can speed things up considerably by using asynchronous access if you don't need to get things done in the same frame.

[Lil_Lloyd]

Good starting points for some research, thanks both of you! 

[larspensjo]

The fact that you need access to this data implies that you will use it for something. Maybe you already considered the possibility to use a shader to do the computing?

 

Shaders doesn't have to produce graphical results only.

[Lil_Lloyd]

That's a good point larpensjo, coincidentally this evening I have started to render a terrain via heightmap using a texture look up in a shader as opposed to writing the y co ordinate values to a vertex buffer. Thusly, I am able to use the same heightmap to look up where an object should be placed. 

[mhagain]

If you read back from a buffer object what is going to kill you will not be bandwidth, it will not be volume of data read back, it will be CPU/GPU synchronization.  Because the CPU and GPU operate asynchronously, and because there may still be pending draw calls using that buffer object, it will be necessary for all pending operations to be flushed and completed before the readback can return.  This may potentially take up to 3 or so frames worth of time to complete, and will be true whether you read back one byte or 100mb.

 

IMO any requirement to read back from a GPU resource is more indicative of a design flaw than anything else.  The whole point of GPU resources is to keep data that the GPU needs to use a lot in memory that is local to the GPU, so rebuilding your design around that behaviour and thinking is essential (there are of course exceptions to this rule, such as screenshots).