scratt:
So if you then alter your re-factoring code to simply return 0.5 as before does the same problem persist?
CPU usage for every sized poly model, and all different sized for loops all have CPU at 55%. The FPS slow down with larger poly model and/or when I have a larger for loop/ buffer element changes.
scratt:
Have you tried profiling your code?
I have not. I could only find gDebugger which allows only a 3 or 7 day trial and then a license must be bought. I haven’t had any openGL training so I wasn’t sure what is the standard for GPU/CPU usage tracing.
scratt:
But something along the lines of Shark (part of the OS X dev tools)…
Right now I’m programming in Windows in Bootcamp. If I start up into OS X and get the dev tools, would my code port easily? Perhaps I should start programming this in the OS X to take advantage of Shark?
scratt:
Without seeing your code in it’s entirety I don’t think I can help much more.
I hope not! This CPU/GPU stalling is quite out of my league. I have compiled a list of performance stats to help in the understanding of where things are going wrong, hopefully you can still take a look.
dletozeun:
If you use the glBufferData(… NULL) trick, you do not need the double vbo and mapping thing. It is worth a try since you can quickly implement this but i would not expect good performances.
I have two VBO’s set up for the attributes. I then BindBuffer(Buffer1), glBufferData(NULL), glMapBuffer(Buffer1), Update, UnmapBuffer, and DrawElements(Buffer1 is still bound)
I change this on frame N, I do this to buffer1, frame N+1, Buffer2. This provides slightly better performance compared to the double buffering as described above. The stats of this will follow below.
dletozeun:
Very simple but very brutal and you will rapidly face the bus bandwidth limits. Furthermore if your update function is computationally expensive you can simply forget it.
What sort of bus bandwith limits would I be looking at? Am I encountering them now? My update function has a for loop of approx. 5; Each iteration it uses an index to lookup a value in an array (linear time?) and then multiples this by another value in another array (linear time?). It adds this value to a float, which it then returns to the main glMapBuffer for loop to change the element in memory.
dletozeun:
I do think that the only robust solution is the ping/pong and multithreaded approach.
How is it that using the ping/pong method now always has a CPU peak of 55% regardless of buffer element changes, while the other method of glBufferData(NULL) appears to rely entirely upon the amount of the elements I change in my for loop?
Does my CPU max out at 50% because Intel Mac Mini is Dual Core Intel?
With the correct double buffer implementation, CPU always at 55% no matter
what the size of the for loop/changes to buffer are. Slightly higher
average CPU (55%) compared to incorrect implementation of double buffer
which is around 50% when spiking.
Incorrect Buffer Implementation Statistics
One Buffer Bind
glBufferData(null)
MapthatBuffer
Unmap
DrawElements
With pData[i] = 0.5;
650k Model -
10% of Total Model, 64000 Size of For Loop-> CPU 50%
Under 10% of Total Model, < 64000 For Loop -> CPU 4%
Above 10% of Total Model, > 64000 For Loop -> CPU 50%
50k Model -> Buffer Size of 25000 Floats -> Always 3%
25k Model -> 20k Floats Buffer Size -> Always 3%
With pData[index] = Compute()
650k Poly Model - Floats, Size of Buffer
50k Poly Model - 25k Floats, Size of Buffer
Low Poly Model - 20k Floats, Size of Buffer
1)
For loop-576 size
Change 576 Elements - 20% CPU
CPU Jumps to 50%, then drops to 20% after 2 seconds
For Loop-720
Change 720 Elements - 27% CPU
For Loop-886
Change 886 Elements - 33% CPU
For Loop-1061
Change 1061 Elements - 39%
Loop - 1536
Change 1536 Elements - 50%
Addition
When I moved this code with the single buffer with glBufferData(NULL) to my laptop, Lenovo T61 QuadroFX 570M, the data is no longer correct. The brain model has random coloring that looks like noise. The correct coloring is still there, just plus all this random noise. The double buffer method, though, works perfectly on the laptop.
**
