On Fri, 2008-01-11 at 18:05 +0100, Ferran Basora wrote:

Nowadays, I think that all people that works with GIMP have a 3D Graphic card. It could be possible to integrate some of GEGL operations with the OpenGL library and delegate a part of work to be faster?

3D and Free Software means that only Intel video will work with a Free Software stack or older ATI. [1] So in short you are asking to implement something that will require freedom-restricting software in a lot of cases.

Hub

[1] recent ATI might be, but it is just the future, not the present. nouveau (for nvidia) might also do some progress. but again just the uncertain future

That's not true, Hub: if you write a program based on OpenGL, you are not in any way forcing people to use non-free software.

If you have a graphics card that does not support hardware-accelerated 3D operations, then the operations will be done in software. As far as I know, in Linux, the Mesa library is used for this: http://www.mesa3d.org/

Note that there are lots of free 3D graphics applications, for example Blender http://www.blender.org/ and a number of games, that do use OpenGL.

Jesper

On Fri, 2008-01-11 at 18:05 +0100, Ferran Basora wrote:

Nowadays, I think that all people that works with GIMP have a 3D Graphic card. It could be possible to integrate some of GEGL operations with the OpenGL library and delegate a part of work to be faster?

3D and Free Software means that only Intel video will work with a Free Software stack or older ATI. [1] So in short you are asking to implement something that will require freedom-restricting software in a lot of cases.

Hub

[1] recent ATI might be, but it is just the future, not the present. nouveau (for nvidia) might also do some progress. but again just the uncertain future

On Jan 11, 2008 5:05 PM, Ferran Basora wrote:

Nowadays, I think that all people that works with GIMP have a 3D Graphic card. It could be possible to integrate some of GEGL operations with the OpenGL library and delegate a part of work to be faster? For example, rotate, transform, blur, mask operations.

Some operations of GEGL can potentially be accelerated by the means of a GPU. Accelerating things directly with OpenGL is not possible since OpenGL gives no warranties about the precision of the resulting rendering (it just has to "look good enough"). GEGL on the other hand aims for high precision rather than performance in it's output. It might be viable at some point in the future to add fast paths to GEGL that use GLSL or similar fragment shaders to do some of the work.

One of the main issues with accelerating these things with a GPU is that moving data from the system memory to the graphics memory and back is slow. Another problem is that you restrict the portability of the software severely. Thus you will often end up with a problem if some of your operations are GPU accelerated and some are not, the net effect might be that the end result is slower than a pure software implementation.

The only way I see it as viable to add usch acceleration to GEGL is to add optional fast paths in addition to the reference code already existing in C. This will be the same route GEGL will go down in accepting 8bit, 16bit, MMX, SSE and similar optimizations as well, they will be in addition to the sofware based floating point operations and it shall be possible to disable their use if they do not achieve sufficient precision.

Another thing that GEGL currently is lacking but it will most certainly get support for before GPU based acceleration is proprly considered is other forms of parallellziation, two, four, eight and eighty cpu cores are things that seems to become more and more wide spread.

/Øyvind K.