PDA

View Full Version : GPU on CPU



Racoon
11-01-2005, 12:14 PM
Why have CPU loaded strongly when in simple render cycle is executing the glDrawArray? PBO is using. The number of vertexes is large.

Thanks in advance.

SirKnight
11-01-2005, 12:41 PM
So if I understand correctly, your CPU usage is high and you're not doing much other than drawing something with glDrawArray. Try putting a Sleep(1) call at the end of your render loop after you do a SwapBuffer. Sounds like a classic case of your 3d app hogging all the CPU. :)

-SirKnight

Racoon
11-01-2005, 01:28 PM
Thanks, but to sleep in run time render cycle... :)
But in spite of everything is work!.. (just at low fps) How?

As can i'm see:
glDrawArray () -- 40 ms
Sleep (N) -- + N ms

Why (when low fps) fps has unchanged?
A glDrawArray is asynchronous call?
What is making CPU when GPU is calculating the vertexes? (strongly loaded indicated)

rgpc
11-01-2005, 04:31 PM
Originally posted by Racoon:
The number of vertexes is large.How large?

Racoon
11-01-2005, 11:35 PM
The number of vertex = 2 million.

Just glDepthTest and GL_VERTEX_ARRAY is enabled, i.e. no texture, no normals, ... it is disabled. I'm using window mode (32x32 pels to make min the work on BitBlt). As far as know the main part of work is doing the glFinish. What is it doing?

Thanks!

Zulfiqar Malik
11-02-2005, 12:39 AM
Sounds like a batching problem to me.
Read this (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=013637) OpenGL thread for more information on better batching.

Overmind
11-02-2005, 01:23 AM
Have you tried using glFlush instead of glFinish?

Racoon
11-02-2005, 04:19 AM
Thanks for link. It is actually contact to my questions.

Yes, I'm have tried using glFlush instead of glFinish. But it have unchanged.

Why is the sleep necessary using? In wait-time the CPU is executing GPU driver and one is stronly interacting with WIN32K.SYS. What one is doing? (VBO is using)

tamlin
11-03-2005, 02:38 AM
I'm going out on a limb here, but if win32k.sys is indeed the one sucking CPU I'd think its due to GDI. I'd then guess your PBO format isn't matching what the hardware wants or supplies, so GDI must convert every single pixel in software.

Again, I'm just guessing, but color-conversion (even if as simple as RGB(A)<->BGR(A) ) or stretching (however that could become involved in PBO I don't know :) ) could display this behaviour.