From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p435s8s5022191 for ; Tue, 3 May 2011 07:54:08 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEBAF2Xv03RVdY2kGdsb2JhbACYFIZQhyQIFAEBAQEJCQ0HFAQhiHKgRop8giqEbjSIXgEBAwaFegSCDYQBiG+IGYIjO4NM X-IronPort-AV: E=Sophos;i="4.64,307,1301868000"; d="scan'208";a="94260649" Received: from mail-bw0-f54.google.com ([209.85.214.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 May 2011 07:54:03 +0200 Received: by bwz12 with SMTP id 12so10608767bwz.27 for ; Mon, 02 May 2011 22:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4dK6xNR1qREsxY9rJSANLUG9R4AAEkQDDujhSQ6MuH8=; b=PYyBEVwZwsMiFV8CHCL6D2hBSstU8osskGOwj4Xo6nO0ShOQ9RI+Dvnejyqli5rPqZ y9NXKtGOsxOGw4cFCRMk67uaFRvrcYFCGi4CONv60gXFj7uv3vIf9wZPIKucBh4+L78f UpupeHu9VcvXz35vSgb97IWVFXW8tjKU52mFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=F+nGwWgg/Eirma2tnopjktTEX3CQPbwqMYP8FdUJoxOvJLQGznVFw5ge89s6ggKvZG EjHdR3Q5H+oTIG5okOWAU/OKWTkLDcdPicsped3jo8IFFWoTY+OgMseGgq9ymZ2hHSc6 OJYPBdk4gFBZCmWmbxaXMSRbaHumrltgUBVy0= MIME-Version: 1.0 Received: by 10.204.16.70 with SMTP id n6mr3992994bka.87.1304402041830; Mon, 02 May 2011 22:54:01 -0700 (PDT) Received: by 10.204.16.129 with HTTP; Mon, 2 May 2011 22:54:01 -0700 (PDT) In-Reply-To: <201105021848.45284.monnier.florent@gmail.com> References: <85360856-DA1E-48C8-B449-BD03EAA4F154@math.nagoya-u.ac.jp> <201105021848.45284.monnier.florent@gmail.com> Date: Mon, 2 May 2011 23:54:01 -0600 Message-ID: From: Anthony Tavener To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=0003255559a258fc5604a258c4d7 Subject: Re: [Caml-list] Pros and cons of different GL bindings ? --0003255559a258fc5604a258c4d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is fantastic work and I'm glad to see LablGL getting shader support! But I've been targeting the reduced set of OpenGL4/GLES2, so my input is more as an observer than potential client. The premise behind the "vector" functions (ending with v), is that if the application already has what amounts to a contiguous array of floats in memory, it's far more efficient to pass the pointer to where it is. This can easily be and often is the case from C code. No so from OCaml (not that this is bad!). First problem in my mind, is that there's going to be a remapping anyway: from OCaml float to "float32". Since we're unable to use the data in-place, it might as well be in any arbitrary form the application wants, but then to avoid two remappings the interface from LablGL must be fairly "raw" (float32 array). Alternatively, the data is structured with types useful in application code and known by the functions. Any way I think of a higher-level construct, it just comes back as being more straight-forward to let the OCaml-side iterate multiple uniform_matrix calls or map to the desired array (float32). Having a somewhat structured input (like array of arrays, or array of tuples) is more cumbersome unless the application-data is already in that form, which I think is unlikely. I wouldn't work with such structures, especially not if they were being remapped anyway. I'd prefer to have, say, a tree of my own matrix type which I then remap once (per frame!) for OpenGL. In C, I would certainly strive for contiguous arrays of floats so the CPU has no additional burden. So, it seems unfortunate, but the interface being as raw as possible makes the most sense to me. If you have LablGL matrices or something, then taking a function which extracts those from a data structure so you can pack them into a float array... that would be nice and high level for the uniform_matrix*v calls. Good luck Florent! So have you moved on from glMLite? Or does it still have a life of it's own and you're helping to modernize LablGL? On Mon, May 2, 2011 at 10:48 AM, Florent Monnier wrote: > Le jeudi 28 avril 2011 02:32:06, Jacques Garrigue a =E9crit : > > On 2011/04/28, at 1:24, Anthony Tavener wrote: > > > Ethan's summary is good. I'll elaborate a bit on glcaml... > > > > > > I use glcaml, but don't recommend it in general. There are two reasons > I > > > chose it: 1. It looks like OpenGL, so my familiarity with it directly > > > translates... the only differences are lowecase GL constants and no > > > parentheses around arguments. 2. It (kind-of) supports features like > > > shaders. > > > > > > What I mean by "kind-of" is that the bindings are broken for a lot of > > > lesser-used features. I've been maintaining my own modifications to > > > support features I need (same with sdlcaml)... though I recently > decided > > > I should follow OpenGL 4 (basically the same as OpenGL ES 2), which > > > strips the interface down to a minimal set heavily reliant on shaders. > > > This is turning into "yet another set of bindings". > > > > > > I know I tried glMLite... but can't remember what problems I > encountered, > > > and I did encounter problems which led me to settle on glcaml. > > > > > > Also, there is one other binding I know, by Jeffrey Scofield, for > OpenGL > > > ES 1, and he uses this for iPhone development: > > > http://psellos.com/ocaml/lablgles-build.html > > > > > > > > > Summary: > > > > > > If you don't need shaders: LablGL > > > > > > If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES > > > > > > If you need shaders: glcaml or glMLite > > > > Actually, LablGL has some shader support, provided by Florent Monnier. > > It has been in CVS for more than a year (file src/glShader.ml), but > somehow > > I never came around to make a new release. > > I'm really sorry for the inconvenience. > > > > If some people could test this code, this would be most helpful, and I > > could make a release in a few weeks. > > > > Jacques Garrigue > > I take the opportunity of this thread to ask to the users what > they would prefer about this module (GlShader). > This is about all the functions which has a "count" parameter in the OCaml > interface (and which wrap a C function which ends with the letter "v" for > vertex probably) > > http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar- > ocaml/lablGL/src/glShader.ml?rev=3D1.1;content-type=3Dtext%2Fx-cvsweb-mar= kup > > http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar- > ocaml/lablGL/src/ml_shader.c?rev=3D1.1;content-type=3Dtext%2Fx-cvsweb-mar= kup > > The array data are currently provided to these functions in a *flatten* > way, > and the question is maybe the users would prefer a more high-level > interface? > A more high-level way would be an array of array or an array of tuples. > > An array of tuples would be the safer but would probably not be the more > easy > to manipulate, while a tuple is immutable. > > An array of array would need to check the size of every sub-array. > With these two alternatives, the "count" parameter would not be needed > anymore. > > Please tell us what you would prefer. > ___ > > doc for glUniform* and glUniformMatrix* : > http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml > ___ > > external uniform4fv: location:int -> count:int -> value:float array -> un= it > =3D > "ml_gluniform4fv" > > CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars > ) > { > int count =3D Int_val(ml_count); > int i, len =3D Wosize_val(vars) / Double_wosize; > GLfloat val[len]; > if (len !=3D (4 * count)) caml_failwith("GlShader.uniform4fv: the array > size > should be a multiple of 4"); > for (i=3D0; i val[i] =3D Double_field(vars, i); > } > LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC) > glUniform4fv( Int_val(location), count, val ); > return Val_unit; > } > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > external uniform_matrix4x3fv: location:int -> count:int -> transpose:bool > -> > value:float array -> unit =3D "ml_gluniformmatrix4x3fv" > > CAMLprim value ml_gluniformmatrix4x3f( > value location, > value transpose, > value mat ) > { > GLfloat val[12]; > int i, len; > len =3D Wosize_val(mat) / Double_wosize; > if (len !=3D 12) caml_failwith("GlShader.uniform_matrix4x3f: array sho= uld > contain 12 floats"); > for (i=3D0; i<12; i++) { > val[i] =3D Double_field(mat, i); > } > LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC) > glUniformMatrix4x3fv( > Int_val(location), > 1, > Bool_val(transpose), > val ); > return Val_unit; > } > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --0003255559a258fc5604a258c4d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is fantastic work and I'm glad to see LablGL getting shader suppor= t! But I've been targeting the reduced set of OpenGL4/GLES2, so my inpu= t is more as an observer than potential client.

The premise behind t= he "vector" functions (ending with v), is that if the application= already has what amounts to a contiguous array of floats in memory, it'= ;s far more efficient to pass the pointer to where it is. This can easily b= e and often is the case from C code. No so from OCaml (not that this is bad= !).

First problem in my mind, is that there's going to be a remapping a= nyway: from OCaml float to "float32". Since we're unable to u= se the data in-place, it might as well be in any arbitrary form the applica= tion wants, but then to avoid two remappings the interface from LablGL must= be fairly "raw" (float32 array). Alternatively, the data is stru= ctured with types useful in application code and known by the functions.

Any way I think of a higher-level construct, it just comes back as bein= g more straight-forward to let the OCaml-side iterate multiple uniform_matr= ix calls or map to the desired array (float32). Having a somewhat structure= d input (like array of arrays, or array of tuples) is more cumbersome unles= s the application-data is already in that form, which I think is unlikely. = I wouldn't work with such structures, especially not if they were being= remapped anyway. I'd prefer to have, say, a tree of my own matrix type= which I then remap once (per frame!) for OpenGL. In C, I would certainly s= trive for contiguous arrays of floats so the CPU has no additional burden.<= br>
So, it seems unfortunate, but the interface being as raw as possible ma= kes the most sense to me. If you have LablGL matrices or something, then ta= king a function which extracts those from a data structure so you can pack = them into a float array... that would be nice and high level for the unifor= m_matrix*v calls.

Good luck Florent! So have you moved on from glMLite? Or does it still = have a life of it's own and you're helping to modernize LablGL?
=

On Mon, May 2, 2011 at 10:48 AM, Florent= Monnier <monnier.florent@gmail.com> wrote:
Le jeudi 28 avril 2011 02:32:06, Jacques Ga= rrigue a =E9crit :
> On 2011/04/28, at 1:24, Anthony Tave= ner wrote:
> > Ethan's summary is good. I'll elaborate a bit on glcaml..= .
> >
> > I use glcaml, but don't recommend it in general. There are tw= o reasons I
> > chose it: 1. It looks like OpenGL, so my familiarity with it dire= ctly
> > translates... the only differences are lowecase GL constants and = no
> > parentheses around arguments. 2. It (kind-of) supports features l= ike
> > shaders.
> >
> > What I mean by "kind-of" is that the bindings are broke= n for a lot of
> > lesser-used features. I've been maintaining my own modificati= ons to
> > support features I need (same with sdlcaml)... though I recently = decided
> > I should follow OpenGL 4 (basically the same as OpenGL ES 2), whi= ch
> > strips the interface down to a minimal set heavily reliant on sha= ders.
> > This is turning into "yet another set of bindings".
> >
> > I know I tried glMLite... but can't remember what problems I = encountered,
> > and I did encounter problems which led me to settle on glcaml.
> >
> > Also, there is one other binding I know, by Jeffrey Scofield, for= OpenGL
> > ES 1, and he uses this for iPhone development:
> > http://psellos.com/ocaml/lablgles-build.html
> >
> >
> > Summary:
> >
> > If you don't need shaders: LablGL
> >
> > If you want to do OpenGL ES 1.x (mobile device, for example): Lab= lGLES
> >
> > If you need shaders: glcaml or glMLite
>
> Actually, LablGL has some shader support, provided by Florent Monnier.=
> It has been in CVS for more than a year (file src/glShader.ml), but so= mehow
> I never came around to make a new release.
> I'm really sorry for the inconvenience.
>
> If some people could test this code, this would be most helpful, and I=
> could make a release in a few weeks.
>
> Jacques Garrigue

I take the opportunity of this thread to ask to the users what<= br> they would prefer about this module (GlShader).
This is about all the functions which has a "count" parameter in = the OCaml
interface (and which wrap a C function which ends with the letter "v&q= uot; for
vertex probably)

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/glShader.ml?rev=3D1.1;content-type=3Dtext%2Fx-cvsweb-marku= p

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/ml_shader.c?rev=3D1.1;content-type=3Dtext%2Fx-cvsweb-marku= p

The array data are currently provided to these functions in a *flatten* way= ,
and the question is maybe the users would prefer a more high-level interfac= e?
A more high-level way would be an array of array or an array of tuples.

An array of tuples would be the safer but would probably not be the more ea= sy
to manipulate, while a tuple is immutable.

An array of array would need to check the size of every sub-array.
With these two alternatives, the "count" parameter would not be n= eeded
anymore.

Please tell us what you would prefer.
___

doc for glUniform* and glUniformMatrix* :
http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml
___

external uniform4fv: location:int -> count:int -> value:float array -= > unit =3D
"ml_gluniform4fv"

CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars = )
{
=A0 =A0int count =3D Int_val(ml_count);
=A0 =A0int i, len =3D Wosize_val(vars) / Double_wosize;
=A0 =A0GLfloat val[len];
=A0 =A0if (len !=3D (4 * count)) caml_failwith("GlShader.uniform4fv: = the array size
should be a multiple of 4");
=A0 =A0for (i=3D0; i<len; i++) {
=A0 =A0 =A0 =A0val[i] =3D Double_field(vars, i);
=A0 =A0}
=A0 =A0LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC)
=A0 =A0glUniform4fv( Int_val(location), count, val );
=A0 =A0return Val_unit;
}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

external uniform_matrix4x3fv: location:int -> count:int -> transpose:= bool ->
value:float array -> unit =3D "ml_gluniformmatrix4x3fv"

CAMLprim value ml_gluniformmatrix4x3f(
=A0 =A0 =A0 =A0value location,
=A0 =A0 =A0 =A0value transpose,
=A0 =A0 =A0 =A0value mat )
{
=A0 =A0GLfloat val[12];
=A0 =A0int i, len;
=A0 =A0len =3D Wosize_val(mat) / Double_wosize;
=A0 =A0if (len !=3D 12) caml_failwith("GlShader.uniform_matrix4x3f: a= rray should
contain 12 floats");
=A0 =A0for (i=3D0; i<12; i++) {
=A0 =A0 =A0 =A0val[i] =3D Double_field(mat, i);
=A0 =A0}
=A0 =A0LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC)
=A0 =A0glUniformMatrix4x3fv(
=A0 =A0 =A0 =A0Int_val(location),
=A0 =A0 =A0 =A01,
=A0 =A0 =A0 =A0Bool_val(transpose),
=A0 =A0 =A0 =A0val );
=A0 =A0return Val_unit;
}


--
Caml-list mailing list. =A0Subscri= ption management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--0003255559a258fc5604a258c4d7--