Starting making bindings for OpenCL using NativeBoost.
Hello, I started working in making some basic bindings for OpenCL using NativeBoost. Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success. I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2. Currently uploading my work into http://smalltalkhub.com/#!/~ronsaldo/OpenCL. No configuration or stable release yet. Greetings, Ronie
wow nice, opencl can seriously speed things up for many diffirent kind's of calculation. Blender <http://www.blender.org/> is actually porting OpenCL for its rendering engine cycles. Cycles already uses CUDA. They say that openCL is quite buggy yet and not well supported. Whats your experience with it ? In Blender CUDA alone speed things up 3 times compared to my CPU. For serious GPUs this number can go easily up to 10 times. I have even heard that in some cases the speed up reach 100 times. Are you going to expose also an API for non graphic stuff ? On Thu, May 8, 2014 at 9:32 AM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I started working in making some basic bindings for OpenCL using NativeBoost.
Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success.
I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2.
Currently uploading my work into http://smalltalkhub.com/#!/~ronsaldo/OpenCL . No configuration or stable release yet.
Greetings, Ronie
Excellent!!!!! Go go go! Alexandre On May 8, 2014, at 2:32 AM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I started working in making some basic bindings for OpenCL using NativeBoost.
Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success.
I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2.
Currently uploading my work into http://smalltalkhub.com/#!/~ronsaldo/OpenCL . No configuration or stable release yet.
Greetings, Ronie <opencl-screenshot.png>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi ronie Some questions: do you think that we could have a openCL back-end for athens? do you think that we could avoid having openCL text inside Pharo but have a kind of DSL? Stef On 8/5/14 08:32, Ronie Salgado wrote:
Hello,
I started working in making some basic bindings for OpenCL using NativeBoost.
Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success.
I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2.
Currently uploading my work into http://smalltalkhub.com/#!/~ronsaldo/OpenCL <http://smalltalkhub.com/#%21/%7Eronsaldo/OpenCL> . No configuration or stable release yet.
Greetings, Ronie
Blender <http://www.blender.org/> is actually porting OpenCL for its rendering engine cycles. Cycles already uses CUDA. They say that OpenCL is quite buggy yet and not well supported. Whats your experience with it ?
This is actually a problem with the AMD implementation of OpenCL, and yes it is buggy, but being improved over the time, specially after Valve is going for Linux and the new generation of consoles is based in AMD hardware. Until AMD made the GCN architecture(HD7xxx and upward), they did not have hardware support for function calls unlike NVIDIA, so they have to inline everything. The Blender Cycles rendering engine is huge, and specially their noise functions used for procedural textures. Because everything was being in-lined, they ended running out of memory easily when compiling their kernels for the first time. In my desktop machine with 3 GB of RAM I end without of memory when trying Cycles with OpenCL, but in my laptop with 8 GB of RAM it works, but not perfect because they haven't done(at least the last year when I last tried ) too much testing with OpenCL. With GCN AMD should have fixed the problem, but they keep using the same intermediate representation that they used for their previouse generation, so they keep inlining everything. In some time AMD should fix the problem, specially when most of the new generation of consoles uses GCN and Valve coming to Linux. My recommendation is to keep OpenCL kernels as simple as possible, which should also be done for performance. Are you going to expose also an API for non graphic stuff ?
I am exposing some parts of the OpenCL API one by one. OpenCL is a small API, but it is designed for C, so I am trying to make it a bit more Smalltalk friendlier. But just a bit more. For testing the bindings, I have one test that performs a simple big vector addition. So, it can be used for non graphics stuffs. Graphics are cooler to show. do you think that we could have a openCL back-end for athens?
Yes, it should be possible. A scanline renderer in OpenCL should be really interesting of implementing. But, I think that a better option is to use OpenGL with the Stencil Buffer and manual evaluation of the curves. I have done it before for vector graphics, and I need an OpenGL based Athens backend for Roassal 3D and my next video-game graphics engine. I also tried some time ago with the paper present here: http://ramisantina.com/blog/2011/09/resolution-independent-curves-at-graphic.... I am interested in extending his technique from quadratic NURBS into cubic NURBS. They are lot of different ways for making 2D vector graphics in the GPU, and I want to try some of them for profiling. do you think that we could avoid having openCL text inside Pharo but have a
kind of DSL?
I hate MATLAB, so I would love a DSL for working with matrices, vectors and use Roassal/GraphET for displaying the data and plotting. This should be very easy to implement. For some domains, making a DSL should be easy. In general, a DSL for the GPGPU is not going to be enough. Some algorithms have to be adapted explicitly for the GPU, taking in account the presence of different memory models, such as the local memory. If we want a generic model, we need to make a different Pharo-ish programming language. The work with UFFI/VirtualCPU should make that very long term task easy. But for now, lets just use some DSLs. Greetings, Ronie 2014-05-08 11:06 GMT-04:00 stepharo <stepharo@free.fr>:
Hi ronie
Some questions: do you think that we could have a openCL back-end for athens?
do you think that we could avoid having openCL text inside Pharo but have a kind of DSL?
Stef
On 8/5/14 08:32, Ronie Salgado wrote:
Hello,
I started working in making some basic bindings for OpenCL using NativeBoost.
Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success.
I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2.
Currently uploading my work into http://smalltalkhub.com/#!/~ ronsaldo/OpenCL <http://smalltalkhub.com/#%21/%7Eronsaldo/OpenCL> . No configuration or stable release yet.
Greetings, Ronie
thanks for the detailed answer :) I am definitely excited about your project. I am sure however far you will go with it , it will definitely benefit Pharo . Good luck and keep us informed :) On Thu, May 8, 2014 at 11:55 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Blender <http://www.blender.org/> is actually porting OpenCL for its
rendering engine cycles. Cycles already uses CUDA. They say that OpenCL is quite buggy yet and not well supported. Whats your experience with it ?
This is actually a problem with the AMD implementation of OpenCL, and yes it is buggy, but being improved over the time, specially after Valve is going for Linux and the new generation of consoles is based in AMD hardware.
Until AMD made the GCN architecture(HD7xxx and upward), they did not have hardware support for function calls unlike NVIDIA, so they have to inline everything. The Blender Cycles rendering engine is huge, and specially their noise functions used for procedural textures. Because everything was being in-lined, they ended running out of memory easily when compiling their kernels for the first time. In my desktop machine with 3 GB of RAM I end without of memory when trying Cycles with OpenCL, but in my laptop with 8 GB of RAM it works, but not perfect because they haven't done(at least the last year when I last tried ) too much testing with OpenCL.
With GCN AMD should have fixed the problem, but they keep using the same intermediate representation that they used for their previouse generation, so they keep inlining everything. In some time AMD should fix the problem, specially when most of the new generation of consoles uses GCN and Valve coming to Linux.
My recommendation is to keep OpenCL kernels as simple as possible, which should also be done for performance.
Are you going to expose also an API for non graphic stuff ?
I am exposing some parts of the OpenCL API one by one. OpenCL is a small API, but it is designed for C, so I am trying to make it a bit more Smalltalk friendlier. But just a bit more.
For testing the bindings, I have one test that performs a simple big vector addition. So, it can be used for non graphics stuffs. Graphics are cooler to show.
do you think that we could have a openCL back-end for athens?
Yes, it should be possible. A scanline renderer in OpenCL should be really interesting of implementing.
But, I think that a better option is to use OpenGL with the Stencil Buffer and manual evaluation of the curves. I have done it before for vector graphics, and I need an OpenGL based Athens backend for Roassal 3D and my next video-game graphics engine. I also tried some time ago with the paper present here: http://ramisantina.com/blog/2011/09/resolution-independent-curves-at-graphic.... I am interested in extending his technique from quadratic NURBS into cubic NURBS.
They are lot of different ways for making 2D vector graphics in the GPU, and I want to try some of them for profiling.
do you think that we could avoid having openCL text inside Pharo but have
a kind of DSL?
I hate MATLAB, so I would love a DSL for working with matrices, vectors and use Roassal/GraphET for displaying the data and plotting. This should be very easy to implement.
For some domains, making a DSL should be easy.
In general, a DSL for the GPGPU is not going to be enough. Some algorithms have to be adapted explicitly for the GPU, taking in account the presence of different memory models, such as the local memory. If we want a generic model, we need to make a different Pharo-ish programming language.
The work with UFFI/VirtualCPU should make that very long term task easy. But for now, lets just use some DSLs.
Greetings, Ronie
2014-05-08 11:06 GMT-04:00 stepharo <stepharo@free.fr>:
Hi ronie
Some questions: do you think that we could have a openCL back-end for athens?
do you think that we could avoid having openCL text inside Pharo but have a kind of DSL?
Stef
On 8/5/14 08:32, Ronie Salgado wrote:
Hello,
I started working in making some basic bindings for OpenCL using NativeBoost.
Currently I can run basics OpenCL OpenCL kernels. I tried to generate quickly some procedural images which was a success.
I am going to be showing some more cool stuffs when mixing OpenCL+OpenGL+SDL2.
Currently uploading my work into http://smalltalkhub.com/#!/~ ronsaldo/OpenCL <http://smalltalkhub.com/#%21/%7Eronsaldo/OpenCL> . No configuration or stable release yet.
Greetings, Ronie
participants (4)
-
Alexandre Bergel -
kilon alios -
Ronie Salgado -
stepharo