First version

[MarkKremer]

Hi people,

In this issue I will track the progress for the first version of Vulkan support for Gorgonia as proposed by 0x0f0f0f. This is not an exhaustive list. There is a lot to be figured out and I will add items along the way.

My current plan is to see if I can get something of the ground. There will be a lot of work that needs to be done that I won't be able to get around to. If you want to contribute, let me know and we'll figure out what you can do. For casual contributors, I'll try to make some nice low-hanging-fruit tasks available soon-ish.

TODO

• [x] Initialization
  • [x] Create instance
  • [x] Set-up validation layers and debug callback
  • [x] Hardware device selection
  • [x] Logical device creation
  • [x] Load queues
• [x] Computing (not yet connected to Gorgonia)
  • [x] Load data using buffers and descriptors onto the GPU
  • [x] Retrieve buffers from the GPU (is this different from retrieving the result from a shader?)
  • [x] Create a compute pipeline (reference)
  • [x] Create a command buffer
  • [x] Run a command buffer / figure out fences etc.
  • [x] Retrieve the result of a shader
  • [x] ...
• [ ] Implement tensor Engine interface
• [ ] Write shaders
  • [ ] Test output by comparing it to cpu tensor output
• [x] Make simple program that lists graphics cards and capabilities for debugging
• [ ] Write readme
• [ ] Write other docs
• [ ] Add licence file

Low hanging fruit / other free to take tasks

• [ ] Test the cmd/testing application on Windows. The docs state that SetDefaultGetInstanceProcAddr is only implemented for Linux but the implementation tells a different story.
• [ ] Test the cmd/testing application on Mac. The docs state that SetDefaultGetInstanceProcAddr is only available for Linux. Looking at the implementation, this seems to be true for Mac. Check if there is an issue for this in the vulkan-go repo, create an issue for this or see if we can get this working some other way without needing a windowing library.

When you take on a low-hanging-fuit task, please comment below so other contributors know not to work on the same task.

Contributing

For Vulkan you need to install the Vulkan drivers for your specific graphics card. You'll also need to install the Vulkan SDK. Read this tutorial for extra instructions. You can ignore the GLFW/GLM parts.

If you're new to Vulkan, I recommend diving into this tutorial. It is focused a bit more on the graphics side than on the compute but you'll notice that a lot of it works in the same way.

[MarkKremer]

I've been thinking about what Vulkan calls to place under which Gorgonia interfaces. I've been looking a lot at Kompute for inspiration. So here's my stream of consciousness:

• Gorgonia's tensor.Engine interface does memory allocation. So this will contain CreateBuffer, AllocateMemory, BindBufferMemory and MapMemory calls. The Engine.Alloc function will return our Vulkan implementation of the Memory interface.
• Kompute uses something that is called a "Sequence". It basically holds a command buffer and has functions to begin/end/eval recording. It also deals with fences for (a)sync operations. Kompute's "Manager" has a lookup table so you can have multiple sequences and use them by name. The manager basically calls the begin/end/eval functions one after another to execute an "op". I think this abstraction is useful to keep our Engine clean. But to keep things simple, I think it's useful to have our Engine just have a single Sequence for now.
• It has two other classes: "OpAlgoBase" (which ops inherit from) and "Algorithm". The op uses Algorithm to create descriptors/descriptorLayouts/descriptorSets, upload the shader, and create the pipeline that will be run on the sequence. The op itself loads the shader needed for the op from the disk. It also checks if the tensor are compatible with itself. Gorgonia works a little differently. Engine implements MatMuler etc.. But this just executes the matrix multiplication. Dense (implements Tensor and DenseTensor) has a MatMul function too, which checks the shapes and calls the engine to perform the operation. It would be great if we could use the existing Dense implementation as-is. I'm not entirely sure if this is possible. Our Vulkan engine will need to implement the MatMuler interface and the like. I think the Algorithm/OpAlgoBase abstraction is useful to copy. Mostly because it can hold the command buffer. Then we'll be able to cache the ops in the engine at some point. For now I think it's fine to just create and init the op in the MatMul function and then to run it. Engine will need a function to run an op in a sequence just like Kompute's Manager. Sidenote: Kompute makes heavy use of constructors and templates so I'll have to figure out how to convert that to somewhat idiomatic Go.
• Assignment/retrieval of values to/from tensors is also done using ops by Kompute. This sounds fine to me but I haven't thought about it much yet.