Recent changes to feature-requests

#3 Add support for ARB_draw_instanced and ARB_instanced_arrays

mohawk — Sun, 11 May 2025 19:54:44 -0000

status: open --> closed

#2 OpenGL ES support

ddumont — Tue, 11 Nov 2014 19:01:53 -0000

There's a discussion with patches about glew and gles integration. Unfortunately, the conlusion of this thread is not really in favor of gles integration:

I'd be a bit concerned on mobile platforms that the full desktop GLEW would be trying to load all kinds of irrelevant desktop extensions for OpenGL ES, and resulting in a much larger footprint than necessary.

And there's no mention of gles in glew changelog.

I'm beginning to wonder if supporting gles as part of pogl is the right solution. May be a new set of bindings would be better...

#2 OpenGL ES support

Chris Marshall — Tue, 11 Nov 2014 15:45:30 -0000

The current POGL bindings are hand generated XS wrappers that cover OpenGL functionality up to OpenGL 2.x-ish. This has the problem that they are determined at build time and not at run time so there is a possible issue of functionality that might be available (or not) at build time but differs at run time.

The planned solution is to use the GLEW library to generated the POGL bindings that would be able to be determined at run time. This gives dynamic bindings and full support for all features and extensions up through OpenGL 4.x.

I'm not familiar enough with the modern OpenGL vs OpenGL ES stuff to understand how this would need to change for the use of OpenGL ES rather than OpenGL. Maybe a similar strategy to the GLEW one could be used there.

Regarding GLUT, that was added in an attempt to move POGL from the original X11 base implementation to one that is portable across platforms. While it did achieve that goal, it also added a false requirement on FreeGLUT to perl modules using OpenGL.

The plan for the POGL update is to spin off the user interface/context generation part into separate modules with a generic plugin type approach. That would allow one to use any of a number of options for platform interfaces: X11, GLUT, GLFW, Qt, wxWidgets, or any other library that can provide the needed graphic context.

#2 OpenGL ES support

ddumont — Tue, 11 Nov 2014 11:23:41 -0000

Hmm, I think that GLES is already a subset of existing OpenGL API. (See http://en.wikipedia.org/wiki/OpenGL_ES and http://web.eecs.umich.edu/~sugih/courses/eecs487/common/notes/APITables.xml )

On linux, gles is provided by libGLESv2.so.2 . POGL is not linked to that library.

I think (well, I hope), that supporting GLES would require:
- be able to link POGL to libGLESv2.so instead of libglut.so
- be able to #ifdef out all OpenGL only function definitions in XS files

Of course, I may be completely wrong...

What do you think ?

All the best

#3 Add support for ARB_draw_instanced and ARB_instanced_arrays

orafu — Mon, 02 Dec 2013 17:29:07 -0000

Actually MESA had them in 7.11 already. Intel support came later.

Add support for ARB_draw_instanced and ARB_instanced_arrays

orafu — Mon, 02 Dec 2013 17:11:32 -0000

Hello,

the title summarizes it.

For the visualization of algorithms, particle systems or molecules, often many objects of the same shape need to be drawn.

The extensions for instanced drawing apparently push OpenGLs ability to draw many objects of the same shape. One test measured a speedup of a factor 2 to 18 on two 2009-vintage video cards from Nvidia and AMD, depending on instance polygon count and the polygon caching capacity of the hardware. The test indicates that the speedup may even improve on newer hardware.

I expect that POGL will get even greater performance benefits, because rendering the same object many times without these extensions requires many API calls, and as POGL is an additional layer on top of the OpenGL API it has additional overhead for API calls.

It looks like an implementation needs to support only 2 - 3 additional functions: ARB_draw_instanced adds DrawArraysInstancedARB() and DrawElementsInstancedARB() and ARB_instanced_arrays adds VertexAttribDivisorARB(). (ARB_instanced_arrays is not strictly needed, but it means that the vertex shader code becomes much simpler as vertex attribute arrays can be used to transmit per-instance data, rather than textures (or uniforms, which also kill performance benefits).)

In my eyes the most important missing feature for visualization.

Note that even Intel HD Graphics since SandyBridge support these extensions. MESA had them since version 9.0, including support in the Intel driver.

Best regards

Add support for ARB_draw_instanced and ARB_instanced_arrays

orafu — Mon, 02 Dec 2013 17:11:32 -0000

Ticket 3 has been modified: Add support for ARB_draw_instanced and ARB_instanced_arrays
Edited By: mohawk (mohawk111)
Status updated: 'open' => 'closed'

OpenGL ES support

Brian Fraser — Thu, 22 Aug 2013 02:40:22 -0000

Howdy all!

I think the title of the feature request says it all : D I know next to nothing about OpenGL in general, and I imagine that this request might be tough as nails, since there's no GLUT on embedded systems, but I'm more than willing to learn the codebase and try doing some of the footwork myself if you folk think that GLES support is possible.

As for why, GLES support is essential for running things on the raspberry pi, or, more importantly to me, creating no-java-just-perl android apps.

add ability to specify OpenGL compile/link options

Chris Marshall — Tue, 12 Jul 2011 17:42:08 -0000

Transferred from bug #52350 for OpenGL: OpenGL fails to compile...
> ...
> The point is, I can have both 32-bit and 64-bit libraries as well as
> both 32-bit and 64-bit perls _and_ no clues about correct library paths
> in Config. Or, as I discovered another day, I can have broken Mesa in
> /usr/lib for backwards compatibility and working libGL in /usr/X11/lib
> so that I have to do some clever dance with LD_RUN_PATH.
>
> So, letting one specify the correct -I, -L and LD_RUN_PATH through the
> environment could be the best solution for automatic testing (as a
> bonus, you may harvest the configuration data from tester reports).

This would allow the OpenGL module to build whenever the
user can specify the neede compile, link, and load options.
This is particularly important when there are more than one
set of applicable libraries on a system: 32bit, 64bit, wgl,
glx, agl...