Thanks ronie for your analysis (especially the thread local point).
Stef
Le 28/7/16 à 20:36, Ronie Salgado a écrit :
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
<http://keithp.com/%7Ekeithp/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.ber...@me.com
<mailto:alexandre.ber...@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/
<http://smalltalkhub.com/#%21/%7EThibaultRaffaillac/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
