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).
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.
Is there a particular reason you choose to explicitly add CXX flags ('-std=c++11') over CMake's compiler feature support? The later is, in principle, more portable and future proof than hardcoding the flags.
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.
