Polytonic

Thule Paramount! (29L) - https://www.amazon.com/gp/product/B00MHNPQ16/ ($115)

Flap-top with side-access zippers. Carries my 15" rMBP in a padded pocket, has a decent selection of mesh pockets, rubber hooks for attaching a bicycle rear-light, and fits under an airplane seat.

>On the other hand, if you don't mind using other languages for the host code, there are a number of libraries in Java, Python, etc. that make it much simpler and more feature-complete than this library.

What features would you consider to be missing?

>Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.

Of course, though I wouldn't say cripple. With abstraction comes an associated performance cost. Chlorine is intended to reduce the barrier to entry. It's one of those "do things that don't scale" ideas. It hides some of the boilerplate from you, and is meant to help you quickly validate your ideas. If you need more fine-grained control over memory allocation, execution order, etc., you can always turn to the C/C++ API for performance, and it shouldn't be too difficult to port.

>The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.

My goal is to make GPU programming more accessible, so it's always good to see competition! Anyway, Chlorine is OpenCL 1.1/1.2 only, mainly because OSX is not OpenCL 2.0 compatible (knowing Apple, it may never be).

My primary platform is OSX, and Chlorine was written to target OSX first. It is arguably the easiest to get started under OSX.

The idea is to be super simple and easy to pick up. I'd rather spend my day to day time working on interesting problems, rather than slapping together boilerplate. Hence, my goal is to make it very easy to get started. When you need the performance, you can always reach for the C++ or C API.

>I'd love to use this, if there were more options available.

Did you have anything specific in mind? I'd be happy to add features.

By "developer" is this from the perspective of say, a company looking to use Glitter as a starting point for something?

Glitter started off as a quickstart for students taking Computer Graphics related classes at my school, not as the foundation for writing commercial game engines.

Was there something in mind that you feel like is missing? I'm happy to add to the readme.

TIL! This is awesome! I never knew about this.

What does it do under Windows? Does it run say, devenv.exe/msbuild in the shell, as opposed to in Visual Studio?

Hey, I noticed you haven't actually opened an issue. Did you work through your problem or ...?

Hi, can you open a GitHub issue for this? Would prefer to keep problems centralized to the repository.

This was asked in an issue earlier today. It's a combination of 1) I didn't even know such flags existed! and 2) I had some compatibility issues with older versions of CMake on my test machines.

I'll look into adding it in the future though!

This might be easier on the eyes for people as well: http://polytonic.github.io/Glitter/

Looks a bit prettier than the default GitHub repository page anyway.

Yeah, CMake is a bit of a complicated beast to "learn" so to speak. I spent a fair number of hours pulling my hair out trying to get it working.

This is the result! Hope you find it helpful!

GLUT is a windowing library. GLFW3, SDL, SFML mostly replace everything it does in terms of windowing and input.

:)

They certainly do appeal, but are likely a little outside my expertise to go implement, at least right now. Definitely something I'll look into, time permitting!

I was aiming more for "simpler" to start with I think.

It would be an interesting comparison, yeah. I haven't worked with CUDA much lately though. I was thinking of adding CUDA support so that Chlorine would default to CUDA on Nvidia cards, but it seemed of limited value. The real goal is 1) portability and 2) ease of use, rather than absolute performance.

I was contemplating doing a FFT as a demo, but Mandelbrot was low hanging fruit that made for pretty pictures. Keep in mind this was student work.

If you have a specific problem in mind, I'd be happy to work on adding it as an example.

I'm in search of my first "customer" so to speak. :)

I think the problem with (most of?) these libraries is that they don't solve the fundamental problem, which is: the OpenCL API is awful to work with. Various strategies have been attempted, mainly involving some form of "wrap the C API in less verbose C++!"

Sorry to keep plugging my stuff, but you might be interested in this ... https://github.com/Polytonic/Chlorine

No raw pointers, but you can use C arrays (was that what you meant by raw pointers?).

I wrote this blog post a while ago, and decided to revisit it over the weekend to generate/add some benchmarking data. Figured I'd post it here and see if anyone has any feedback.

I wrote something similar a while back (https://github.com/Polytonic/Chlorine). Always good to see more attention paid to OpenCL though!

I recently put together Glitter (https://github.com/Polytonic/Glitter) which is a basic OpenGL boilerplate that runs on every platform. The only dependency is cmake, so getting started with OpenGL is as simple as generating an IDE project file or makefile and pressing play. No messing with compilers or linkers required. :)

I've spent a significant amount of time learning both OpenGL and WebGL, and I have to say, there is significant value in starting with OpenGL first. For starters, the GLSL compiler is much friendlier. There are also merits to understanding the state-machine from a "C" perspective.