pure-gl
Albert Graef
them here:
http://code.google.com/p/pure-lang/source/browse/trunk/pure-gl
Scott, can you please review and update this as you see fit? Also, it
would be nice if you could add a brief description to the Addons wiki
page at:
http://code.google.com/p/pure-lang/wiki/Addons
I'm ready to do an initial file release, just let me know. If you
prefer, you can also do that yourself. 'make dist' rolls a tarball; you
can set the version number at the top of the Makefile. Then go to
http://code.google.com/p/pure-lang/downloads/list and upload the tarball
with "New Download".
Thanks! :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
sedillard
On Feb 2, 1:29 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> I'm ready to do an initial file release, just let me know.
anything like a release. Things there are much worse than I had
anticipated. I naively thought that Nvidia and ATI would be merciful
enough to overwrite Microsoft's antiquated opengl32.dll, so that we
could fetch the functions directly from there using the normal Pure
extern facility. It turns out there is some opaque mechanism in that
file for forwarding GL calls to the vendor's drivers, so it is
impossible to link directly to the functions; instead they must be
fetched using the irritating wglGetProcAddress function and called
through a function pointer.
As with many things on Windows, some beneficent 3rd parties have
stepped in to clean up the mess, http://glew.sourceforge.net/index.html
, http://www-sop.inria.fr/reves/Sylvain.Lefebvre/glux/ , but these
don't really help because they are designed to be used at the API
level, rather than ABI.
We could use libffi to call through these function pointers, but it
complicates things. Do we use libffi for the whole library, making all
calls uncurried? Or is there some way to use the normal Pure extern
facility with function pointers. On some level this is happening
anyway, because its going through dlsym, right?
Also, I can load the Pure GL, GLU and GLUT bindings on Windows, but
when I call any function I get a segfault (or so I assume. I chose not
to send an error report to Microsoft, so who knows.)
Scott
Albert Graef
> I kind of want to deal with the situation on Windows before making
> anything like a release. Things there are much worse than I had
> anticipated.
Yes. Things are *always* much worse on Windows than anticipated. :)
> As with many things on Windows, some beneficent 3rd parties have
> stepped in to clean up the mess, http://glew.sourceforge.net/index.html
> , http://www-sop.inria.fr/reves/Sylvain.Lefebvre/glux/ , but these
> don't really help because they are designed to be used at the API
> level, rather than ABI.
I think we need a C wrapper module anyway. This can easily be generated
alongside the .pure modules. The C module is then what gets imported and
it just calls through to the proper functions. Doing that via GLEW
probably has the advantage that all existing extensions are available,
even if they are not in the host system header files or import
libraries. (Which is always a problem on Windows, I still remember that
I had to deal with this for my Q OpenGL wrapper which was generated with
SWIG.)
> We could use libffi to call through these function pointers, but it
> complicates things.
Yes, and it adds overhead. The C wrapper solution seems easy and more
reliable.
> Do we use libffi for the whole library, making all
> calls uncurried?
Well, writing a little helper function to curry an uncurried function
with any number of arguments is an easy exercise:
> curryn f () = f;
> curryn f (x,xs) = curryn (f x) xs;
> curryn f x = f x;
> curryn f (a,b,c);
f a b c
uncurryn is slightly more involved, but not difficult either. Maybe some
kind soul should add these to the library. :)
> Or is there some way to use the normal Pure extern
> facility with function pointers.
No, and I won't add it, that's what pure-ffi is for. Even if we had that
functionality, you'd have to go through eval to make it work since the
function pointers are only known at runtime. This would be much slower
than using the ffi mechanism.
> On some level this is happening
> anyway, because its going through dlsym, right?
The function addresses are resolved through dlsym or something
equivalent, yes. But they do become ordinary functions with extern C
linkage in the LLVM code module. Thus the calls to such functions in
LLVM IR are lowered to native code by the JIT. (Incidentally this part
seems to be flaky on Windows, see my earlier posts.)
> Also, I can load the Pure GL, GLU and GLUT bindings on Windows, but
> when I call any function I get a segfault (or so I assume. I chose not
> to send an error report to Microsoft, so who knows.)
Yes, I had that, too. The "segfault" in my case was actually one of
those dreaded c0000xxx exceptions generated by the msvc runtime while
trying to execute a "privileged" sti instruction (at least that's what
the ms debugger tells me), so it's clearly caused by the execution of
bogus code. Calling the same function pointers through ffi works fine,
so I suspect it's a problem with the LLVM JIT on Windows. I'm not
inclined to debug that right now, because I'd rather spend my days
hacking Pure than doing machine code hacking on Windows. ;-)
sedillard
On Feb 3, 7:35 am, Albert Graef <Dr.Gr...@t-online.de> wrote:
>
> I think we need a C wrapper module anyway. This can easily be generated
> alongside the .pure modules. The C module is then what gets imported and
> it just calls through to the proper functions. Doing that via GLEW
> probably has the advantage that all existing extensions are available,
> even if they are not in the host system header files or import
> libraries. (Which is always a problem on Windows, I still remember that
> I had to deal with this for my Q OpenGL wrapper which was generated with
> SWIG.)
>
generating any C code, on sane platforms at least. (Did anyone try on
the Mac?) This business of fetching function pointers at runtime is
only to deal with C linking; if your C program calls the function,
then the dll has to define it or the program won't load, even if you
guard your calls with checks for extensions support. Pure doesn't have
this problem since it looks up functions at runtime anyway. So by
going back to C we bring up all the old headaches which we don't
otherwise have to deal with.
I don't think we need GLEW. GLEW is essentially generated from the
same information which I've already teased out of the headers, so we
can just directly generate the calls to xxxGetProcAddress. One less
dependency.
Additionally, GLEW makes an association between an extension name,
e.g. GL_ARB_shader_objects, with some function names, e.g.
glCompileShaderARB, glUseProgramARB, etc, so the programer specifies
that he wants "GL_ARB_shader_objects" and GLEW goes an calls
xxxGetProcAddress for all of those functions. In order to make use of
this, we'd also have to make these associations, but its not like
they're in some database somewhere. I think it could be gleaned from
the headers, but I'm not excited about doing it. Anyway, this is not
necessary for Pure; we can just call xxxGetProcAddress for all
functions, and if they aren't there then it will return null, so we
just print an error or something. It's still up to the programmer to
check the value of glGetString(GL_EXTENSIONS) to see if the extension
is supported.
> so I suspect it's a problem with the LLVM JIT on Windows. I'm not
> inclined to debug that right now, because I'd rather spend my days
> hacking Pure than doing machine code hacking on Windows. ;-)
>
as they are, then I'm inclined to put this off indefinitely. I'm
willing to put in some effort to make things "just work" for Windows
users, but this is absurd. MS hasn't updated opengl32.dll since Bill
Clinton was reelected. Its one thing to not support extensions, but
the standard API has gone through 2 major and 7 minor revisions since
then. (Funny thing: It's actually possible to fix this by compiling
your own opengl32.dll that defines all the functions, but this is also
how people cheat at online games. They make an opengl32.dll that turns
off z-buffering so you can see through walls, since walls are usually
drawn before the other players. So now all the game servers checksum
this file to see if you're cheating, which partly explains why it
hasn't changed. Only MS could dictate such a change and they have no
incentive.)
Scott
sedillard
module that has for each function something like
void glFunction(args) {
static void(ptr*)(args) = 0;
if (!ptr) ptr = getProcAddress("glFunction");
if (!ptr) pure_throw ( gl_unsupported "glFunction" );
return (*ptr)(args);
}
So all functions are loaded on first use. This insulates us pretty
well from any underlying OpenGL implementation, and has the bonus of
graceful failure for unsupported functions.
I've pushed this change and made a Makefile (cut-n-paste from pure-
gsl) so after we test on Windows and Mac it should be ready to go.
Scott
Albert Graef
> So all functions are loaded on first use. This insulates us pretty
> well from any underlying OpenGL implementation, and has the bonus of
> graceful failure for unsupported functions.
Yeah, that's what I had in mind. Thanks a lot. I'll test it tomorrow.
(Just wasted two hours on my own quick and dirty port to Windoze until I
found out that you already did it. ;-)
I think you still have to regenerate and commit those GL*.pure files
after your most recent change to the generator (r734).
For Windows, we also need to fix the dll names, but I can easily do with
a little sed script. Are opengl32.dll, glu32.dll and freeglut.dll all
that's needed? How does getProcAddress resolve the extensions, would I
need to load additional vendor-specific dlls to get those or is that
handled automagically?
sedillard
On Feb 3, 7:49 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
>
> I think you still have to regenerate and commit those GL*.pure files
> after your most recent change to the generator (r734).
they were the same so svn skipped them. (Svn does this, right?)
>
> For Windows, we also need to fix the dll names, but I can easily do with
> a little sed script. Are opengl32.dll, glu32.dll and freeglut.dll all
> that's needed? How does getProcAddress resolve the extensions, would I
> need to load additional vendor-specific dlls to get those or is that
> handled automagically?
>
comes from here http://www.xmission.com/~nate/glut.html . That I think
is more common than freeglut on windows, it's even linked from
opengl.org. wgetGetProcAddress is in opengl32.dll, and that is the
only entry point you need. It will return pointers to functions in the
vendor's drivers.
Scott
Albert Graef
> No the change only affected pure-gl.c. I did regenerate the files and
> they were the same so svn skipped them. (Svn does this, right?)
I'm referring to these changes in r734:
+fputs "using \"lib:pure-gl\";\n" out_gl;
There are a couple of those in r734 and AFAICS they are not reflected in
the GL*.pure files currently in svn.
> Yes I believe those are the only dlls. There is also glut32.dll, which
> comes from here http://www.xmission.com/~nate/glut.html . That I think
> is more common than freeglut on windows, it's even linked from
> opengl.org.
freeglut is much more useful than the standard glut. That's also what I
use on Linux. I already have a dll that I can just include with the
Windows version. Would it be possible to add the additional freeglut
calls to GLUT.pure, at least as an option?
sedillard
On Feb 3, 8:34 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
> sedillard wrote:
> > No the change only affected pure-gl.c. I did regenerate the files and
> > they were the same so svn skipped them. (Svn does this, right?)
>
> I'm referring to these changes in r734:
> +fputs "using \"lib:pure-gl\";\n" out_gl;
>
tomorrow.
> freeglut is much more useful than the standard glut. That's also what I
> use on Linux. I already have a dll that I can just include with the
> Windows version. Would it be possible to add the additional freeglut
> calls to GLUT.pure, at least as an option?
>
callbacks. I guess we can do glut.pure and freeglut.pure, for those
who know they want freeglut.
By the way: GLUT.pure or glut.pure? GL.pure or gl.pure? GL::Begin
GL::POLYGON, gl::Begin gl::POLYGON, or even gl::Begin gl::Polygon ...?
Any preference? I really don't care.
Scott
Albert Graef
> Right of course. Left that on the other computer so I'll push that
> tomorrow.
Ok, thanks.
> To be honest I don't know much glut beyond making windows and basic
> callbacks. I guess we can do glut.pure and freeglut.pure, for those
> who know they want freeglut.
freeglut offers some extended mouse support, as well as support for
other devices like graphic tablets IIRC. But most importantly it gives
you a simple way to exit the main loop without exiting the program, or
to write your own main loop altogether. That's pretty useful at times. ;-)
The freeglut extensions are in freeglut_ext.h, so it should be possible
to generate an additional GLUT_EXT.pure module from that in the same
spirit as the GL_*.pure extension modules.
(BTW, there's also a newer spinoff of freeglut named openglut, also on
sf.net, but I haven't taken a look at that yet.)
> By the way: GLUT.pure or glut.pure? GL.pure or gl.pure? GL::Begin
> GL::POLYGON, gl::Begin gl::POLYGON, or even gl::Begin gl::Polygon ...?
> Any preference? I really don't care.
I think that the scheme you have now works pretty well. We might add an
opengl.pure umbrella module which imports GL*.pure, but that's just a
convenience.
Albert Graef
to work. I still have to work around a few quirks, but they're easy to
fix, so we're finally getting somewhere. ;-)
First, one thing that I didn't realize is that all the opengl stuff uses
stdcall on Windos. Which is why the 'extern's segfaulted in the first
place, just like your version did now until I fixed it. (This didn't
affect my homebrew freeglut.dll because I modified it so that it would
use ccall instead.) D'oh!
Second, wglGetProcAddress won't resolve stuff that's in opengl32.dll et
al, and thus all standard GL routines would throw an unsupported
exception. ;-) A combination of wglGetProcAddress with
LoadLibrary/GetProcAddress cures that.
There's still some more stuff left to do:
- GLU and GLUT need to be given the same treatment as the GL/GL_* stuff,
so that these routines are invoked with the proper calling convention on
Winblows.
- I also want to regenerate the GLUT stuff so that the freeglut
extensions become available.
I'd say it's best if I just take care of that now because I know what's
needed and can test it immediately on both Linux and Windoze.
But I'd need the header files you used for generating stuff because
AFAICT the headers I have on my Linux box aren't as complete as yours.
Could you please place these into pure-gl/generator?
Thanks,
sedillard
On Feb 4, 2:30 pm, Albert Graef <Dr.Gr...@t-online.de> wrote:
>
> Second, wglGetProcAddress won't resolve stuff that's in opengl32.dll et
> al, and thus all standard GL routines would throw an unsupported
> exception. ;-) A combination of wglGetProcAddress with
> LoadLibrary/GetProcAddress cures that.
> needed and can test it immediately on both Linux and Windoze.
pure.c.fragment ?
>
> But I'd need the header files you used for generating stuff because
> AFAICT the headers I have on my Linux box aren't as complete as yours.
> Could you please place these into pure-gl/generator?
>
headers into svn because they are not Free, but they are freely
available so you can download them here :
http://www.nvidia.com/object/unix.html
Scott
Albert Graef
> So you've already added this GetProcAddress thing to gl-
> pure.c.fragment ?
Yes it's all in svn now and tested on Linux, I just need to do another
round of tests on Windows now.
Ryan and Eddie, now would be the right time to start testing pure-gl on
OSX and *BSD. :) There are probably quite a few kinks still to be ironed
out there.
Eddie Rucker
> Ryan and Eddie, now would be the right time to start testing pure-gl on
> OSX and *BSD. :) There are probably quite a few kinks still to be ironed
> out there.
I'll try as soon as I get a chance. This week is too hectic!
e.r.
Albert Graef
> Yes it's all in svn now and tested on Linux, I just need to do another
> round of tests on Windows now.
Ok, the latest in svn works fine on both Linux and Windows. Scott, if
you agree we can do a release, I'll then update pure-0.17.msi
accordingly (a version which includes pure-gl-0.4 already sits on my
harddisk).
We can always deal with bug reports on OSX and *BSD later. I don't
expect major hiccups there, most probably we just need to adjust some
link options and have another look at pure-gl.c.fragment.