Hello, what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much. Best wishes, Wolfgang
Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
Hello,
what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much.
Best wishes, Wolfgang
Hmm, no reply until now. :-( A related question: I plan to let "my" students write some HOpenGL based applications in a practical course whose intend is to train them in functional and logic programming. One of these applications should simulate a flight over a landscape whose surface is modelled via fractal brownian motion. So the program needs to display a rather large amount of geometric primitives and needs to do this rather fast because the thing is animated. Now my question: Is Haskell in conjunction with HOpenGL overstrained with this problem or can I expect the application to run fast enough to not make the students laugh about Haskell's speed. :-) Of course, the program should be run only on graphic cards with 3D acceleration. I'd be happy about quick replies. :-) Best wishes, Wolfgang
On 1/16/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
Hello,
what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much.
Best wishes, Wolfgang
Hmm, no reply until now. :-(
A related question: I plan to let "my" students write some HOpenGL based applications in a practical course whose intend is to train them in functional and logic programming. One of these applications should simulate a flight over a landscape whose surface is modelled via fractal brownian motion. So the program needs to display a rather large amount of geometric primitives and needs to do this rather fast because the thing is animated. Now my question: Is Haskell in conjunction with HOpenGL overstrained with this problem or can I expect the application to run fast enough to not make the students laugh about Haskell's speed. :-) Of course, the program should be run only on graphic cards with 3D acceleration.
I'd be happy about quick replies. :-)
As long as you don't do it naively there should be no problems. I.e. do not draw the terrain using the vertex-calls, but rather use vertex-arrays, or (better) vertex buffer objects. Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible. Also, some sort of level-of-detail-scheme is probably a good idea (blocks of terrain far away have lower level of detail). To summarize: Drawing vast terrains quickly has much more to do with algorithmic cleverness rather than miniscule overheads from library bindings. You may want to find a good terrain-rendering library rather than implementing it yourself. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
[...]
Hello Sebastian, thank you for your answer.
As long as you don't do it naively there should be no problems. I.e. do not draw the terrain using the vertex-calls, but rather use vertex-arrays,
Hmm, this will make it rather complex for my students since they have not much experience with Haskell programming. In addition, where can I find documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
or (better) vertex buffer objects.
What's this?
Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible.
Too complicated for the practical course. Doesn't OpenGL already do something like this?
Also, some sort of level-of-detail-scheme is probably a good idea (blocks of terrain far away have lower level of detail).
Maybe also too complicated or too extensive for the practical course.
To summarize: Drawing vast terrains quickly has much more to do with algorithmic cleverness rather than miniscule overheads from library bindings.
I did not refer to the overheads of the binding but to "the slowness of Haskell" (compared to C, of course ;-) ).
You may want to find a good terrain-rendering library rather than implementing it yourself.
Is there one for Haskell?
/S
/W
On 1/16/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
[...]
Hello Sebastian,
thank you for your answer.
As long as you don't do it naively there should be no problems. I.e. do not draw the terrain using the vertex-calls, but rather use vertex-arrays,
Hmm, this will make it rather complex for my students since they have not much experience with Haskell programming. In addition, where can I find documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
I suppose here: http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... But it should correspond fairly well to any general documentation on vertex arrays (www.opengl.org will surely have reference documentation somwhere).
or (better) vertex buffer objects.
What's this?
It's a fairly recent addition meant to be used instead of vertex arrays in most cases. I'm not sure if HOpenGL supports them, but I believe it does. The main benefit as far as I can tell is that unlike vertex arrays the data does not need to be validated everytime it's sent to the graphics card (the implementation is prohibited from assuming that the data in a vertex array hasn't changed, so it must be validated every time it's referenced). VBOs are managed by the graphics driver to a larger extent, so can be optimized "behind the curtains".
Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible.
Too complicated for the practical course. Doesn't OpenGL already do something like this?
OpenGL can use scissors to clip triangles and won't perform any rasterizing if it's outside the screen (not sure how this is set by default, though). However, you still incur the cost of sending everything down to the graphics card, which may very well be your bottle-neck for a large terrain.
I did not refer to the overheads of the binding but to "the slowness of Haskell" (compared to C, of course ;-) ).
Well I don't think it's going to be much of a problem, as most of the heavy stuff happens in the driver and on the graphics card. Unless you do some really heavy lifting, you should be GPU-limited.
You may want to find a good terrain-rendering library rather than implementing it yourself.
Is there one for Haskell?
Not that I know of, but if you find one for C it shouldn't be too hard to create a binding... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Am Montag, 16. Januar 2006 22:12 schrieb Sebastian Sylvan:
On 1/16/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
[...]
Hello Sebastian,
thank you for your answer.
As long as you don't do it naively there should be no problems. I.e. do not draw the terrain using the vertex-calls, but rather use vertex-arrays,
Hmm, this will make it rather complex for my students since they have not much experience with Haskell programming. In addition, where can I find documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
I suppose here: http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/ Graphics-Rendering-OpenGL-GL-VertexArrays.html
Hmm, this is not much of a documentation. No explanation of the types, functions, etc.
But it should correspond fairly well to any general documentation on vertex arrays (www.opengl.org will surely have reference documentation somwhere).
Yes, the only explanation on the above page is a pointer to the corresponding section in the OpenGL specs. I hope that the correspondence between the Haskell module and the chapter of the specs is rather tight. After all, the Haskell module uses Haskell classes, Ptr values, etc.
or (better) vertex buffer objects.
What's this?
It's a fairly recent addition meant to be used instead of vertex arrays in most cases. I'm not sure if HOpenGL supports them, but I believe it does.
At least from skimming the HOpenGL module list, I couldn't find anything which has to do something with "buffers".
The main benefit as far as I can tell is that unlike vertex arrays the data does not need to be validated everytime it's sent to the graphics card (the implementation is prohibited from assuming that the data in a vertex array hasn't changed, so it must be validated every time it's referenced). VBOs are managed by the graphics driver to a larger extent, so can be optimized "behind the curtains".
Sounds interesting.
[...]
You may want to find a good terrain-rendering library rather than implementing it yourself.
Is there one for Haskell?
Not that I know of, but if you find one for C it shouldn't be too hard to create a binding...
Too time-consuming for me. :-(
/S
/W
On 1/17/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Montag, 16. Januar 2006 22:12 schrieb Sebastian Sylvan:
On 1/16/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
[...]
Hello Sebastian,
thank you for your answer.
As long as you don't do it naively there should be no problems. I.e. do not draw the terrain using the vertex-calls, but rather use vertex-arrays,
Hmm, this will make it rather complex for my students since they have not much experience with Haskell programming. In addition, where can I find documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
I suppose here: http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/ Graphics-Rendering-OpenGL-GL-VertexArrays.html
Hmm, this is not much of a documentation. No explanation of the types, functions, etc.
But it should correspond fairly well to any general documentation on vertex arrays (www.opengl.org will surely have reference documentation somwhere).
Yes, the only explanation on the above page is a pointer to the corresponding section in the OpenGL specs. I hope that the correspondence between the Haskell module and the chapter of the specs is rather tight. After all, the Haskell module uses Haskell classes, Ptr values, etc.
or (better) vertex buffer objects.
What's this?
It's a fairly recent addition meant to be used instead of vertex arrays in most cases. I'm not sure if HOpenGL supports them, but I believe it does.
At least from skimming the HOpenGL module list, I couldn't find anything which has to do something with "buffers".
http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Am Montag, 16. Januar 2006 21:52 schrieb Wolfgang Jeltsch:
Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
or (better) vertex buffer objects.
What's this?
The basic idea behind buffer objects is a general mechanism which allows the driver to keep huge amounts of data on the extremely fast on-board memory of graphics cards, potentially in an already preprocessed form. Currently two kinds of data are standardised: Vertex arrays and indices into those arrays. This is a rather cool mechanism, making some more specialised extensions like compiled vertex arrays (=> Quake :-) superfluous.
Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible.
Too complicated for the practical course. Doesn't OpenGL already do something like this?
OpenGL is intentionally designed as a *rendering* library, onto which higher-level libraries (e.g. Inventor) can be layered. Of course OpenGL throws away invisible primitives as fast as possible, but even this takes some time, so higher-level libraries can make OpenGL's life much easier.
[...]
To summarize: Drawing vast terrains quickly has much more to do with algorithmic cleverness rather than miniscule overheads from library bindings.
I did not refer to the overheads of the binding but to "the slowness of Haskell" (compared to C, of course ;-) ). [...]
I think this is one of the strengths of a Haskell binding for OpenGL: You can concentrate on the fun part (i.e. clever rendering algorithms etc.) much more easily than in C. Given the same amount of time, I imagine that one can implement much more elaborate stuff than in C, so you can actually get better performance. Cheers, S.
Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
Hello,
what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much.
Best wishes, Wolfgang
Hmm, just tested this on a computer with faster CPU and 3D acceleration and there glxgears was only about 7 % faster than the Haskell Gears. Best wishes, Wolfgang
[ Sorry for the extremely slow reply, I'm just working through a mail backlog of about one month... ] Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much.
An almost identical issue was discussed on the HOpenGL mailing list some time ago: http://www.haskell.org//pipermail/hopengl/2004-March/000476.html The net result is: There is no measurable speed difference compared to plain old C when using Haskell + HOpenGL. Another nice project to look at: http://www.haskell.org//pipermail/haskell/2005-November/016941.html Having said this, one should mention that there are plenty of reasons for bottlenecks when doing graphics in OpenGL in general: The application performance can be limited by the CPU, memory bandwidth, the GPU on the graphics card, pixel bandwidth, etc. The least thing I would worry about would be Haskell or the HOpenGL package. :-) Rendering terrain efficiently is a rather tricky topic, so one can find tons of books and papers on it, and I guess it still has enough potential to give material for several PhD dissertations. If your students are new to Haskell, OpenGL and terrain rendering algorithms, this might be a little bit too much IMHO. Regarding documentation: The OpenGL package documentation is admittedly sometimes a bit terse, it ranges from no comments at all (i.e. only things that Haddock can generate automatically) to rather elaborate, e.g.: http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... The OpenGL 1.5 spec is about 333 pages, and translating this into Haddock comments is a huge amount of work, so I comment only from time to time (a slow, but ongoing process). But the main idea here is that the OpenGL binding resembles the C API closely enough that everybody who knows the spec should have no problem at all writing OpenGL stuff in Haskell. Therefore the whole module structure and naming is designed to closely follow the spec, compare e.g. http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Render... with the index of the OpenGL 1.5 spec. Furthermore, the GLUT package has quite a few examples to get everyone started. If there are still problems, there is still the hopengl list and I'll happily clarify any unclear points. The GLUT package is structured similarly, but fully documented: http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT.... In general, I think it is a good idea for any binding to follow the structure of the original spec as closely as possible. Cheers, S.
participants (3)
-
Sebastian Sylvan -
Sven Panne -
Wolfgang Jeltsch