This lab has 6 implementation steps.
Work through each step in Visual Studio, implementing the code as described. Use the arrow keys or the slide panel to navigate freely between steps.
→ Press the right arrow or click Next to begin.
CONCEPT
A compute shader in OpenGL is still just a program object — the same GLuint handle, the same glUseProgram binding, and the same glUniform* uniform system as any other shader. The only things that differ are how it is compiled (one stage, not two) and how it is executed (dispatched, not drawn).
Because all the shared infrastructure already lives in the base Shader class — Bind(), Unbind(), the uniform location cache, and the destructor — there is no reason to duplicate it. Public inheritance lets ComputeShader reuse all of that with zero changes.
The key design decision is the protected default constructor Shader(). Calling it sets m_RendererID = 0 without triggering the vertex+fragment parsing path in the normal constructor. This gives ComputeShader a clean slate to perform its own single-stage compilation, while still owning the base class fields it needs.
Consider: what would go wrong if you called the public Shader(vertPath, fragPath) constructor instead?
YOUR TASK
ComputeShader.h.Shader.const std::string& filepath.Dispatch method with signature:void Dispatch(unsigned int groupsX, unsigned int groupsY, unsigned int groupsZ) const;ReadFile and Compile with the signatures shown in the starter code.Shader.h.STARTER CODE
#pragma once\n#include \"Shader.h\"\n\n// TODO: Declare ComputeShader inheriting from Shader.\n// Add the constructor, Dispatch method, and two private helpers.\n// Use the protected Shader() default constructor in the initialiser list.\nclass ComputeShader // TODO: inherit from Shader\n{\npublic:\n // TODO: constructor\n // TODO: Dispatch()\nprivate:\n // TODO: ReadFile()\n // TODO: Compile()\n};EXPECTED RESULT
The header compiles with no errors. No functionality exists yet — that comes in later steps.
CONCEPT
Unlike the base Shader class, which must parse a combined .glsl file for two stages using the #shader vertex / #shader fragment sentinel pattern, a compute shader is a single unbroken block of GLSL. There is no stage to split — the entire file is the program.
This means ReadFile can be written as a straightforward whole-file read: open an std::ifstream, stream the buffer into a std::stringstream, return the string. No parsing, no state machine.
It is worth adding a file-existence check using std::filesystem::exists before attempting to open the stream. A silent open failure produces an empty source string which then causes a cryptic shader compilation error rather than a clear message at the point of failure.
Note that std::filesystem requires C++17. Check that your project is targeting C++17 or later in the project properties if the include fails.
YOUR TASK
ComputeShader.cpp.ComputeShader::ReadFile(const std::string& filepath).std::filesystem::exists to print a warning to std::cerr if the file does not exist.std::ifstream, stream it into a std::stringstream, and return the resulting string.<fstream>, <sstream>, <filesystem>, <iostream>.STARTER CODE
#include \"ComputeShader.h\"\n#include <fstream>\n#include <sstream>\n#include <filesystem>\n#include <iostream>\n\nstd::string ComputeShader::ReadFile(const std::string& filepath)\n{\n // TODO: Check the file exists using std::filesystem::exists.\n // If not, print a warning to std::cerr.\n\n // TODO: Open with std::ifstream, stream into std::stringstream, return the string.\n return \"\";\n}EXPECTED RESULT
No visible output yet. If you temporarily pass a non-existent path you should see the warning printed to the console.
CONCEPT
OpenGL shader compilation is a three-step process regardless of shader type: create a shader object (glCreateShader), attach source (glShaderSource), compile (glCompileShader). What changes here is the type token passed to glCreateShader: instead of GL_VERTEX_SHADER or GL_FRAGMENT_SHADER, you pass GL_COMPUTE_SHADER.
GL_COMPUTE_SHADER was introduced in OpenGL 4.3. If your context is created at 3.3 (the common tutorial default), glCreateShader(GL_COMPUTE_SHADER) will return 0 and subsequent calls will fail silently. You must request a 4.3 or later context when initialising GLFW.
After calling glCompileShader, always query GL_COMPILE_STATUS with glGetShaderiv. If compilation failed, retrieve the info log with glGetShaderInfoLog and print it before calling glDeleteShader — otherwise the shader object leaks. Return 0 on failure so the caller can detect the problem.
On MSVC, stack-allocated log buffers can use _malloca rather than a fixed-size array, since the required length is queried first.
YOUR TASK
ComputeShader::Compile(const std::string& source) in ComputeShader.cpp.GL_COMPUTE_SHADER object using glCreateShader.GL_COMPILE_STATUS. On failure, retrieve the info log, print it to std::cerr, delete the shader, and return 0.id on success.STARTER CODE
unsigned int ComputeShader::Compile(const std::string& source)\n{\n // TODO: Create a GL_COMPUTE_SHADER object.\n unsigned int id = 0; // replace with glCreateShader(...)\n\n // TODO: Attach source with glShaderSource and compile with glCompileShader.\n\n // TODO: Query GL_COMPILE_STATUS.\n // On failure: get the info log length, allocate with _malloca,\n // retrieve with glGetShaderInfoLog, print to std::cerr,\n // call glDeleteShader(id), and return 0.\n\n return id;\n}EXPECTED RESULT
If you supply a valid .comp file, Compile returns a non-zero shader id. If you introduce a syntax error in the GLSL, the error message appears in the console.
CONCEPT
A compiled shader object is not yet usable on its own. OpenGL requires you to attach one or more shader objects to a program object and link them before the GPU can execute the code. The program object is what you bind with glUseProgram and what holds the uniform state.
For a traditional vertex+fragment pipeline you attach two shader objects. For a compute shader you attach one. The API calls are otherwise identical: glCreateProgram, glAttachShader, glLinkProgram, glValidateProgram.
After linking, always query GL_LINK_STATUS. Linking can fail even if each individual shader compiled successfully — for example if the compute shader references a built-in incorrectly or if required extensions are unavailable.
Once linking succeeds, the shader object is baked in: the program retains a reference to the compiled binary. The separate shader object is no longer needed and should be deleted with glDeleteShader to avoid leaking GPU memory. This is a step the original base-class CreateShader omitted.
YOUR TASK
ComputeShader constructor in ComputeShader.cpp.Shader().ReadFile, call Compile.glCreateProgram, glAttachShader, glLinkProgram, glValidateProgram.GL_LINK_STATUS and print the info log to std::cerr on failure.glDeleteShader on the shader object after linking.STARTER CODE
ComputeShader::ComputeShader(const std::string& filepath)\n // TODO: call the protected Shader() default constructor here\n{\n m_Filepath = filepath;\n\n // TODO: Read the source file.\n // TODO: Compile the single compute stage.\n\n // TODO: Create a program object.\n // TODO: Attach the compiled shader.\n // TODO: Link and validate the program.\n\n // TODO: Check GL_LINK_STATUS; print info log to std::cerr on failure.\n\n // TODO: Delete the shader object — it is no longer needed after linking.\n}EXPECTED RESULT
Constructing a ComputeShader with a valid .comp file prints nothing to the console and sets m_RendererID to a non-zero program handle.
CONCEPT
glDispatchCompute(groupsX, groupsY, groupsZ) is the compute equivalent of a draw call. Rather than processing triangles, it launches a three-dimensional grid of work groups. Each work group runs a fixed number of threads defined inside the shader with the layout(local_size_x = N, local_size_y = 1, local_size_z = 1) in; qualifier.
Total threads launched = groupsX * groupsY * groupsZ * local_size_x * local_size_y * local_size_z.
For a 1D problem such as updating 100,000 particles with local_size_x = 256, you need ceil(100000 / 256) = 391 groups in X, with Y and Z set to 1. This gives 391 * 256 = 100,096 threads — 96 more than needed. Every thread checks its global index against the particle count and returns early if out of range:
uint idx = gl_GlobalInvocationID.x;\nif (idx >= u_ParticleCount) return;
The dispatch itself is non-blocking: the CPU continues immediately. Results are not guaranteed to be visible to subsequent draw calls until you insert a glMemoryBarrier — covered in Step 6.
YOUR TASK
ComputeShader::Dispatch in ComputeShader.cpp.glDispatchCompute(groupsX, groupsY, groupsZ) wrapped in your project's GlCall() macro.unsigned int groups = (100000 + 255) / 256;shader.Bind(), then shader.Dispatch(groups, 1, 1).STARTER CODE
void ComputeShader::Dispatch(unsigned int groupsX, unsigned int groupsY, unsigned int groupsZ) const\n{\n // TODO: Call glDispatchCompute, wrapped in GlCall().\n}\n\n// --- In your application / test code: ---\n// unsigned int groups = (particleCount + localSize - 1) / localSize;\n// computeShader.Bind();\n// computeShader.Dispatch(groups, 1, 1);\n// TODO: What is missing here before you use the SSBO in a draw call? (Step 6)EXPECTED RESULT
No crash or GL error. The dispatch call appears in an OpenGL debug output layer (if enabled) as a compute dispatch event. Particle data in the SSBO is updated on the next frame.
CONCEPT
The GPU executes pipeline stages out of order and asynchronously. After glDispatchCompute returns on the CPU, the compute shader may still be running on the GPU. More importantly, even after it finishes, the results written to the SSBO are not automatically visible to the vertex shader in the next draw call — the GPU's caches must be flushed and the writes made coherent.
glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT) inserts a synchronisation point: all compute writes to shader storage buffers are completed and made visible before any subsequent shader stage reads from the same buffer.
Without this barrier, the vertex shader may read stale data from the SSBO — particle positions from the previous frame, or partially updated values from the current one. The resulting artefact is typically flickering or particles appearing frozen, which is plausible and easy to misattribute to a logic bug in the update shader.
The barrier goes between the dispatch call and the draw call, never inside either. Placing it too early (before the dispatch) has no effect. Placing it too late (after the draw) is also incorrect.
YOUR TASK
glMemoryBarrier call is missing between the dispatch and the draw.GlCall(glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT));STARTER CODE
// BUG: glMemoryBarrier is missing — find where it belongs and add it.\n\nvoid ParticleSystem::Update(float dt)\n{\n m_ComputeShader->Bind();\n m_ComputeShader->setUniform1f(\"u_DeltaTime\", dt);\n m_ComputeShader->setUniform1i(\"u_ParticleCount\", m_ParticleCount);\n\n unsigned int groups = (m_ParticleCount + 255) / 256;\n m_ComputeShader->Dispatch(groups, 1, 1);\n\n // TODO: Add glMemoryBarrier here with the correct barrier bit.\n\n // TODO (Extension): Bind second compute shader, dispatch, add second barrier.\n\n m_ComputeShader->Unbind();\n}\n\nvoid ParticleSystem::Render()\n{\n // Vertex shader reads SSBO here — must be after barrier.\n glBindVertexArray(m_VAO);\n GlCall(glDrawArrays(GL_POINTS, 0, m_ParticleCount));\n glBindVertexArray(0);\n}EXPECTED RESULT
After the fix, particles update smoothly with no flickering. After the extension, the second dispatch appears in GPU profiler captures (e.g. RenderDoc) as a separate compute event between the two barrier markers.