View Full Version : GPU on CPU
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.
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. :)
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)
Originally posted by Racoon:
The number of vertexes is large.How large?
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?
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.
11-02-2005, 01:23 AM
Have you tried using glFlush instead of glFinish?
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)
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.
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.