Hot answers tagged

39

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


32

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


23

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


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

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


11

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


10

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


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

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


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

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


5

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


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

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

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.


4

It depends on what you want to do. If you want to learn graphics programming only for yourself, it really doesn't matter what you choose. If you are thinking about professional work I recommend Vulkan. It is closer to hardware and I think knowledge about what hardware do is important for graphics programmers. Vulkan is closer to hardware because OpenGL ...


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

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.


4

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


3

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


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

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


3

You're sort of asking two different questions here but that's okay. Changing Sampler states is pretty straightforward. When you create a descriptor set, you write your VkSampler object that you've created into a descriptor set. If you want to update a sampler in a descriptor set, create a VkSampler with the sampler settings you want and then call ...


3

Basic Vulkan availability can be checked by the presence of the loader dynamic library. This will reside in a standard place where you can load it with dlopen or LoadLibrary. If it fails to load then vulkan is not installed. If it does load then you can get the vkGetInstanceProcAddr function pointer from it with dlsymor GetProcAddress. After that you can ...


3

There's no such thing as a Vulkan context, the way there is with OpenGL. There are a number of things that kind of correspond to an OpenGL context. There's a VkInstance. This encapsulates access to the Vulkan libraries on the system, including the extensions. There's a physical device VkPhysicalDevice and a Device. The former encapsulates all the ...


3

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.


3

It is your responsibility to support includes by instantiating an IncluderInterface instance and calling SetIncluder(...) on the options instance. The interface includer API consists of the following methods: // Handles shaderc_include_resolver_fn callbacks. virtual shaderc_include_result* GetInclude(const char* requested_source, ...


2

I've been "getting in to" graphics programming for a few months now. Right now I'm still in High School, and I can tell you I am almost always looking to develop cross platform applications. This is in fact my number one problem with Vulkan - It isn't developed to work on all platforms. I work with OpenGL in Java and have for over 6 months. Another problem ...


2

I would like to give you my graphics beginner perspective on the subject. What I realised (in many years working as an engineer in another field) is that the fundamental concepts are the most important part. Once you have a solid understanding of those, learning the last shiny new API is the least difficult part. I don't know if you are a young hobbiest ...


2

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


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