Sorry if I’m asking redundant questions, but I assume you have support for wrapping a ByteBuffer+offset with a struct so I can malloc one big buffer and store multiple structs in it?
ByteBuffer b = malloc(...);
VkApplicationInfo appInfo1 = VkApplicationInfo.wrap(b, 0);
VkApplicationInfo appInfo2 = VkApplicationInfo.wrap(b, ...);
[quote=“theagentd,post:21,topic:56271”]
LWJGL currently supports the following:
ByteBuffer b = BufferUtils.createByteBuffer(VkApplicationInfo.SIZEOF * 10);
long a = memAddress(b);
VkApplicationInfo ai1 = new VkApplicationInfo(b); // no explicit offset, uses current ByteBuffer.position() like everything else in LWJGL
VkApplicationInfo ai2 = VkApplicationInfo.malloc(); // allocates uninitialized memory, make sure to set all fields
VkApplicationInfo ai3 = VkApplicationInfo.calloc(); // allocates zeroed-out memory
VkApplicationInfo ai4 = VkApplicationInfo.create(); // allocates a ByteBuffer via NIO and wraps it
VkApplicationInfo ai5 = VkApplicationInfo.create(a); // arbitrary memory address
// A <StructClass>.Buffer has an API similar to a NIO buffer, except each element is a struct.
// Also supports flyweight access.
VkApplicationInfo.Buffer aib1 = new VkApplicationInfo.Buffer(b);
VkApplicationInfo.Buffer aib2 = VkApplicationInfo.malloc(10);
VkApplicationInfo.Buffer aib3 = VkApplicationInfo.calloc(10);
VkApplicationInfo.Buffer aib4 = VkApplicationInfo.create(10);
VkApplicationInfo.Buffer aib5 = VkApplicationInfo.create(a, 10);
Instances created with options 2 & 3 must be explicitly freed. ByteBuffer instances allocated via NIO can never be eliminated via EA.
The latest nightly build (3.0.0 #24) includes Vulkan bindings. Notes:
glfwInit();
System.out.println(glfwVulkanSupported());
[quote]0
[/quote]
EDIT:
[quote]1
[/quote]
API version is tricky:
int majorVersion = 1;
int minorVersion = 0;
int patchVersion = 3;
int apiVersion = (majorVersion << 22) | (minorVersion << 12) | (patchVersion << 0);
1.0.0 - 1.0.3 works for my Nvidia driver. Just passing in 0 does not work on the Nvidia driver. It’s a bug as the spec says that if 0 is passed in it’s ignored.
[quote]Physical devices: 2
[/quote]
:’)
Needed extensions:
VK_KHR_surface
VK_KHR_win32_surface
Instance layers: 0
Physical devices: 2
Device 1:
API version: 1.0.3
Driver version: 1493811200
Vendor ID: 4318
Device ID: 4484
Device type: Discrete GPU
Device name: GTX 770
Pipeline cache UUID: 2b1bc16c4d82f369b03e374cdbc0b09f
Device layers: 0
Queue families: 1
Queue family 1:
Flags: Graphics Compute Transfer Sparse
Queue count: 16
Valid timestamp bits: 64
Minimum image transfer granularity: (1, 1, 1)
Device 2:
API version: 1.0.3
Driver version: 1493811200
Vendor ID: 4318
Device ID: 4484
Device type: Discrete GPU
Device name: GTX 770
Pipeline cache UUID: 2b1bc16c4d82f369b03e374cdbc0b09f
Device layers: 0
Queue families: 1
Queue family 1:
Flags: Graphics Compute Transfer Sparse
Queue count: 16
Valid timestamp bits: 64
Minimum image transfer granularity: (1, 1, 1)
EDIT: glfwGetPhysicalDevicePresentationSupport() is missing in GLFW.
EDIT2: And glfwCreateWindowSurface(). Well, I’m stuck.
OHH!! Thanks a lot, SHC! But… Why?!
I don’t know, but guessing that because they are part of GLFW 3.2 which is not released yet?
VK_KHR_swapchain isn’t supported on my implementation… Murr murr.
[quote]Supported extensions
VK_KHR_surface
VK_KHR_win32_surface
VK_EXT_debug_report
[/quote]
Now I need to figure out how to display stuff to a window without a swap chain…
You sure it is unavailable? Did you explicitly request it in the VkDeviceCreateInfo struct?
Can you post the code you use to build the VkDeviceCreateInfo struct to call vkCreateDevice with?
[quote=“theagentd,post:29,topic:56271”]
The reason is modularity. The LWJGL bindings generator + build system support configuration of which bindings will be included in an LWJGL build. The methods in GLFWVulkan have dependencies in the org.lwjgl.vulkan package. Keeping it separate enables building LWJGL without Vulkan.
edit: Technically not required, but I’ll move glfwVulkanSupported and glfwGetRequiredInstanceExtensions to GLFWVulkan as well (in the next build).
I was checking for instance extensions, not device extensions.
[quote] Supported extensions
VK_KHR_swapchain
VK_NV_glsl_shader
[/quote]
EDIT: vkGetPhysicalDeviceSurfacePresentModesKHR() has no version which takes a VkPresentInfoKHR.Buffer. See below.
[quote=“theagentd,post:26,topic:56271”]
Currently the AMD beta drivers only supports 1.0.0 - 1.0.2, however passing 0 works fine.
According to the current version of the spec, its signature is:
VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceSurfacePresentModesKHR(
VkPhysicalDevice physicalDevice,
VkSurfaceKHR surface,
uint32_t* pPresentModeCount,
VkPresentModeKHR* pPresentModes);
There is no VkPresentInfoKHR in it. And the last parameter pPresentModes is a list of enums, with the enum literals in the LWJGL class KHRSurface.
The signature of the LWJGL method is:
int vkGetPhysicalDeviceSurfacePresentModesKHR(
long physicalDevice, long surface, IntBuffer pPresentModeCount,
IntBuffer pPresentModes)
VkPresentModeKHR is missing entirely.
Ehhhhhhhhhh my fever’s talking.
Yes, it is conceptually an enum. Like I said, the enum literals are in KHRSurface:
public static final int
VK_PRESENT_MODE_IMMEDIATE_KHR = 0x0,
VK_PRESENT_MODE_MAILBOX_KHR = 0x1,
VK_PRESENT_MODE_FIFO_KHR = 0x2,
VK_PRESENT_MODE_FIFO_RELAXED_KHR = 0x3,
VK_PRESENT_MODE_MAX_ENUM = 0x7FFFFFFF;
The IntBuffer argument to the pPresentModes parameter will be filled with those ints by Vulkan.
vkAcquireNextImageKHR() doesn’t seem to accept null fences or semaphores due to LWJGL pointer checks. I don’t see why null wouldn’t be accepted.
EDIT: I think I got a basic swapchain working… Fraps isn’t working obviously, but my test program reports 8800 FPS. I need a break…
[quote=“theagentd,post:39,topic:56271”]
Please download the latest nightly build. “Non-dispatchable” handles (see Vulkan spec p2.2) are now treated correctly and, as a side-effect, the null checks are gone.