why are my vertex arrays slow?
Author
Well I''ve got a terrain drawn with quadtree culling, and I break it up into 8x8 chunks for rendering. I have 2 ways of drawing the chunks right now, one by using standard glBegin() ... draw the chunk...glEnd() and another using an indexed vertex array. So if these are supposed to be faster and more efficient why do I get about a 1-2% fps drop when using the vertex array method? Any insight on how I can get the vertex array thing to give me a speed up like advertised would be great. Thanks.
-are you enabling/disabling VA for every chunk?
-are you using 1 tri strip/patch?
-are you generating array every frame?
You should never let your fears become the boundaries of your dreams.
-are you using 1 tri strip/patch?
-are you generating array every frame?
You should never let your fears become the boundaries of your dreams.
What array format are you using? Some formats are not optimised, and will therefore be slower than immediate mode (On nVidia cards at least). If you have an nVidia card, look at developer.nvidia.com to see what formats are optimised and fast.
sbennett : Even with not optimized format VA are faster than immediate mode. Just about anything is.
Author
I use 8 strips in each chunk, have to ''cause it''s a square. The arrays are all pre calculated and I don''t enable/disable va every chunk, it''s once per frame. I looked at developer.nvidia.com but couldn''t find that info, do you have a more specific link for me? Anyway I''m using an unsigned short array, I''d think that would be fast given the fact that less data is actually transferred compared to a float array or something.
quote:Original post by y2kiah
Anyway I''m using an unsigned short array, I''d think that would be fast given the fact that less data is actually transferred compared to a float array or something.
I''d bet that the GPU expect float data and therefore have to make conversions on the fly, which may be quite expansive. You should try using floats.
quote:
Anyway I''m using an unsigned short array, I''d think that would be fast given the fact that less data is actually transferred compared to a float array or something.
You are absolutely correct. You should use the smallest data format possible, in order to increase performance, memory access and bandwidth requirements are reduced. The GPU doesn''t expect any special dataformat. It has to convert all of them, including float, since it internally operates on a fixed point format. Actually, integer to fixed point conversion might even be faster than float to fixed point.
But there is one exception: vertex arrays. You should use floats for them. Use shorts or unsigned bytes for everything else (color arrays, texcoord arrays, normal arrays, etc). This little problem might have gone with newer drivers though.
How many faces/vertices do you have per glDrawElements() call ?
/ Yann
Author
I''ll definitely try a float array for my vertices now, thanks for the tips I hope it speeds up. For Yann, I have 128 faces per call, that''s 8x8 quads x 2 tris per quad.
Here''s another question, when and if I use glDrawElements as my final choice, how do I use auto tex coord generation for channel 1 and 2 of ARB_multitexture? Or is it not possible? Right now I''d love to be doing that to save memory but I can only see it working for one channel.
Thanks everyone.
Here''s another question, when and if I use glDrawElements as my final choice, how do I use auto tex coord generation for channel 1 and 2 of ARB_multitexture? Or is it not possible? Right now I''d love to be doing that to save memory but I can only see it working for one channel.
Thanks everyone.
quote:
For Yann, I have 128 faces per call, that''s 8x8 quads x 2 tris per quad.
Hmm, 128 isn''t really much for a VA call, but not that low either. It should definitely show a great speedup compared to immediate mode. Weird.
quote:
Here''s another question, when and if I use glDrawElements as my final choice, how do I use auto tex coord generation for channel 1 and 2 of ARB_multitexture?
glActiveTextureARB(GL_TEXTURE1_ARB); // or GL_TEXTURE0_ARB, GL_TEXTURE2_ARB, GL_TEXTURE3_ARB, etc...glEnable(GL_TEXTURE_GEN_S);glEnable(GL_TEXTURE_GEN_T);glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, mode);glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, mode); / Yann
Author
Yeah tell me about it...I''ll keep fooling around with it and post something up here if I find the reason.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
