[英]OpenGL PBO for texture upload, can't understand one thing
Okay , I read everything about PBO here : http://www.opengl.org/wiki/Pixel_Buffer_Object and there http://www.songho.ca/opengl/gl_pbo.html , but I still have a question and I don't know if I'll get any benefit out of a PBO in my case : 好的,我在这里阅读了有关PBO的所有内容: http : //www.opengl.org/wiki/Pixel_Buffer_Object ,还有http://www.songho.ca/opengl/gl_pbo.html ,但我还有一个问题,我不知道我知道在我的情况下,我是否会从公益组织中获得任何好处:
I'm doing video-streaming,currently I have a function copying my data buffers to 3 different textures, and then I'm doing some maths in a fragment shader and I display the texture. 我正在做视频流,目前我有一个函数将我的数据缓冲区复制到3个不同的纹理,然后我在片段着色器中做一些数学运算并显示纹理。
I thought PBO could increase the upload time CPU -> GPU, but here it is, let's say we have this example here taken from the second link above. 我认为PBO可以增加上传时间CPU - > GPU,但是这里就是说,我们这里的例子来自上面的第二个链接。
glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, pboIds[nextIndex]);
// map the buffer object into client's memory
// Note that glMapBufferARB() causes sync issue.
// If GPU is working with this buffer, glMapBufferARB() will wait(stall)
// for GPU to finish its job. To avoid waiting (stall), you can call
// first glBufferDataARB() with NULL pointer before glMapBufferARB().
// If you do that, the previous data in PBO will be discarded and
// glMapBufferARB() returns a new allocated pointer immediately
// even if GPU is still working with the previous data.
glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, DATA_SIZE, 0, GL_STREAM_DRAW_ARB);
GLubyte* ptr = (GLubyte*)glMapBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, GL_WRITE_ONLY_ARB);
if(ptr)
{
// update data directly on the mapped buffer
updatePixels(ptr, DATA_SIZE);
glUnmapBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB); // release pointer to mapping buffer
}
// measure the time modifying the mapped buffer
t1.stop();
updateTime = t1.getElapsedTimeInMilliSec();
///////////////////////////////////////////////////
// it is good idea to release PBOs with ID 0 after use.
// Once bound with 0, all pixel operations behave normal ways.
glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, 0);
Well, whatever is the behavior of the updatePixels
function , it is still using CPU cycles to copy the data to the mapped buffer isn't it? 那么,无论
updatePixels
函数的行为是什么,它仍然使用CPU周期将数据复制到映射缓冲区不是吗?
So let's say I wanted to use PBO in such a manner, that is, to update my frame pixels to the PBO in a function , and then in the display
function to call glTexSubImage2D (which should return immediately)... Would I see any speed-up in term of performance? 所以我想说我想以这种方式使用PBO,也就是说,在一个函数中将我的帧像素更新为PBO,然后在
display
函数中调用glTexSubImage2D(应该立即返回)...我会看到任何在性能方面加速? I can't see why it would be faster... okay we're not waiting anymore during the glTex* call, but we're waiting during the function that uploads the frame to the PBO, aren't we? 我不明白为什么它会更快......好吧我们在glTex *调用期间不再等待了,但我们正在等待将帧上传到PBO的功能,不是吗?
Could someone clear that out for me please? 有人可以帮我清楚吗?
Thanks 谢谢
The point about Buffer Objects is, that they can be use asynchronously. 关于缓冲区对象的观点是,它们可以异步使用。 You can map a BO and then have some other part of the program update it (think threads, think asynchronous IO) while you can keep issuing OpenGL commands.
你可以映射一个BO,然后让程序的其他部分更新它(想想线程,想想异步IO),同时你可以继续发出OpenGL命令。 A typical usage scenario with triple buffered PBOs may look like this:
具有三重缓冲PBO的典型使用方案可能如下所示:
wait_for_video_frame_load_complete(buffer[k-2])
glUnmapBuffer buffer[k-2]
glTexSubImage2D from buffer[k-2]
buffer[k] = glMapBuffer
start_load_next_video_frame(buffer[k]);
draw_texture
SwapBuffers
This allows your program to do usefull work and even upload data to OpenGL while its also used for rendering 这允许您的程序执行有用的工作,甚至将数据上传到OpenGL,同时它也用于渲染
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.