any TBDR limitations?

This topic contains 3 replies, has 2 voices, and was last updated by  Xmas 9 years ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #29589

    d1mbu1b
    Member

    Kindly direct me to any developer guidelines you may have for your PowerVR MBX chip.

    Does the nature of the TBDR mean that instructions get buffered?
    If so are there any limits on this buffer?

    I am having a problem drawing 6000+ GL_LINE_STRIPS (coastline data) using one VBO containing  115000+ vertices.

    I can draw all of them in different frames but cannot execute all 6000+ glDrawArrays() calls in one frame.

    #32285

    Xmas
    Member

    Hi,

    MBX developer guidelines are part of our POWERVR OpenGL ES 1.1 SDK.

    Yes, buffering of scene data is inherent to a TBDR. The amount of buffer space is implementation-dependent, but POWERVR hardware has mechanisms in place that ensure the scene is rendered correctly even when this buffer becomes full. However I should highlight that 6000 draw calls per frame won’t be fast even if you had just a single line per call, simply because of the overhead associated with each draw call. Can you combine multiple strips to a single one?

    If you see any particular limits on a specific platform you are targeting, you need to contact the platform provider.

    #32286

    d1mbu1b
    Member

    Thank you for the reply, tips, and, pointer to the guidelines. Very much appreciated.

    Understood. About the manufacturer.

    For the sake of followup:
    calling glDrawArrays(GL_LINES, 0, numVerts); fails as well.
        …correction above, meant to say GL_LINES instead of GL_LINE_STRIP
    I have to limit the count to about 20000 vertices somewhere around 256K of data.
    and multiple subsequent calls to this fails also.
    I was hoping to add dummy endpoints to each line strip and call with GL_LINES twice to save instruction overhead as recommended.

    basically a poor mans interlacer.

    Although the 6000+ instructions per frame yields acceptable (to me) performance on lesser platforms.

    It acts as if the graphics chip does not have direct memory access to the vertex data even though I am using a VBO.
    I am not sure of the architecture. if the VBO is in shared memory I could be having race condition. If the vertex data is on the graphics chip then I’m hosed.
    again its acting as if all the VBO data is getting sent across the CPU/GPU bus each frame.
    I’m confused and frustrated.
    Is it posible I am trying to access the VBO memory from both sides.
    I see that glBufferSubData() acts like glMapData(). Since glMapData() and glUnMapData() are not part of OpenGL-ES 1.x the is it possible I need to unmap the data mapped by the original load using glBuffer(Sub)Data()?

    I assume since I am the only one with this problem, that this is MY bug.

    I am using glBindBuffer(GL_ARRAY_BUFFER, 0); when I am done with rendering from the VBO.
    I could not find this documented anywhere. Maybe this is the problem.
    Is it possible to differentiate between a VBO and an VertexPointer with a VBO still bound?
    I will be adding this discussion to the khronos forum so please forgive the duplicate effort.

    thanks again for the help

    d1mbu1b2008-09-17 14:11:14

    #32287

    Xmas
    Member

    I don’t think there is any problem with VBOs at all. From what you’ve written I can’t see why you believe VBOs are the issue. It is just possible that the platform you are targeting has certain limits regarding vertex data per frame. Unfortunately in this case we won’t be able to help you since this does not apply to MBX in general.

Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.