hi all,

in my application i use the PDR extension.
i get enourmous speedups, so i am very
happy with it.

but somehow my opengl application crashes
if i enable glEnableClientState(GL_WRITE_PIXEL_DATA_RANGE_NV)
too early.

my application is the initialization stage as this:

			// get proc adress, allocate, assert and clear mem
			wglAllocateMemoryNV = (PFNWGLALLOCATEMEMORYNVPROC)wglGetProcAddress("wglAllocateMemoryNV");
			next_mem = main_agp_mem = (char*) wglAllocateMemoryNV( agp_mem_size, 0.0, 0.1, 1.0 ); // last 0.5: agp last 1.0: vram

			memset(main_agp_mem, 0, agp_mem_size );

			// declare memory as pixel data range and enable DMA
			glPixelDataRangeNV(GL_WRITE_PIXEL_DATA_RANGE_NV, agp_mem_size, main_agp_mem);


then other init stages follow … nothing special.

but then the app crashes, interestingly in some other thread. this threads stack is

> nvoglnt.dll!6975eef5()

the app crashes somewhere inside the nvidia driver. (does the nvidia driver start an
own thread ?!)

i can avoid this crash, if i move the glEnableClientState(GL_WRITE_PIXEL_DATA_RANGE_NV) call at the beginning of my main loop.

does anyone know whats wrong or any other hint how to order the gl commands?

with the best regards,

That extension is long superseded by pixel bufferobjects.
You shouldn’t use PDR anymore in new code.
It was replaced with
Then standardized in an ARB version (use that)

i used the PBO extension before, but IMHO it does not have the same functionality.

using PDR i can unpack & upload the data in a different thread, which is very useful on multicore machines. i do not need a current valid context during this operation.

as far as i understood PBOs i cannot do this with pixel buffer objects. all commands need a valid context, and the data pointer returned bx glMapBuffer should not be passed around, stored or used in different threads… or did i miss an important point?


Originally posted by henniman:
and the data pointer returned bx glMapBuffer should not be passed around, stored or used in different threads…
Why not? You can pass the pointer to the worker thread and unmap the buffer after the thread has completed the work. I see no problems here.

finally found the quote (Using-VBOs.pdf from NVidia)

Using the technique of buffer mapping (glMapBuffer and
glUnmapBuffer): This works similar to Direct3D’s Lock and Unlock. You get
a temporary pointer as an entry to the beginning itof the buffer, meaning the
buffer is mapped in the client’s memory. OpenGL is responsible for how this
mapping into the client’s absolute memory is done. For this reason, mapping
must be done for a short operation and the pointer must not be stored for
further use.
the latter is indeed a restriction, but just to be clear: the pointer must not be stored - i am ok with that, mapping may change - but what do they mean when they are talking about a “short operation” ?? is the pointer/mapped memory volatile?

I understand it like that: if you map a buffer, make sure you do all you need as fast as possible and unmap the buffer then. This means, don’t map on the setup stage, but rather, each time you have to. The “must not be stored” just means that after unmapping, the pointer becomes invalid.

i would be very interested in when
the (DMA!) transfer will be triggered:

    pointer ptr = glMapBuffer(...);
    memcpy (ptr, my_pic, size of pic);

    glUnMapBuffer(...);    <--- here
    glTexSubImageXY(...);  <--- or here ?

glUnMapBuffer will be what transfers the data to the card, probably. You would then glBindBuffer before calling glTexSubImage, to tell OpenGL to take its data from on-card memory.

It is up to driver to decide. I believe, the transfer will be triggered as soon as possible. Also, you could be writing direct to the video memory, so no DMA transfer would be required. All in all: you can never know :slight_smile:

All in all: you can never know
it is hard to optimize for the unknown … maybe thats the reason why i still feel somewhat more comfortable using this pdr thingy. i know where the mem is, i know what triggers the transfer and i know when its finished ( using fences ) - and get good and reliable speedups …

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.