Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (764)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (852)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Vulkan and SPIR-V Presentation  (Read 3152 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2015-04-04 20:58:21 »

https://www.youtube.com/watch?v=qKbtrVEhaw8&feature=iv&src_vid=EUNMrU8uU5M&annotation_id=annotation_697454733

Vulkan summary

 - GPU selection / Multi-GPU compatibility
 - Opt in for extensions, nothing is automatically enabled.
 - No driver validation by default. Validation layer is opt-in for development.
 - Queues for graphics, compute and DMA (asynchronous data transfer). Multiple queues of each type.
 - Command buffers can be created from all threads, but they are not thread-safe (use 1 command buffer per thread).
 - Command buffers can be precomputed and reused, and all driver optimizations etc are done on application thread. Driver is simpler
 - SPIR-V shaders are compiled instantly on application thread, allowing multi-threaded shader compilation.
 - Pipeline = shader + framebuffer internal format + blend/depth/stencil etc state. Precompiled, but some settings are dynamic.
 - Resources are allocated by creating the CPU side object, then attaching GPU memory to them. GPU memory can be allocated in chunks and the application can do exactly what it wants with it.
 - Resources are accessed by GPU using descriptors. Descriptors are organized in descriptor sets.
 - Descriptor sets and pipelines both have layouts that much match, allowing you to switch entire descriptor sets extremely fast.
 - Rendering is done in render passes. Encapsulates all operations for a specific framebuffer.
 - Rendering is essentially [bind pipeline, bind descriptor set, draw call] triples.
 - All these draw calls are stored in a command buffers.
 - No global state! Driver only tracks state inside command buffers.
 - Indexed, non-indexed, direct, indirect, compute, etc draw calls supported.
 - Synchronization between CPU, GPU, etc.
 - Barriers must be placed when using a resource in a new way (example: render-to-texture --> sample texture)
 - Finally submit command buffers to the Vulkan queues. Can reuse command buffers any number of times.

 - Apparently not really low-level. Just a much better fit for modern GPUs.
 - Even without utilizing multithreading, has much better CPU performance anyway.

SPIR-V summary
 - Open standard. Can write your own <whatever>-to-SPIR-V compiler.
 - SPIR-V is an intermediate language. Vulkan drivers can only use SPIR-V shaders.
 - Compile GLSL/whatever to SPIR-V offline, distribute SPIR-V binary file with game.
 - Driver still needs to compile SPIR-V to assembly code for the GPU you have.
 - SPIR-V can support pointers but can also run without them (like GLSL).
 - Can contain debug information to allow you to debug the source code.
 
 - All in all, not really that relevant for us.


ARM summary
 - Prototype ARM Mali Midgard GPU driver created for Vulkan.
 - Vulkan takes only 21% as many CPU cycles to render the same thing in their test.


The rest
 - Imagination technologies ported a complicated demo using 2 people and 2 months to Vulkan, got better CPU performance.
 - Intel has a prototype Vulkan render 200 000 primitives using OpenGL CPU bound at ~30 FPS, using Vulkan the CPU usage drops a lot, splits the load across all cores and runs at ~42 FPS.
 - Nvidia showed an unoptimized "OpenGL-emulated" Vulkan driver that had 5x (400ms --> 80ms) better CPU performance, and they're expecting a 45x (400ms --> 9ms) increase after optimization.


Q&A
 - Open-source intermediate loader takes care of directing Vulkan calls to the right driver when using multiple GPUs from different vendors.
 - Minimum specs roughly equivalent to OpenGL ES 3. Seems to require compute shaders, which in theory should be Nvidia 8000 series and AMD HD 3000 series (OGL3), but might mean OGL 4 cards only if we're unlucky.
 - The demos used an open source GLSL-to-SPIR-V compiler which is still under development. One demo faked it and loaded GLSL directly to be able to benchmark the relevant CPU overhead of Vulkan only.
 - They will not be abandoning OpenGL. Fuuuuuuuu-------
 - Hello world! on GL is 5 lines; on Vulkan it's 600 lines, but obviously a lot of that can be reused.

Myomyomyo.
Offline KudoDEV

JGO Ninja


Medals: 79
Exp: 6 years


Game Dev Hobbyist


« Reply #1 - Posted 2015-04-04 21:16:46 »

Multiple Vulkan instances and GPU handles sounds pretty exciting!

Offline theagentd
« Reply #2 - Posted 2015-04-04 21:59:21 »

Should be able to manually use two or more GPUs and be able to synchronize resources the way you want. I could for example simplify and improve my temporal antialiasing by manually synchronizing the previous framebuffer between GPUs instead of having to work with the last framebuffer rendered by that GPU.

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (591 views)
2018-06-10 19:43:48

EgonOlsen (695 views)
2018-06-10 19:43:44

EgonOlsen (478 views)
2018-06-10 19:43:20

DesertCoockie (831 views)
2018-05-13 18:23:11

nelsongames (1026 views)
2018-04-24 18:15:36

nelsongames (1083 views)
2018-04-24 18:14:32

ivj94 (1664 views)
2018-03-24 14:47:39

ivj94 (622 views)
2018-03-24 14:46:31

ivj94 (1501 views)
2018-03-24 14:43:53

Solater (569 views)
2018-03-17 05:04:08
Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46

Deployment and Packaging
by philfrei
2018-08-19 23:53:08

Deployment and Packaging
by philfrei
2018-08-19 23:50:04

Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!