Programming on the GPU

Hi,

When I program my openGL program, I use VBO so I’m using directly the GPU for run my app. However, the rest of the functions which are not used to directly draw the vertexs where are they executed? On the CPU or GPU?

Here’s my point:
I need to program the most robust program. If I m not wrong, the best way to do that is using the CPU most of the time because GPU can have some problems of how they interpret the code (ATI vs nVidia).

So my second question will be, I m right with my point?

Thanks.

I’m not quite sure I’m following you. You need to write OpenGL code to perform some functions (like drawing something) - so you have little choice here - you WILL be using OpenGL function calls. How those functions are executed depends upon the implementation and it’s drivers. The OpenGL specification is quite clear and some of those functions are executed on the CPU (via the drivers) and some are executed on the GPU. Either way, it’s not like you have a choice and can arbitarity decide which component execute your function. The only choice you have is whether or not to make use of GPU memory to store data (eg Buffer Objects and textures) but this is hardly problematic and is usually well implemented across all vendors.

I need to program the most robust program. If I m not wrong, the best way to do that is using the CPU most of the time because GPU can have some problems of how they interpret the code (ATI vs nVidia).

You could write everything yourself in software (CPU) and forego OpenGL entirely. But what good would that do?
You’d spend years adding in all the functionality which already exists and you’d never get the bugs sorted out.
On top of that performance would be really, really bad.

So your point is somewhat unfounded and misguided IMHO.

Depends on your hardware and driver. For the most part, almost everything will happen on the GPU - all that an OpenGL driver really does, after all, is take function calls (and data), convert them to something the GPU can understand, and pass them on to the GPU for execution. (This is a simplified description, of course, but it should suffice for this topic.)

If your hardware can’t accelerate a particular feature you’re using, but your driver does support it, then your driver will emulate it in software. Unfortunately OpenGL doesn’t provide any mechanism for determining when this happens (a mistake IMO, but a topic for another thread) but you can easily detect it as it normally manifests as a sudden and extreme drop in performance.

If your hardware is reasonably modern (say 5 years or less old) then this should never happen in the normal case.

There are some OpenGL calls that always happen on the CPU despite this. There would include the now-deprecated matrix stack functions (glTranslatef and friends), but even so the final multiplication of position by MVP (or MVP by position) will happen on the GPU (assuming hardware T&L - again, should be present on all reasonably modern hardware).

VBOs are just buffers. It might be stored on the GPU RAM or system RAM. You will never know.
Using that to render some polygons is another matter. But again, you’ll never know how it’s done.

If you don’t like GL, then use D3D. You could use some software GL emulator but it would be too slow.

I know it can be a silly question but here’s the idea:

The program have to run on all the computers (having openGL drivers ofc). Using grafic cards, I risk to have failures because the developpers of the cards might not have followed the standards with all possible rigor.

Someone told me about two modes on openGL, hardview mode (using GPU and less CPU) and softview mode (using CPU and less GPU). Is it true? where can I find more information about it?

Ok, let’s take an example. I have one computer without GPU, openGL still working if the drivers exist on the machine. The only problem will be that the hardware work of GPU will be emulate with software, but, less eficiently.

Correct?

It’s a little more complicated than that.

Your program will never run on all computers. This is not an achievable goal. You need to decide where your reasonable cutoff point is.

OpenGL itself doesn’t have any modes that you can select. You get what the driver gives you and you have to accept it.

It’s getting increasingly difficult to find computers without some kind of graphics hardware installed. Even 5 year old business PCs will have graphics hardware that is capable of running simple OpenGL programs.

The worst case you’re going to see is Intel graphics chips. These are known for having bad OpenGL support, but their Direct3D support is OK (quite good in some cases, even). At that point you need to make a decision - if you must run on these you need to decide if you’re willing to switch to Direct3D and be able to run on Windows only, or stay with OpenGL and accept bad performance and limited functionality. That’s your choice to make and there is no best option for all cases; it depends on what your program needs to do and who your target audience is, and only you know that fully.

A general tip I give with Intel is that if a feature doesn’t exist in Direct3D then don’t expect it to work (well, or at all) in OpenGL. Getting to know some Direct3D is obviously useful here.

Working well can have two meanings. It might have bugs or other strange behaviours or it might run slowly (typically by being emulated in software).

In the case where OpenGL is software emulated, some or all of it may be done in software.

For simple programs, if the vertex pipeline is all that’s done in software then a fast enough CPU will be able to compensate and it will run fine.

If any of the per-fragment stages of the pipeline need to be done in software you’ll typically get less than 1 frame per second.

Not all OpenGL drivers are equal, and some are less equal than others. If your driver does not support some functionality then you cannot use it, not even in software. You’ll never be able to run GLSL programs on a TNT2 driver. You’ll never be able to use VBOs, you’ll never be able to use occlusion queries. You’re limited to what the TNT2 driver supports, and it doesn’t support these. This comes back to “do you really need to run on all computers?”

So two conditions need to be met. You hardware needs to support it. Your driver needs to support it. If these aren’t met, your driver might provide a software emulation. If your driver doesn’t provide a software emulation you can’t do it.

But… A full software implementation of OpenGL does exist (Mesa3D) (it’s not “official” and it’s not a “driver”, but it works) but this only implements OpenGL up to version 2.1 and is an all or nothing option. If you use it, everything will run in software, typically at less than 1 frame per second. You can’t mix and match parts of Mesa3D and parts of your driver, it’s one or the other.

It’s important to understand at this point that OpenGL is not software, and it’s not OpenGL that does the rendering. All that OpenGL does is convert OpenGL function calls to rendering commands (and data) in a format that your hardware can understand, then send them on to the hardware; your hardware is what does the actual rendering. Even in a full software emulation, the video hardware is still ultimately responsible for the final part which is plotting pixels on screen.

Worrying about driver quality at this stage is premature. No hardware vendor perfectly implements the standard, and you just have to live with it. NVIDIA will have the best support, Intel the worst and ATI/AMD somewhere inbetween. Driver quality will cause you some trouble, but avoid the common mistakes and use this forum when you have specific problems and you won’t go too far wrong.

Thank you! It was very usefull reply!

mhagain, I send you a PM, check you message box when you could plz.