- January 16, 2009 at 10:58 am #29676
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,
AndiJanuary 16, 2009 at 2:49 pm #32624
There is no extension for OpenGL ES that would introduce glDrawRangeElements. Simply use glDrawElements instead.January 16, 2009 at 3:24 pm #32625
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?January 16, 2009 at 5:04 pm #32626
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);
}January 16, 2009 at 9:01 pm #32627
Xmas… Thanks again for the help. I was really confused about the start and the end. ÂMarch 31, 2009 at 12:27 pm #32628
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 regardsApril 2, 2009 at 12:16 pm #32629
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?April 3, 2009 at 8:23 am #32630
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.
AndiApril 3, 2009 at 11:42 am #32631
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?April 3, 2009 at 11:53 am #32632
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.April 6, 2009 at 8:19 am #32633
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?April 6, 2009 at 1:16 pm #32634
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?April 6, 2009 at 2:22 pm #32635
Time is measured like this:Code:
Â TTime starttime, endtime;
Â TTimeIntervalMicroSeconds rendertime;
// Drawcall here
rendertime = endtime.MicroSecondsFrom(starttime);
I allready tried to disable Texturing ( noÂ measurable result )
Best regardsApril 7, 2009 at 8:20 am #32637
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?