Skip to content

Add a chapter on Compute Shaders#366

Open
spencer-lunarg wants to merge 1 commit intoKhronosGroup:mainfrom
spencer-lunarg:spencer-lunarg-compute
Open

Add a chapter on Compute Shaders#366
spencer-lunarg wants to merge 1 commit intoKhronosGroup:mainfrom
spencer-lunarg:spencer-lunarg-compute

Conversation

@spencer-lunarg
Copy link
Contributor

Rendered view

Kind review @jeffbolznv - mainly around the shared memory races and any other stuff you think would be useful

Copy link
Collaborator

@SaschaWillems SaschaWillems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a chapter explaining basic compute terms is a great addition 👍🏻


Setting the `workgroup` size can be done in 3 ways

1. Using the `WorkgroupSize` built-in (link:https://godbolt.org/z/ees83eT7x[example])

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most developers wouldn't care about this detail and it would be more useful to show how it's declared in GLSL/HLSL/Slang.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, part of this was the "pure" vulkan/spirv point-of-view, but can easily throw a "how to do it in GLSL/HLSL/Slang" example with it

----
shared uint my_var;
void main() {
// All the invocations in the workgroup are going to try to write to the same memory.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's confusing to lead with this example, and would be better to start with examples of cross-thread communication and using barrier() first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you provide some GLSL snippets here (in the comment), I know you are more of an expert in this area and probably better at providing some better examples to provide

Copy link
Contributor

@gpx1000 gpx1000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The chapter is a solid addition and fills a clear gap in the guide!


For those who are more familiar with graphics in Vulkan, compute will be a simple transition. Basically everything is the same except:

- No vertex buffers, render passes, swapchains needed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While technically correct that they aren't required to execute the pipeline, it's worth mentioning that compute shaders often interact with these resources (e.g., writing data into a vertex buffer or post-processing a swapchain image as a storage image). This clarifies that they aren't "isolated" from the rest of the graphics pipeline.

For those who are more familiar with graphics in Vulkan, compute will be a simple transition. Basically everything is the same except:

- No vertex buffers, render passes, swapchains needed
- Call `vkCmdDispatch` instead of `vkCmdDraw`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend mentioning vkCmdDispatchIndirect here as well. Indirect dispatch is a cornerstone of advanced compute usage and GPU-driven pipelines, and it fits perfectly in a list of "Vulkan-isms."

----
shared uint my_var;
void main() {
atomicStore(temp, 0u, gl_ScopeWorkgroup, 0, 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a typo here—temp should be my_var to match the variable declared above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants