Khronos Vulkan + SPIR-V - could Go shine in graphics?

<p>Hey fellow Gophers, today I read about next-gen specification for graphics development called <a href="https://www.khronos.org/vulkan">Vulkan.</a></p> <p>It&#39;s cross-platform, OS-independent, GPU-vendor independent which gives one consistent API. More importantly it gives responsibility to app developers for thread management to generate command buffers to driver. So it got me thinking about Go and its goroutines.</p> <p>What do you think about it? Do you believe Go could finally be good in graphics processing?</p> <p>You can watch Vulkan and SPIR-V presentation <a href="https://www.youtube.com/watch?v=qKbtrVEhaw8">here.</a> There are some pretty impressive demos as well.</p> <p>I searched through GitHub and found that development for <a href="https://github.com/jteeuwen/spirv">SPIR-V</a> has already begun, so I&#39;m very happy to see it.</p> <p>^Note ^that ^I&#39;m ^not ^advanced ^developer ^and ^have ^close ^to ^zero ^experience ^with ^graphical ^{applications,} ^so ^I ^might ^be ^wrong.</p> <p>edit: quote from <a href="https://github.com/jteeuwen/spirv">SPIR-V</a> go package:</p> <blockquote> <p>Vulkan is a new open standard API by Khronos that offers low-level control of GPUs for graphics and general purpose computation. It has been designed from the ground up around the capabilities of modern hardware.</p> <p>Direct GPU control with minimal driver overhead. For example, data is written directly to GPU memory instead of using calls equivalent to glUniform. Applications can implement their own memory allocation strategies.</p> <p>Another feature is the render pass, which offers control over loading of render targets at the start and end of renders, which is very useful for tiling architectures.</p> <p>Multi-threading friendly architecture. Multiple threads can create and populate command buffers at the same time, which can then be submitted to the GPU by a separate thread.</p> <p>Unified API for desktop, mobile and embedded platforms. There is no equivalent of OpenGL ES, Vulkan offers the same API on all platforms.</p> <p>Intermediate bytecode for shaders. The driver accepts shaders in the SPIR-V bytecode format. Khronos will supply a separate compiler for GLSL that targets this intermediate format. Third-party developers will be able to write their own compilers for other languages.</p> </blockquote> <hr/>**评论：**<br/><br/>sh41: <pre><p>I am excited about Vulkan and I think it will go great with Go. I&#39;m currently using OpenGL (via <a href="https://github.com/goxjs/gl">https://github.com/goxjs/gl</a> bindings) for all my graphics needs.</p> <p>My only beef with Vulkan is that it doesn&#39;t support the browser, unlike WebGL. I don&#39;t think I can leave OpenGL behind until it does. But I&#39;ll definitely be playing with it as soon as I can get my hands on it.</p> <p>Keep your eyes open on developments in the <a href="https://github.com/go-gl">https://github.com/go-gl</a> organization.</p></pre>exch: <pre><p>I&#39;m the owner of that github repo. While a fair amount of work has been done, a lot still has to be addressed. The reason the repo has been quiet since March is because the SPIR-V and Vulkan specifications were still in flux and incomplete at the time.</p> <p>I will likely resume work on it once Khronos settles on the final versions. Given I have a lot of other things going on in my life at the moment, I can&#39;t guarantee that though.</p></pre>singron: <pre><p>Garbage collected languages aren&#39;t terribly good at high performance graphics. If you are pushing performance (and would benefit from a higher performance api like this), any gc is going to make you skip at least 1 frame. No gc can be tuned well enough to have no pause and not slow down the application.</p> <p>Also, go doesn&#39;t have interfaces for memory mapped io, so you might end up having to write a lot of glue code in C or Cgo, depending on how prevalent those apis are.</p> <p>Goroutines are a big win with blocking io, since the runtime can keep all the cores running without threading overhead, and you can write ordinary synchronous code (no callbacks). With GPU command buffering, go routines don&#39;t matter as much since adding commands won&#39;t block. Goroutines also still have overhead, so you still wouldn&#39;t want to spawn a goroutine for every little object you wanted to render and try to parallelize that way.</p></pre>kylewolfe: <pre><p>While I am no expert with graphics, I would like to point out that Java is garbage collected and there is plenty of game development done in it. As far as go, there have been significant improvements to the GC, as it is now concurrent (<a href="http://www.youtube.com/watch?v=S9Bu6fZnLGM&amp;t=1m56s">http://www.youtube.com/watch?v=S9Bu6fZnLGM&amp;t=1m56s</a>). Furthermore, GC can be disabled entirely in Go.</p></pre>singron: <pre><p>Concurrent GC isn&#39;t enough (I was specifically talking about this when I said &#34;no gc can be tuned well enough&#34;). If you look at the slides, the goal is no more than 10 ms pauses. In order to render 60 frames per second, you need to render a frame <em>every</em> 16 ms. If you take more than 6 ms to render a frame, 10 ms will always cause a frame skip. If you are taking 15 ms per frame, a single garbage collection might make you skip 2 frames in a row. The slides also show running application code for 40 ms out of every 50 ms. If you garbage collect every 50 ms, you are going to skip at least 1 frame every ~3 frames.</p> <p>Java has the exact same issues. Games written in Java have the same problems with skipping frames and GC. I&#39;ve never seen a java game that was sufficiently graphically intense to take more than 6 ms per frame, run at 60 fps, and not jittery.</p> <p>There are some ways to get around this in garbage collected languages. You can allocate big byte arrays and manipulate them without pointers (there are a few libraries that do this very performantly for simple things like caches). The lack of pointers and individually allocated objects keeps pauses really short. However this quickly breaks down when you want to do complicated things, since you have to throw away all the properties about Go you like (gc, methods, interfaces, type checking, etc.). At this point, you are better off writing in a different language.</p> <p>You can turn off GC, but you better not allocate anything! You can attempt to do this in Go, but it will limit the dynamic content of anything you program. If you have 1 screen with 100 monsters, 1 screen with 100 people, and 1 screen with 1000 items, you need to have all of that allocated simultaneously at all times, even though you don&#39;t use any of it simultaneously (and you ideally need to pre-allocate it, so that you don&#39;t generate garbage while appending and modifying datastructures).</p> <p>If you don&#39;t really care about 60 fps, not skipping frames, and doing intensive rendering, then Go, Java, and whatever else are perfectly good languages, but then you also wouldn&#39;t care about Vulkan.</p></pre>kylewolfe: <pre><blockquote> <p>You can turn off GC, but you better not allocate anything! You can attempt to do this in Go, but it will limit the dynamic content of anything you program. If you have 1 screen with 100 monsters, 1 screen with 100 people, and 1 screen with 1000 items, you need to have all of that allocated simultaneously at all times, even though you don&#39;t use any of it simultaneously (and you ideally need to pre-allocate it, so that you don&#39;t generate garbage while appending and modifying datastructures).</p> </blockquote> <p>How is this done in c++ / c# / whatever is used these days?</p> <p>Edit: What I&#39;m wondering is if non garbage collected c++ == non garbage collected Go, with the exception of mature supporting libraries to tackle common game development tasks. It sounds like the issue of having to watch what you allocate (and do not) exists in either language. Are there also tools to help with this that Go does not have?</p></pre>TerriblementeCruel: <pre><p>So is there any alternative besides C/C++ for &#34;serious&#34; game development? I know a lot of people use C# for gamedev, but it has GC as well (how do they deal with it?).</p></pre>scoith: <pre><p>With some effort, is it well possible. There&#39;re dozens of AAA titles developed with Unity or UnrealEngine, all with GC.</p></pre>