Please provide Stuffs needed cube to run on wayland linux

[neurlang]

Recently I got running the go-wayland-cube demo on Nvidia on Wayland Ubuntu Linux. This fixed the last big gpu vendor (Intel, Amd worked fine).

I've used egl-wayland-1.1.11, and driver was 515.65.01

The things missing from your awesome vulkan package to make this work are available in the vulkan/ subdir of my repo github.com/neurlang/wayland/tree/master/vulkan

Please consider adding those things to your repo, because it's really vulkan related and should be provided by you. Thanks.

[xlab]

@neurlang mind creating a simple PR pls? :) I can quickly merge if it looks fine

[neurlang]

Please don't merge yet, Just take a look at the fork and tell me what you think about the changes https://github.com/neurlang/vulkan

Big problem is there are now two vkCreateInstance, the old one CreateInstance and a new one I renamed as WaylandCreateInstance.

The behavior of the old one needs to support both cases.

[neurlang]

I'd say the old CreateInstance should not be auto generated anymore, and it should iterate InstanceCreateInfo.PpEnabledExtensionNames to see if there's string "VK_KHR_wayland_surface\000". When that string is found, it could trigger the wayland behavior.

But I'm no expert on the matter.

[xlab]

Hi, I think there is some confusion between vk.CreateInstance and vk.CreateWindowSurface, the latter is platform-specific, and the former is not. For instance, in this case:

I don't see that create instance function has anything specific to Wayland.

So, the platform-dependent workflow is like this: 1) get capabilities, check for surface type 2) use platform-specific surface constructor

Within VK package I am providing some platform-dependent code: https://github.com/vulkan-go/vulkan/blob/master/vulkan_android.go#L31

• this one implements surface creation for android surfaces. I generated the code in that file by setting VK_USE_PLATFORM_ANDROID_KHR=1 here: https://github.com/vulkan-go/vulkan/blob/956e3850d8f9d2e617caf5a60622c638ff729c2b/vulkan.yml#L26

I think the approach of having the support of Wayland is following: 1) Generate the platform specific surface creator by setting VK_USE_PLATFORM_WAYLAND_KHR 2) Make a standalone file that uses that generated code, but adds some tags and conditions, so the file is being used only if Go compiles with -tags wayland on Linux. 3) Make a PR to this repo.

[xlab]

Also, there is a high-level abstraction over platform init that I made: https://github.com/vulkan-go/asche

Specifically, your App has to implement a single interface, for example, there is an Android app that creates own surface: https://github.com/vulkan-go/demos/blob/7232238edeba325ac4f953a9e77feaf18d4b414e/vulkancube/vulkancube_android/main.go#L24-L25 (using the platform-dependent method)

So Asche app is platform-agnostic, but your specific app that implements the interface can initialize platform-dependent surfaces.

[neurlang]

Yeah I didn't do anything platform specific in vkCreateInstance. In my case the problem was that I didn't call vk.Init() after vk.SetDefaultGetInstanceProcAddr() Now after fix, I removed the my version of vkCreateInstance, used yours and cube still works.

[neurlang]

What remains needed is the following:

• expose vkGetPhysicalDeviceFeatures2 in your api

• expose vkCreateWaylandSurfaceKHR in your api

• expose vkGetPhysicalDeviceWaylandPresentationSupportKHR in your api

• add WaylandSurfaceCreateInfo type to your api

• add WaylandSurfaceCreateFlags type to your api

Optionally also these two vars, they are difficult to make in go: VkPipeline nilPipeline = (VkPipeline) { 0 }; VkPipelineCache nilPipelineCache = (VkPipelineCache) { VK_NULL_HANDLE };

var NilPipeline = (Pipeline)(unsafe.Pointer(&C.nilPipeline)) var NilPipelineCache = (PipelineCache)(unsafe.Pointer(&C.nilPipelineCache))

[neurlang]

Done.

vkGetPhysicalDeviceFeatures2 also isn't strictly needed, and will be added by other's effort.

Pls have a look: https://github.com/vulkan-go/vulkan/pull/65

[neurlang]

Any feedback for the PR? Any possible problems?

Is the approach of setting the build define VK_USE_PLATFORM_ANDROID_KHR using -tags wayland ok with you?

Users who don't use this tag will be unaffected by this merge.

And vkGetPhysicalDeviceFeatures2 can be done later by upgrading to newer vulkan.

[xlab]

Everything looks fine, I merged! :)