PBO

Is there any docs about GL_EXT_pixel_buffer_object?
I really need this…

yooyo

I had a cursory search for docs when I noticed the extension after installing the latest dets. Nothing on the sgi extension registry and I couldn’t find it in the in the 1.5 spec pdf. I think its mentioned briefly in some Nvidia presentations but haven’t been able to find the spec for it.

NVidia guys are debugging some issues, and it should be released officially within “few months” they say …
Maybe we’ll have some overview in the registerd developer section …

SeskaPeel.

Originally posted by paulc:
I had a cursory search for docs when I noticed the extension after installing the latest dets. Nothing on the sgi extension registry and I couldn’t find it in the in the 1.5 spec pdf. I think its mentioned briefly in some Nvidia presentations but haven’t been able to find the spec for it.
All I need is few #define directives… The rest of job sholud be same as in VBO.

yooyo

Just in case you didn’t noticed, Case Everitt mentions PBO in its Opengl 2.0 presentation at GDC 2004 (see page 11 of OpenGL2.pdf, at Nvidia GDC 2004 presentations )

He says :

"PBO uses same API [as VBO], but has binding points for

  • PIXEL_PACK_BUFFER
    > glRealPixels(), glGetTexImage(),etc.
  • PIXEL_UNPACK_BUFFER
    > glTexImage*(), glDrawPixels(), etc. "
    Is this enough (with the latest dets) to use the extension ?

Maybe we will know more after the official NV40 launch (April 13th) …

I got it… I have made a simple app that call glBindBufferARB using all possible params and check gl error after each call. I have found values for
GL_PIXEL_PACK_BUFFER and GL_PIXEL_UNPACK_BUFFER.

Extension work right now. I’ll have to do some more tests, because there is no any doc’s, but I suppose it very similar as VBO.

  
#define GL_PIXEL_PACK_BUFFER_EXT     0x88EB
#define GL_PIXEL_UNPACK_BUFFER_EXT   0x88EC 

yooyo

Great !
Let us know if you got it right !

Wow, word travels fast. :slight_smile:

Originally posted by cass:
Wow, word travels fast. :slight_smile:
Cass? Cass Everitt? nVidia?

@cass: Why is it a GL_EXT_* extension and not a GL_ARB_* extension?

@cass: Im trying to do streaming video in OpenGL.
Can PDR/PBO helps me? Any clue?

yooyo

Originally posted by cass:
Wow, word travels fast. :slight_smile:
Nowadays, it’s good to have entry points with hardware vendors. Still, ATi is clearly missing something about this, whereas NVidia leads the way. Yet, they are (NVidia) still looking for a way to do this correctly, but a big thumbs up for great intention.

PBO provides a simple (hardware accelerated yet ?) way to map / unmap texture buffers for several tasks, as dynamic loading, but not for render to texture. We’ll still have to wait for superbuffers or whatever names can be given to it.

SeskaPeel.

Why do we need two different targets GL_PIXEL_{PACK|UNPACK}BUFFER_EXT?
Wouldn’t one target GL_PIXEL_BUFFER_OBJECT
{EXT|ARB} be enough?
I think, GL_{STREAM|DYNAMIC|STATIC}_{DRAW|COPY|READ}ARB are enough to differentiate between the different usage patterns.
For now, we can only use GL
{STREAM|DYNAMIC|STATIC}_DRAW_ARB with GL_VERTEX_BUFFER_OBJECT_ARB, and GL_STATIC_READ_ARB for GL_PIXEL_PACK_EXT, and GL_STATIC_DRAW_ARB for GL_PIXEL_UNPACK_EXT, right?
Wouldn’t it then be better to use GL_VERTEX_BUFFER_STREAM_ARB, GL_VERTEX_BUFFER_DYNAMIC_ARB, GL_VERTEX_BUFFER_STATIC_ARB, GL_PIXEL_BUFFER_PACK_ARB, and GL_PIXEL_BUFFER_UNPACK_ARB, and forget about the usage pattern hint?

Originally posted by Hampel:
Why do we need two different targets GL_PIXEL_{PACK|UNPACK}BUFFER_EXT?
Wouldn’t one target GL_PIXEL_BUFFER_OBJECT
{EXT|ARB} be enough?
I think, GL_{STREAM|DYNAMIC|STATIC}_{DRAW|COPY|READ}_ARB are enough to differentiate between the different usage patterns.

Read the NV_pixel_data_range spec. Read is assumed to be slow while write is not. So there are two buffers that are stored and then they can be synced whenever required.

Originally posted by yooyo:
[quote]Originally posted by cass:
Wow, word travels fast. :slight_smile:
Cass? Cass Everitt? nVidia?
[/QUOTE]Yep.

Originally posted by Hampel:
Why do we need two different targets GL_PIXEL_{PACK|UNPACK}BUFFER_EXT?
Wouldn’t one target GL_PIXEL_BUFFER_OBJECT
{EXT|ARB} be enough?

One target would have been enough, but two helps indicate that these are fundamentally different operations, often with different memory type requirements.

This is a nearly final version of the spec, though the list of contributors should now include Bill Licea-Kane and Brian Paul.

http://www.r3.nu/~cass/opengl/ext/GL_EXT_pixel_buffer_object.txt

Don’t rely on this link being up-to-date in the future, but it should be enough to get you started…

Hope this helps.

Cass

10x cass
That’s exactly I need!

yooyo

Thanks a lot Cass.

I like specs with examples !!

Originally posted by cass:
[b]This is a nearly final version of the spec, though the list of contributors should now include Bill Licea-Kane and Brian Paul.

http://www.r3.nu/~cass/opengl/ext/GL_EXT_pixel_buffer_object.txt
Hope this helps.

Cass[/b]
Example with streaming textures doesn’t work properly. I have made a simple app that each frame upload one texture using code in your example. Sometimes there is a some glitches in texture. glMapBuffer always returns same pointer to PBO memory but previous glTexSubImage2D call didn’t yet finished it’s job. Result is overlapped texture data. Should glMapBuffer return another piece of safe AGP memory if previous operation are still in progress?

yooyo