EXT_pixel_buffer_object

[snakeloco]

Hi.
I am beggining to experiment the EXT_pixel_buffer_object extension in one of my projects.
My application performs a series of CPU memory manipulation followed by glDrawPixels commands.
The pseudo code is similar to one of the examples provided in the extension docs found in SGI extension registry:

void *pboMemory, *drawdata;

int N = number of drawpixels() operations per frame
int screensize = W*H*3*N // RGB, enough space for all the drawpixel buffers.

// create and bind buffer object
GenBuffers(1, &mybuffer);
BindBuffer(PIXEL_UNPACK_BUFFER_EXT, mybuffer);
BufferData(PIXEL_UNPACK_BUFFER_EXT, screensize, NULL, DYNAMIC_DRAW);

drawdata = getNextData();

while (drawdata) {
// map the texture image buffer
pboMemory = MapBuffer(PIXEL_UNPACK_BUFFER_EXT, WRITE_ONLY);
pboOffset = GetOffset(drawdata); // one offset per draw data

// modify (sub-)buffer data (performing a CPU operation here)
memcpy(pboMemory+pboOffset, drawdata, W*H*3);

// unmap the texture image buffer
if (!UnmapBuffer(PIXEL_UNPACK_BUFFER_EXT)) {
// Handle error case
}

// draw pixels
glDrawPixels(w,h,GL_BGR_EXT,GL_UNSIGNED_BYTE,pboOf fset);

drawdata = getNextData();
}

BindBuffer(PIXEL_UNPACK_BUFFER_EXT, 0);


I want to parallelize the CPU operation and the drawpixels by using this extension.
Following the previous discussion about the NV_pixel_data_range extension, I expect that
when i issue the glDrawPixels command, it immediately returns, starting some kind of fast transfer to the graphics card asynchronously, with me on the application side ensuring that the mapped memory will not be changed while the transfer occurs.

What is actually happening is that the glDrawPixels operation is taking very long, hurting performance instead of what I expected. Taking very long meaning gettimeofday() differences.

What am I missing here?
I am using Linux kernel 2.4.22-smp, driver 61.06.
The same behaviour happened on a Windows XP machine with the latest driver (61.13 i think)

Thank you
-- Fred