You can subscribe to this list here.
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(4) |
Dec
(6) |
| 2017 |
Jan
(1) |
Feb
(13) |
Mar
(5) |
Apr
|
May
|
Jun
(4) |
Jul
(7) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|
From: Chris M. <dev...@gm...> - 2017-09-04 19:56:10
|
Thanks! Just what I was looking for. --Chris On 9/3/2017 16:12, kmx wrote: > Hi Chris, > > if you mean packages like: > http://strawberryperl.com/package/kmx/64_libs/gcc71-2017Q2/ > > there are no written guidelines. These ZIPs with external libraries > are built via scripts fom https://github.com/StrawberryPerl/build-extlibs > > -- > kmx > > On 03.09.2017 18:45, Chris Marshall wrote: >> Hi kmx- >> >> I've released OpenGL::GLFW with bindings to the GLFW >> library. At the moment, I don't have Alien::GLFW >> support but looking to that end, I was wondering if >> you have any guidelines for how you typically build >> and name your packages for SPP and SPP+PDL? >> >> Thanks, >> Chris >> > |
|
From: kmx <km...@at...> - 2017-09-03 20:30:48
|
Hi Chris, if you mean packages like: http://strawberryperl.com/package/kmx/64_libs/gcc71-2017Q2/ there are no written guidelines. These ZIPs with external libraries are built via scripts fom https://github.com/StrawberryPerl/build-extlibs -- kmx On 03.09.2017 18:45, Chris Marshall wrote: > Hi kmx- > > I've released OpenGL::GLFW with bindings to the GLFW > library. At the moment, I don't have Alien::GLFW > support but looking to that end, I was wondering if > you have any guidelines for how you typically build > and name your packages for SPP and SPP+PDL? > > Thanks, > Chris > |
|
From: Chris M. <dev...@gm...> - 2017-09-03 16:46:13
|
Hi kmx- I've released OpenGL::GLFW with bindings to the GLFW library. At the moment, I don't have Alien::GLFW support but looking to that end, I was wondering if you have any guidelines for how you typically build and name your packages for SPP and SPP+PDL? Thanks, Chris |
|
From: Chris M. <dev...@gm...> - 2017-08-04 19:49:27
|
I've finished implementing the complete(*) GLFW bindings for perl at https://github.com/devel-chm/OpenGL-GLFW . I believe the module is complete but I have yet to implementthe probing for the GLFW library installation in any form andhelp with that process would be welcome! Please see the TODO.md file in the repository and take a look. Apologies for early users who will have to fix LIBS and INC in the Makefile.PL for their configuration. Thanks for any feedback or help you can provide! Chris * Except for what is not implemented :-) |
|
From: Chris M. <dev...@gm...> - 2017-07-14 14:03:41
|
In addition to the priority_xs routines, any routines having non-arrays of strings for input or output directly translate to perl scalars so they can be generated as "good" routines. There are 71 of these routines which signatures are in the file signatures/badp-XS-sigs/badp-XS-with-GLchar-string and the implementation is basically using a T_PV typemap and fixing the code generation for the function name to not use a suffix. --Chris On Fri, Jul 14, 2017 at 9:33 AM, Chris Marshall <dev...@gm...> wrote: > Some other points: > > * We do have 1265 OpenGL API routines done (the non-pointer ones) > as compared with about the 300 non-suffixed ones in POGL > > * The basis of the implementation is to process the function signatures > from the GLEW extension library to generate the bindings. > > * The priority-xs-code branch is where I have been working on the > signatures and code generation for so called "required" routines > that have been reported to me as being used. > > * See the table of required/priority routines in the issue tracker at > https://github.com/devel-chm/OpenGL-Modern/issues/7 > > * There are about 45 total specific routines in the priority set but > if you include other variants of the same routine, it works out to > 155 routines. See the signatures and notes in utils/priority_xs > and below folders. > > * My first attempt is using the Template library to generate the > code. Still a work in progress... > > Cheers, > Chris > > > On Fri, Jul 14, 2017 at 12:04 AM, Chris Marshall <dev...@gm...> > wrote: > >> Hi Dmitry- >> >> At the moment, there are approximately >> 1483 OpenGL functions that need basic >> (suffixed or not) perl bindings to be >> completed---as discussed the _c to >> get things done doesn't count. :-) >> >> > |
|
From: Chris M. <dev...@gm...> - 2017-07-14 13:33:39
|
Some other points: * We do have 1265 OpenGL API routines done (the non-pointer ones) as compared with about the 300 non-suffixed ones in POGL * The basis of the implementation is to process the function signatures from the GLEW extension library to generate the bindings. * The priority-xs-code branch is where I have been working on the signatures and code generation for so called "required" routines that have been reported to me as being used. * See the table of required/priority routines in the issue tracker at https://github.com/devel-chm/OpenGL-Modern/issues/7 * There are about 45 total specific routines in the priority set but if you include other variants of the same routine, it works out to 155 routines. See the signatures and notes in utils/priority_xs and below folders. * My first attempt is using the Template library to generate the code. Still a work in progress... Cheers, Chris On Fri, Jul 14, 2017 at 12:04 AM, Chris Marshall <dev...@gm...> wrote: > Hi Dmitry- > > At the moment, there are approximately > 1483 OpenGL functions that need basic > (suffixed or not) perl bindings to be > completed---as discussed the _c to > get things done doesn't count. :-) > > |
|
From: Chris M. <dev...@gm...> - 2017-07-14 04:04:36
|
Hi Dmitry-
At the moment, there are approximately
1483 OpenGL functions that need basic
(suffixed or not) perl bindings to be
completed---as discussed the _c to
get things done doesn't count. :-)
Once the basic functionality is working...
There are plenty of directions for providing
completely perlish bindings. Whether to move
the suffixed routines into their own module
versus tags for export or whatever would be
a nice problem to have with full OpenGL API
bindings in a first version.
Regarding performance, there have been
discussions of optimal performance from
perl with specific timings from Mithaldu
and the point being that for some ops,
overhead in the bindings can mean the
difference between 1000 sprites being
renderable from perl OpenGL or no.
Any specific decisions based on performance
would clearly need to be based on actual
timings. Personally, I think any specific
optimized implementations could have their
own suffix and can co-exist with any other
variants historical or going forward.
Cheers,
Chris
On 7/13/2017 18:10, Dmitry Karasik wrote:
> Hi Chris,
>
> I buy the compatibility argument, but I'm rather suspicious of the performance argument -
> I'd like to see the hard numbers. As for the compatibility though, I'd rather propose to break it,
> but provide OpenGL::Modern::Compat that exposes the suffixed calls for users who don't
> want to refactor.
>
> Dmitry
>
> On Thu, Jul 13, 2017 at 05:59:50PM -0400, Chris Marshall wrote:
>> Hi Dmitri-
>>
>> My goal for the function names is clarity, simplicity,
>> unambiguousness, and DWIM. In order to avoid breaking
>> compatibility we'll have the various suffixed names
>> which may always be used and may be desired for peak
>> performance and when things are stable and decided upon,
>> we'll make the prettiest name map to the appropriate
>> implementation. For example: my thought was the _g
>> implementation might be a candidate for the default,
>> non-suffixed name.
>>
>> NOTE: We should probably come up with a way to specify
>> mappings so that folks can use different maps but still
>> be compatible with the official versions.
>>
>> On Thu, Jul 13, 2017 at 5:07 PM, Dmitry Karasik <dm...@ka...>
>> wrote:
>>
>>> Hi Chris,
>>>
>>> I appreciate this effort, I think that shift towards more
>>> perlish API is what needed. The vision I have though is
>>> actually to go another step further - probably you mean the
>>> same by writing "... these bindings are interim only pending
>>> better more perlish or more direct implementations".
>> There are two stages here: (1) where the bindings use
>> perl native types to interface with OpenGL with XS used
>> for any translations needed from perl space to C space
>> (such as hand packing data and getting a pointer), and
>> (2) a more perlish interface that mates well with idiomatic
>> perl language usages and programmer expectations.
>>
>>> But still I'd like to explain what I have in mind, namely,
>>> just one perl function with the same name as the C function.
>>>
>>> I don't pretend I understand all use cases, but I think it will
>>> be possible to write the XS in such a way so that depending on
>>> type arguments passed, it will figure out whether the parameter
>>> is a list of values or a packed string. Also, it seems to be
>>> that _c functions won't be needed, because we can provide a
>>> special wrapper function that can convert an arbitrary memory
>>> buffer from C into a (read-only) perl scalar, which can be
>>> passed as a normal argument.
>> The _c variants are pretty much only to make something
>> operable until the stage 1 bindings are done. Users should
>> no have to pack and unpack data buffers or strings by hand.
>> A basic implementation with a switch based on the arg type
>> say ref($arg) eg ARRAY, SCALAR, PDL, OpenGL::Array along with
>> argument counting could make a seamless call for many use
>> cases.
>>
>>> Packed format will be tricky though. In Prima, I adopted a
>>> similar technique for Prima::array, which is just a blessed
>>> pointer to packed scalar. One can create and extend it in C,
>>> and one can create and extend it in Perl. But surely there are
>>> other ways too.
>> I don't understand why packed format is specifically tricky.
>> In fact, it seems to me to be an artifact of implementation
>> choice that OpenGL::Array uses its own malloc/free'd data
>> rather than the contents of a perl SV.
>>
>>> So as an example let's take a glProgramUniform4fv:
>>>
>>> Case 1: just a perlish call - that'll be glProgramUniform4fv($x,$y,$z,$t),
>>> but can be uneffective, because XS has to construct the memory buffer
>>> and pass it. Yet it will be perlish okay.
>> In OpenGL 4.x the C API call in perl notation is
>> glProgramUniform4fv($program,$location,$count,$values_4f) which I would
>> translate into glProgramUniform4fv($program,$location,@values_4f) or
>> glProgramUniform4fv($program,$location,[@values_4f]) since
>> the $count can be determined by the number of elements in @values_4f
>> by poking the array ref or just gotten from the number of args on
>> the XS call stack.
>>
>> This can still be efficient because in XS we could have a static
>> array of floats and just copy the @values_f4 into them for the call,
>> no malloc/free/New/SafeFree.
>>
>>> Case 2: packed array: that's be glProgramUniform4fv(
>> gl_pack('f',$x,$y,$z,$t))
>>> # f.ex. a OpenGL::Modern::array blessed scalar which will be more
>>> effective because result of gl_pack can be reused.
>> We don't want to make users do the packing but as below, I
>> don't believe special preference should be given to
>> OpenGL::Array objects over [any] other options. In fact,
>> I was thinking we could implement a simple, packed scalar
>> data blob type that could be used for many/most of the
>> OpenGL::Modern pointer/array objects. For example, it would
>> be easy to "cast" the packed data of a piddle into the
>> Packed::Array type for the OpenGL operations.
>>
>>> Case 3: SDL/PDL/memory buffer: glProgramUniform4fv( gl_ptr( $piddle ));
>>> gl_ptr() creates a readonly scalar pointing to the buffer; dangerous
>>> if buffer is freed before the scalar.
>> The usage for OpenGL 4.x would be
>> glProgramUniform4fv($program,$location,$oga) for the OpenGL::Array case,
>> glProgramUniform4fv($program,$location,$pdl) for the PDL case,
>> glProgramUniform4fv($program,$location,$packed_array_data) for Packed::Array
>> which might be a class but I was thinking could also be a role that we
>> check for and use. Then a module wanting to "just work with OpenGL::Modern"
>> could implement and/or compose the role for their object....
>>
>>> The getter, f.ex. glGetnUniformfv would be subject to similar cases:
>>>
>>> Case 1: perlish - @v = glGetnUniformfv(...)
>>>
>>> Case 2: packed array - glGetnUniformfv(..., $result_of_gl_pack); # can be
>> expanded, one shouldn't care for buffer overflow
>>> or, alternatively, using wantarray:
>>>
>>> @v = gl_unpack('f', glGetnUniformfv(...))
>>>
>>> or
>>>
>>> @v = @{ glGetnUniformfv(...) } if the representation of the packed array
>> implements Tie::Array::FETCH.
>>> Case 3: SDL/PDL - glGetnUniformfv(..., $result_of_gl_ptr); # won't be
>> expanded, will die if length is insufficient
>>> In my eyes it would be more DWIM'my to go in this direction, and cause
>> less
>>> confusion on guidelies how to implement new functions. I'm not aware of
>> OGA
>>> difficulties but I hope that this use case can be also handled in a smart
>> way
>>> by the XS.
>> Alot of these cases will depend on what users use. As mentioned
>> above, we'll already have suffixed routines to implement any
>> specific desired features.
>>
>> Thanks for the ideas,
>> Chris
>>
>>> On Thu, Jul 13, 2017 at 03:45:59PM -0400, Chris Marshall wrote:
>>>> This is a quick email on my current plans for OpenGL::Modern
>>>> bindings and the function naming convention(s). There are a
>>>> number of (possibly conflicting) goals:
>>>>
>>>> (1) Consistent and simple relation to the base C OpenGL API names
>>>>
>>>> To keep things simple, we need to have bindings for Perl that
>>>> correlate fully with the native C API. This makes for simple
>> translation
>>>> between C OpenGL program conventions and Perl OpenGL::Modern
>>>> program ones.
>>>>
>>>> The original Perl OpenGL module (POGL) had four classes of
>>>> routine names. For routines taking and/or returning *only* scalar
>>>> arguments (no pointers * or arrays []) the names were the same
>>>> as the C OpenGL routine being bound.
>>>>
>>>> Routines having pointers and/or C array data inputs or outputs
>>>> are given a suffix to indicate the implementation: '_c' for raw
>>>> C-pointer type binding, '_p' for a more perlish interface (for example
>>>> returning multiple args rather than using pointers valued inputs),
>>>> and '_s' for bindings using data in a packed scalar format (such
>>>> as SDL or PDL). While these general namings are used in
>>>> OpenGL::Modern as well, there are some inconsistencies that
>>>> will be noted and corresponding changes needed for clarity.
>>>>
>>>> (2) Maintain compatibility with POGL bindings as possible
>>>>
>>>> As with POGL, perl bindings to OpenGL API routine having
>>>> no pointer or C array input arguments or return values have
>>>> the identical name as the C API. These non-suffixed names
>>>> in OpenGL::Modern are the same where a POGL binding
>>>> exists although the POGL bindings cover about 1/4th of
>>>> the ones in OpenGL::Modern.
>>>>
>>>> Any OpenGL API routine having a pointer * or C array []
>>>> argument or return value have a binding with a '_c' suffix
>>>> that is implemented with raw C pointers. It is up to the
>>>> perl user to create the needed pointer values for input/output
>>>> and to translate the data sent/received correctly. These
>>>> bindings are interim only pending better more perlish or
>>>> more direct implementations:
>>>>
>>>> * null terminated strings map directly to/from perl
>>>> and their '_c' binding needs to be direct to perl with the
>>>> name either having '_p' or for single strings IN/OUT
>>>> the non-suffixed version is appropriate.
>>>>
>>>> * OpenGL routines with names like glXxxx[#][type]v should
>>>> take variable numbers of arguments and/or return an
>>>> array of results and be named with a '_p'.
>>>>
>>>> * Routines in POGL using OpenGL::Array arguments are
>>>> being renamed with a '_o' suffix for OGA from the confusing
>>>> '_p' name which preferentially selected OpenGL::Arrays as
>>>> the preferred binary data implementation over PDL or other
>>>> possible representation.
>>>>
>>>> (3) Make room for nice, friendly, default perlish bindings
>>>>
>>>> * Bindings that can handle multiple input options in a
>>>> simple and symmetric fashion are planned to be given
>>>> a '_g' suffix for general. If performance is sufficient, the
>>>> "friendly" bindings might eventually become the default,
>>>> non-suffixed version.
>>>>
>>>> * Generic bindings without specific numerical data types
>>>> could have an OpenGL::Modern name with all the [#][type]
>>>> stuff removed.
>>>>
>>>> * POGL used glp[A-Z]... to indicate new routines in the
>>>> perl bindings that were implemented. This can be maintained
>>>> for compatibility. In fact, the misleading glGetVersion() routine
>>>> will likely be renamed glpGetVersion() since there is no
>>>> OpenGL routine named glGetVersion().
>>>>
>>>> As OpenGL::Modern is still a work in progress, there is
>>>> room for comment and changes as things evolve. The above
>>>> naming strategy seems best suited to meet needs of
>>>> back-compatibility to POGL and yet having room for a
>>>> better set of bindings going forward.
>>>>
>>>> Cheers,
>>>> Chris
>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Pogl-devel mailing list
>>>> Pog...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pogl-devel
>>>
>>> --
>>> Sincerely,
>>> Dmitry Karasik
>>>
>>>
|
|
From: Dmitry K. <dm...@ka...> - 2017-07-13 22:10:27
|
Hi Chris,
I buy the compatibility argument, but I'm rather suspicious of the performance argument -
I'd like to see the hard numbers. As for the compatibility though, I'd rather propose to break it,
but provide OpenGL::Modern::Compat that exposes the suffixed calls for users who don't
want to refactor.
Dmitry
On Thu, Jul 13, 2017 at 05:59:50PM -0400, Chris Marshall wrote:
> Hi Dmitri-
>
> My goal for the function names is clarity, simplicity,
> unambiguousness, and DWIM. In order to avoid breaking
> compatibility we'll have the various suffixed names
> which may always be used and may be desired for peak
> performance and when things are stable and decided upon,
> we'll make the prettiest name map to the appropriate
> implementation. For example: my thought was the _g
> implementation might be a candidate for the default,
> non-suffixed name.
>
> NOTE: We should probably come up with a way to specify
> mappings so that folks can use different maps but still
> be compatible with the official versions.
>
> On Thu, Jul 13, 2017 at 5:07 PM, Dmitry Karasik <dm...@ka...>
> wrote:
>
> > Hi Chris,
> >
> > I appreciate this effort, I think that shift towards more
> > perlish API is what needed. The vision I have though is
> > actually to go another step further - probably you mean the
> > same by writing "... these bindings are interim only pending
> > better more perlish or more direct implementations".
>
> There are two stages here: (1) where the bindings use
> perl native types to interface with OpenGL with XS used
> for any translations needed from perl space to C space
> (such as hand packing data and getting a pointer), and
> (2) a more perlish interface that mates well with idiomatic
> perl language usages and programmer expectations.
>
> > But still I'd like to explain what I have in mind, namely,
> > just one perl function with the same name as the C function.
> >
> > I don't pretend I understand all use cases, but I think it will
> > be possible to write the XS in such a way so that depending on
> > type arguments passed, it will figure out whether the parameter
> > is a list of values or a packed string. Also, it seems to be
> > that _c functions won't be needed, because we can provide a
> > special wrapper function that can convert an arbitrary memory
> > buffer from C into a (read-only) perl scalar, which can be
> > passed as a normal argument.
>
> The _c variants are pretty much only to make something
> operable until the stage 1 bindings are done. Users should
> no have to pack and unpack data buffers or strings by hand.
> A basic implementation with a switch based on the arg type
> say ref($arg) eg ARRAY, SCALAR, PDL, OpenGL::Array along with
> argument counting could make a seamless call for many use
> cases.
>
> > Packed format will be tricky though. In Prima, I adopted a
> > similar technique for Prima::array, which is just a blessed
> > pointer to packed scalar. One can create and extend it in C,
> > and one can create and extend it in Perl. But surely there are
> > other ways too.
>
> I don't understand why packed format is specifically tricky.
> In fact, it seems to me to be an artifact of implementation
> choice that OpenGL::Array uses its own malloc/free'd data
> rather than the contents of a perl SV.
>
> > So as an example let's take a glProgramUniform4fv:
> >
> > Case 1: just a perlish call - that'll be glProgramUniform4fv($x,$y,$z,$t),
> > but can be uneffective, because XS has to construct the memory buffer
> > and pass it. Yet it will be perlish okay.
>
> In OpenGL 4.x the C API call in perl notation is
> glProgramUniform4fv($program,$location,$count,$values_4f) which I would
> translate into glProgramUniform4fv($program,$location,@values_4f) or
> glProgramUniform4fv($program,$location,[@values_4f]) since
> the $count can be determined by the number of elements in @values_4f
> by poking the array ref or just gotten from the number of args on
> the XS call stack.
>
> This can still be efficient because in XS we could have a static
> array of floats and just copy the @values_f4 into them for the call,
> no malloc/free/New/SafeFree.
>
> > Case 2: packed array: that's be glProgramUniform4fv(
> gl_pack('f',$x,$y,$z,$t))
> > # f.ex. a OpenGL::Modern::array blessed scalar which will be more
> > effective because result of gl_pack can be reused.
>
> We don't want to make users do the packing but as below, I
> don't believe special preference should be given to
> OpenGL::Array objects over [any] other options. In fact,
> I was thinking we could implement a simple, packed scalar
> data blob type that could be used for many/most of the
> OpenGL::Modern pointer/array objects. For example, it would
> be easy to "cast" the packed data of a piddle into the
> Packed::Array type for the OpenGL operations.
>
> > Case 3: SDL/PDL/memory buffer: glProgramUniform4fv( gl_ptr( $piddle ));
> > gl_ptr() creates a readonly scalar pointing to the buffer; dangerous
> > if buffer is freed before the scalar.
>
> The usage for OpenGL 4.x would be
> glProgramUniform4fv($program,$location,$oga) for the OpenGL::Array case,
> glProgramUniform4fv($program,$location,$pdl) for the PDL case,
> glProgramUniform4fv($program,$location,$packed_array_data) for Packed::Array
> which might be a class but I was thinking could also be a role that we
> check for and use. Then a module wanting to "just work with OpenGL::Modern"
> could implement and/or compose the role for their object....
>
> > The getter, f.ex. glGetnUniformfv would be subject to similar cases:
> >
> > Case 1: perlish - @v = glGetnUniformfv(...)
> >
> > Case 2: packed array - glGetnUniformfv(..., $result_of_gl_pack); # can be
> expanded, one shouldn't care for buffer overflow
> >
> > or, alternatively, using wantarray:
> >
> > @v = gl_unpack('f', glGetnUniformfv(...))
> >
> > or
> >
> > @v = @{ glGetnUniformfv(...) } if the representation of the packed array
> implements Tie::Array::FETCH.
> >
> > Case 3: SDL/PDL - glGetnUniformfv(..., $result_of_gl_ptr); # won't be
> expanded, will die if length is insufficient
> >
> > In my eyes it would be more DWIM'my to go in this direction, and cause
> less
> > confusion on guidelies how to implement new functions. I'm not aware of
> OGA
> > difficulties but I hope that this use case can be also handled in a smart
> way
> > by the XS.
>
> Alot of these cases will depend on what users use. As mentioned
> above, we'll already have suffixed routines to implement any
> specific desired features.
>
> Thanks for the ideas,
> Chris
>
> > On Thu, Jul 13, 2017 at 03:45:59PM -0400, Chris Marshall wrote:
> > > This is a quick email on my current plans for OpenGL::Modern
> > > bindings and the function naming convention(s). There are a
> > > number of (possibly conflicting) goals:
> > >
> > > (1) Consistent and simple relation to the base C OpenGL API names
> > >
> > > To keep things simple, we need to have bindings for Perl that
> > > correlate fully with the native C API. This makes for simple
> translation
> > > between C OpenGL program conventions and Perl OpenGL::Modern
> > > program ones.
> > >
> > > The original Perl OpenGL module (POGL) had four classes of
> > > routine names. For routines taking and/or returning *only* scalar
> > > arguments (no pointers * or arrays []) the names were the same
> > > as the C OpenGL routine being bound.
> > >
> > > Routines having pointers and/or C array data inputs or outputs
> > > are given a suffix to indicate the implementation: '_c' for raw
> > > C-pointer type binding, '_p' for a more perlish interface (for example
> > > returning multiple args rather than using pointers valued inputs),
> > > and '_s' for bindings using data in a packed scalar format (such
> > > as SDL or PDL). While these general namings are used in
> > > OpenGL::Modern as well, there are some inconsistencies that
> > > will be noted and corresponding changes needed for clarity.
> > >
> > > (2) Maintain compatibility with POGL bindings as possible
> > >
> > > As with POGL, perl bindings to OpenGL API routine having
> > > no pointer or C array input arguments or return values have
> > > the identical name as the C API. These non-suffixed names
> > > in OpenGL::Modern are the same where a POGL binding
> > > exists although the POGL bindings cover about 1/4th of
> > > the ones in OpenGL::Modern.
> > >
> > > Any OpenGL API routine having a pointer * or C array []
> > > argument or return value have a binding with a '_c' suffix
> > > that is implemented with raw C pointers. It is up to the
> > > perl user to create the needed pointer values for input/output
> > > and to translate the data sent/received correctly. These
> > > bindings are interim only pending better more perlish or
> > > more direct implementations:
> > >
> > > * null terminated strings map directly to/from perl
> > > and their '_c' binding needs to be direct to perl with the
> > > name either having '_p' or for single strings IN/OUT
> > > the non-suffixed version is appropriate.
> > >
> > > * OpenGL routines with names like glXxxx[#][type]v should
> > > take variable numbers of arguments and/or return an
> > > array of results and be named with a '_p'.
> > >
> > > * Routines in POGL using OpenGL::Array arguments are
> > > being renamed with a '_o' suffix for OGA from the confusing
> > > '_p' name which preferentially selected OpenGL::Arrays as
> > > the preferred binary data implementation over PDL or other
> > > possible representation.
> > >
> > > (3) Make room for nice, friendly, default perlish bindings
> > >
> > > * Bindings that can handle multiple input options in a
> > > simple and symmetric fashion are planned to be given
> > > a '_g' suffix for general. If performance is sufficient, the
> > > "friendly" bindings might eventually become the default,
> > > non-suffixed version.
> > >
> > > * Generic bindings without specific numerical data types
> > > could have an OpenGL::Modern name with all the [#][type]
> > > stuff removed.
> > >
> > > * POGL used glp[A-Z]... to indicate new routines in the
> > > perl bindings that were implemented. This can be maintained
> > > for compatibility. In fact, the misleading glGetVersion() routine
> > > will likely be renamed glpGetVersion() since there is no
> > > OpenGL routine named glGetVersion().
> > >
> > > As OpenGL::Modern is still a work in progress, there is
> > > room for comment and changes as things evolve. The above
> > > naming strategy seems best suited to meet needs of
> > > back-compatibility to POGL and yet having room for a
> > > better set of bindings going forward.
> > >
> > > Cheers,
> > > Chris
> >
> > >
> ------------------------------------------------------------------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> > > _______________________________________________
> > > Pogl-devel mailing list
> > > Pog...@li...
> > > https://lists.sourceforge.net/lists/listinfo/pogl-devel
> >
> >
> > --
> > Sincerely,
> > Dmitry Karasik
> >
> >
--
Sincerely,
Dmitry Karasik
|
|
From: Chris M. <dev...@gm...> - 2017-07-13 21:59:58
|
Hi Dmitri-
My goal for the function names is clarity, simplicity,
unambiguousness, and DWIM. In order to avoid breaking
compatibility we'll have the various suffixed names
which may always be used and may be desired for peak
performance and when things are stable and decided upon,
we'll make the prettiest name map to the appropriate
implementation. For example: my thought was the _g
implementation might be a candidate for the default,
non-suffixed name.
NOTE: We should probably come up with a way to specify
mappings so that folks can use different maps but still
be compatible with the official versions.
On Thu, Jul 13, 2017 at 5:07 PM, Dmitry Karasik <dm...@ka...>
wrote:
> Hi Chris,
>
> I appreciate this effort, I think that shift towards more
> perlish API is what needed. The vision I have though is
> actually to go another step further - probably you mean the
> same by writing "... these bindings are interim only pending
> better more perlish or more direct implementations".
There are two stages here: (1) where the bindings use
perl native types to interface with OpenGL with XS used
for any translations needed from perl space to C space
(such as hand packing data and getting a pointer), and
(2) a more perlish interface that mates well with idiomatic
perl language usages and programmer expectations.
> But still I'd like to explain what I have in mind, namely,
> just one perl function with the same name as the C function.
>
> I don't pretend I understand all use cases, but I think it will
> be possible to write the XS in such a way so that depending on
> type arguments passed, it will figure out whether the parameter
> is a list of values or a packed string. Also, it seems to be
> that _c functions won't be needed, because we can provide a
> special wrapper function that can convert an arbitrary memory
> buffer from C into a (read-only) perl scalar, which can be
> passed as a normal argument.
The _c variants are pretty much only to make something
operable until the stage 1 bindings are done. Users should
no have to pack and unpack data buffers or strings by hand.
A basic implementation with a switch based on the arg type
say ref($arg) eg ARRAY, SCALAR, PDL, OpenGL::Array along with
argument counting could make a seamless call for many use
cases.
> Packed format will be tricky though. In Prima, I adopted a
> similar technique for Prima::array, which is just a blessed
> pointer to packed scalar. One can create and extend it in C,
> and one can create and extend it in Perl. But surely there are
> other ways too.
I don't understand why packed format is specifically tricky.
In fact, it seems to me to be an artifact of implementation
choice that OpenGL::Array uses its own malloc/free'd data
rather than the contents of a perl SV.
> So as an example let's take a glProgramUniform4fv:
>
> Case 1: just a perlish call - that'll be glProgramUniform4fv($x,$y,$z,$t),
> but can be uneffective, because XS has to construct the memory buffer
> and pass it. Yet it will be perlish okay.
In OpenGL 4.x the C API call in perl notation is
glProgramUniform4fv($program,$location,$count,$values_4f) which I would
translate into glProgramUniform4fv($program,$location,@values_4f) or
glProgramUniform4fv($program,$location,[@values_4f]) since
the $count can be determined by the number of elements in @values_4f
by poking the array ref or just gotten from the number of args on
the XS call stack.
This can still be efficient because in XS we could have a static
array of floats and just copy the @values_f4 into them for the call,
no malloc/free/New/SafeFree.
> Case 2: packed array: that's be glProgramUniform4fv(
gl_pack('f',$x,$y,$z,$t))
> # f.ex. a OpenGL::Modern::array blessed scalar which will be more
> effective because result of gl_pack can be reused.
We don't want to make users do the packing but as below, I
don't believe special preference should be given to
OpenGL::Array objects over [any] other options. In fact,
I was thinking we could implement a simple, packed scalar
data blob type that could be used for many/most of the
OpenGL::Modern pointer/array objects. For example, it would
be easy to "cast" the packed data of a piddle into the
Packed::Array type for the OpenGL operations.
> Case 3: SDL/PDL/memory buffer: glProgramUniform4fv( gl_ptr( $piddle ));
> gl_ptr() creates a readonly scalar pointing to the buffer; dangerous
> if buffer is freed before the scalar.
The usage for OpenGL 4.x would be
glProgramUniform4fv($program,$location,$oga) for the OpenGL::Array case,
glProgramUniform4fv($program,$location,$pdl) for the PDL case,
glProgramUniform4fv($program,$location,$packed_array_data) for Packed::Array
which might be a class but I was thinking could also be a role that we
check for and use. Then a module wanting to "just work with OpenGL::Modern"
could implement and/or compose the role for their object....
> The getter, f.ex. glGetnUniformfv would be subject to similar cases:
>
> Case 1: perlish - @v = glGetnUniformfv(...)
>
> Case 2: packed array - glGetnUniformfv(..., $result_of_gl_pack); # can be
expanded, one shouldn't care for buffer overflow
>
> or, alternatively, using wantarray:
>
> @v = gl_unpack('f', glGetnUniformfv(...))
>
> or
>
> @v = @{ glGetnUniformfv(...) } if the representation of the packed array
implements Tie::Array::FETCH.
>
> Case 3: SDL/PDL - glGetnUniformfv(..., $result_of_gl_ptr); # won't be
expanded, will die if length is insufficient
>
> In my eyes it would be more DWIM'my to go in this direction, and cause
less
> confusion on guidelies how to implement new functions. I'm not aware of
OGA
> difficulties but I hope that this use case can be also handled in a smart
way
> by the XS.
Alot of these cases will depend on what users use. As mentioned
above, we'll already have suffixed routines to implement any
specific desired features.
Thanks for the ideas,
Chris
> On Thu, Jul 13, 2017 at 03:45:59PM -0400, Chris Marshall wrote:
> > This is a quick email on my current plans for OpenGL::Modern
> > bindings and the function naming convention(s). There are a
> > number of (possibly conflicting) goals:
> >
> > (1) Consistent and simple relation to the base C OpenGL API names
> >
> > To keep things simple, we need to have bindings for Perl that
> > correlate fully with the native C API. This makes for simple
translation
> > between C OpenGL program conventions and Perl OpenGL::Modern
> > program ones.
> >
> > The original Perl OpenGL module (POGL) had four classes of
> > routine names. For routines taking and/or returning *only* scalar
> > arguments (no pointers * or arrays []) the names were the same
> > as the C OpenGL routine being bound.
> >
> > Routines having pointers and/or C array data inputs or outputs
> > are given a suffix to indicate the implementation: '_c' for raw
> > C-pointer type binding, '_p' for a more perlish interface (for example
> > returning multiple args rather than using pointers valued inputs),
> > and '_s' for bindings using data in a packed scalar format (such
> > as SDL or PDL). While these general namings are used in
> > OpenGL::Modern as well, there are some inconsistencies that
> > will be noted and corresponding changes needed for clarity.
> >
> > (2) Maintain compatibility with POGL bindings as possible
> >
> > As with POGL, perl bindings to OpenGL API routine having
> > no pointer or C array input arguments or return values have
> > the identical name as the C API. These non-suffixed names
> > in OpenGL::Modern are the same where a POGL binding
> > exists although the POGL bindings cover about 1/4th of
> > the ones in OpenGL::Modern.
> >
> > Any OpenGL API routine having a pointer * or C array []
> > argument or return value have a binding with a '_c' suffix
> > that is implemented with raw C pointers. It is up to the
> > perl user to create the needed pointer values for input/output
> > and to translate the data sent/received correctly. These
> > bindings are interim only pending better more perlish or
> > more direct implementations:
> >
> > * null terminated strings map directly to/from perl
> > and their '_c' binding needs to be direct to perl with the
> > name either having '_p' or for single strings IN/OUT
> > the non-suffixed version is appropriate.
> >
> > * OpenGL routines with names like glXxxx[#][type]v should
> > take variable numbers of arguments and/or return an
> > array of results and be named with a '_p'.
> >
> > * Routines in POGL using OpenGL::Array arguments are
> > being renamed with a '_o' suffix for OGA from the confusing
> > '_p' name which preferentially selected OpenGL::Arrays as
> > the preferred binary data implementation over PDL or other
> > possible representation.
> >
> > (3) Make room for nice, friendly, default perlish bindings
> >
> > * Bindings that can handle multiple input options in a
> > simple and symmetric fashion are planned to be given
> > a '_g' suffix for general. If performance is sufficient, the
> > "friendly" bindings might eventually become the default,
> > non-suffixed version.
> >
> > * Generic bindings without specific numerical data types
> > could have an OpenGL::Modern name with all the [#][type]
> > stuff removed.
> >
> > * POGL used glp[A-Z]... to indicate new routines in the
> > perl bindings that were implemented. This can be maintained
> > for compatibility. In fact, the misleading glGetVersion() routine
> > will likely be renamed glpGetVersion() since there is no
> > OpenGL routine named glGetVersion().
> >
> > As OpenGL::Modern is still a work in progress, there is
> > room for comment and changes as things evolve. The above
> > naming strategy seems best suited to meet needs of
> > back-compatibility to POGL and yet having room for a
> > better set of bindings going forward.
> >
> > Cheers,
> > Chris
>
> >
------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> > _______________________________________________
> > Pogl-devel mailing list
> > Pog...@li...
> > https://lists.sourceforge.net/lists/listinfo/pogl-devel
>
>
> --
> Sincerely,
> Dmitry Karasik
>
>
|
|
From: Dmitry K. <dm...@ka...> - 2017-07-13 21:08:14
|
Hi Chris,
I appreciate this effort, I think that shift towards more perlish API is what
needed. The vision I have though is actually to go another step further -
probably you mean the same by writing "... these bindings are interim only
pending better more perlish or more direct implementations". But still I'd like
to explain what I have in mind, namely, just one perl function with the same
name as the C function.
I don't pretent I understand all use cases, but I think it will be possible to
write the XS in such a way so that depending on type arguments passed, it will
figure out whether the parameter is a list of values or a packed string.
Also, it seems to be that _c functions won't be needed, because we can provide a
special wrapper function that can convert an arbitrary memory buffer from C
into a (read-only) perl scalar, which can be passed as a normal argument.
Packed format will be tricky though. In Prima, I adopted a similar technique
for Prima::array, which is just a blessed pointer to packed scalar. One can
create and extend it in C, and one can create and extend it in Perl. But surely
there are other ways too.
So as an example let's take a glProgramUniform4fv:
Case 1: just a perlish call - that'll be glProgramUniform4fv($x,$y,$z,$t), but
can be uneffective, because XS has to construct the memory buffer and pass it.
Yet it will be perlish okay.
Case 2: packed array: that's be glProgramUniform4fv( gl_pack('f',$x,$y,$z,$t)) # f.ex. a OpenGL::Modern::array blessed scalar
which will be more effective because result of gl_pack can be reused.
Case 3: SDL/PDL/memory buffer: glProgramUniform4fv( gl_ptr( $piddle ));
gl_ptr() creates a readonly scalar pointing to the buffer; dangerous if buffer is freed before the
scalar.
The getter, f.ex. glGetnUniformfv would be subject to similar cases:
Case 1: perlish - @v = glGetnUniformfv(...)
Case 2: packed array - glGetnUniformfv(..., $result_of_gl_pack); # can be expanded, one shouldn't care for buffer overflow
or, alternatively, using wantarray:
@v = gl_unpack('f', glGetnUniformfv(...))
or
@v = @{ glGetnUniformfv(...) } if the representation of the packed array implements Tie::Array::FETCH.
Case 3: SDL/PDL - glGetnUniformfv(..., $result_of_gl_ptr); # won't be expanded, will die if length is insufficient
In my eyes it would be more DWIM'my to go in this direction, and cause less
confusion on guidelies how to implement new functions. I'm not aware of OGA
difficulties but I hope that this use case can be also handled in a smart way
by the XS.
Dmitry
On Thu, Jul 13, 2017 at 03:45:59PM -0400, Chris Marshall wrote:
> This is a quick email on my current plans for OpenGL::Modern
> bindings and the function naming convention(s). There are a
> number of (possibly conflicting) goals:
>
> (1) Consistent and simple relation to the base C OpenGL API names
>
> To keep things simple, we need to have bindings for Perl that
> correlate fully with the native C API. This makes for simple translation
> between C OpenGL program conventions and Perl OpenGL::Modern
> program ones.
>
> The original Perl OpenGL module (POGL) had four classes of
> routine names. For routines taking and/or returning *only* scalar
> arguments (no pointers * or arrays []) the names were the same
> as the C OpenGL routine being bound.
>
> Routines having pointers and/or C array data inputs or outputs
> are given a suffix to indicate the implementation: '_c' for raw
> C-pointer type binding, '_p' for a more perlish interface (for example
> returning multiple args rather than using pointers valued inputs),
> and '_s' for bindings using data in a packed scalar format (such
> as SDL or PDL). While these general namings are used in
> OpenGL::Modern as well, there are some inconsistencies that
> will be noted and corresponding changes needed for clarity.
>
> (2) Maintain compatibility with POGL bindings as possible
>
> As with POGL, perl bindings to OpenGL API routine having
> no pointer or C array input arguments or return values have
> the identical name as the C API. These non-suffixed names
> in OpenGL::Modern are the same where a POGL binding
> exists although the POGL bindings cover about 1/4th of
> the ones in OpenGL::Modern.
>
> Any OpenGL API routine having a pointer * or C array []
> argument or return value have a binding with a '_c' suffix
> that is implemented with raw C pointers. It is up to the
> perl user to create the needed pointer values for input/output
> and to translate the data sent/received correctly. These
> bindings are interim only pending better more perlish or
> more direct implementations:
>
> * null terminated strings map directly to/from perl
> and their '_c' binding needs to be direct to perl with the
> name either having '_p' or for single strings IN/OUT
> the non-suffixed version is appropriate.
>
> * OpenGL routines with names like glXxxx[#][type]v should
> take variable numbers of arguments and/or return an
> array of results and be named with a '_p'.
>
> * Routines in POGL using OpenGL::Array arguments are
> being renamed with a '_o' suffix for OGA from the confusing
> '_p' name which preferentially selected OpenGL::Arrays as
> the preferred binary data implementation over PDL or other
> possible representation.
>
> (3) Make room for nice, friendly, default perlish bindings
>
> * Bindings that can handle multiple input options in a
> simple and symmetric fashion are planned to be given
> a '_g' suffix for general. If performance is sufficient, the
> "friendly" bindings might eventually become the default,
> non-suffixed version.
>
> * Generic bindings without specific numerical data types
> could have an OpenGL::Modern name with all the [#][type]
> stuff removed.
>
> * POGL used glp[A-Z]... to indicate new routines in the
> perl bindings that were implemented. This can be maintained
> for compatibility. In fact, the misleading glGetVersion() routine
> will likely be renamed glpGetVersion() since there is no
> OpenGL routine named glGetVersion().
>
> As OpenGL::Modern is still a work in progress, there is
> room for comment and changes as things evolve. The above
> naming strategy seems best suited to meet needs of
> back-compatibility to POGL and yet having room for a
> better set of bindings going forward.
>
> Cheers,
> Chris
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pogl-devel mailing list
> Pog...@li...
> https://lists.sourceforge.net/lists/listinfo/pogl-devel
--
Sincerely,
Dmitry Karasik
|
|
From: Chris M. <dev...@gm...> - 2017-07-13 19:46:07
|
This is a quick email on my current plans for OpenGL::Modern bindings and the function naming convention(s). There are a number of (possibly conflicting) goals: (1) Consistent and simple relation to the base C OpenGL API names To keep things simple, we need to have bindings for Perl that correlate fully with the native C API. This makes for simple translation between C OpenGL program conventions and Perl OpenGL::Modern program ones. The original Perl OpenGL module (POGL) had four classes of routine names. For routines taking and/or returning *only* scalar arguments (no pointers * or arrays []) the names were the same as the C OpenGL routine being bound. Routines having pointers and/or C array data inputs or outputs are given a suffix to indicate the implementation: '_c' for raw C-pointer type binding, '_p' for a more perlish interface (for example returning multiple args rather than using pointers valued inputs), and '_s' for bindings using data in a packed scalar format (such as SDL or PDL). While these general namings are used in OpenGL::Modern as well, there are some inconsistencies that will be noted and corresponding changes needed for clarity. (2) Maintain compatibility with POGL bindings as possible As with POGL, perl bindings to OpenGL API routine having no pointer or C array input arguments or return values have the identical name as the C API. These non-suffixed names in OpenGL::Modern are the same where a POGL binding exists although the POGL bindings cover about 1/4th of the ones in OpenGL::Modern. Any OpenGL API routine having a pointer * or C array [] argument or return value have a binding with a '_c' suffix that is implemented with raw C pointers. It is up to the perl user to create the needed pointer values for input/output and to translate the data sent/received correctly. These bindings are interim only pending better more perlish or more direct implementations: * null terminated strings map directly to/from perl and their '_c' binding needs to be direct to perl with the name either having '_p' or for single strings IN/OUT the non-suffixed version is appropriate. * OpenGL routines with names like glXxxx[#][type]v should take variable numbers of arguments and/or return an array of results and be named with a '_p'. * Routines in POGL using OpenGL::Array arguments are being renamed with a '_o' suffix for OGA from the confusing '_p' name which preferentially selected OpenGL::Arrays as the preferred binary data implementation over PDL or other possible representation. (3) Make room for nice, friendly, default perlish bindings * Bindings that can handle multiple input options in a simple and symmetric fashion are planned to be given a '_g' suffix for general. If performance is sufficient, the "friendly" bindings might eventually become the default, non-suffixed version. * Generic bindings without specific numerical data types could have an OpenGL::Modern name with all the [#][type] stuff removed. * POGL used glp[A-Z]... to indicate new routines in the perl bindings that were implemented. This can be maintained for compatibility. In fact, the misleading glGetVersion() routine will likely be renamed glpGetVersion() since there is no OpenGL routine named glGetVersion(). As OpenGL::Modern is still a work in progress, there is room for comment and changes as things evolve. The above naming strategy seems best suited to meet needs of back-compatibility to POGL and yet having room for a better set of bindings going forward. Cheers, Chris |
|
From: Chris M. <dev...@gm...> - 2017-06-25 18:56:39
|
On 6/25/2017 12:10, Dmitry Karasik wrote: >> The fact that you have to hand-convert the raw array data to >> IV as pointers is only needed until the real bindings are >> completed. There are more than a thousand routines needing >> to be implemented. As they are completed, then the need >> for users to hack in the pointers themselves will go away. >> The OpenGL::Modern::Helpers exists to provide the needed >> documentation and interface examples until a nice, perl-ish >> interface is done. > Right. So what do you mean by more perlish here? F.ex. the original > Max's code for OpenGL::Glew was doing things like f.ex. > > glGenVertexArrays( 1, xs_buffer(my $buffer, 8 )); > my $vao = (unpack 'I', $buffer)[0]; > > whereas the current state of things is > > glGenVertexArrays_c( 1, iv_ptr(my $buffer, 8 )); > > Do you mean to drive the project so that the former style of calls will be available > again, or do you mean something else? > I actually like the former variant - unless of course you might mean something even more > perlish like > > my $vao = glGenVertexArrays(1); > This is in the table of priority bindings in this issue: https://github.com/devel-chm/OpenGL-Modern/issues/7 as glGenVertexArrays_p TODO GL_ARB_vertex_array_object 1 and the binding would be _p with usage as: my @vao = glGenVertexArrays_p($n); I've been considering a more general interface which could be used as the default binding where the argument and return types are used to do the right thing behind the scenes. If the scheme works, it would be the default non-suffixed binding. E.g. for glGenVertexArrays() one might have: glGenVertexArrays(3,\@vaos); # perl array glGenVertexArrays(3,\$vaos); # packed string array output glGenVertexArrays(3, $pdl); # PDL array glGenVertexArrays(3, $oga); # OpenGL::Array object ... You can look at my OpenGL::Modern github repo and the branch priority-xs-code to see work in progress on the categorization in the utils/priority_xs directory. This is an example of the raw signature information format for glGenVertexArrays() routine. The OpenGL extension or Core is before the : and the CSV after the colon are, in order, with one line for each in/out arg to the function. See the work at https://github.com/devel-chm/OpenGL-Modern/issues/53 for more explanations. GL_ARB_vertex_array_object.csv:glGenVertexArrays,-1,0,void,N/A,N/A,out,fixed,N/A GL_ARB_vertex_array_object.csv:glGenVertexArrays,0,0,GLsizei,n,N/A,in,fixed,N/A GL_ARB_vertex_array_object.csv:glGenVertexArrays,1,1,"GLuint *",arrays,"arg0(n)",out,variable,NA Hope this helps. --Chris |
|
From: Chris M. <dev...@gm...> - 2017-06-25 15:25:04
|
On 6/25/2017 06:46, Dmitry Karasik wrote:
>> I would like to see real bindings to these
>> routines with the pointer/array values handled
>> directly from the XS rather than the hacks
>> in OpenGL::Modern::Helpers. If you'll open
>> the ticket with a list of the _c that should
>> just be _ nothing, I can definitely get that
>> out quickly.
> Hi Chris,
>
> Thank you I understand the issue better now. The problem is definitely
> solvable, but it's not easy - one has to go through all functions and their
> respective API documentation to judge whether _p is justified or not. For my
> level of OpenGL knowledge is a herculean task, and I'm not ready to commit
> myself to that, frankly :)
As you find them is fine---I know there are a lot of functions. :-)
> However, there's another issue I'd like to ask about: it's the sending of a
> buffer address as an integer, the one that requires the wrapper to do the
> unpack('Q', pack('p', ..)) stuff. It looks to me that this is a rather
> unnecessary step, and arguments like these could be just sent as SvPVs and
> their buffers treated as respective pointers to the data buffers. In case one
> indeed needs to pass the explicit pointer to an arbitrary memory location,
> there can be added just a special XS function wrapper that creates a fresh SV
> for that, plus SvPV_set(arbitrary_pointer) on top. Do you think it will make
> sense to abolish the whole set of these, or I'm missing some important use
> cases?
The fact that you have to hand-convert the raw array data to
IV as pointers is only needed until the real bindings are
completed. There are more than a thousand routines needing
to be implemented. As they are completed, then the need
for users to hack in the pointers themselves will go away.
The OpenGL::Modern::Helpers exists to provide the needed
documentation and interface examples until a nice, perl-ish
interface is done.
--Chris
|
|
From: Dmitry K. <dm...@ka...> - 2017-06-25 11:05:18
|
> I would like to see real bindings to these
> routines with the pointer/array values handled
> directly from the XS rather than the hacks
> in OpenGL::Modern::Helpers. If you'll open
> the ticket with a list of the _c that should
> just be _ nothing, I can definitely get that
> out quickly.
Hi Chris,
Thank you I understand the issue better now. The problem is definitely
solvable, but it's not easy - one has to go through all functions and their
respective API documentation to judge whether _p is justified or not. For my
level of OpenGL knowledge is a herculean task, and I'm not ready to commit
myself to that, frankly :)
However, there's another issue I'd like to ask about: it's the sending of a
buffer address as an integer, the one that requires the wrapper to do the
unpack('Q', pack('p', ..)) stuff. It looks to me that this is a rather
unnecessary step, and arguments like these could be just sent as SvPVs and
their buffers treated as respective pointers to the data buffers. In case one
indeed needs to pass the explicit pointer to an arbitrary memory location,
there can be added just a special XS function wrapper that creates a fresh SV
for that, plus SvPV_set(arbitrary_pointer) on top. Do you think it will make
sense to abolish the whole set of these, or I'm missing some important use
cases?
--
Sincerely,
Dmitry Karasik
|
|
From: Chris M. <dev...@gm...> - 2017-06-24 13:50:36
|
Hi Dmitry- cc-ing the pogl-devel list as well... The suffixes come from the original Perl OpenGL implementation and are useful since for performance and to reduce latency one want the perl->C OpenGL as lightweight as possible. The fact that glGetUniformLocation has a _c in the bindings is an artifact of the automatic code generation where anything with a pointer in an input or output argument is given a _c binding. I believe that the current binding actually works fine with no special pointer magic so it is a bug in the code generation. Please open issues on github as you find these things so we can track them and I work better when working with others. :-) AFAICT, you are the only one using or trying to use OpenGL::Modern and I *really* appreciate the work and the feedback. I'm finishing up some bindings to the GLFW library and then would like to make another step in the OpenGL::Modern bindings code. You can look at the table of "priority" routines from current modules using OpenGL at https://github.com/devel-chm/OpenGL-Modern/issues/7 I would like to see real bindings to these routines with the pointer/array values handled directly from the XS rather than the hacks in OpenGL::Modern::Helpers. If you'll open the ticket with a list of the _c that should just be _ nothing, I can definitely get that out quickly. The rest is more a matter of my time available for development and other developers help. Most of this is all turning the crank but with more than 1000 routines to port and check, many hands makes light work and there have been no hands but mine lately. Personally, I find I develop faster and better when working with others. Thanks for contributing. Cheers, Chris On 6/24/2017 04:48, Dmitry Karasik wrote: > Hello Chris, > > As Max merged my changed to app-shadertoy, and it seems to work now, > I have a question to you which I delayed until this moment. > > I'm confused, what is the purpose of _p/_c suffixes to gl function names? > There are lots of examples where it doesn't make much sense to distinguish > between f.ex. glGetUniformLocation_c and glGetUniformLocation - the function > takes a string, explicitly, not even a binary buffer. > > I understand it's a sort of a heritage from OpenGL architecture, but possibly > now there is a chance to make this right, and make it so that there's only one > function of the same name as in C API, - of course, XS is required to do some > magick, but I still wonder if you share this view. > |
|
From: <sis...@op...> - 2017-03-04 09:28:36
|
From: Chris Marshall
Sent: Saturday, March 04, 2017 2:52 AM
To: pog...@li... ; perldl
Subject: [Pdl-general] CHM/OpenGL-GLU-0.02_02.tar.gz uploaded to CPAN
...and should be appearing at a mirror near you soon.
Not passing for me with 64-bit Strawberry 5.24.1. Also not working with my
own perls.
There's a warning during the compilation:
In file included from GLU.xs:34:0:
const-c.inc: In function 'constant_18':
const-c.inc:1097:20: warning: overflow in implicit constant conversion
[-Woverflow]
*iv_return = GLU_TESS_MAX_COORD;
And then the test script fails:
t/OpenGL-GLU.t .. 1/2
# Failed test 'Constants'
# at t/OpenGL-GLU.t line 71.
# Looks like you failed 1 test of 2.
t/OpenGL-GLU.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests
The output of running 'perl -Mblib t/OpenGL-GLU.t' is attached.
(Sorry, I don't have much time today.)
Cheers,
Rob
|
|
From: Chris M. <dev...@gm...> - 2017-03-03 15:52:14
|
...and should be appearing at a mirror near you soon. This release fixes a number of problems with the existing release where it basically wasn't working at all but there was a bug in the test suite so that the FAIL came out as PASS. :-( Not only do all tests pass---for real, but if you have OpenGL::GLUT and OpenGL::GLU and OpenGL::Modern installed, you can even run the examples/tessellation.pl program! Assuming tests pass, this will be pushed as the official OpenGL::GLU release real soon. As always, feedback welcome. --Chris |
|
From: Chris M. <dev...@gm...> - 2017-03-03 14:56:38
|
...and should be appear at a mirror near you soon. Both releases are to address build problems on MacOSX which I believe has now been fixed. Once this has been confirmed by CPAN Testers and OpenGL users (this means you!), we'll be pushing a new official release. NOTE: Both these modules are stand alone implementations of functionality from the original Perl OpenGL module to support the new OpenGL::Modern bindings. They are not compatible with OpenGL which already includes their entire functionality. Regards, Chris |
|
From: Christian W. <wal...@gm...> - 2017-03-03 00:55:13
|
On Thu, 02 Mar 2017 15:59:17 +0100, Chris Marshall <dev...@gm...> wrote: > I've just pushed the stand-alone OpenGL::Array moduleto our github repository: > https://github.com/devel-chm/OpenGL-Array > Please confirm if you can build and whether it can beused in place of OpenGL for this functionality. Becausethe OpenGL implementation automatically loads thisno matter what, you'll need to test with code that doesn'tuse OpenGL. > I've edited the oga.pl file in the distribution to workwith OpenGL::Modern and OpenGL::Array. The currentplan is to release a first official version to CPAN thisweekend to support the coming work to finish codegeneration for OpenGL routines with pointer/arrayarguments. > As always feedback/comments are welcome. > --Chris Confirmed by way of uplifting OpenGL::Image to OpenGL::Modern::Image in https://github.com/wchristian/OpenGL-Modern-Image (not release-ready) and integrating that into Microidium. Both use the new OpenGL::Array and OpenGL.pm was not loaded when the benchmark loop of microidium ended, and microidium ran fine. I do wish though it were OpenGL::Modern::Array to avoid *any* confusion about namespacing. (opengl::array does pop up from the old dist here: https://metacpan.org/search?q=opengl%3A%3Aarray ) Also, do you want to adopt OpenGL::Modern::Image into your github account as well, or maybe open a github org for all these things? -- With regards, Christian Walde |
|
From: Chris M. <dev...@gm...> - 2017-03-02 14:59:23
|
I've just pushed the stand-alone OpenGL::Array module
to our github repository:
https://github.com/devel-chm/OpenGL-Array
Please confirm if you can build and whether it can be
used in place of OpenGL for this functionality. Because
the OpenGL implementation automatically loads this
no matter what, you'll need to test with code that doesn't
use OpenGL.
I've edited the oga.pl file in the distribution to work
with OpenGL::Modern and OpenGL::Array. The current
plan is to release a first official version to CPAN this
weekend to support the coming work to finish code
generation for OpenGL routines with pointer/array
arguments.
As always feedback/comments are welcome.
--Chris
|
|
From: Chris M. <dev...@gm...> - 2017-02-27 19:03:57
|
This is an alpha release of the new stand-alone perl bindings to GLUT and FreeGLUT. It should be a compatible replacement for the GLUT/FreeGLUT bindings in the Perl OpenGL module. Build tests and use tests welcome. It is expected that this will have an official release very soon. Enjoy, Chris for the Perl OpenGL developers |
|
From: Chris M. <dev...@gm...> - 2017-02-27 12:50:20
|
I've set up a github repo for the work to create a stand alone
OpenGL::GLUT module based on the original OpenGL one.
The module builds and passes tests but there is some sort
of problem with AUTOLOAD which you can see if you
try running the menutest.pl example. See issue #2 for
discussion and fixes (yes, please!).
https://github.com/devel-chm/OpenGL-GLUT
--Chris
|
|
From: Chris M. <dev...@gm...> - 2017-02-25 18:01:54
|
On 2/25/2017 12:17, Christian Walde wrote:
> On Sat, 25 Feb 2017 17:01:49 +0100, Chris Marshall
> <dev...@gm...> wrote:
>
>>>> I thought perl roles were always composed by the class/object.
>>>
>>> No idea why you say that. "*that* part" refers to the whole "it's only
>>> an interface role" bit. And that's what it is. Those words should've
>>> been mentioned at the very start.
>>
>> It was what I thought "that part" referred to.
>
> Ah, well, you can have it both ways. You can either have the class
> itself use the role, or you can "add" a role to any object, which is
> typically done by creating an anonymous class that extends the old
> class of the object, consumes the role, then reblesses the object to
> that.
>
>>>>> Interface roles are certainly a possibility, but only very rarely
>>>>> actually used in Perl. This isn't java, so if you're thinking that,
>>>>> and mean it, but don't say it, you visit a lot of confusion on
>>>>> people.
>>>>
>>>> They are interface roles
>>>
>>> What you're describing is one interface role that consists only of
>>> `requires "whatever_method";` calls.
>>>
>>>> ---at the least. Ideally, we would have some
>>>> type of standard implementation as well (even if only diagnostic).
>>>
>>> Sure, it can have that, but that doesn't change it primarily is only
>>> an interface role.
>>
>> If you review the original message, the idea is to replace per-object
>> bindings for the general OpenGL::Modern with something that would
>> work the same for different "providers" of the data/array/pointer args.
>
> Right, i saw what you wanted to do with the gl calls. The thing what
> was left open for me was, put in simpler words:
>
> Whether you wanted to:
> 1. Design a standard that everyone is invited to follow.
> 2. Write an object munger that does the heavy lifting inside the
> repositor OpenGL-Modern to wrap around known objects.
> 3. Both.
>
> Right now it looks like 1.
Right now, you have to study the OpenGL bindings and
implement your own for any new routines. Pretty much
all undocumented and needing experience with OpenGL
API and C/XS perl development.
1. Implement a standard interface we support for
the default set of functionality: CPTR, PACKED, and OGA
from OpenGL which would be ported to the new API in
OpenGL::Modern. PDL, which uses PACKED strings for
its data would be supported when I implement the
needed role/methods.
2. Applying to known objects could be done as well----just
not required to get a working full OpenGL::Modern set
of bindings.
3. Yes. I believe the role approach supports this and more.
Not much to do for legacy code but for new code using
Moo[se] we should be able to go pretty far. In fact,
for PDL:NG (PDL Next Generation) the hope is to use
this to support things like JIT compiling. JIT could also
be applicable to OpenGL::Modern performance optimization.
>> I think this discussion would be more productive with actual
>> code. We seem to be talking in circles. Without a specific
>> implementation, our own assumptions are confusing things.
>
> I think code would help, but at the same time we've also come to
> better understanding on both sides imo. (I mean, most of it has been
> me going "i don't get this, here's what i read, what did you mean?"
> but the other option is not saying anything, which would likely not
> help you either.)
>
>> At the moment, my plan is that all the glRoutine_p would be
>> glRoutine using the role based approach. This may not be the
>> fastest possible implementation but it would be simple to use
>> and allow for more flexible implementations.
>>
>> With an actual implementation, we could then look at the
>> various need for optimizations. For example, there could be
>> glRoutine_o that use OGAs or it could be in an
>> OpenGl::Modern::OGA or something.
>>
>> In the meantime, we have more than 1700 routines that don't
>> have reasonable bindings so optimizing performance for them
>> is definitely putting the cart in front of the horse.
>
> That plan sounds reasonable as long as we remain aware that the
> proposed _p functions then would be known as (and documented as)
> "convenient, but slow" wrappers around the actual calls.
>
> Of course, its usefulness still depends on how willing the other
> projects are at committing to helping out. I suppose given you are on
> the line for OpenGL::Array and PDL those are committed? (I just tried
> looking up C::Pointers, and can't actually find that on CPAN. Have you
> talked to the maintainer yet?)
>
CPTR, PACKED, OGA are all from the OpenGL implementation.
I would propose a standard implementation for these types
of data sources for OpenGL::Modern.
>> more than 1700 routines that don't have reasonable bindings
>
> Out of interest, how can i figure out which ones those are? I know you
> have a bunch of files documenting such in the repo, but i don't know
> which file you are referring to.
>
Look in the signatures/ folder in the git repo.
good-XS-fun-list.txt is the 1263 routines that have only
scalar args and so the generated code is believed to be correct.
Can't say that anyone has tested them all.
bad-Xs-sigs-numptr.pl is a formatted version of the result
of the generate-XS.pl signature extraction.
signatures/badp-XS-sigs/ breaks out the above file by number
of arguments/return values with a pointer/array type.
signatures/priority/ breaks out the routines needed by
various things and collected in required-api-(good|bad).txt
as a minimum set to say "we're done---at least as a
replacement for OpenGL".
Regards,
Chris
|
|
From: Christian W. <wal...@gm...> - 2017-02-25 17:17:23
|
On Sat, 25 Feb 2017 17:01:49 +0100, Chris Marshall <dev...@gm...> wrote: >>> I thought perl roles were always composed by the class/object. >> >> No idea why you say that. "*that* part" refers to the whole "it's only >> an interface role" bit. And that's what it is. Those words should've >> been mentioned at the very start. > > It was what I thought "that part" referred to. Ah, well, you can have it both ways. You can either have the class itself use the role, or you can "add" a role to any object, which is typically done by creating an anonymous class that extends the old class of the object, consumes the role, then reblesses the object to that. >>>> Interface roles are certainly a possibility, but only very rarely >>>> actually used in Perl. This isn't java, so if you're thinking that, >>>> and mean it, but don't say it, you visit a lot of confusion on people. >>> >>> They are interface roles >> >> What you're describing is one interface role that consists only of >> `requires "whatever_method";` calls. >> >>> ---at the least. Ideally, we would have some >>> type of standard implementation as well (even if only diagnostic). >> >> Sure, it can have that, but that doesn't change it primarily is only >> an interface role. > > If you review the original message, the idea is to replace per-object > bindings for the general OpenGL::Modern with something that would > work the same for different "providers" of the data/array/pointer args. Right, i saw what you wanted to do with the gl calls. The thing what was left open for me was, put in simpler words: Whether you wanted to: 1. Design a standard that everyone is invited to follow. 2. Write an object munger that does the heavy lifting inside the repositor OpenGL-Modern to wrap around known objects. 3. Both. Right now it looks like 1. > I think this discussion would be more productive with actual > code. We seem to be talking in circles. Without a specific > implementation, our own assumptions are confusing things. I think code would help, but at the same time we've also come to better understanding on both sides imo. (I mean, most of it has been me going "i don't get this, here's what i read, what did you mean?" but the other option is not saying anything, which would likely not help you either.) > At the moment, my plan is that all the glRoutine_p would be > glRoutine using the role based approach. This may not be the > fastest possible implementation but it would be simple to use > and allow for more flexible implementations. > > With an actual implementation, we could then look at the > various need for optimizations. For example, there could be > glRoutine_o that use OGAs or it could be in an > OpenGl::Modern::OGA or something. > > In the meantime, we have more than 1700 routines that don't > have reasonable bindings so optimizing performance for them > is definitely putting the cart in front of the horse. That plan sounds reasonable as long as we remain aware that the proposed _p functions then would be known as (and documented as) "convenient, but slow" wrappers around the actual calls. Of course, its usefulness still depends on how willing the other projects are at committing to helping out. I suppose given you are on the line for OpenGL::Array and PDL those are committed? (I just tried looking up C::Pointers, and can't actually find that on CPAN. Have you talked to the maintainer yet?) > more than 1700 routines that don't have reasonable bindings Out of interest, how can i figure out which ones those are? I know you have a bunch of files documenting such in the repo, but i don't know which file you are referring to. -- With regards, Christian Walde |
|
From: Chris M. <dev...@gm...> - 2017-02-25 16:01:54
|
On 2/25/2017 07:48, Christian Walde wrote: > On Sat, 25 Feb 2017 13:07:35 +0100, Chris Marshall > <dev...@gm...> wrote: > >>>> In this case, the role is like a set of required methods for the >>>> class/object. We just call them to do the interfacing. It is the >>>> problem of the class/object to implement/compose the role. >>> >>> Please mention *that* part first when talking about roles in the >>> future. :) >> >> I thought perl roles were always composed by the class/object. > > No idea why you say that. "*that* part" refers to the whole "it's only > an interface role" bit. And that's what it is. Those words should've > been mentioned at the very start. It was what I thought "that part" referred to. > >>> Interface roles are certainly a possibility, but only very rarely >>> actually used in Perl. This isn't java, so if you're thinking that, >>> and mean it, but don't say it, you visit a lot of confusion on people. >> >> They are interface roles > > What you're describing is one interface role that consists only of > `requires "whatever_method";` calls. > >> ---at the least. Ideally, we would have some >> type of standard implementation as well (even if only diagnostic). > > Sure, it can have that, but that doesn't change it primarily is only > an interface role. If you review the original message, the idea is to replace per-object bindings for the general OpenGL::Modern with something that would work the same for different "providers" of the data/array/pointer args. > >>> With only a single implementation in OgA, i don't see how it'd be much >>> more than a standard used by only a single thing; unless you actually >>> get the authors of the appropiate things to commit to implementing it. >> >> There is not only a single implementation. In fact, the current >> OpenGL::Array in the OpenGL module would not work---it doesn't >> know anything about a role to implement its functionality. > > I have no damn idea what you're saying here. You said you are planning > to implement the functionality to satisfy the interface of the role in > OpenGL::Array and let everyone else do it on their own. > If you want specific OGA bindings, then you would implement something like glRoutine_o or whatever. The role is to remove the requirement for OpenGL::Array in OpenGL::Modern. I would like users to be able to work with their preferred tools rather than being forced to use OGA and RPN. >>> Additional concerns: >>> >>> 1. Perl function calls and method resolutions are not cheap. glRoutine >>> in its entirety should be, for performance reasons, implemented in XS, >>> so a call to glRoutine does not cause further perl code to be executed >>> before running the actual gl call. >> >> Roles are composed into the class. The methods should be found quickly >> as they are "right there". >> BTW, any idea > > It still takes time to: Do the perl call to get into the function, and > resolve the method in Perl. > This is added on top of the time taken by the XS call and whatever > time is needed for the C bit. > Please try to keep this in mind now and all future: Compared to C code > Perl calls are significantly expensive and method calls even more so. > Every expense possible must be taken to avoid them. > This is a simple fact of hard reality. Not avoidable. > >> what the cost of a perl function/method call would be compared >> to an XS call? > > See attached. Even the most simple implementation adds significant > time. Summary: > > glBufferData_c 10µs > + $oga->length + $oga->ptr 2µs > + perl shenanigans 12µs > -------------------------------- > = glBufferData_p 24µs > >>> If this does not happen then there are still explicitly performant >>> implementations of the appropiate calls needed. >> >> The role is the framework, the idea/hope is that a sufficiently >> performant implementation would be possible. > > As long as you're calling methods in a perl function before the actual > XS call, no implementation you can hope for would be equal to having > it in XS. > >>> And the thought of simply having the object emit a C structure on a >>> method call does not usefully address it, unless you plan to get that >>> C structure within an XS implementation. >>> >> >> That was one idea for a low latency implementation. > > Doesn't help you as long as you're still stepping through Perl. > >>> Do you have a concrete plan as to how to implement the role checking >>> and data retrieval in XS? >> >> Call does() to determine if the role has been composed. If the role is >> composed into OGA, for example, and there are already methods of >> the same name then they are used. > > does() works in XS? I'm actually clueless on that. > >>> 2. The methods, if declared by fiat, must be named to avoid any >>> collision with existing methods. That probably means using a prefix. >> >> Nope, this is the property of role composition. The composing >> class would need to deal with method conflicts. You are much >> more conversant with the ways it would be done in Moo. > > No, you misunderstand. If we define the interface for getting the > amount of elements in a C::Blocks, OGA, PDL, whatever to be ->size and > implement the OpenGL calls with the expectation that that interface is > fulfilled, but C::Blocks provides the size of the buffer in bytes on a > -> size call, then there is literally no way it can fulfill the > interface. There is nothing the composing class can do. At all. Ever. > Period. > > Choosing sane names falls on us if we go this way. You are right. It would be better to have prefix/unambiguous names to reduce problems of routines with the same name but different interfaces. > >> Another thought, the default role implementation could handle >> the existing cases. The optimized implementation would just >> improve the performance. > > I don't honestly understand what that means. I think this discussion would be more productive with actual code. We seem to be talking in circles. Without a specific implementation, our own assumptions are confusing things. At the moment, my plan is that all the glRoutine_p would be glRoutine using the role based approach. This may not be the fastest possible implementation but it would be simple to use and allow for more flexible implementations. With an actual implementation, we could then look at the various need for optimizations. For example, there could be glRoutine_o that use OGAs or it could be in an OpenGl::Modern::OGA or something. In the meantime, we have more than 1700 routines that don't have reasonable bindings so optimizing performance for them is definitely putting the cart in front of the horse. Regards, Chris |
