Re: Raw generator and performance

On Fri, Aug 24, 2012 at 2:07 PM, Fabian Binz <[email protected]> wrote:
> Hi list,
>
>
>
> I have two questions:
>
>
>
> 1. What is holding the release of OpenGLRawGen (see [1]) back? I tried it
> and it works quite well, although there seems to be a problem with at lea=
st
> some functions: glGenVertexArrays and the related functions are not expor=
ted
> by any core module, although it=92s part of the core since OpenGL 3.0. I =
tried
> to find the source of this error in the code, but the codebase is quite b=
ig
> and I still don=92t know where things go wrong.
>
>

What release do you mean, one on hackage or the use of it to generate
an new OpenGLRaw? A release on hackage might not be very useful as
it's a rather specific development tool. I don't know why it's not
used, maybe failure to promote it from my site, not being on hackage,
lack of time or interest could all be reasons.

The error with glGenVertexArrays (and a lot more functions) was caused
by a bug in the reuse options (the gl.spec has some comments on that
the functions are reused from an extension, which cannot be parsed
decently). I've fixed the bug in commit [5a38bc] on github.

>
> 2. Looking at the source of HSOpenGLRaw.c it seems to be quite costly to
> call OpenGL functions, because every time the function pointer has to be
> retrieved. Or does GetProcAdress (or the equivalent on Mac and Linux) cac=
he
> previous results? Other librarys (like GLEW or gl3w for C) load the
> functions pointers once at initialization (which has of course to be done
> explicitly unlike in HOpenGL), which I guess is for efficiency reasons.
>

It is effectively cached. The current implementation of functions is
done via the EXTENSION_ENTRY macro defined in HsOpenGLRaw.h.
OpenGLRawGen makes the same code as the macro execution would (that's
the theory). For every function the macro makes three declarations.
- a dynamic foreign import :: FunPtr t -> t
- the actual function pointer :: FunPtr t
- the actual function :: t
Where t is the type of the actual OpenGL function.

The actual function pointer is retrieved via an 'unsafePerformIO'-like
trick namely
thePointerName =3D unsafePerformIO $ getExtensionEntry 'functionName'.
Which is marked as NOINLINE, and is only evaluated once (on first use)
and the result is reused thereafter (as FunPtr t is pure).
getExtensionEntry is making (indirectly) the calls to
hs_OpenGLRaw_getProcAdress.

Lars

[5a38bc] https://github.com/Laar/OpenGLRawgen/commit/5a38bc297e0a3aafd153b8=
60f4ccabd18e2a2b62

>
> [1] http://www.haskell.org/pipermail/hopengl/2012-January/001073.html
>
>
> _______________________________________________
> HOpenGL mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/hopengl
>