glDrawRangeElements

This topic contains 23 replies, has 3 voices, and was last updated by  Xmas 6 years, 5 months ago.

Viewing 15 posts - 1 through 15 (of 24 total)
  • Author
    Posts
  • #29676

    Lichtens
    Member

    Hi…

    two questions in one thread: is powervr mbx providing an extension to use glDrawRangeElements?

    If not, it there a reference, how to emulate this functionallity in performantic way?

    With the best regards,

    Andi

    #32624

    Xmas
    Member

    There is no extension for OpenGL ES that would introduce glDrawRangeElements. Simply use glDrawElements instead.

    #32625

    Lichtens
    Member

    Ok, problem is, that i have vertexarrays and indexarrays coming from an “full OpenGL” application… so i am thinking about a way how to render these for glDrawRangeElements designed arrays in OpenGL ES.

    Any conclusion?

    #32626

    Xmas
    Member

    As I wrote before, simply use glDrawElements. Drop the start and end parameters to glDrawRangeElements, the rest is the same.

    This is a perfectly valid implementation of glDrawRangeElements:

    Code:
    void glDrawRangeElements(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, void *indices)

    {

        glDrawElements(mode, count, type, indices);

    }
    #32627

    Lichtens
    Member

    Xmas… Thanks again for the help. I was really confused about the start and the end.  

    #32628

    Lichtens
    Member

    Since i use glDrawElemets for these range elements now, this is really slow.

    i need about 10 ms per draw call, means around 400ms for 40 batches, which results in a framerate of 2 frames per second. This is really slow.

    Any way to speed this up? where can be the the problem, making this that slow?

    Best regards

    #32629

    Xmas
    Member

    What device are you using? What are the arguments for the draw calls, i.e. primitive type, number of vertices? What is your vertex data layout?

    #32630

    Lichtens
    Member

    Hi xmas… to your questions:

    All tests are running on Nokias N95 8GB.

    Primitive Type is GL_TRIANGLE

    Number of vertices depends because of flexible building of the batches as spatial groups and related to the textures. is is per batch somewere between 12 and 2000 verts.

    The vertex data layout is build out of own classes for Vector3 and Vector2, all holding floats in an array. The vertex array it selve is an strider, containing a Vector3 for the vertices followed by a Vector2 holding the texture coordinates. An own strider is given for the U16 indices. 

    so, i hope, i answered all the questions.

    Best Regards, 

    Andi

    #32631

    Xmas
    Member

    That really seems to be quite slow. How do you measure the time for each draw call? Do you have blending or alpha test enabled? What texture format are you using?

    #32632

    Lichtens
    Member

    Texture Format is PVRTC… in these batches no alpha tests and no blending.

    The time is measured by symbian system calls and written in a debug file, after all drawing is over.

    #32633

    Lichtens
    Member

    So no further ideas?

    Maybe ideas, how to find the leak. If you say, this sounds for you quite slow ( i feel the same ), there should be a leak. What do you think?

    #32634

    Xmas
    Member

    Please try reducing the workload in specific areas to find the bottleneck, e.g. disable texturing, reduce the viewport size, reduce the frustum size, use smaller vertex data types, or submit only one triangle per draw call.

    How exactly are you measuring the time for each draw call?

    #32635

    Lichtens
    Member

    Time is measured like this:

    Code:

    #ifdef DEBUG_PUSHING_BATCH
      TTime starttime, endtime;
      TTimeIntervalMicroSeconds rendertime;
      starttime.HomeTime();
     #endif

    // Drawcall here

    #ifdef DEBUG_PUSHING_BATCH

    endtime.HomeTime();
    rendertime = endtime.MicroSecondsFrom(starttime);
    #endif

    I allready tried to disable Texturing ( no measurable result )

    Best regards

    #32636

    Xmas
    Member

    Did you try the other suggestions as well?

    #32637

    Lichtens
    Member

    Reducing the count of triangles is (of course) speeding up the drawcalls. The vertexbuffers, the ranges are drawn from are flexible rebuilt. means, there are parts of it changed during the runtime. is it possible, that memory gets fragmented and so the memory acces gets that slow?

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