Results 1 to 7 of 7

Thread: Vulkan (API) by the Khronos Group

  1. #1
    Join Date
    Sep 2004
    Posts
    1,905
    Rep Power
    21

    Default Vulkan (API) by the Khronos Group

    Vulkan API
    https://en.wikipedia.org/wiki/Vulkan_(API)
    Vulkan is a low-overhead, cross-platform 3D graphics and compute API first announced at GDC 2015 by the Khronos Group. The Vulkan API was initially referred to as the "next generation OpenGL initiative" by Khronos, but use of those names were discontinued once the Vulkan name was announced. Vulkan is derived from and built upon components of AMD's Mantle API, which was donated by AMD to Khronos with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry, much like OpenGL.

    Like OpenGL, Vulkan targets high-performance realtime 3D graphics applications such as videogames and interactive media across all platforms, and offers higher performance and lower CPU usage, much like Direct3D 12 and Mantle. In addition to its lower CPU usage, Vulkan is also able to better distribute work amongst multiple CPU cores.

    Operating system Android, Linux, Tizen, Microsoft Windows

    Khronos Group
    https://en.wikipedia.org/wiki/Khronos_Group
    The Khronos Group is an American non-profit member-funded industry consortium based in Beaverton, Oregon, focused on the creation of open standard, royalty-free application programming interfaces (APIs) for authoring and accelerated playback of dynamic media on a wide variety of platforms and devices. Khronos members may contribute to the development of Khronos API specifications, vote at various stages before public deployment, and accelerate delivery of their platforms and applications through early access to specification drafts and conformance tests.

    On 31 July 2006, it was announced at SIGGRAPH that control of the OpenGL specification would be passed to the group.

    What Is Vulkan & Why Should Gamers CARE?
    https://www.youtube.com/watch?v=dvioALNs_Bc

    Vulkan vs DirectX
    http://www.digitaltrends.com/computi...an-vs-directx/
    Generously, AMD handed over the code to its own API, Mantle, over to the Khronos Group in an effort to accelerate the production of a unified low-overhead API standard (ironically, the consortium is led by Nvidia vice president Neil Trevett, though there are some AMD members on the board).
    If the Khronos Group’s messaging is to be believed, Vulkan is not only easier to port to from OpenGL and OpenGL ES than DirectX 12, but it also provides more significant performance improvements. And that goes without mentioning, once again, that this is in fact a cross-platform API spanning a vast assortment of devices. The apparently inferior DirectX 12, on the other hand, is still limited to Windows 10 and Xbox One.
    It’s so potent, in fact, that its LunarG SDK (wiki) is being sponsored by Valve, and its working group participants consist of companies as reputable as Google, Sony, Nvidia, Nintendo, and Epic Games.

    Benefits of Vulcan (or DX12) for System Upgraders
    https://www.youtube.com/watch?v=ETzA1kDKwbI

    NVidia Officially Supports Vulkan just like it Supports OpenGL
    https://developer.nvidia.com/Vulkan
    We have been using NVIDIA hardware and drivers on both Windows and Android for Vulkan development, and the reductions in CPU overhead have been impressive.
    High-Performance, Low-Overhead Rendering with OpenGL and Vulkan (presented by NVIDIA)
    http://www.gdcvault.com/play/1023516...head-Rendering

    CryEngine Plan for Vulkan
    CryEngine plan for Vulkan
    CryEngine 5.2 is set with DirectX 12 multi-GPU support, the complete DX12 renderer, then full C++11 support for engine code, possibly PhysX support and even more.

    Now, with CryEngine 5.3 due out in mid-October, the developers have planned full support for the Vulkan API. Along with other graphics and rendering updates, audio improvements, sandbox enhancements and still more.

    Unreal Engine 4 Already has Support for Vulcan
    Epic Games adds Vulkan support to Unreal Engine 4
    Epic Games has announced that it has added support for the Vulkan 1.0 low-level API to the popular Unreal Engine 4, making it the first major game engine vendor to do so.

    DirectX 12 is just starting to do what Mantle was already doing, old post
    http://www.littletinyfrogs.com/artic...oversimplified
    In theory, all your cores can talk to the GPU simultaneously. Mantle already does this and the results are spectacular.
    https://en.wikipedia.org/wiki/Mantle_(API)
    Mantle is a low-overhead rendering API targeted at 3D video games. AMD originally developed Mantle in cooperation with DICE, starting in 2013. Mantle was designed as an alternative to Direct3D and OpenGL
    According to AMD, Mantle will make a shift in focus after March 2015 to other areas since DirectX 12 and the Mantle-derived Vulkan API are largely replacing it in the gaming industry.


    Discussion:
    Do you think Vulcan is going to be the API that developers will use more, or prefer, seen as it is open like OpenGL, in preference to DX12 and the predecessor OpenGl? Vulcan is cross-platform!


    My Thoughts
    • Xbox One and PS4 are on GCN which supports and should benefit from Vulcan. Even though there are different game console "Operating Systems", there maybe a way to integrate Vulcan API in some layer close to the hardware on the consoles, or on the Game discs. If something similar is not already been done. Developers may prefer Vulcan API so less work in porting the graphics code.
    • NVidia is likely to release next gen hardware more with the future in mind, whether it be DX12 or Vulcan. Vulcan and DirectX will be competitors, which will benefit gamers. A better programming approach leads to more beautiful and faster graphics. Muhuhaaahaa.
    • Vulcan can run on Windows, no need for DX12? Allows same games on Windows 8???
    • Vulcan (and DX12) is more parallel with regard to the cpu core and gpu.
    • Vulcan (and DX12) has reduced work on the cpu, as opposed to in OpenGL and DX11. Cpu traditionally did more work. Now a lot of that work is moved to Gfx card via future design architecture. Thus the bottle neck from the cpu, tru the drivers, to the graphic card is removed, since the work is instead done right on the graphics card.
    • Vulcan is more advanced than OpenGL, better gains, so Androids developers could switch from OpenGL. Google support Vulcan in Android 7.
      Vulcan has a better programming approach to parallelism, and there is also explicit control over memory management and synchronization than OpenGL which does not mean developers have to write them tediously. There are templates and Engines.




    I skipped tru theses vids
    Vulkan Session @ GDC 2016 Part I
    https://www.youtube.com/watch?v=HM8vYJQtHpA
    Vulkan Session @ GDC 2016 Part II
    https://www.youtube.com/watch?v=EX1RKhlOYmY

    PS. Just because an Engine supports Vulcan does not mean benefits are automatic. Developers still need to have a understanding of the basic programming concepts that it brings, and use it effectively.
    Let's act on what we agree on now, and argue later on what we don't.
    Black men leave Barbeque alone if Barbeque don't trouble you

  2. #2
    Join Date
    Jul 2007
    Posts
    16,974
    Rep Power
    33

    Default

    As someone who has helped in developing a few games. If the Engine supports it your game has it. That is the point of an engine.

    open unity3d or Unreal engine, check box dx, vulkan etc. You have all features the Engine supports for the said api.

    So I am not sure what you mean by "Just because an Engine supports Vulcan does not mean benefits are automatic. Developers still need to have a understanding of the basic programming concepts that it brings, and use it effectively"

    In regards to programming, when using an engine all you worry about is game mechanics not api.

    I would like Vulkan to take over but Dx has a strong hold. So I think Vulkan will still be second place. These engines incorporating Vulkan should make adoption easier though.
    SLAPPA Phenom II AM3 Overclocking Essentials
    I HAVE HIGHEST OC ON TECHJA 4.2ghz
    4890oc beats gtx 285
    PS3 FAILCAKE
    ps3 only advantage is bluray
    4890 oc roundup
    http://miniprofile.xfire.com/bg/sh/type/0/skugpezz.png
    Mi know dem fear mi!!!!! Gigabyte 790x ud4p
    phenom 2 955@3.8ghz 24/7 stable , 4GB ddr3 1333@1.5ghz ,3850 256MB (temp card) (4890 soon),700 watt dual rail psu, (overclocking rules) my avatar represents my personality

  3. #3
    Join Date
    Sep 2004
    Posts
    1,905
    Rep Power
    21

    Default

    (I feel like my original post was a software/programming post)

    Well I said that on the basis that I do not fully understand Vulcan's mechanics on the basic of parallelism.

    For example, will the engine handle all the threading, priority threads, and so on stuff? I do not know. I am guessing not. I could be wrong. I was saying that some basic understanding of the features of Vulcan may be required. In layman's term, how to multi-thread using the paradigm of Vulcan. The engine would layer it so not much code is required.

    I have used an engine already, but I never did multi threading, in the engine.

    In a game, if you "call" a man, then the Engine draws a man. The easy stuff, engine take care of everything. But I am not talking about a game world with just simple polygons. I am talking about programming the parallelism that you want. For example the ability to parallel tasks is there but maybe the developer does not know the basic, and write code without specifying parallel stuff.

    Example: if the world is interactive, lava is present, x volume of the player's mech suit is in lava, and then that part gets damage only. Say you want Shaders or whatever to calculate the volume, and the amount of time before that mech arm or leg, melts off, and you are not programming it on the cpu thread but with the engine, you would have to have a basic understanding.

    https://www.khronos.org/registry/vul...ion-programmer

    To the programmer, Vulkan is a set of commands that allow the specification of shader programs or shaders, kernels, data used by kernels or shaders, and state controlling aspects of Vulkan outside the scope of shaders. Typically, the data represents geometry in two or three dimensions and texture images, while the shaders and kernels control the processing of the data, rasterization of the geometry, and the lighting and shading of fragments generated by rasterization, resulting in the rendering of geometry into the framebuffer.

    A typical Vulkan program begins with platform-specific calls to open a window or otherwise prepare a display device onto which the program will draw. Then, calls are made to open queues to which command buffers are submitted. The command buffers contain lists of commands which will be executed by the underlying hardware. The application can also allocate device memory, associate resources with memory and refer to these resources from within command buffers. Drawing commands cause application-defined shader programs to be invoked, which can then consume the data in the resources and use them to produce graphical images. To display the resulting images, further platform-specific commands are made to transfer the resulting image to a display device or window.
    Command buffers are objects used to record commands which can be subsequently submitted to a device queue for execution. There are two levels of command buffers - primary command buffers, which can execute secondary command buffers, and which are submitted to queues, and secondary command buffers, which can be executed by primary command buffers, and which are not directly submitted to queues.

    Command buffers are represented by VkCommandBuffer handles:

    VK_DEFINE_HANDLE(VkCommandBuffer)


    https://docs.unrealengine.com/latest...fer/index.html

    class FVulkanBuffer : public FRHIResource

    The whole point of performance gain is the level of parallelism you can achieve. I do not think it is anything too hard, just to have a basic concept of ho Vulcan is designed, and then an appreciation for the hardware design will come.

    In time the Engine will grow. And you can just specify a Lava object and all that code will be done already.

    I was thinking, basically, some amount of rework of a game was still needed. Somethings, the engine would have done already so thanks for correcting me.
    Let's act on what we agree on now, and argue later on what we don't.
    Black men leave Barbeque alone if Barbeque don't trouble you

  4. #4
    Join Date
    Feb 2010
    Posts
    1,073
    Rep Power
    0

    Default

    You know I know absoultely nothing about what you guys are talking about, but reading these posts has piqued my interest. Please lets keep the discussion going.
    Live Well, Love Much, Laugh Often -Anonymous.......

  5. #5
    Join Date
    Jul 2007
    Posts
    16,974
    Rep Power
    33

    Default

    Quote Originally Posted by crosswire View Post
    (I feel like my original post was a software/programming post)

    Well I said that on the basis that I do not fully understand Vulcan's mechanics on the basic of parallelism.

    For example, will the engine handle all the threading, priority threads, and so on stuff? I do not know. I am guessing not. I could be wrong. I was saying that some basic understanding of the features of Vulcan may be required. In layman's term, how to multi-thread using the paradigm of Vulcan. The engine would layer it so not much code is required.

    I have used an engine already, but I never did multi threading, in the engine.

    In a game, if you "call" a man, then the Engine draws a man. The easy stuff, engine take care of everything. But I am not talking about a game world with just simple polygons. I am talking about programming the parallelism that you want. For example the ability to parallel tasks is there but maybe the developer does not know the basic, and write code without specifying parallel stuff.

    Example: if the world is interactive, lava is present, x volume of the player's mech suit is in lava, and then that part gets damage only. Say you want Shaders or whatever to calculate the volume, and the amount of time before that mech arm or leg, melts off, and you are not programming it on the cpu thread but with the engine, you would have to have a basic understanding.

    https://www.khronos.org/registry/vul...ion-programmer






    https://docs.unrealengine.com/latest...fer/index.html




    The whole point of performance gain is the level of parallelism you can achieve. I do not think it is anything too hard, just to have a basic concept of ho Vulcan is designed, and then an appreciation for the hardware design will come.

    In time the Engine will grow. And you can just specify a Lava object and all that code will be done already.

    I was thinking, basically, some amount of rework of a game was still needed. Somethings, the engine would have done already so thanks for correcting me.
    I see what you are saying.

    There are two things:

    You use a game engine that has all the features you want.

    Or you use a game engine that has some the features that you want and you edit the engine to add the rest.

    Perfect example titan fall. Titanfall was made using modified source engine. They could have just used unreal engine or something else that has all the features they want, but Source engine is easy on hardware and don't require much GPU power to output nice graphics.

    So yes an Engine can support Vulkan without having some features of it that are optional. The part that boost performance for GPUs is not optional. Vulkan was made to bring graphics and compute together. Developed by AMD as mantle and donated to them.

    Multithreading I am assuming you are talking about cpu threading. Yes an engine might not support that and the programmers have to edit the engine. But then you can go use Frostbite engine, cryeEngine and others that do multithreading. You just write your code and mechanics.

    about this:
    For example the ability to parallel tasks is there but maybe the developer does not know the basic, and write code without specifying parallel stuff.
    If the ability to parallel task is there then you wont have to write code to specify parallel stuff. The Engine will handle all of that. You can download CryEngine for free and try it or even Unity3d. If the ability is not there then they have to write code for it or maybe the parallelism is not good enough in the engine and they want to edit it to make it better.


    Example: if the world is interactive, lava is present, x volume of the player's mech suit is in lava, and then that part gets damage only. Say you want Shaders or whatever to calculate the volume, and the amount of time before that mech arm or leg, melts off, and you are not programming it on the cpu thread but with the engine, you would have to have a basic understanding.
    A game engine will handle all of that without any basic understanding. that is automatic. unless you using a bad engine.

    I was thinking, basically, some amount of rework of a game was still needed. Somethings, the engine would have done already so thanks for correcting me.
    If multithreading in the engine is not as good as you want it be then programmers can get the engine. Or just use a better engine.
    SLAPPA Phenom II AM3 Overclocking Essentials
    I HAVE HIGHEST OC ON TECHJA 4.2ghz
    4890oc beats gtx 285
    PS3 FAILCAKE
    ps3 only advantage is bluray
    4890 oc roundup
    http://miniprofile.xfire.com/bg/sh/type/0/skugpezz.png
    Mi know dem fear mi!!!!! Gigabyte 790x ud4p
    phenom 2 955@3.8ghz 24/7 stable , 4GB ddr3 1333@1.5ghz ,3850 256MB (temp card) (4890 soon),700 watt dual rail psu, (overclocking rules) my avatar represents my personality

  6. #6
    Join Date
    Sep 2004
    Posts
    1,905
    Rep Power
    21

    Default

    AMD Simplified: Vulkan™ API
    https://www.youtube.com/watch?v=qZLzz3OOl3A


    AMD Simplified: Asynchronous Shaders
    https://www.youtube.com/watch?v=v3dUhep0rBs



    WTF is going on with DX12 and Vulkan?

    https://www.youtube.com/watch?v=r0fgEVEgK_k


    I am hyped on Vulcan.

    It is:
    • Cross platform.
      The API can be installed on Android 7.0, Linux, and Windows. It is open, therefore, other OS could do their implementation in time.
    • Low-overhead, and efficient
    • Asynchronous Shaders, and further efficient
    • Distributes load to the CPU cores more evenly than previous APIs
      I have not wrapped my head around this as yet
    • Increased draw calls. More draw calls issued from even slower CPU core
      I have not fully understand this fully either


    However, it is also:

    • Fairly new
      However, tutorials and docs are available.
    • Not Murphy-proof.
      Murphy would make a slow app with Vulcan


    Draw Calls

    http://answers.unity3d.com/questions...raw-calls.html
    Draw calls, broadly speaking, are similar to when a painter has to un-load their brush with one colour of paint, and load it up with another, before continuing to draw.

    In GPU terms though, the different "paint colours" equates to different materials in your scene, and different models which can move independently.

    Therefore, you can reduce these number of draw calls by designing the objects in your scene so that as much as possible can be drawn with each single "call".
    https://www.pcper.com/reviews/Editor...What-Can-It-Do
    Mantle, Vulkan, and DirectX 12 all claim to reduce overhead and provide a staggering increase in “draw calls”. As mentioned in the previous editorial, loading graphics card with tasks will take a drastic change in these new APIs. With DirectX 10 and earlier, applications would assign attributes to (what it is told is) the global state of the graphics card. After everything is configured and bound, one of a few “draw” functions is called, which queues the task in the graphics driver as a “draw call”.
    The paradigm used to load graphics cards is the problem. It doesn't make sense anymore. A developer might not want to draw a primitive with every poke of the GPU. At times, they might want to shove a workload of simple linear algebra through it, while other requests could simply be pushing memory around to set up a later task (or to read the result of a previous one). More importantly, any thread could want to do this to any graphics device.
    Vulcan Tutorials
    https://www.youtube.com/watch?v=wHt5...BIDtCbZnKNGp0P


    @Pezz
    It is done in the game engine.

    Most of everything including paralleling, is done in the engine, at least when engines mature and Vulcan matures. Vulcan is fairly new to Unreal Engine.

    Even so, understanding the basics of how the engine works, will always benefit the developer.

    Engines are not 100% automatic. No matter how much work they offload from the developer.

    Example: If your engine cannot handle many draw calls, then, as a game developer, you could rearrange scene objects and reuse them, to more efficiently use the engine. This is, if you understand the limitations of your engine, then you can try to avoid them.

    Example: If your engine can handle 75% more physics without any loss of frames per second (on GCN card) then you can utilize that behavior in the game. That is, if you understand the features of your engine.
    Let's act on what we agree on now, and argue later on what we don't.
    Black men leave Barbeque alone if Barbeque don't trouble you

  7. #7
    Join Date
    Sep 2004
    Posts
    1,905
    Rep Power
    21

    Default Asynchronous Shaders

    This brings me back to Asynchronous Compute or Asynchronous Shaders

    Asynchronous Shaders

    The AMD Radeon R9 Fury X Review: Aiming For the Top Page 4
    http://www.anandtech.com/show/9390/the-amd-radeon-r9-fury-x-review/4

















    https://en.wikipedia.org/wiki/Graphics_Core_Next

    AMD Graphics Core Next command processing: Each Asynchronous Compute Engines (ACE) can parse incoming commands and dispatch work to the Compute Units (CUs). Each ACE can manage up to 8 independent queues. The ACEs can operate in parallel with the graphics command processor and two DMA engines. The graphics command processor handles graphics queues, the ACEs handle compute queues, and the DMA engines handle copy queues. Each queue can dispatch work items without waiting for other tasks to complete, allowing independent command streams to be interleaved on the GPU’s Shader Engines and execute simultaneously.

    The Asynchronous Compute Engine (ACE) feeds the Compute Units (CU). The basic improvement is that Compute Tasks can run parallel with Render Tasks. Furthermore, different types of Compute Task can run in parallel. As a layman, I would guess, physics tasks can run parallel with lighting tasks, along with object deformation, and so on. Traditionally all the Shaders would do one task, lighting. Then move on to the next task in the pipeline. However, some sections of the pipeline may be less data, and not all Shaders used. I am not so sure if I understand it well myself.





    AMD Dives Deep On Asynchronous Shading
    http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading

    (This link was made before on this site, I think. It does a good job of explaining Asynchronous Shading)

    AMD Improves DirectX 12 Performance By Up To 46% With Asynchronous Compute Engines
    http://wccftech.com/amd-improves-dx12-performance-45-gpu-asynchronous-compute-engines/



    Games may not increase if they cannot be paralleled any further.


    Game engines will mature in time. I would use a engine instead of using the API directly, unless I am doing a small app, and I have a good template code for the API.

    In time I will try the Vulcan API, and Unreal Engine 4.0
    Let's act on what we agree on now, and argue later on what we don't.
    Black men leave Barbeque alone if Barbeque don't trouble you

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •