Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (799)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (865)
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 ... 7
  ignore  |  Print  
  Vulkan 1.0 Release  (Read 129863 times)
0 Members and 2 Guests are viewing this topic.
Offline NegativeZero

JGO Kernel


Medals: 346
Exp: 1 month or less


Zero but not.


« Posted 2016-01-16 23:47:44 »

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

Offline theagentd
« Reply #1 - Posted 2016-01-17 01:17:10 »

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

@theagentd

Myomyomyo.
Offline elect

JGO Knight


Medals: 72



« Reply #2 - Posted 2016-02-16 12:14:44 »

So, today seems to be the big day..  Clueless

https://twitter.com/1ace/status/699513909531799552
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2016-02-16 12:45:31 »

HYPE

Myomyomyo.
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #4 - Posted 2016-02-16 19:05:15 »

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

https://www.khronos.org/vulkan/

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.

Offline KaiHH

JGO Kernel


Medals: 764



« Reply #5 - Posted 2016-02-16 19:16:41 »

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
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #6 - Posted 2016-02-16 21:18:42 »

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

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.

Offline KaiHH

JGO Kernel


Medals: 764



« Reply #7 - Posted 2016-02-16 21:41:21 »

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. Smiley
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.  Pointing No, sorry, that was overstressed.  Grin
Offline NegativeZero

JGO Kernel


Medals: 346
Exp: 1 month or less


Zero but not.


« Reply #8 - Posted 2016-02-16 21:44:35 »

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?

Offline thedanisaur

JGO Knight


Medals: 59



« Reply #9 - Posted 2016-02-16 21:47:19 »

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!

Every village needs an idiot Cool
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 764



« Reply #10 - Posted 2016-02-16 21:50:16 »

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. Smiley
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 Smiley https://github.com/LWJGL/lwjgl3/issues/144#issuecomment-184723602

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.
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?
Offline NegativeZero

JGO Kernel


Medals: 346
Exp: 1 month or less


Zero but not.


« Reply #11 - Posted 2016-02-16 21:55:52 »



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 Tongue


Offline theagentd
« Reply #12 - Posted 2016-02-16 22:49:41 »

Ohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohbo yohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohb oyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyohboyoh boyohboyohboyohboyohboyohboyohboyohboyohboy...

Myomyomyo.
Offline NegativeZero

JGO Kernel


Medals: 346
Exp: 1 month or less


Zero but not.


« Reply #13 - Posted 2016-02-17 02:14:22 »

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.

Offline Spasi
« Reply #14 - Posted 2016-02-17 11:38:38 »

But that would make that structs-building also a vital and core part of the API and not only the functions, wouldn't it?

Made decent progress last night, up to creating a Vulkan instance. Struct-building preview:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
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);
Offline KaiHH

JGO Kernel


Medals: 764



« Reply #15 - Posted 2016-02-17 11:45:54 »

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. Smiley
Offline theagentd
« Reply #16 - Posted 2016-02-17 13:35:52 »

But that would make that structs-building also a vital and core part of the API and not only the functions, wouldn't it?

Made decent progress last night, up to creating a Vulkan instance. Struct-building preview:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
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);


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.

Myomyomyo.
Offline Spasi
« Reply #17 - Posted 2016-02-17 14:56:13 »

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.

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.

Even just having a single constructor that sets everything (preferably without breaking escape analysis) would help a lot.

This exists already for all mutable structs. The above code could be written like so:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
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.
Offline KaiHH

JGO Kernel


Medals: 764



« Reply #18 - Posted 2016-02-17 14:57:58 »

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.

@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.
Offline Icecore
« Reply #19 - Posted 2016-02-17 15:49:04 »

1  
2  
3  
4  
VkApplicationInfo app = VkApplicationInfo.malloc()
   .sType(VK_STRUCTURE_TYPE_APPLICATION_INFO)
   .pNext(NULL)
...

You can Use something like this Smiley
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
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(){
      ....
   }
}

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline theagentd
« Reply #20 - Posted 2016-02-17 16:17:01 »

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?
1  
2  
3  
ByteBuffer b = malloc(...);
VkApplicationInfo appInfo1 = VkApplicationInfo.wrap(b, 0);
VkApplicationInfo appInfo2 = VkApplicationInfo.wrap(b, ...);

Myomyomyo.
Offline Spasi
« Reply #21 - Posted 2016-02-17 16:51:38 »

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?

LWJGL currently supports the following:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
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.
Offline Spasi
« Reply #22 - Posted 2016-02-17 23:37:02 »

The latest nightly build (3.0.0 #24) includes Vulkan bindings. Notes:

- There's virtually no documentation, only way I could get it out so soon.
- There's no real bootstrapping or a "capabilities" class. I'll work on it when I have time for a proper reading of the spec. Currently all functions are blindly loaded from the ICD, let me know if there are any issues with that.
- I'm currently porting this test from the GLFW repo. Demo contributions are welcome (single-file only please).
Offline theagentd
« Reply #23 - Posted 2016-02-18 14:11:03 »

1  
2  
      glfwInit();
      System.out.println(glfwVulkanSupported());

Quote
0

 Stare

EDIT:
https://developer.nvidia.com/Vulkan

Quote
1

 Smiley

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 764



« Reply #24 - Posted 2016-02-18 14:30:12 »

JOML supports Vulkan  Pointing ... lol Roll Eyes
Offline theagentd
« Reply #25 - Posted 2016-02-18 14:56:38 »

API version is tricky:

1  
2  
3  
4  
      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
:')

Myomyomyo.
Offline theagentd
« Reply #26 - Posted 2016-02-18 16:06:16 »

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
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.

Myomyomyo.
Offline SHC
« Reply #27 - Posted 2016-02-18 17:21:07 »

EDIT: glfwGetPhysicalDevicePresentationSupport() is missing in GLFW.

It's in the GLFWVulkan class.

Offline theagentd
« Reply #28 - Posted 2016-02-18 17:26:37 »

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

Myomyomyo.
Offline SHC
« Reply #29 - Posted 2016-02-18 17:46:32 »

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?

Pages: [1] 2 3 ... 7
  ignore  |  Print  
 
 

 
Riven (189 views)
2019-09-04 15:33:17

hadezbladez (4875 views)
2018-11-16 13:46:03

hadezbladez (1790 views)
2018-11-16 13:41:33

hadezbladez (5147 views)
2018-11-16 13:35:35

hadezbladez (1018 views)
2018-11-16 13:32:03

EgonOlsen (4377 views)
2018-06-10 19:43:48

EgonOlsen (5220 views)
2018-06-10 19:43:44

EgonOlsen (2949 views)
2018-06-10 19:43:20

DesertCoockie (3868 views)
2018-05-13 18:23:11

nelsongames (4294 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
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!