Hot answers tagged

46

If you're getting started now, and you want to do GPU work (as opposed to always using a game engine such as Unity), you should definitely start by learning Vulkan. Maybe you should learn GL later too, but there are a couple of reasons to think Vulkan-first. GL and GLES were designed many years ago, when GPUs worked quite differently. (The most obvious ...


37

Hardly! This seems a lot like asking "Should new programmers learn C++ instead of C," or "Should new artists be learning digital painting instead of physical painting." Especially because it's NOT backward compatible, graphics programmers would be foolish to exclude the most common graphics API in the industry, simply because there's a new one. ...


35

Learning graphics programming is about more than just learning APIs. It's about learning how graphics works. Vertex transformations, lighting models, shadow techniques, texture mapping, deferred rendering, and so forth. These have absolutely nothing to do with the API you use to implement them. So the question is this: do you want to learn how to use an API?...


22

Metal and Vulkan are low-level 3D graphics APIs, in much the same way that OpenGL and Direct3D are 3D graphics APIs. Metal is Apple's API, usable on iOS and MacOS. Vulkan was developed by the Khronos Group, who also oversees the various forms of OpenGL. Vulkan is directly usable on all non-Apple platforms, and there is the MoltenVK project which provides a ...


15

D3D12 has 4 separate kinds of command lists: direct, bundle, compute, and copy. Vulkan has similar concepts, but they happen in a different way. Command buffers are allocated from command pools. And command pools are directly associated with a queue family. And command buffers allocated from a pool can only be submitted to the queue family for which the ...


13

The main gain would be that it would be easier to divide CPU tasks into multiple threads, without having to solve all the difficult issues with accessing the graphics API. Normally you either would have to make the context current (which might have bad performance implications) or provide a queue and call the graphics api in a single thread. I don't think ...


12

Because the fundamental foundation of OpenGL makes multi-CPU-core submission impossible. OpenGL, at its core, is a synchronous API. Every OpenGL command behaves "as if" it were executed and completed immediately. Sure, glFlush and glFinish are provided, so that implementations can have some asynchronous execution of commands. But these are essentially fig ...


9

UBOs can be updated at any time with vkCmdUpdateBuffer From the specification: "vkCmdUpdateBuffer is only allowed outside of a render pass." So "at any time" is not the case. Even if it were allowed inside of a render pass, it's still a transfer operation. Which means you need to synchronize the memory transfer with the commands that use it. Which slows ...


9

There's a lot of work needed on the CPU to set up a frame for the GPU, and a good chunk of that work is inside the graphics driver. Prior to DX12 / Vulkan, that graphics driver work was essentially forced to be single-threaded by the design of the API. The hope is that DX12 / Vulkan lift that restriction, allowing driver work to be performed in parallel on ...


8

Instead of listing specific use cases, I will explain the technical limitations of a render pass structure which would prevent someone from putting all of their rendering within it. The use cases naturally fall out from those limitations. The most important being this: you cannot arbitrarily access any of the images attached to the render pass throughout the ...


7

It's very different between the Khronos standards (including Vulkan) and DirectX. In DirectX, Microsoft implements the API, but they publish to GPU vendors a HAL API. There's actually two HALs: one that runs in kernel-mode, to communicate with the card directly; and one that runs in user-space, to do other tasks (like manage memory, set up data structures, ...


7

The primary appeal of OpenGL (at least to me) is that it works on many platforms. Currently, Vulkan does not work on OSX, and Apple has a competing API called Metal. It's very possible that it will be some time before Apple supports Vulkan, and when they do, Vulkan support may only come to their latest hardware. OpenGL already supports most hardware, and ...


6

In GL's model of the GPU, the colour blending step is performed by special-purpose hardware. This idea dates back to the fixed-function origins of GL, before programmable shaders were even a thing. But not all GPUs today implement all colour blend options with special-purpose hardware. The hardware vendor can reduce gate count and power use by getting rid ...


6

So, I'll start by saying I'm not a driver developer, but I have read many comments and docs in this regard. First of all, we can see how Khronos's own slides on presentation day were mentioning some rather vague "any OpenGL ES 3.1 GPU" (or desktop 4.X). This means something added around that mark would be the secret to it. Compute shaders are ...


6

How does the driver know what to update/transfer and when? It doesn't. There is no transfer or update in that fashion. All memory allocated through a Vulkan device represents memory that some device operations can read directly. If a Vulkan device advertises that it can use visible/coherent memory as source vertex data for rendering operations, that does ...


6

Typically compiling GLSL to SPIRV would be something you do as part of the build process, so that you end up distributing SPIRV instead of GLSL. Then you don't need to compile it at runtime. Assuming you're using the Vulkan SDK, the binary for glslangValidator (or a shell script to build it) should be part of the installed SDK. That said, if you want to ...


6

There's no such thing as a Vulkan context, the way there is with OpenGL. This is because Vulkan is a lower level API and an OpenGL context ties together a number of concepts that are distinct in the Vulkan API. For example, the OpenGL context ties together the concept of extension management, memory management, draw commands and surface presentation. In ...


6

The block should total up to 8320 bytes. No, it shouldn't. You use a uint[16] array. Well, std140 layout makes it clear that the array stride for any array is always rounded up to the stride of a vec4. So that array takes up 256 bytes. You should instead use a uvec4[4] instead, which you would index from like a multidimensional array.


6

What you're ultimately trying to do is, between draw calls, change some state that allows one to select which set of read-only data to use in the rendering process. There are many techniques for this. Push constants can be used to provide an index into an array of arbitrary size stored in an SSBO. Indeed, a single push constant can be used to provide ...


5

You are looking for vkCmdClearColorImage, It does exactly what it says on the tin, it clears an image to a specified color. This command uses the Transfer stage as far as barriers are concerned. You will need to add one between the clear and the vkCmdDispatch. There is also a vkCmdClearDepthStencilImage if you need it.


5

Modern GPUs generally have a single frontend section that processes an entirely linear stream of commands from the CPU. Whether this is a natural hardware design or if it simply evolved out of the days when there was a single CPU core generating commands for the GPU is debatable, but it's the reality for now. So if you generate a single linear stream of ...


5

You might want to try the VK_LAYER_LUNARG_monitor layer from the LunarG Vulkan SDK. Download the SDK from the LunarXchange site. After SDK installation, you can activate the layer by setting this environment variable: VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_monitor The monitor layer displays the FPS value in the application window's title bar.


5

TL;DR: There's some room for optimization in Vulkan drivers, but not nearly to the degree that there is in GL / DX11 drivers. how much do drivers affect performance? It depends a great deal on how the application is written and the hardware. Specifically it depends on whether you're using features where there are large opportunities for optimization on ...


5

With OpenGL I would have to reload whole vertex VBO's. No you wouldn't. You can use glBufferSubData I suppose with Vulkan there could be a way to directly access VBO's to only change/add/remove the changed vertex data If you know the memory layout of the vertex buffer, you can find the offset of the contents you want to change, populate a transfer ...


4

Yes, there are advantages. You can render different command buffers to different queues. Modern NVIDIA hardware, in particular, offers a full sixteen separate queues that are capable of rendering independent graphics operations. By putting each eye in a separate queue, you may be able to use the available hardware resources more efficiently. Then again, it ...


4

Vulkan and OpenGL use different models for their resource bindings. Vulkan uses descriptor sets + binding, while OpenGL uses binding indices. As such, the SPIR-V they consume use different decorations for their resources. There are also a number of differences in terms of built-ins that the two APIs provide. For example, Vulkan accepts the InstanceIndex ...


4

It's possible to emulate Vulkan on a sufficiently capable non-Vulkan API. This is the point of the Vulkan Portability Initiative. Indeed, there is already a Vulkan implementation on top of the Apple proprietary API Metal, and there is work being done to implement Vulkan on top of D3D12. It probably would be possible to implement a version of Vulkan that ...


4

This is a similar question to following: When do you need to cook? You can go to a restaurant. Why would you need to know woodworking? You can buy things from a shop. There are two answers here In order for you to claim ownership on some tech. You need to build it. This can be simply because you have chosen to sell a competing product or need to lower your ...


3

Vulkan is not really suited to at least some of the task you're trying to accomplish. It has no mechanism to declare from within a shader that some additional work should be invoked. Or at least, not directly. The most effective way to execute this on the GPU would be to compute each level of all of the trees as a distinct dispatch operation. So you process ...


3

I'm a newbie in terms of CG world. I'm curious to know about the applications that use Vulkan API and their performances compared to other APIs There are some popular magazine websites, such as PCGamer and AnandTech that has some comparison charts between other rendering APIs. PCGamer compares OpenGL vs Vulkan for Doom (2016) AnandTech compares Vulkan vs ...


Only top voted, non community-wiki answers of a minimum length are eligible