What is the vertex limit number of glDrawArrays?
Author
What is the vertex limit number of glDrawArrays? Should I divide two parts when I want to draw the vertices over 65535?
You should be aware that that function asks you for the type of the indices.
If you specify GL_UNSIGNED_SHORT, then of course you are limit is 65,536 vertices.
However, if you specify GL_UNSIGNED_INT, your limit is 4,294,967,296 vertices, which is far more than is ever possible for you to create.
In general, people make wrappers around the OpenGL functions instead of calling them directly.
If you make a wrapper class that encapsulates an index buffer, you will be able to automatically switch between GL_UNSIGNED_SHORT and GL_UNSIGNED_INT.
L. Spiro
If you specify GL_UNSIGNED_SHORT, then of course you are limit is 65,536 vertices.
However, if you specify GL_UNSIGNED_INT, your limit is 4,294,967,296 vertices, which is far more than is ever possible for you to create.
In general, people make wrappers around the OpenGL functions instead of calling them directly.
If you make a wrapper class that encapsulates an index buffer, you will be able to automatically switch between GL_UNSIGNED_SHORT and GL_UNSIGNED_INT.
L. Spiro
Author
Thanks. Another problem, how do I set the vertex limit to 4,294,967,296? Use which function?
Careful, there are two limits. The first, obvious hard limit as pointed out by YogurtEmperor.
The second is a soft limit denoted by GL_MAX_ELEMENTS_VERTICES. You can draw more than this limit, but an implementation is not required to perform at maximum possible speed (and some will not).
Note that this limit is not documented for glDrawArrays, but it is well-documented for glDrawRangeElements, which performs an almost identical operation (with indices in addition to a range). Both functions must lock a range of vertices to draw them, and the amount of vertices the driver can lock is obviously finite. It is therefore reasonable to assume that the same limit applies to both draw calls.
The second is a soft limit denoted by GL_MAX_ELEMENTS_VERTICES. You can draw more than this limit, but an implementation is not required to perform at maximum possible speed (and some will not).
Note that this limit is not documented for glDrawArrays, but it is well-documented for glDrawRangeElements, which performs an almost identical operation (with indices in addition to a range). Both functions must lock a range of vertices to draw them, and the amount of vertices the driver can lock is obviously finite. It is therefore reasonable to assume that the same limit applies to both draw calls.
Careful, there are two limits. The first, obvious hard limit as pointed out by YogurtEmperor.
The second is a soft limit denoted by GL_MAX_ELEMENTS_VERTICES. You can draw more than this limit, but an implementation is not required to perform at maximum possible speed (and some will not).
Note that this limit is not documented for glDrawArrays, but it is well-documented for glDrawRangeElements, which performs an almost identical operation (with indices in addition to a range). Both functions must lock a range of vertices to draw them, and the amount of vertices the driver can lock is obviously finite. It is therefore reasonable to assume that the same limit applies to both draw calls.
The only thing that I have seen is that GL_MAX_ELEMENTS_VERTICES applies to glDrawElements and glDrawRangeElements (and perhaps glMultiDrawElements).
glDrawArrays doesn't have a limit. It is possible that the driver does some yo-yo and juggling behind the scene that causes performance loss if you send too many vertices but there is nothing in the GL specification about limits.
The only thing that I have seen is that GL_MAX_ELEMENTS_VERTICES applies to glDrawElements and glDrawRangeElements (and perhaps glMultiDrawElements).
glDrawArrays doesn't have a limit. It is possible that the driver does some yo-yo and juggling behind the scene that causes performance loss if you send too many vertices but there is nothing in the GL specification about limits.
True that OpenGL itself doesn't specify a limit, but you can bet that the hardware does. Generally, keeping under 64k seems a good idea to me (split your draw calls if you need to go over) but if you're targetting more modern hardware you should be easily able to go higher.
It's worth noting that the documentation and spec for many of these older functions was originally written in pre-hardware T&L days, and has had minimal updating since. Factors such as hardware limits on that part of the pipeline didn't even exist back then.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
