Did D will try to get the vulkan opportunity?

ZombineDev via Digitalmars-d digitalmars-d at puremagic.com
Thu Mar 26 05:33:57 PDT 2015

On Wednesday, 25 March 2015 at 18:46:51 UTC, bioinfornatics wrote:
> Dear,
> I would like to know if D dev have a plan with vulkan : 
> https://www.khronos.org/vulkan/ ?
> D lang will be at same level than others language, nothing 
> exists !
> D could try to provide API and an environment around vulkan. To 
> become a language  "need to be used" in this field.
> Regards

I'm very excited about the movement in the graphics API space to 
provide a better abstraction over the modern GPUs.
I was planning to make a Mantle binding when the SDK was to be 
released (because it would be at least 90% the same as Vulkan, 
minus the SPIR-V), and I also wanted to get my hands dirty 
earlier), but unfortunately AMD announced that they will be 
releasing only the spec.

Well they've now released[1] the spec and I couldn't resist 
reading it.
I was very (pleasantly) surprised with how little AMD specific 
stuff it has in it. Actually it is divided into core Mantle and 
AMD extentions and the core part is pretty generic because it has 
to support different GPUs, different OSes and different driver 
versions. For example you need to query the API at runtime for 
the size of the objects, their alignment requirements, their 
preferred placement in one of the (possibly several) memory heaps 
and so on. At the initialization of the API you can provide your 
custom allocation and deallocation functions.

Since it is pure C API the obvious things that a D binding can do 
better are:
+ use slices were the API expects a pointer and size
+ functions like grGetObjectInfo[2] can be templated on the 
GR_INFO_TYPE enum, so you won't have to manually provide the 
value of pDataSize and and the D binding will automatically 
assert/enforce that pDataSize bytes has been written.
+ various other CTFE automation of the quite verbose C API.
+ overall the API is UFCS friendly - for example [3] can be 
written in D as [4].
+ the one thing that can be potentially higher impact is to able 
to compile D code to SPIR-V (maybe doable via CTFE DSL, but it 
probably better if we can use the LLVM or GCC backends). There is 
a C++14 subset that you can use in OpenCl 2.1 C++. We can do 
probably something similar with D.

The moment a working Vulkan SDK is released I will try to make a 
D binding. I expect that other people from the D community are 
also interested in this, so you can sure there will be at least a 
DerelictVulkan ;)


[2]: GR_RESULT grGetObjectInfo(
             GR_BASE_OBJECT object,
             GR_ENUM infoType,
             GR_SIZE* pDataSize,
             GR_VOID* pData);

// This is C code
#include<gr> //mantle or vulkan

result = grCreateCommandBuffer(device, &cmdBufInfo, &cmdBuffer);

// Start building command buffer, optimize fo single time 
result = grBeginCommandBuffer(

// Record command buffer commands
grCmdSetEvent(cmdBuffer, event);

// Finish recording

// This is D code
import gr; // this our Mantle or Vulkan wrapper module

// Return a new CmdBuffer instance by value, since it is 
// not much larger than a handle.
// Pass a CmdBufInfo by ref, or expand the members
// of the struct as parameters to
// device "method" (in semi-OOP terminology).
// The wrapper function asserts that the GR_RESULT is GR_SUCCESS
// since it is probably a logic error that we have provided
// invalid arguments, and we are not Go fanboys obsessed with
// checking error codes :-D
auto cmdBuffer = device.createCommandBuffer(cmdBufInfo);

// The rest is UFCS + scope statement + style
// changes (to make it more friendly-looking).
     scope(exit) cmdBuffer.endRecording();


More information about the Digitalmars-d mailing list