[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Weird figures with OpenGL 3.2 and Intel HD3000 David Gohara Thu Feb 02 06:08:03 2012

On Jan 18, 2012, at 4:29 AM, [EMAIL PROTECTED] wrote:
>> the same call to glDrawElements takes *20 µs* on average; that’s much less
>> that the customary call to glClear (GL_COLOR_BUFFER_BIT) that consumes
>> around 90 µs.
>> (BTW, I made a mistake in my first message. On the HD3000, it takes 10 ms,
>> not 10 µs).
> That is a huge difference. To me, it sounds like the rendering is dropping
> into software rendering somewhere. Maybe in the fragment shader? Then the
> number of vertices wouldn't affect the problem.

  What does OpenGL Profiler tell you? If it's software rendering then you 
should be able to break on that.

  FWIW, I saw something similar with glDrawArrays, except in those cases it 
cause the entire screen to freeze and I had to restart (I don't recall the 
hardware at the time, it was on 10.6). The solution in my case was to process 
the data in smaller batches. I think the real cutoff was higher than 500 
elements (below). I think you can get the detailed limits on your card from 
OpenGL Extension Viewer (http://www.realtech-vr.com/glview/download.html):

int batchsize = 500;
int batchstart = 0;
int totalData = nobjects;
while (batchstart < totalData) {
        int drawsize = batchsize;
        if(drawsize + batchstart > totalData)
                drawsize = totalData - batchstart;
        batchstart += drawsize;

  Not sure if any of that is relevant here though.


David W. Gohara, Ph.D.
Department of Biochemistry and Molecular Biology
Saint Louis University

314-977-9215 (phone)
617-216-8616 (cell)
Google Chat: sdg0919
iChat: sdg0919

Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]