Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Vulkan delayed to "early 2016" Q___Q  (Read 4298 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2015-12-19 15:08:46 »

Vulkan Working Group Update - December 18th 2015

We have some good news and some bad news.  The year-end target release date for Vulkan will not be met.  However, we are in the home stretch and the release of Vulkan 1.0 is imminent!

Here is a more detailed update...

The Vulkan specification is complete and undergoing legal review and final polishing. The Vulkan conformance tests are being finalized and multiple member companies are preparing drivers for release. Implementation feedback is the vital final stage of making any Khronos specification ready for primetime, and the Vulkan 1.0 specification will be published when the first conformant implementations are confirmed.

Work is also progressing to complete Vulkan SDKs for Windows, Android and Linux. Google has upgraded to Promoter membership and is now on the Khronos Board to help steer Vulkan strategy for Android and the wider industry.

There is considerable energy driving the work to bring you Vulkan. We are planning Vulkan sessions and demos at key industry events throughout the year. We are excited about the emerging Vulkan ecosystem that will create new business opportunities for the graphics and compute industry.

Vulkan will set the foundation for graphics and compute APIs for years to come and so Khronos is taking the time needed to do this right – and the Vulkan 1.0 release is near!

The Khronos Vulkan Working Group

On behalf of my exams I would like to thank you, Khronos, and on behalf of myself I would like to say that you ruined my Christmas. Q_Q

Offline KaiHH

JGO Kernel

Medals: 786

« Reply #1 - Posted 2015-12-19 15:18:38 »

In my opinion, I would be fine if it took yet another year for Khronos to make the conformance tests so damn tight and 100% coverage that you will be 100% sure that EVERY Vulkan-certified driver WILL work EXACTLY like every other such driver. Smiley
No more driver quirks, different unspecified or other annoying driver behaviour anymore, like with OpenGL today. Yes, I'm looking at you, Intel, for having crappy drivers and I am looking at you, Nvidia, for having far too lenient drivers and GLSL compiler.

Then we can finally have a cross-platform Direct3D.
Offline theagentd
« Reply #2 - Posted 2015-12-20 02:07:01 »

I have to admit I misunderstood AMD's intentions when they first announced Mantle. I was worried that they would aim for lock-in by "encouraging" vendors to only develop games using Mantle. As it turned out, AMD was actually the good guy here, and I've gained a lot of respect for them since Mantle was announced. They've done a HUGE favor to all gamers and developers by pretty much throwing Mantle on Khronos' table and saying "go nuts with it". They knew that the PC APIs were stuck and the only way to show the world what we've been missing was to do something drastic. Frankly, we have AMD to thank for a lot, including the biggest revolution in OpenGL's development since, well, since it frigging came out in the 1990s, AND for finally bringing out the potential of PC gaming compared to consoles as well. The implications here are massive. With DX12 and Vulkan destroying the current-gen consoles when it comes to performance just 2-3 years after their release, we may hopefully be seeing the last generation of consoles and a migration to Steamboxes or PC-"consoles", especially when you consider the bad hardware choices made for this generation (weak CPUs that will heavily limit the scale of future games). When you add AMD's recent open-sourcing of some of their tools and APIs, they're starting to look pretty damn good.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2015-12-20 03:04:47 »

Continuing my console rant...

The CPU cores used in both the PS4 and the XB1 are both based on AMD's Jaguar architecture. The CPU performance per core should be very similar if not identical to the performance of Athlon 5150 desktop CPU. These CPUs almost have identical clock speeds as well (Athlon: 1.6GHz, PS4: 1.6GHz, XB1: 1.75GHz). Looking up benchmarks comparing the quadcore Athlon 5150 with a modern Intel i5 or i7 shows that it's around 1/4th to 1/5th as fast. However, the consoles both have 8 cores, not 4, but of these only 7 are actually usable by developers (with the 7th core being unlocked for developers very recently for both consoles). For the sake of argument, let's be generous and say that the console CPUs are around half as fast as a modern i7. This means that the consoles were far behind high-end CPU parts when they were launched, around mid-end.

Up until now, consoles have had a huge advantage that helped them compete with PC. With just a single piece of hardware to support, you can go nuts with low-level optimizations and tailor-make entire APIs to fit the hardware, which the console makers have been doing vigorously since they were first made. My favourite example of this is how the last games developed for the PS3 actually offloaded many graphics effects like lighting to the CPU and did very fine culling of triangles on the CPU just to take a few percentages of load off the GPU. That would be impossible to do on PC without inducing massive stalls and lag with the current APIs. The ability to multithread command buffer generation and the much thinner bare-bones drivers with no API overhead gives the developers much more control and power to optimize their games. This advantage that has been exclusive to consoles since I was born is disappearing with the Vulkan and DX12, as can be seen in this Vulkan demo. In synthetic tests we're talking performance increases up to 10x, while more realistic examples (especially of DX12) are talking about 2x improvements in CPU-limited games. This doesn't account for the difference in RAM (for example, the PS4 uses GDDR5 for the CPU too, which can have serious performance drawbacks).

The reason why we won't see a 10x improvement in actual games is that these games already utilize multiple cores for their logic, physics, etc. The increased performance comes from being able to utilize multiple cores for the traditionally single-threaded draw calls. If your game logic is taking 10 ms and your draw calls used to take 10ms, a 10x increase in API performance would mean an almost doubling of your FPS. This doesn't mean that you'll be able to draw 10x as many trees in your games, no, the GPU's ability to draw triangles won't get improve. If you could draw 1000 identical trees with OpenGL without being CPU bottlenecked, you can draw 1000 trees with Vulkan too. The difference is that with Vulkan each of those 1000 trees can be unique, as we can afford to do one draw call for each tree. Vulkan brings the power to add more variety and scale to our games, simply by alleviating a bottleneck that noone's bothered to solve for years. The hardware world is very different from when OpenGL was designed, and this modernization won't just improve the performance of the API a lot, it will also allow us to fully take advantage of all the CPU cores people's computers have and scale our games to use any number of cores.

We're even gonna get a few GPU optimization opportunities, the most interesting one being asynchronous computing. GPUs have a lot of fixed functionality hardware in them, and sometimes the thousands of shader units you have at your disposal are left idle while this hardware does its job. A great example is shadow map rendering. Since shadow maps are just depth images, we don't actually need a pixel shader stage at all for them. The hardware rasterizer is what generates the fragments and their depth values, so the shaders are pretty much idle (apart from running vertex shaders). With Vulkan, you can actually fire off compute kernels in parallel with rendering commands (it's a different command queue), meaning that you could render a shadow map while computing tile-based deferred lighting, possibly even double-buffering your shadow maps to keep both the rasterizer and the shader cores busy.

1. Draw shadow map 1.
2. Use shadow map 1 for compute shader lighting while drawing shadow map 2.
3. Use shadow map 2 for compute shader lighting while drawing shadow map 1.
4. Repeat 2-3.

You can even start doing post-processing early asynchronously while doing the lighting. It's perfectly plausible to compute SSAO (requires only a depth and normal buffer, so can be done right after the G-buffer pass is done) while doing lighting. With all these opportunities, you may actually be able to cram out a few extra trees. =P Texture streaming will also be much easier to do with explicit control over DMA memory transfers to GPU memory memory. We won't have to depend on driver hacks that allow DMA texture streaming to be done from a separate thread. Multi-GPU support can also be properly coded for in the first place, as you can actually query all GPUs connected to the computer, control them individually and manually handle synchronization of resources.

When you add the massively reduced driver complexity, having simple-to-compile SPIR-V as an intermediate shader format and the much more rigorous conformance tests that Khronos are developing, it's clear that Vulkan will solve so many issues in the current OpenGL ecosystem. It really looks like we'll be able to test our code on a single computer, and if it runs there's a very very high chance that it will run on all of them.

Offline deepthought
« Reply #4 - Posted 2016-01-08 22:21:13 »

and of course less confusion over what the fast path is

Mad Scientist
Pages: [1]
  ignore  |  Print  

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

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

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

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

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

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

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

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

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

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

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 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‑
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!