[Pharo-users] OpenGLES2 binding available!

Ronie Salgado roniesalg at gmail.com
Thu Jul 28 14:36:49 EDT 2016


>
> Isn't it what Ronie is working on?

I am not working with OpenGL or OpenGL ES anymore. I am moving all of my
efforts into Woden 2, the AbstractGPU (an abstraction layer for
Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom
shader language whose compiler I implemented in Pharo, with a backend for
SpirV, GLSL and C++. I still have to implement the backends for Metal and
HLSL.

Thibault is interested more on being able to use OpenGL ES 2.0 directly in
the playground, for teaching purposes without any abstraction layer
underlying. I do not agree with many of his approaches, too low level, and
many of themp do not work well with Pharo VM. One of the biggest issue of
OpenGL is related with vsync, which is an operation that can block all of
the Pharo processes, until we get a VM with the threaded FFI, which will
have in the near future. It will use the UnifiedFFI API, so we will not
have to further changes to take advantage of the threaded ffi in the user
code.

A far worse problem with OpenGL is that the current OpenGL context is a
thread local variable, which do not interact at all with Pharo processes.
This is the reason of why I added the OSWindowRenderThread class for
serializing OSWindow and OpenGL animations. SDL2 renderers are usually
implemented using OpenGL. They are two correct solution for this problem:
- Having a VM that maps each Pharo Process into an operating system thread,
- Not using OpenGL at all.

The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely
on a global thread local storage variable. These APIs are object oriented,
so handles are passed in each API call.

Currently, I have an Athens backend above Woden 2, which is only supporting
Vulkan for now. Since this backend is for Woden 2, it has some dependencies
in the Woden 2 Math and the Lowcode NativeStructure. This means that the
Woden 2 Athens backend has a strong dependency in the the modified
OpalCompiler that uses the Lowcode extended byte code set, and the the
modified PharoVM that implements these extra bytecode in the just in time
compiler.

Anyway, implementing a Athens backend from scratch is a really hard
problem, because paths can be concave, curve and self intersecting. Drawing
a path, unlike drawing a triangle is a global operation, for which GPUs
were not designed for. The easiest and most robust technique for drawing a
path using the GPU is to flatten the path using De Casteljau's algorithm
and then using the stencil buffer technique for drawing concave polygons
that was described in the OpenGL red book (
http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of
this technique is that involves many state changes(glStencil*)  and drawing
commands(glDrawElements) per path, which are the most expensive operations
when using OpenGL. The alternative is to perform a triangulation in the CPU
of paths, or to use one of the newer low level APIs such as Vulkan and
Direct 3D 12 which were designed to reduce or eliminate the cost of state
changes and drawing commands.

Path stroking is an even harder problem, which I have not solved yet. The
standard approach is to convert a stroked path into a path that can be
filled. The problem is that bezier offset curves are not bezier curves, so
they have to be approximated. Fortunately, since this operation is backend
agnostic, it can be used and reused by many Athens backends. Since stroking
is not critical for my needs, I do not think I will implement it soon
properly. Currently I am just drawing a 1 pixel thick line, which can look
horrible, but is better than nothing. One algorithm that seems to be simple
to implement is one described in a paper from the Cairo people, which uses
the Minkowksi  Sum between the outline of the path to be stroked, and shape
of the pen that is stroking
the path: http://keithp.com/~keithp/talks/cairo2003.pdf

Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to
integrate these bytecodes into the mainline VM.

I will not publish Woden 2 until the dependencies and Woden 2 itself can be
loaded easily.  Soon I will publish properly the Dastrel shader language
and the Slovim backend. Slovim name comes from Smalltalk Low levelish
VIrtual Machine, an intermediate representation heavily modeled after the
one used in LLVM, implemented in Pharo, some very basic optimizations(basic
constant folding, inlining and some dead code generation), and a code
generator backend for SpirV, GLSL and C++. My biggest issue before
publishing this compiler are:
- Implementing a command line interface.
- Doing an easy to install and use package for Linux, OS X and Windows.
- Documenting the language and the compiler.

Best regards,
Ronie

2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel at me.com>:

> I would love to see an athens back-end for it.
>
> Isn't it what Ronie is working on?
>
> Alexandre
>
>
> Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :
>
> Hi all,
>
> My tiny binding for OpenGLES2 is ready :)http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/
>
> It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages.
>
> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays.
> Tested only on Mac OSX, patches welcome!
>
> Cheers,
> Thibault
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160728/b1ee985e/attachment.html>


More information about the Pharo-users mailing list