Help with understanding where OpenGL lives

OpenGL Development JOGL Development
#1

Hi,

I’ve used OpenGL before, but I was wondering if someone can tell me exactly where OpenGL actually “lives”.

Does it reside in software (like in some Vista code or driver code) or hardware (like in the gfx card) ? I’ve just bought a brand new PC with an ATI Radeon X1300 graphics card. Of course the card comes with drivers from ATI that presumably let Windows Vista communicate with the card.

When I give OpenGL a command (like to draw a square, say) I am having trouble working out exactly how the computer ends up drawing it on the screen.

I assume that the command travels from my code to JOGL, and then to the ATI graphics driver which then breaks this OpenGL “command” down into pieces that the graphics card can understand. Is this correct?

Does the “hardware acceleration” for OpenGL occur automatically (by feeding the calls directly to the graphics card) or do I have to do something special to “tell” the card to accelerate the command? How do I know that my CPUs are not responsible for the rendering and that I’m actually using the power of the gfx card?

On a related note, I noticed that I can run Google Earth using OpenGL if I want. When I do the rendering of the earth slows down incredibly (remember I have a new machine, a 1.8GHz core 2 duo). Why is the rendering so incredibly awful? Is it some Microsoft thing? It looks to me like the rendering is being done either very inefficiently or in software rather than being accelerated.

Thanks in advance.

Mark

#2

If you said you had vista, that should explain it. The vista openGL drivers are very bad the last time I’ve heard. Based on my understanding you seem to have the basic flow correct. If the drivers that you have support hardware acceleration, it should automatically be used by the driver. This doesn’t mean that everything will always be on the GPU, but all the bits that can get easily accelerated by a graphics card’s specialized processor (ie vector math and shader programs, and some other things too) should be there.

#3

My understanding of how your Java program communicates with your videocard via OpenGL on Windows is like this:
Java program -> JOGL -> OpenGL32.dll library -> (vendor-specific OpenGL library, eg: nvoglnt.dll) -> videocard

If you don’t have hardware support for OpenGL, then I think it’s more like this:
Java program -> JOGL -> OpenGL32.dll library -> CPU -> videocard / shared video / etc

#4 


              App/OS link
       /----------------------------\
Application ---- Driver (1) ------- OS --------------------------- Driver (2) -------------------- Hardware (roughly in order)
glBegin()        set state          provide api process address    convert data to native format   vertex transformation
glColor()        validate state     provide hardware access        set hardware registers/memory   triangle setup
glNormal()       pass data                                                                         fragment rasterization
glVertex()                                                                                         attribute interpolation
....                                                                                               texturing
glEnd()                                                                                            fogging
                                                                                                   alpha test
                                                                                                   stencil/z test
                                                                                                   write to buffer

You might want to take a closer look at the old state diagram for OpenGL 1.1, which is still mostly correct for the newer versions of OpenGL, with the major caveat being that the vertex and fragment processors vastly simplify the diagram by absorbing large sections of it.