From entrox at entrox.org Sat Nov 11 15:53:12 2006 From: entrox at entrox.org (Oliver Markovic) Date: Sat, 11 Nov 2006 16:53:12 +0100 Subject: [cl-opengl-devel] Patch to add support for VBOs, PBOs and FBOs + example Message-ID: Hi, I've pushed a patch that adds support for vertex, pixel and framebuffer objects. The latter is not part of core OpenGL yet, so I've added a new file extensions.lisp to the GL bindings. I've also added a new example to misc/ which uses FBOs to render into a texture and display it on a rotating quad; there's a screenshot and link to the code on the front-page of cl- opengl now. I tried to imitate the new iTunes 3D cover style :) Sorry for the long hiatus, but I haven't been able to do any Lisp (e.g. non-paid) programming lately. Question: now that there aren't separate enums anymore, couldn't gl/funcs.lisp be autogenerated too? The reason for it being written by hand was to be able to have distinct enum types as parameters and if we don't do them anymore, there's no point in having to write it manually. -- Oliver Markovic From 00003b at gmail.com Sun Nov 12 08:44:52 2006 From: 00003b at gmail.com (Bart Botta) Date: Sun, 12 Nov 2006 02:44:52 -0600 Subject: [cl-opengl-devel] generating function bindings, extension loading Message-ID: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com> I've been working on generating bindings from the .spec files on opengl.org, and it seems to be to the point where it could be turned into a patch... Before that though, I wanted to get some feedback about changing the naming for the bindings: First suggestion is moving the function bindings to a separate package, and giving them lisp style names, so people like me who want to use them directly have supported access to them. Second is changing the GLenums from cffi:defcenums to defconstants. Advantages I can think of from doing that: *Easier for users to add enums from a new extension without modifying library code (unless cffi allows adding to an enum after it is defined, not sure about that) *Easier to add offsets to them, for example a loop to disable all lights could use (+ index gl:+light0+) instead of having to convert from enum and back, or store a list of the light enums or whatever. *being able to add offsets also solves the problem of some values (light in particular) potentially having more valid values than are enums. (The .spec files name 8 lights, but leaves room for 4096, I'm pretty sure there has been hardware supporting at least 32.) *compatibility with other bindings (glx and cl-sdl both use +foo+ style for enums if I remember correctly) *possibly speed. If cffi can remap values at compile time it probably isn't too bad, but it probably wouldn't be too hard to find code with a lot of enums specified at runtime. (Alternately, is it possible to tell cffi to allow using either the constants or the keywords?) Also, a small patch: someone in #lisp was having problems with OpenMCL objecting to compute-applicable-methods being called with extra arguments in glut/interface.lisp, which was fixed by the following patch to define-glut-event: diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp 130c130 < :func ',event-func :arg-count ,(length args)) --- > :func ',event-func :arg-count ,(length arg-names)) From entrox at entrox.org Sun Nov 12 11:44:47 2006 From: entrox at entrox.org (Oliver Markovic) Date: Sun, 12 Nov 2006 12:44:47 +0100 Subject: [cl-opengl-devel] generating function bindings, extension loading In-Reply-To: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com> References: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com> Message-ID: On 12.11.2006, at 09:44, Bart Botta wrote: > First suggestion is moving the function bindings to a separate > package, and giving them lisp style names, so people like me who want > to use them directly have supported access to them. This is fine by me. > Second is changing the GLenums from cffi:defcenums to defconstants. > Advantages I can think of from doing that: This is not. The whole point of cl-opengl was having hand-written bindings that feel Lispy and not like a direct mapping to C. I do NOT want to write code like (gl:clear-color (logior gl:+color-buffer-bit+ gl:+depth- buffer-bit+)) or having to think about how to construct a foreign array to pass to glLightfv. If somebody wants to use bindings like this, Glouton[1] or kt-opengl [2] seem like a better fit. They follow a different, more direct approach for people who prefer that model. Writing bindings isn't exactly rocket science, so having more than one way to do things is a good thing as far as I'm concerned. > *Easier for users to add enums from a new extension without > modifying library code (unless cffi allows adding to an enum after it > is defined, not sure about that) This sounds like an easy addition to CFFI. > *Easier to add offsets to them, for example a loop to disable all > lights could use (+ index gl:+light0+) instead of having to convert > from enum and back, or store a list of the light enums or whatever. > *being able to add offsets also solves the problem of some values > (light in particular) potentially having more valid values than are > enums. (The .spec files name 8 lights, but leaves room for 4096, I'm > pretty sure there has been hardware supporting at least 32.) The right way (IMHO) would be to have functionality in CFFI to add offsets to enums if desired, but there aren't that many places in OpenGL where this would even apply. Off the top of my head, I can name GL_LIGHTi, GL_AUXi, GL_TEXTUREi, GL_CLIPPLANEi and GL_COLOR_ATTACHMENTi_EXT and I don't know a single graphics card whose limits exceed those defined in the spec/ headers, since a few of these are obsolete anyway thanks to programmable hardware. You can see limits for most Macintosh graphics cards at http://homepage.mac.com/arekkusu/bugs/GLInfo.html I /do/ agree that functions like GL:LIGHT should be able to take both a symbolic and a numeric identifer though, for the reasons you mentioned. But this can be done without ditching CFFI enums. > *compatibility with other bindings (glx and cl-sdl both use +foo+ > style for enums if I remember correctly) I neither care about GLX nor CL-SDL. If neither CLX, nor any other non-C library use +foo+, why should we? Personally, I think it looks way too ugly. > *possibly speed. If cffi can remap values at compile time it > probably isn't too bad, but it probably wouldn't be too hard to find > code with a lot of enums specified at runtime. It does remap values where possible. Here's an example from OpenMCL: ? (defun foo () (gl:clear :color-buffer-bit :depth-buffer-bit)) FOO ? (disassemble 'foo) (TWNEI NARGS 0) (MFLR LOC-PC) (BLA .SPSAVECONTEXTVSP) (STWU SP -80 SP) (STW RZERO 8 SP) (LWZ ARG_Y '# FN) (LWZ ARG_Z 2 ARG_Y) (TWEQI ARG_Z NIL) (VPUSH ARG_Z) (LI IMM0 16640) (STW IMM0 24 SP) (LWZ ARG_Z 0 VSP) (LA VSP 4 VSP) (BLA .SPPOWEROPEN-FFCALL) (LI ARG_Z NIL) (BA .SPPOPJ) Note the LI IMM0 16640. GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT => 0x4100 => 16640. But even then, the performance impact of doing so at runtime is neglible. > Also, a small patch: someone in #lisp was having problems with OpenMCL > objecting to compute-applicable-methods being called with extra > arguments in glut/interface.lisp, which was fixed by the following > patch to define-glut-event: > > diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp > 130c130 > < :func ',event-func :arg-count ,(length > args)) > --- >> :func ',event-func :arg-count ,(length >> arg-names)) Applied, thank you. [1] http://common-lisp.net/project/glouton/ [2] Somewhere in http://common-lisp.net/project/cello/ From 00003b at gmail.com Sun Nov 12 13:51:09 2006 From: 00003b at gmail.com (Bart Botta) Date: Sun, 12 Nov 2006 07:51:09 -0600 Subject: [cl-opengl-devel] generating function bindings, extension loading In-Reply-To: References: <77cb99c00611120044v2c1df8f0y22d3d0d7ad5c165@mail.gmail.com> Message-ID: <77cb99c00611120551q6d0600a4wb2626791cf657a1e@mail.gmail.com> On 11/12/06, Oliver Markovic wrote: > > On 12.11.2006, at 09:44, Bart Botta wrote: > > > Second is changing the GLenums from cffi:defcenums to defconstants. > > Advantages I can think of from doing that: > > This is not. The whole point of cl-opengl was having hand-written > bindings > that feel Lispy and not like a direct mapping to C. I do NOT want to > write > code like (gl:clear-color (logior gl:+color-buffer-bit+ gl:+depth- > buffer-bit+)) > or having to think about how to construct a foreign array to pass to > glLightfv. I'm not arguing that the behavior of the hand written API should change*, just the shape of the parameters. gl:clear still handles combining the arguments, it just uses logior instead of make-bitfield. *(well, actually, I might argue that the API should change, but if I did, the argument would be that cl-opengl is too low level, not that it should be closer to the C API :) > If somebody wants to use bindings like this, Glouton[1] or kt-opengl > [2] seem > like a better fit. Or my bindings if I release them, I was just hoping to have that behavior as a subset of cl-opengl to avoid pointless forks :) > > Off the top of my head, I can name GL_LIGHTi, GL_AUXi, GL_TEXTUREi, > GL_CLIPPLANEi and GL_COLOR_ATTACHMENTi_EXT and I don't know > a single graphics card whose limits exceed those defined in the spec/ > headers, > since a few of these are obsolete anyway thanks to programmable > hardware. I was thinking more of workstation level cards, 3dlabs realizm, etc. http://www.delphi3d.net/hardware/viewreport.php?report=1503 Easy enough to just add more enums to cover the extra if you stay with cffi enums, so it isn't too much of a problem. > > *compatibility with other bindings (glx and cl-sdl both use +foo+ > > style for enums if I remember correctly) > > I neither care about GLX nor CL-SDL. If neither CLX, nor any other > non-C library > use +foo+, why should we? Personally, I think it looks way too ugly. Sorry, I meant CLX, not GLX : http://common-lisp.net/~crhodes/clx/gl.lisp and CL-SDL is a set of lisp bindings for SDL and OpenGL. The 2 libraries you linked both used GL_FOO style constants/defparameters though, so not sure how much it matters. > But even then, the performance impact of doing so at runtime is > neglible. Might be, I'll have to see if I can think of any concrete tests and try it... From entrox at entrox.org Sun Nov 12 15:24:11 2006 From: entrox at entrox.org (Oliver Markovic) Date: Sun, 12 Nov 2006 16:24:11 +0100 Subject: [cl-opengl-devel] generating function bindings, extension loading Message-ID: (gah, I always forget to hit "Reply All") On 12.11.2006, at 14:51, Bart Botta wrote: > I'm not arguing that the behavior of the hand written API should > change*, just the shape of the parameters. gl:clear still handles > combining the arguments, it just uses logior instead of make-bitfield. > > *(well, actually, I might argue that the API should change, but if I > did, the argument would be that cl-opengl is too low level, not that > it should be closer to the C API :) Well, I don't see any significant advantage in doing so. > Or my bindings if I release them, I was just hoping to have that > behavior as a subset of cl-opengl to avoid pointless forks :) It's not pointless fork if it wants to do things differently. This project was originally made to collaborate with Luis Oliveira on writing Lispy OpenGL bindings that suit our personal needs. Nothing more. As I said, writing bindings is not rocket science and one could generate a simple set in an afternoon if desired, so I do not see any harm in having more than one. > I was thinking more of workstation level cards, 3dlabs realizm, etc. > http://www.delphi3d.net/hardware/viewreport.php?report=1503 > > Easy enough to just add more enums to cover the extra if you stay with > cffi enums, so it isn't too much of a problem. Well yeah, it wasn't meant to be dismissive, just that I don't see it as a big problem that would justify switching to defconstants. It's easy to switch those few functions to accept integers instead of enums and have a function like this: (defun enum-value (base value &key (min 0) (max most-positive-fixnum)) (assert (or (keywordp value) (<= min value max))) (if (keywordp value) (foreign-enum-value 'enum value) (+ (foreign-enum-value 'enum base) value))) and change gl:light to use it: (defun light (light pname value) (let ((light-name (enum-value :light0 value :max 4096))) (%glLightfv light-name ...))) There, problem solved. You can now call it like (gl:light :light7 ...) or (gl:light 7 ...) and it should work. We don't even need to define new enums. > Sorry, I meant CLX, not GLX : > http://common-lisp.net/~crhodes/clx/gl.lisp > and CL-SDL is a set of lisp bindings for SDL and OpenGL. > > The 2 libraries you linked both used GL_FOO style > constants/defparameters though, so not sure how much it matters. I didn't even look closely at them to be honest. It's just that I never see any juggling of +constants+ in native Lisp code and think that it's a C-ism that I want to avoid. > Might be, I'll have to see if I can think of any concrete tests and > try it... Sure, it'd be nice to know for certain, but I can't imagine any situation where looking up a few keywords at runtime would be a bottleneck in any shape, way or form unless you construct such a case. You're supposed to minimize the number of OpenGL calls anyway and I expect the cost of doing such a lookup is absolutely dwarfed by the cost of doing the call itself and possibly introducing pipeline bubbles. -- Oliver Markovic From 00003b at gmail.com Mon Nov 13 10:52:44 2006 From: 00003b at gmail.com (Bart Botta) Date: Mon, 13 Nov 2006 04:52:44 -0600 Subject: [cl-opengl-devel] extension loading + wrapper generation Message-ID: <77cb99c00611130252q6b863483vb0b13d450f37a78b@mail.gmail.com> OK, first draft of the wrapper generation/extension loading code is available at http://www.3bb.cc/tmp/cl-opengl-3b.tar.bz2 Let me know if you have any problems/suggestions... main changes: *generates gl/funcs.lisp from gl.spec *uses gl extension support for extensions and functions from versions >= 1.2 - works on win32 (tested with sbcl 0.9.18) - can save cores (tested on sbcl 0.9.18 amd64 linux and x86 win32, and cmucl 19dpre2 x86 linux) *rearranged low level bits into a separate package - cl-opengl-bindings, nickname %gl - basic types, constants, function wrappers *binding names are lisp style - %gl:vertex-3f instead of %glVertex3f *Makefile downloads current .spec files from opengl.org if needed (with wget), then builds gl/constants.lisp, gl/bindings-package.lisp and gl/funcs.lisp *rename calls to %gl* as applicable in gl/*lisp *glut/init.lisp: need to tell extension loader how to get extension pointers from glut (possibly should be some somewhere other than glut:init though?) *misc patches (see end of message) I noticed some of the cl-opengl code uses things like (:pointer gl:double) instead of :pointer for defcfun parameter types, is this something the generated bindings should do also? (and if so, is (:pointer (:pointer foo)) correct syntax for foo**?) Wrapper generator handles either option, just wasn't sure what benefits it had, and if it was worth dropping cffi 0.9.1 support for. Misc patches mentioned above, not part of the extension/wrapper stuff, but needed for testing on my systems: -nvidia 96.29 amd64 linux drivers are returning FRAMEBUFFER_UNSUPPORTED_EXT from the completeness check in misc/render-to-texture.lisp if the texture doesn't have mipmaps - windows GLU doesn't seem to have gluCheckExtension or gluUnProject4 diff -rN -u old-cl-opengl/examples/misc/render-to-texture.lisp new-cl-opengl/examples/misc/render-to-texture.lisp --- old-cl-opengl/examples/misc/render-to-texture.lisp 2006-11-13 04:30:03.000000000 -0600 +++ new-cl-opengl/examples/misc/render-to-texture.lisp 2006-11-13 04:30:03.000000000 -0600 @@ -28,6 +28,8 @@ (gl:tex-parameter :texture-2d :texture-min-filter :linear-mipmap-linear) (gl:tex-parameter :texture-2d :texture-mag-filter :linear) (gl:tex-image-2d :texture-2d 0 :rgba 512 512 0 :rgba :unsigned-byte (cffi:null-pointer)) + (gl:generate-mipmap-ext :texture-2d) + (gl:bind-texture :texture-2d 0) (gl:framebuffer-texture-2d-ext :framebuffer-ext :color-attachment0-ext :texture-2d diff -rN -u old-cl-opengl/glu/glu.lisp new-cl-opengl/glu/glu.lisp --- old-cl-opengl/glu/glu.lisp 2006-11-13 04:30:03.000000000 -0600 +++ new-cl-opengl/glu/glu.lisp 2006-11-13 04:30:03.000000000 -0600 @@ -55,6 +55,7 @@ (defcfun ("gluGetString" get-string) :string (name-keyword string-name)) +#-win32 (defcfun ("gluCheckExtension" check-extension) (:boolean gl:boolean) (extension-name :string) (extension-string :string)) @@ -151,6 +152,7 @@ (obj-y (:pointer gl:double)) (obj-z (:pointer gl:double))) +#-win32 (defcfun ("gluUnProject4" %gluUnProject4) glu-result (win-x gl:ensure-double) (win-y gl:ensure-double) From jamesjb at jamesjb.com Fri Nov 17 01:49:49 2006 From: jamesjb at jamesjb.com (James J Bielman) Date: Thu, 16 Nov 2006 17:49:49 -0800 Subject: [cl-opengl-devel] extension loading + wrapper generation In-Reply-To: <77cb99c00611130252q6b863483vb0b13d450f37a78b@mail.gmail.com> References: <77cb99c00611130252q6b863483vb0b13d450f37a78b@mail.gmail.com> Message-ID: <2619FDC1-3194-4FDE-A975-86F50CC559A1@jamesjb.com> On Nov 13, 2006, at 2:52 AM, Bart Botta wrote: > I noticed some of the cl-opengl code uses things like (:pointer > gl:double) instead of :pointer for defcfun parameter types, is this > something the generated bindings should do also? (and if so, is > (:pointer (:pointer foo)) correct syntax for foo**?) > Wrapper generator handles either option, just wasn't sure what > benefits it had, and if it was worth dropping cffi 0.9.1 support for. I started doing this for new functions that I added bindings for because it was more self-documenting. The previous convention had been to add the pointer type in comments after the argument, which is less than ideal IMHO. Personally I prefer to parameterize the pointer type, but it does indeed require a more recent CFFI. One advantage to this is that when a type checking system is (someday) added to CFFI, the OpenGL bindings should be able to take advantage of it if the pointers are typed. James From luismbo at gmail.com Fri Nov 17 03:06:44 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Fri, 17 Nov 2006 03:06:44 +0000 Subject: [cl-opengl-devel] extension loading + wrapper generation In-Reply-To: <77cb99c00611130252q6b863483vb0b13d450f37a78b@mail.gmail.com> References: <77cb99c00611130252q6b863483vb0b13d450f37a78b@mail.gmail.com> Message-ID: <391f79580611161906m4ec32582u7350900af3b1d944@mail.gmail.com> On 11/13/06, Bart Botta <00003b at gmail.com> wrote: > OK, first draft of the wrapper generation/extension loading code is available > at http://www.3bb.cc/tmp/cl-opengl-3b.tar.bz2 > Let me know if you have any problems/suggestions... Unfortunately I don't time at the moment to test your stuff but your description looks cool. I've applied your patches. Unfortunately, I don't seem to have the EXT_framebuffer_object extension so I couldn't test the render-to-texture example. I hope it didn't break. We should look into giving you repository access. Getting a common-lisp.net account would be the first step if you don't have one already. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/