Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 ... 7
  ignore  |  Print  
  Vulkan 1.0 Release  (Read 77390 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Reply #30 - Posted 2016-02-18 18:04:01 »

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

Now I need to figure out how to display stuff to a window without a swap chain...

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 481



« Reply #31 - Posted 2016-02-18 18:23:56 »

You sure it is unavailable? Did you explicitly request it in the VkDeviceCreateInfo struct?
https://github.com/SaschaWillems/Vulkan/blob/master/base/vulkanexamplebase.cpp#L57
Can you post the code you use to build the VkDeviceCreateInfo struct to call vkCreateDevice with?
Offline Spasi
« Reply #32 - Posted 2016-02-18 18:51:43 »

OHH!! Thanks a lot, SHC! But... Why?!

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).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #33 - Posted 2016-02-18 19:27:27 »

You sure it is unavailable? Did you explicitly request it in the VkDeviceCreateInfo struct?
https://github.com/SaschaWillems/Vulkan/blob/master/base/vulkanexamplebase.cpp#L57
Can you post the code you use to build the VkDeviceCreateInfo struct to call vkCreateDevice with?
I was checking for instance extensions, not device extensions.
Quote
   Supported extensions
        VK_KHR_swapchain
        VK_NV_glsl_shader

EDIT: vkGetPhysicalDeviceSurfacePresentModesKHR() has no version which takes a VkPresentInfoKHR.Buffer.
See below.

Myomyomyo.
Offline NegativeZero

JGO Kernel


Medals: 329
Exp: 1 month or less


Zero but not.


« Reply #34 - Posted 2016-02-18 20:12:27 »

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

Currently the AMD beta drivers only supports 1.0.0 - 1.0.2, however passing 0 works fine.

Offline KaiHH

JGO Kernel


Medals: 481



« Reply #35 - Posted 2016-02-18 20:14:16 »

EDIT: vkGetPhysicalDeviceSurfacePresentModesKHR() has no version which takes a VkPresentInfoKHR.Buffer.
According to the current version of the spec, its signature is:
1  
2  
3  
4  
5  
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:
1  
2  
3  
int vkGetPhysicalDeviceSurfacePresentModesKHR(
         long physicalDevice, long surface, IntBuffer pPresentModeCount,
         IntBuffer pPresentModes)
Offline theagentd
« Reply #36 - Posted 2016-02-18 20:25:56 »

VkPresentModeKHR is missing entirely.

Ehhhhhhhhhh my fever's talking.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 481



« Reply #37 - Posted 2016-02-18 20:26:51 »

Yes, it is conceptually an enum. Like I said, the enum literals are in KHRSurface:
1  
2  
3  
4  
5  
6  
   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.
Offline theagentd
« Reply #38 - Posted 2016-02-18 21:22:19 »

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...

Myomyomyo.
Offline Spasi
« Reply #39 - Posted 2016-02-18 22:03:15 »

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.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SirSoltex

JGO Coder


Medals: 33
Exp: 1 year


Pixel-man, Programmer. Lover of the pancreas


« Reply #40 - Posted 2016-02-19 00:20:01 »

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

Are you humans? I don't know.
Offline theagentd
« Reply #41 - Posted 2016-02-19 00:55:13 »

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 Huh ?

 - Commands submitted to different queues may execute out of order and/or concurrently (obviously).

 - Huh Semaphores are only needed when synchronizing between queues. If you only have one queue, then you never need to use semaphores. Huh

 - Huh Command buffers submitted to a queue can execute concurrently but not be reordered (the hell does that mean?). Huh

 - Huh 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. Huh

 - Huh 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? Huh

 - Huh Once a command buffer has been vkQueueSubmit()ted, it can immediately be cleared as the contents of it has been copied to the queue. Huh

 - Primitive rendering is ordered by draw call and internally within a render subpass, similarly to OpenGL.


Vulkan looks neat! the stuff people are doing just days after its release is so cool, wish my mac had support for it Cry
It never will be. Enjoy your Metal.

Myomyomyo.
Offline NegativeZero

JGO Kernel


Medals: 329
Exp: 1 month or less


Zero but not.


« Reply #42 - Posted 2016-02-19 00:58:16 »

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

EDIT: AMD Queue Families
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
   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
vkGetDeviceQueue

Offline theagentd
« Reply #43 - Posted 2016-02-19 02:30:20 »

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

EDIT: AMD Queue Families
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
   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.

Myomyomyo.
Offline NegativeZero

JGO Kernel


Medals: 329
Exp: 1 month or less


Zero but not.


« Reply #44 - Posted 2016-02-19 03:07:31 »

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

What are you going to do on Intel, which only has 1 queue?

Offline theagentd
« Reply #45 - Posted 2016-02-19 04:32:42 »

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

What are you going to do on Intel, which only has 1 queue?
It does? Are you sure? I'd love to see what queue families it has.

Myomyomyo.
Offline NegativeZero

JGO Kernel


Medals: 329
Exp: 1 month or less


Zero but not.


« Reply #46 - Posted 2016-02-19 05:55:05 »

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

What are you going to do on Intel, which only has 1 queue?
It does? Are you sure? I'd love to see what queue families it has.
http://vulkan.gpuinfo.org/displayreport.php?id=53
http://vulkan.gpuinfo.org/displayreport.php?id=69
http://vulkan.gpuinfo.org/displayreport.php?id=70
http://vulkan.gpuinfo.org/displayreport.php?id=83

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

Offline ziozio
« Reply #47 - Posted 2016-02-19 06:37:08 »

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?
Offline Phased
« Reply #48 - Posted 2016-02-19 08:08:55 »

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?
By 361 I am assuming thats NVIDIA, I believe the only version that has Vulkan support current is 356 (windows) and 355 (linux).

https://developer.nvidia.com/vulkan-driver

Offline theagentd
« Reply #49 - Posted 2016-02-19 13:42:37 »

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 <Struct>.Buffer classes? I assume <Struct>.Buffer.get(0).free() would work, but that's hacky as hell?

Myomyomyo.
Offline Spasi
« Reply #50 - Posted 2016-02-19 17:20:51 »

I can't find a CharSequence overloaded version for pLayerName of vkEnumerateDeviceExtensionProperties()...

Thanks, fixed in build 27.

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

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.

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

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.

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

Thanks, fixed VkDeviceCreateInfo and other structs with the same problem.

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

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.
Offline theagentd
« Reply #51 - Posted 2016-02-19 17:56:55 »

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.

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

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.
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.

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

Thanks, fixed VkDeviceCreateInfo and other structs with the same problem.

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

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.
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.

Myomyomyo.
Offline Spasi
« Reply #52 - Posted 2016-02-19 18:32:33 »

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.

Good idea, it can be done for set().

The struct arrays don't have that much in common with NIO buffers in the first place IMO.

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.

Having malloc() on the struct class but free() somewhere completely different is what caught me off-guard in the first place.

That's actually a very good point. The memAlloc<Type> 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.
Offline theagentd
« Reply #53 - Posted 2016-02-19 20:56:49 »

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:
1  
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)?

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 481



« Reply #54 - Posted 2016-02-19 21:11:16 »

C declaration:
https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0-VK_EXT_debug_report/src/vulkan/vulkan.h#L3677-L3769

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
Offline theagentd
« Reply #55 - Posted 2016-02-19 21:15:58 »

Dear lord in heaven... Thanks.

Myomyomyo.
Offline Spasi
« Reply #56 - Posted 2016-02-19 22:30:14 »

Please don't bother with EXT_debug_report yet, extension support is broken atm (specifically, loading of extension function pointers).
Offline theagentd
« Reply #57 - Posted 2016-02-19 23:41:35 »

Please don't bother with EXT_debug_report yet, extension support is broken atm (specifically, loading of extension function pointers).
Uhhh? Wait, then how can the swapchain and surface extensions work?

Myomyomyo.
Offline Spasi
« Reply #58 - Posted 2016-02-20 09:40:00 »

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

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:

1  
2  
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.
Offline Spasi
« Reply #59 - Posted 2016-02-20 11:54:31 »

got this funny callback function:
1  
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.

It looks like you haven't set up the LWJGL source in your IDE, the signature is:

1  
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).
Pages: 1 [2] 3 4 ... 7
  ignore  |  Print  
 
 

 
Ecumene (110 views)
2017-09-30 02:57:34

theagentd (146 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (241 views)
2017-08-02 12:19:43

cybrmynd (240 views)
2017-08-02 12:18:09

Sralse (254 views)
2017-07-25 17:13:48

Archive (872 views)
2017-04-27 17:45:51

buddyBro (1024 views)
2017-04-05 03:38:00

CopyableCougar4 (1574 views)
2017-03-24 15:39:42

theagentd (1373 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!