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

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 ;)


[1]: http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle#downloads

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

[3]:
// This is C code
#include<gr> //mantle or vulkan

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

// Start building command buffer, optimize fo single time submittion
result = grBeginCommandBuffer(
              cmdBuffer,
              GR_CMD_BUFFER_OPTIMIZE_ONE_TIME_SUBMIT);

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

// Finish recording
grEndCommandBuffer(cmdBuffer);


[4]:
// This is D code
import gr; // this our Mantle or Vulkan wrapper module

// Return a new CmdBuffer instance by value, since it is (probably)
// 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).
{
    cmdBuffer.beginRecording(CmdBufUsage.oneTimeSubmit);
    scope(exit) cmdBuffer.endRecording();

    cmdBuffer.setEvent(event);
}

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 not one of the D devs, but I'm working on a lib that builds shaders from composable templates (in a very pre-alpha stage still, but this is a tough thing to get right).
I was going to do GPGPU through openGL compute shaders, but as soon as there are actual details on the Vulkan API, I will probably go after that instead.

Maybe not what you were looking for, but if it works out, D will be the only language that I know of with something like this.

What I mean by "composable templates":

  alias affine_transform = vertex_shader!(
    `translation`, `rotation`, `scale`, q{
      gl_Position.x = gl_Position.x * cos (rotation) - gl_Position.y * sin (rotation);
      gl_Position.y = gl_Position.x * sin (rotation) + gl_Position.y * cos (rotation);
      gl_Position.xy *= scale;
      gl_Position.xy += translation;
    }
  );

and basically you tack stuff like that together using UFCS,

  auto boxes = Lifetime.Shared!Texture (resolution)
    .fill (transparent);

  auto sq = square (1f).VertexBuffer;

  borrow (sq).basic_shader (green (0.5))
    .affine_transform (fvec (0, 0), 0, (resolution[1]*1.5f/resolution[0])*vector (1f, 1f/3))
    .line_loop.render_to (boxes);

and once you attach the shader to a canvas, it'll deduce the argument types, generate the rest of the shader code, compile, link, upload uniforms and attributes, and save the shader in a global AA for recall in case you're visiting it in a loop. It's designed to be as much like calling r.map!(x => ...) and friends as possible; functional programming with the GPU.

Still working out how to get it to play nicely with compute shaders (IO works differently than for regular shaders) but maybe the Vulkan spec will reveal an easier way to unify them.

So, there you go; someday, it could be D's own ArrayFire + graphics (with a good bit more work).

I've been incubating it as a private repo since its still so raw, and I don't want to unveil before its ready and have it get a reputation as being half-baked, but if there's legitimate interest from people who have a good idea of what they would like to see from a graphics/compute API of this nature, I can open it up publicly. Or I can send invites, if anyone wants to help incubate it by tossing use-cases my way, I'll gladly take them and do my best to build this thing out to meet the needs.