Archives Discussions

[jtrudeau]

Folks,

Khronos has released technical previews of the OpenGL Next open standard, at GDC. They have trademarked the new name for this standard, Vulkan!

Information here: https://www.khronos.org/news/press/khronos-reveals-vulkan-api-for-high-efficiency-graphics-and-compu...

Live long and prosper, y'all.

[jason]

Super cool.

I for one can't wait to use C++ like CUDA can.  Type traits and static / compile time polymorphism - some fools think C is the way to go but it becomes hard to make generic code and you tend to get higher performance and more flexible code if you (ab)use c++ templates right.  Less macro tom-foolery too and all those defines which need to get set on the host side (for every language that's insantiating the opencl) w/ every given type. 

My advice is put 2.1 out pronto and start sucking more researchers, automotive and military customers back from NVidia - potentially before you've got every bit of Vulkan perfected.

Looking forward to OpenGL's successor not being so gosh darn complicated too.  The math is fine but soooooo many gotchas, it's tremendously off-putting/unproductive to use directly for me.

[mdriftmeyer]

I hope the option to have ObjC interfaces, Swift Interfaces, Java, Python, Ruby, etc., are a possibility and not for a need of a bridge via C++. I'll take C 7 days a week over C++, especially seeing as Clang 3.6 is now C11 default.

[jason]

Uh... objc is probably possible but all the other stuff is not likely to have a good backing.  We're talking of inside the kernels/on device, nothing about the runtime api - restricted subsets of python and other things are possible but its clearly a different environment.  It probably wouldn't be an easy task or ever properly supported and the language will be very different from how you know it.  Taking C 7 days a week over C++ is flamewar words (akin to my earlier statements) but I put it in the same basket as someone who thinks goto is evil... you don't or are unwilling to understand how to use a tool that can help you.  I'm not saying its not rediculously over complex but if you understand how to work with the complexity you will produce faster code than C, and it will be more adaptable/reusable - if you don't understand why go study why this is true.  Remember also we're side skiping out on all the issues that embedded-c folks/nazis hate too: no virtual anything, no exceptions, no dynamic stuff.  Just classes/structs and the full power of templates and type traits.  This actually also has the effect of making reusable constructs but allowing you to tune them to your needs... on the kernel/device side.

Maybe have a look at CUB to understand practically (through a popular library) why all this is a good thing.