Vulkan 1.0 Release

General Discussions
#1

Vulkan has released!
Here’s a list of useful links:

Announcements
Khronos Press Release
Nvidia Press Release
Vulkan Site

Articles
Engaging the Voyage to Vulkan
OpenGL like Vulkan
Transitioning from OpenGL to Vulkan
Vulkan Shader Resource Binding
Vulkan Memory Management
Vulkan in 30 minutes
GLFW with Vulkan

Books
Vulkan Programming Guide: The Official Guide to Learning Vulkan (OpenGL) 1st Edition

Code
Open-Source Vulkan C++ API
Triangle Demo
Cube Demo
Vulkan Info
Vulkan Ecosystem Components
KaiHH’s Vulkan LWJGL/SWT example

Downloads
LunarG Vulkan SDK
Nvidia Vulkan Beta Drivers
AMD Vulkan Beta Drivers

Reference/Specification
Vulkan Specification
Reference Card
Reference Pages
Registry Overview
Vulkan API Documentation Project
Mantle Programming Guide and API reference

Tutorials
Vulkan-tutorial.com

Misc
GPU Compatibility List
Spasi on Vulkan Support in LWJGL3
Should I switch to Vulkan?

This post was originally a link to Engaging the Voyage to Vulkan

#2
  • New concepts are RenderPasses, Pipelines and DescriptorSets. Vertex/Index stuff seems to be similar to VAOs in OpenGL.
  • Commands aren’t executed immediately; they’re queued up allowing multithreading.
  • Much more powerful memory managing tools.

#3

So, today seems to be the big day… :clue:

#4

HYPE

#5

I woke up to the pleasant news that Vulkan has been released.

Also looks like I made the right decision switching to Nvidia at the start of this year, as AMD is yet to release a Linux driver.

#6

Guess how many lines of cross-platform C code it requires to draw a single textured triangle now?
Answer: 2413
Count probably another 1000 lines for proper API error checking, which this demo explicitly omits.
Now Java 2D Processing does not look that bad, does it? :wink:

#7

I’ll need to look into it further, but a fair amount of that C code appears to be window creation, which is always going to be an absolute mess to make cross-platform unless you have a library for it.

And besides, you don’t get this much extra power for free.

#8

That’s true. My comparison with Processing was more in the direction of whether that complexity/power is really needed for most users here. I see Vulkan rather as a nice toy for people inherently interested in that technology to spend countless months of playing around with it. :slight_smile:
But for productively developing games: absolutely not.

Just waiting for Nvidia and the other vendors to finally release that long-awaited PCI-Express wire protocol. More performance. :point: No, sorry, that was overstressed. ;D

#9

I’ve skimmed through that code KaiHH, and building upon HeroesGraveDev’s observation, a large portion of the LOC looks like its just building various structs and objects, such as Command Buffers and Samplers. The bulk of the code is straightforward, its only the little bits that are complex.

@Spasi, when do you think we can expect LWJGL to support Vulkan?

#10

Yeah, this is pretty much what I expected and honestly it’s not that bad considering (already been stated that a lot of it is to make it nicer). I agree though, most people here (and most non pro devs) don’t have a need for it. Still fun though!

#11

I guess he is in knee-deep and has probably locked himself up in a room now to crank a Vulkan-ready version of LWJGL out soon. :slight_smile:
Poor Spasi, so many people asking (kindly of course) for Vulkan support in LWJGL these days now.
Hopefully he will not oversleep tomorrow for work.
Official press statement :slight_smile: https://github.com/LWJGL/lwjgl3/issues/144#issuecomment-184723602

Yepp, that’s true. Vulkan seem to be like Direct3D. Going crazy with structs. But that would make that structs-building also a vital and core part of the API and not only the functions, wouldn’t it?

#12

https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:large

Pretty good little chart about whether or not to use Vulkan. Although I’m sure that everyone on this site who tries it out on this site will be trying it for the fun of it :stuck_out_tongue:

#13

Ohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboy…

#14

Since this is seems to be turning into a general vulkan discussion thread (and the original article wasn’t really discussed), I’ll update the OP with various relevant/useful links pertaining to vulkan and it’s release.

#15

[quote=“KaiHH,post:11,topic:56271”]
Made decent progress last night, up to creating a Vulkan instance. Struct-building preview:

VkApplicationInfo app = VkApplicationInfo.malloc()
	.sType(VK_STRUCTURE_TYPE_APPLICATION_INFO)
	.pNext(NULL)
	.pApplicationName("HeyV")
	.applicationVersion(0)
	.pEngineName("HeyV")
	.engineVersion(0)
	.apiVersion(VK_API_VERSION);

VkInstanceCreateInfo inst_info = VkInstanceCreateInfo.malloc()
	.sType(VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO)
	.pNext(NULL)
	.flags(0)
	.pApplicationInfo(app)
	.enabledLayerCount(enabled_layer_count)
	.ppEnabledLayerNames(instance_validation_layers)
	.enabledExtensionCount(enabled_extension_count)
	.ppEnabledExtensionNames(extension_names);
#16

That fluent-style builder pattern looks very nice for structs. Keep up the nice work!
Now I am thrilled too to try out Vulkan with LWJGL. :slight_smile:

#17

[quote=“Spasi,post:15,topic:56271”]

I’m not entirely sure this is a good idea. There’s a big risk that that usage pattern will kill escape analysis, and regardless it will be disabled when running the game in debug mode. Besides, it’s really frigging annoying to have to recreate these structs all the time. Creating and starting command buffers, running command buffers, starting render passes… Pretty much all setup code and even some code called repeatedly every frame will require creating structs everywhere. This is verbose as hell.

I guess the point of using structs like these is that they can be set up once and then reused forever, but there has to be a less verbose way of doing this. Even just having a single constructor that sets everything (preferably without breaking escape analysis) would help a lot.

#18

[quote=“theagentd,post:17,topic:56271”]
The work on struct support is the primary reason LWJGL 3.0 has not been released yet. I have done extensive testing and I believe that the current implementation is the best we could possibly have until Project Panama. I think I’ve said this before: you’ll find that LWJGL structs are very friendly to escape analysis and clean code (EA is very sensitive to inlining) will easily benefit from eliminated allocations.

Of course, EA will only take care of the Java instance fields. The problem with Java is that you cannot allocate the struct data itself on the stack. So, you always have to do the malloc/free dance and is the reason I’ve worked so hard to incorporate a decent allocator in LWJGL (jemalloc). But, you can also easily provide your own off-heap memory data structure (with stack-like characteristics) and the LWJGL struct implementation will work equally well with that. If you’d like to discuss this further, please make a new post or contact me directly.

[quote=“theagentd,post:17,topic:56271”]
This exists already for all mutable structs. The above code could be written like so:

VkApplicationInfo app = VkApplicationInfo.malloc().set(
	VK_STRUCTURE_TYPE_APPLICATION_INFO,
	NULL,
	appName,
	0,
	appName,
	0,
	VK_API_VERSION
);

VkInstanceCreateInfo inst_info = VkInstanceCreateInfo.malloc().set(
	VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
	NULL,
	0,
	app,
	enabled_layer_count,
	instance_validation_layers,
	enabled_extension_count,
	extension_names
);

It’s a multi-setter instead of a constructor, because there are multiple ways to instantiate a struct instance. I wouldn’t use it in Java, but it’s nice to have for alternative JVM languages with support for named arguments.

#19

@Spasi is smart enough to, of course, foresee that as well.
Like the struct API was at the time I last checked is that you can just use a ByteBuffer to back the storage of a struct. I mean, that struct interface will do that anyways.
Those builder methods and setter/getter methods are just there to ease writing the right values to the right byte offsets into the backing buffer.
But if you know them, then you can just use the java.nio.ByteBuffer API.

#20

You can Use something like this :slight_smile:


class VkApplicationInfo{
	public sType_Enums sType;
	public pNext_Type pNext;
	...
	
	static public VkApplicationInfo CreateDefault(){
		...
		return...
	}
	static public VkApplicationInfo CreateEmpty(){
		return new VkApplicationInfo();
	}
	
	public Buffer MallocData(){
		....
	}
}