I am new to CUDA, and it seems that CUDA and Shader are both GPU programs.

When we talk about GPU programming in rendering, like GPU voxelization, are we talking about CUDA or just converting data to Shader?


2 Answers 2


In opposite to Shaders, CUDA is not restricted to a specific step of the rendering pipeline. It can be used to do calculations that are best suited for the GPU architecture, allowing people to take advantage of today GPUs architecture.

To gain better intuition on it, search the web for "GPU computing". For example, in Machine Learning with really massive data sets to process, when vectorized implementations are possible, doing it in the highly parallelized GPU will took a fraction of the time to process all that data than doing it in the CPU (note, depending of what data set we are speaking of, the process may still take a lot of time, and doing it in chunks may still be needed).

You will use CUDA to implement those algorithm to run on the GPU (or part of them). Taking advantage of its highly parallelized architecture.


I'm not expert on the field, but as general rule: vectorized implementations are for the GPU, while a lot of "if" conditionals or loops won't really gain a lot or probably run even slower when compared to the CPU.

A vectorized implementation is when you try to accommodate your data in big vectors/matrices and process them in a single vector/matrix multiplication (or any other supported operation required). When that isn't possible or you don't know how to do it, you will process the data sequentially using loops, one at a time (bad for GPU, little or no gain in speed).

A brief on shaders

With the old fixed pipeline, you can configure the GPU behavior by uploading different matrices or set certain parameters. This is the best that can be done with the old chips design back in the day when the fixed pipeline was the only option.

Modern chips evolved to be programmable. But shader standards are thought only to allow people to customize what happens in the different steps of the rendering pipeline.

The vertex shader: allow you to modify a vertex at a time. Here you will apply the projection matrix (or, as optimization, hardcode the projection calculations required by your game).

The pixel shader: allows you to "program" what happens in the production of a fragment (pixel). Lighting happens here. Yes, you heard it well, your pixel shader program will run again per each pixel (note that the number of fragments processed, the times the shader will run, won't be equal to the number of pixels on your monitor). This may sound inefficient but the GPU, with his highly parallelized design, can handle it. These kind of things is what makes necessary to have a specialized chip for 3D graphics, making software implementations only useful for didactic purposes or for the production of non real time renders.

About voxelization and the GPU: with vertex shaders and pixel shaders there are little to do to optimize voxels. But there are others stages of programmable pipelines that may helps here, like the Geometry Shader or the Tessellation Shader. They require a very modern GPU.

Each stage has a reduced set of possible inputs and produce specific outputs related to they role in the rendering process.

The language to write these shader programs is different to CUDA. OpenGL has GLSL and Direct3D has HLSL.


CUDA is used to do very expensive calculations, in the GPU, and recover the result.

Shaders are used to program what the GPU must do in each of the programmable stages of the rendering pipeline.


Shaders are typically referenced in the context of a graphics API, like OpenGL or Direct3D. They originated as small program that allowed tweaking the lighting calculations for a surfade, aka "shading" objects. Eventually, shader support was added to various parts of the fixed-function rendering pipelines inherent to GL/D3D. Folks eventually figured out how to use these shaders to do things unrelated to graphics, or at least unrelated to the fixed-function rendering pipeline. The GPUs gained support for more and more general-purpose programming and the graphics APIs eventually gained support for "compute shaders" that live outside the rendering pipeline. The last important bit is that the graphics APIs defined shaders in terms of their own unique languages, aka HLSL and GLSL.

CUDA (and the many, many related technologies) is essentially just a way to run compute shaders without the graphics API and without requiring a particular language. CUDA programs are compiled into PTX (NVIDIA's analoque to x86 assembly for the GPU, though a bit more abstract to remain compatible with GPU revisions) and come be compiled from any number of languages, be it C++, Rust, (variants of) Python, or so on. These kinds of programs could be compiled into HLSL or GLSL as well, but this is often a lot harder to develop and debug.

  • \$\begingroup\$ So can I understand like this? CUDA is the underlying architecture.to shaders. We can use CUDA to create our own shader language. \$\endgroup\$
    – HUAQ
    Commented Jan 19, 2017 at 3:53
  • \$\begingroup\$ @Fer no, not even remotely close. CUDA is a shader language that runs without opengl or directx, it can calculate stuff. \$\endgroup\$
    – Bálint
    Commented Jan 19, 2017 at 7:53
  • \$\begingroup\$ It's remotely close, but not accurate. CUDA is a generic infrastructure primarily built around C++ (though also other languages) for running general computation on NVIDIA's GPUs. You can use PTX, the backend for CUDA, to write your own GPU computation languages for NVIDIA's hardware. If you are concerned with graphics shaders integrated with the hardware rendering pipeline then you want to look into Vulkan's SPIR-V or Direct3D 12's upcoming DXIL instead. \$\endgroup\$ Commented Jan 20, 2017 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .