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