8
\$\begingroup\$

For training a machine learning algorithm, we need to render some geometry in OpenGL without any hardware rendering support (no graphics card). So we were thinking of rendering in pure software, and we have looked at Mesa already. It seems like it is capable of rendering in pure software, but so far, we only get OpenGL 2.x, whereas we need OpenGL 3.3 .

Does anyone know if that is possible? and if so, how? We seem to run into stumbling blocks all the time.

(Background, why we want to do that: for training the learning algorithm, we need to perform a lot of runs of our software on a PC cluster, which do not allow rendering in hardware.)

Any hints, ideas, and pointer will be appreciated.

\$\endgroup\$
2

2 Answers 2

Reset to default
6
\$\begingroup\$

I am confused at your requirements. Are you running the code on a PC or an embedded system? If you are running on anything that remotely looks like a PC the "any hardware rendering support" is basically simply not true. At the bare minimum you have some Intel integrated stuff. I have yet to see a headless system that physically did not have a video chip.

On a headless system you can render without a window, how to do this with GLX you can see details in Windowless OpenGL. In any case even the most crappy hardware will be more efficient than a software renderer.

If you really are in a pinch and absolutely have no graphic hardware, you can use something like VirtualGL.

But if you are synthesizing pictures in software using OpenGL is sort of backwards. OpenGL is designed around the severe restrictions of graphic hardware. The result is that there are significant build in restrictions that can willfully be ignored when rendering in software. In addition the raster algorithm is not very efficient when using current hardware. A first order ray tracing can be more efficient and easily paralyzes over multiple cores. Maybe you can look into something like PovRay.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ There're some crappy intel video chips manufactured even today, which only support OpenGL 1.4 + ARB fragment assembly + ARB software-implemented vertex assembly. These won't be any more efficient than software renderer for any app requiring OpenGL 3. \$\endgroup\$
    – Ruslan
    Commented Jul 24, 2014 at 20:16
  • \$\begingroup\$ Thanks a lot. Yes, it is a PC-like. First, a simple PC in a PC cluster, into which we log in via ssh. Later, it will be PC nodes in a HPC system. Problem is: no matter what we do, we always only get OpenGL 2.1. Our application is based on Qt, but in the windowless version, all Qt code is inactive, except the one that creates the OpenGL context. And, yes, we did set DISPLAY to :0.0 on the remote machine. \$\endgroup\$
    – Gab
    Commented Jul 25, 2014 at 22:35
  • \$\begingroup\$ But then again OpenGL 2.1 is not too bad. I used that extensively with fairly good results. \$\endgroup\$
    – rioki
    Commented Jul 26, 2014 at 12:41
3
\$\begingroup\$

It would seem only OpenGL 2.x is fully supported by the software renderer in Mesa.

However, this answer suggests, that most of the functionality of OpenGL 3.x is supported via extensions. So, you might want to give it a try.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .