After using transform feedback, bind the VBO to the GL_PIXEL_UNPACK_BUFFER binding, bind your texture to GL_TEXTURE_2D, and call glTexImage2D (or TexSubImage) with the data pointer as an offset into your vertex buffer. Then call glGenerateMipmapEXT(GL_TEXTURE_2D) to build the mipmap chain.
Ok, that seems to be a good way to transfer my data server side. I don’t understand why I would use the GL_PIXEL_UNPACK_BUFFER as a binding object? Is that the only way to map it to a PBO?
Somehow the data does not seem to be copied to my texture. My feedback VBO is fine because I can render it with DrawArrays. It might have to do with the layout of the memory. How is that handled from a transform feedback?
Note that I quit the pipeline before rasterizing, since I get my data from the transform feedback.
So either I should be able to fill a PBO directly from my transfer feedback in order to bind that to texture. Or I should make a copy as proposed.
This seems like a roundabout way to do things, unless you also want the data in a VBO. Why not just ignore transform feedback, bind the texture into a framebuffer object and render to it? You would need to write the current position channel to something else (colour?) and set the position to an address in the texture.
This probably won’t work if you’re outputting a variable number of primitives from a geometry shader, though.
The output comes from a geometry shader with a variable number of primitives. With the transform feedback I can store the required data into a buffer object.
In a second pass I would like to have this buffer object as a 2D texture, so I can gather the required data using vertex texture fetch.
The most logical approach seems to be to transform feedback to a PBO, and use TexImage2D to create the texture. However I can’t get this to work.
Just an idea, is it possible that you specify wrong dimensions for your texture? Size of (particleCount/2)x(particleCount/2) would assume that you wrote (up to) particleCount^2/4 particles, is this correct? Did you try to trace the error with glGetError?
Ok, I’m getting close now.
I have the output buffer bound as PBO and created the texture succesfully. It seemed to be the memory layout that was the main problem.
Now I have still have to convert my buffer to a power of two size.
Finally I would like to know if someone managed to dynamically allocate the buffer for transform feedback after the geometry shader. Since we don’t know the number of primitives, how can we preallocate a buffer?
Don’t trust glGetBufferSubData - it’s broken in recent NVIDIA drivers and they aren’t planning to fix it before 100.xx (!?!). I’ve had to work around this by mapping the buffer and doing a memcpy.
I haven’t played with transform feedback myself, but looking at the spec it looks like you can get the buffer size by doing two passes. There is a query (as in glBeginQuery) that says how many primitives were generated, so if you get an overflow on the first pass (which is not considered an error, the feedback just truncates) then you can reallocate a larger buffer and make a second pass. Of course, if you have a good estimate for the size you can often avoid the second pass.
I don’t know if you have considered it, but you can also use a TextureBufferObject to avoid the copy to a 2D texture. It is like a 1D texture that always has nearest filtering and is addressed with non-normalized coordinates.
One word of warning, TeXBO was not supported with GLSL until the 100 series drivers.
Ok, you’ve just answered one of my remaining questions! I was wondering if the glTexImage2d performed a copy internally, or that it would change a pointer.
I did consider a TBO, however the capacity is limited and I can’t perform automatic mipmapping on this texture.
This was actually an old topic, but I’m currently back to this subject a bit. I have now a buffer object bound to GL_PIXEL_UNPACK_BUFFER and I call glGenerateMipmapEXT.
Is there a way to easily get the ‘highest’ mipmap value? (1 texel)