2 Replies Latest reply on Oct 19, 2010 6:32 PM by iLeitgeb

    Data-loss in TransformFeedbackObject (EXT_transform_feedback2)

    iLeitgeb
      [HD3850, Catalyst 10.9, Win7 64bit]

      I'm not sure if I misread the OpenGL specs or if this is erroneous behaviour on the driver's part. I have a hunch that it's the latter.

      I use EXT_transform_feedback2 with OpenGL 3.3 to ping-pong/update to VBOs.
      For that I generate those 2 VBOs, bind them and call glBufferData(,,NULL,) for allocation.
      Then I generate 2 TFOs, bind them and use glBindBufferBase() with the right VBO to set the TFOs 'destination'.

      Now, from my understanding of the specs, the VBO and all related information is stored within the TFO. I only need to bind the TFO before glBeginTransformFeedback(), but calling glBindBufferBase() again should not be necessary.

      Unfortunately that doesn't work. I use glDrawArrays() and glDrawTransformFeedback() while Transform Feedback is active and based on GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN it writes the correct number of primitives. But it is not the output of the vertex/geometry shader that is written to the destination buffer, instead it is only 0s that fill the size of the primitive.
      Actually, not all of them. After letting that ping-ponging run for a while and mapping one of the VBOs to client space some of the vertices had valid data, others had only 0s. But there was no apparent pattern. Looks like a threading/timing issue.

      The thing is, that when I bind a TFO and then make another (what I think to be redundant) call to glBindBufferBase() right after that, before activating Transform Feedback on each update-iteration, it works as expected.

      And yes, I check glGetError() and use AMD_debug_output. Nothing.

      So either I fail at reading and one is supposed to bind the destination buffer each time after binding the TFO or the driver has a problem with keeping the TFO's state.

      Any insight?
      Thank you!