Vulkan 1.0 Release

SirSoltex · February 19, 2016, 12:20am

Vulkan looks neat! the stuff people are doing just days after its release is so cool, wish my mac had support for it :’(

theagentd · February 19, 2016, 12:55am

I have some questions about the synchronization required in Vulkan.

It seems like a Vulkan command “queue” gives very few ordering guarantees, so calling it a queue seems misleading as hell. Does anyone have any more information about the parts marked with ??? ?

Commands submitted to different queues may execute out of order and/or concurrently (obviously).
??? Semaphores are only needed when synchronizing between queues. If you only have one queue, then you never need to use semaphores. ???
??? Command buffers submitted to a queue can execute concurrently but not be reordered (the hell does that mean?). ???
??? If multiple command buffers are submitted to the same queue, they are treated as one big command buffer concatenated together, with commands inside them executed in essentially arbitrary order (except primitives drawn are ordered, see below) unless you use barriers. ???
??? To ensure that previous commands have finished, use memory barriers. In what cases? When the following commands need data generated by previous commands? What about blending? What about presenting? ???
??? Once a command buffer has been vkQueueSubmit()ted, it can immediately be cleared as the contents of it has been copied to the queue. ???
Primitive rendering is ordered by draw call and internally within a render subpass, similarly to OpenGL.

It never will be. Enjoy your Metal.

NegativeZero · February 19, 2016, 12:58am

It appears that Intel and AMD GPUs only have one graphics queue

EDIT: AMD Queue Families


	Queue families: 3
	Queue family 0
		Queue flags: GRAPHICS COMPUTE SPARSEBINDING 
		Queue count: 1
		Timestamp Valid Bits: 63
	Queue family 1
		Queue flags: COMPUTE SPARSEBINDING 
		Queue count: 1
		Timestamp Valid Bits: 63
	Queue family 2
		Queue flags: TRANSFER SPARSEBINDING 
		Queue count: 2
		Timestamp Valid Bits: 0

EDIT2:

Annoyingly, I’m getting a JVM crash when calling [icode]vkGetDeviceQueue[/icode]

theagentd · February 19, 2016, 2:30am

NegativeZero:

It appears that Intel and AMD GPUs only have one graphics queue

EDIT: AMD Queue Families


	Queue families: 3
	Queue family 0
		Queue flags: GRAPHICS COMPUTE SPARSEBINDING 
		Queue count: 1
		Timestamp Valid Bits: 63
	Queue family 1
		Queue flags: COMPUTE SPARSEBINDING 
		Queue count: 1
		Timestamp Valid Bits: 63
	Queue family 2
		Queue flags: TRANSFER SPARSEBINDING 
		Queue count: 2
		Timestamp Valid Bits: 0

[/icode]

That’s really all you need though. One queue for submitting render commands, one for texture streaming and one for asynchronous compute.

NegativeZero · February 19, 2016, 3:07am

[quote=“theagentd,post:44,topic:56271”]
What are you going to do on Intel, which only has 1 queue?

theagentd · February 19, 2016, 4:32am

[quote=“NegativeZero,post:45,topic:56271”]

It does? Are you sure? I’d love to see what queue families it has.

NegativeZero · February 19, 2016, 5:55am

[quote=“theagentd,post:46,topic:56271”]

Each one has 1 family, with one queue. The family has [icode]GRAPHICS[/icode], [icode]TRANSFER[/icode] and [icode]COMPUTE[/icode].
TimestampValidBits of 36, Granularity of (1, 1, 1).

abcdef · February 19, 2016, 6:37am

Has anyone gotten the vulcan drivers to load on Linux? I have the 361 graphics drivers installed and the 352 OpenCL drivers. Do the opencl drivers need to be more current too?

Phased · February 19, 2016, 8:08am

By 361 I am assuming thats NVIDIA, I believe the only version that has Vulkan support current is 356 (windows) and 355 (linux).

theagentd · February 19, 2016, 1:42pm

I can’t find a CharSequence overloaded version for pLayerName of vkEnumerateDeviceExtensionProperties()…

EDIT: I downloaded the latest version of LWJGL, and a lot of stuff got changed from PointerBuffer to LongBuffer. However, command buffers are still used with PointerBuffers. Could be a bug?

EDIT2: I’m fairly convinced that since the spec lists all these things as objects that they should all be PointerBuffers, not LongBuffers.

Things that I noticed started using LongBuffers since last nightly:

vkCreateCommandPool()
glfwCreateWindowSurface()
vkCreateSwapchainKHR()
vkCreateSemaphore()
VkPresentInfoKHR

EDIT3: VkInstanceCreateInfo should probably be reading the limit from the layer and extension buffers instead of taking in a count.

EDIT4: VkDeviceCreateInfo should take a VkDeviceQueueCreateInfo.Buffer since you can pass in multiple queue infos.

EDIT5: There’s no free() function for the .Buffer classes? I assume .Buffer.get(0).free() would work, but that’s hacky as hell?

Spasi · February 19, 2016, 5:20pm

[quote=“theagentd,post:50,topic:56271”]
Thanks, fixed in build 27.

[quote=“theagentd,post:50,topic:56271”]
It’s what I mentioned above about “non-dispatchable handles (Vulkan spec p2.2)”. Dispatchable handles are pointers to opaque structures, which means 32-bit values on 32-bit architectures and 64-bit values on 64-bit architectures. This is what PointerBuffers are good for. Non-dispatchable handles on the other hand are always 64-bit values, even on 32-bit architectures, which is why the affected functions have switched to LongBuffers. VkInstance, VkPhysicalDevice, VkDevice, VkQueue and VkCommandBuffer are dispatchable handles. Other handles are non-dispatchable.

[quote=“theagentd,post:50,topic:56271”]
This is indeed not symmetric with how auto-sized parameters in functions work. The support for functions has the nice property that the size/count parameter is hidden when auto-sizing is applied. The same cannot be done with structs, the size/count field accessors are always there. So when you set the buffer field, it’s not obvious to the user whether they should also set the size/count field or not. You have to document it somehow, but no one really reads documentation.

Anyway, I’m still thinking about it and we have time until 3.0 is released. If anyone has any input on the matter, please let me know.

[quote=“theagentd,post:50,topic:56271”]
Thanks, fixed VkDeviceCreateInfo and other structs with the same problem.

[quote=“theagentd,post:50,topic:56271”]
Struct buffer instances are freed using memFree(). I know this is a bit inconvenient, but I wanted it to be symmetric with how you free NIO buffers (I can’t add a free method to those classes). The same is true for PointerBuffer.

Struct and callback instances on the other hand do have a .free() method.

theagentd · February 19, 2016, 5:56pm

Thanks for your response. I’m sorry I’m missing obvious stuff all the time; head is all foggy from a cold. Seriously, I’ve been reading the spec over and over again but it’s really hard to grasp all the details.

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

For this I was mostly referring to the set() functions which take in all arguments. Having an overloaded set() function which reads from the buffers passed in shouldn’t introduce any confusion IMO.

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

[quote=“theagentd,post:50,topic:56271”]
Thanks, fixed VkDeviceCreateInfo and other structs with the same problem.

I still think it should be added. It’s confusing when struct.malloc() is freeable with struct.free() but struct.malloc(1) isn’t. Having malloc() on the struct class but free() somewhere completely different is what caught me off-guard in the first place. The struct arrays don’t have that much in common with NIO buffers in the first place IMO.

Spasi · February 19, 2016, 6:32pm

[quote=“theagentd,post:52,topic:56271”]
Good idea, it can be done for set().

[quote=“theagentd,post:52,topic:56271”]
A struct buffer is exactly like a NIO buffer. It has position, mark, limit, capacity. You can flip, rewind, reset, slice, duplicate it. It has the same relative and absolute getters and setters. The only difference is that each element is a struct value instead of a primitive value.

[quote=“theagentd,post:52,topic:56271”]
That’s actually a very good point. The memAlloc and memFree methods are in one place (even for PointerBuffer), malloc() and the corresponding free() should always be in the same place too. I’ll add free() to struct buffer classes in the next build.

theagentd · February 19, 2016, 8:56pm

Thanks, Spasi! Much appreciated!

Does anybody know where the specification for the extensions are? I’m trying to get EXTDebugReport and layers working and got this funny callback function:

public int invoke(int arg0, int arg1, long arg2, long arg3, int arg4, long arg5, long arg6, long arg7)

No idea what anything does and I can’t find any documentation on it at all. The Github branch for EXTDebugReport doesn’t seem to be complete. Is there any place I can find pages similar to the OpenGL extension documentation and KHR_vulkan_glsl (https://www.khronos.org/registry/vulkan/specs/misc/GL_KHR_vulkan_glsl.txt)?

KaiHH · February 19, 2016, 9:11pm

C declaration:

github.com

KhronosGroup/Vulkan-Docs/blob/1.0-VK_EXT_debug_report/src/vulkan/vulkan.h#L3677-L3769


#define VK_KHR_win32_surface 1
#include <windows.h>

#define VK_KHR_WIN32_SURFACE_SPEC_VERSION 5
#define VK_KHR_WIN32_SURFACE_EXTENSION_NAME "VK_KHR_win32_surface"

typedef VkFlags VkWin32SurfaceCreateFlagsKHR;

typedef struct VkWin32SurfaceCreateInfoKHR {
    VkStructureType                 sType;
    const void*                     pNext;
    VkWin32SurfaceCreateFlagsKHR    flags;
    HINSTANCE                       hinstance;
    HWND                            hwnd;
} VkWin32SurfaceCreateInfoKHR;


typedef VkResult (VKAPI_PTR *PFN_vkCreateWin32SurfaceKHR)(VkInstance instance, const VkWin32SurfaceCreateInfoKHR* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkSurfaceKHR* pSurface);
typedef VkBool32 (VKAPI_PTR *PFN_vkGetPhysicalDeviceWin32PresentationSupportKHR)(VkPhysicalDevice physicalDevice, uint32_t queueFamilyIndex);

This file has been truncated. show original

Also see LWJGL’s sources jar:
https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=org.lwjgl&a=lwjgl&v=3.0.0-SNAPSHOT&e=jar&c=sources

theagentd · February 19, 2016, 9:15pm

Dear lord in heaven… Thanks.

Spasi · February 19, 2016, 10:30pm

Please don’t bother with EXT_debug_report yet, extension support is broken atm (specifically, loading of extension function pointers).

theagentd · February 19, 2016, 11:41pm

Uhhh? Wait, then how can the swapchain and surface extensions work?

Spasi · February 20, 2016, 9:40am

[quote=“theagentd,post:58,topic:56271”]
For now, you can load function pointers manually (using vkGetInstanceProcAddr or vkGetDeviceProcAddr) and call them using the org.lwjgl.system.JNI class.

Sorry for the inconvenience, but Vulkan is unlike OpenGL (where you have thread-local state) and OpenCL (where everything goes through the ICD). Function pointers in Vulkan may be different for different VkInstances. Also, function pointers may be different for different VkDevices (via vkGetDeviceProcAddr, removing a level of indirection). This doesn’t match LWJGL’s design of using static methods for everything.

I haven’t figured out the best approach to handle it yet, but I assure you it’s top priority. One option would be creating instances of binding classes for particular VkInstances/VkDevices. For example:

VK10 vk = new VK10(myInstance);
vk.MapMemory(...);

but I’d like to avoid doing that. It’s alien to LWJGL (and its users) and requires significant changes in our code generator.

Spasi · February 20, 2016, 11:54am

[quote=“theagentd,post:54,topic:56271”]
It looks like you haven’t set up the LWJGL source in your IDE, the signature is:

int invoke(int flags, int objectType, long object, long location, int messageCode, long pLayerPrefix, long pMessage, long pUserData)

Sorry if I’m wrong, but this is still a good opportunity to write this:

The LWJGL distribution comes with a src.zip. I highly recommend to anyone working with LWJGL to associate that source bundle with lwjgl.jar in your IDE. That way you have direct access to both javadoc and source code. IDEs usually have a javadoc popup you can show, generated directly from source. LWJGL comes with a ton of javadoc and you can browse it without ever leaving your IDE. I dare say this is the best feature in LWJGL 3 and it’s where I’ve spent most time in the last 3 years.

Documentation answers most API related questions, but when you have a LWJGL/Java specific question, you can also ctrl/cmd+click to see how things are implemented in LWJGL. Most of it is trivial and you can easily customize it by using the same internal APIs (everything is publicly accessible).