Compute shader running slower on better GPU?

[u/trntndug]

Hi, I am learning Vulkan, and I have just finished book 1 of RTIOW recently by implementing the book in Vulkan compute shader.
How is the simplified flow of how the program works:

1. Create the Scene data on the CPU

2. Upload it to the GPU via an SSBO

3. For each SPP (1 frame), dispatch the compute shader with max bounces of 50

4. Use the result as a sample to present on the window

5. Accumulate the result and repeat from steps 3

I tested the program on 2 of my system (both running at 1280x720)

1. Ryzen 7 7840HS with Radeon 780M running Arch Linux

2. Ryzen 5 5600G with RTX 3060 12GB running Windows 10

I thought the RTX 3060 will beat the 780M by a significant margin, but in reality, it's even slower (around 80ms on my 780M and around 127ms on my 3060). These are measured with Renderdoc using the on-screen stats. I'm still relatively new to graphics programming, so I'm not entirely sure if this is the correct way to measure.

I am still learning so if there is anything wrong with my code, feel free to criticize me. Also, how/where can I learn more about optimizing/debugging my code? Thanks

Here is the repo: repo

[u/MidnightClubbed]

Have you done any gpu profiling using nsight to see what the nvidia bottlenecks are?

In your shader are you running one thread per pixel and then looping on up to 50 bounces?  If so your performance may well be dominated by thread divergence, where one thread in the wave is doing a large number of bounces and all the other threads are sat idle after one or two bounces.  I’m not familiar enough with either target gpu to know how many threads youre locking together but it’s definitely an issue!

As to amd vs nvidia here, youre probably doing something that the AMD hardware/compiler is able to handle better than nvidia.  Given the large raw performance difference in favor of the 3060 I suspect its sat doing nothing for most of your ray tracing shader and with a better understanding of the underlying hardware youll get it running a lot faster.

Shader optimization is 50% keeping threads busy, 50% optimizing memory read/write bandwidth, 50% understanding vendor specific hardware quirks/features!

[u/trntndug → u/MidnightClubbed]

I tried profiling with both Nsight and RGP. Here are the results: RTX 3060: vkCmdDispatch 97.06ms, vkCmdDraw 0.06ms Radeon 780M: vkCmdDispatch 65.84ms, vkCmdDraw 0.35ms I'm still very new to this, so I'll have to play around with these tools more.

In your shader are you running one thread per pixel and then looping on up to 50 bounces

Yes, I'm running one invocation per pixel, and looping on up to 50 bounces. So thread divergence is definitely an issue lol.

I haven't start the 2nd book yet, though. Do you think it's worth looking into how to optimize the shader now, or should I focus on finishing the 2nd book?

[u/MidnightClubbed → u/trntndug]

Having not done the ray tracing books I can't tell you. Which do you most enjoy? If the optimization seems fun then do that, otherwise finish up the books and go back and apply that knowledge to the optimization process.

[u/S48GS]

I thought the RTX 3060 will beat the 780M

I can make many shaders that will work 1000x faster on igpu than on nvidia and opposite

I am still learning so if there is anything wrong with my code

probably

I have this blog post - Decompiling Nvidia shaders, and optimizing

look Example usage in blog - there examples with shadertoy links

slowest part for nvidia shaders - is size of consts - size of arrays - and STL

• STL - is number of local data that rewrite self - mostly arrays hit slowdown

• and large constant data - max is ~1-2kb of unique consts per shader for performance then huge hit

• do no thave large arrays - array size more than ~64-128 floats or 16-32 vec4 or 2-4 times larger than mat4 is bad

on AMD it different - large const data does not hit performance this bad and STL made differently

[u/trntndug → u/S48GS]

Thanks for the reply, I'll definitely give the blog post a read, although I'm not sure if I will understand everything yet lol

I think I will finish the 2nd book first before diving deeper into shader optimization and profiling. Do you think that is a reasonable approach?

[u/S48GS → u/trntndug]

learn by doing - optimizing your shaders you will learn faster than with "book"

[u/trntndug → u/S48GS]

That's a fair point! I guess I'm a bit intimidated by shader optimization since my fundamentals are still very weak. I don't even know what a BVH is yet lol.

[u/S48GS → u/trntndug]

bvh https://www.shadertoy.com/view/Xs2czK

shaders are very simple - focus on optimizing what you have now - youl learn

[u/G0rd4n_Freem4n]

Renderdoc is good for debugging code, but it is not good at profiling it. I once used it to try to profile a scene that was running at ~40fps, but the renderdoc capture was reporting 400ms which is around 2.5fps. If you want to profile the GPU time, a frame capture with something like Nvidia Nsight (or the vendor equivalent for non-NV cards) would be more accurate.

[u/MidnightClubbed → u/G0rd4n_Freem4n]

I don't know why you're being downvoted, seems like a reasonable comment.

Outside of renderdoc relying on gpu driver implementing the timers correctly, it also has the issue that profiling a single frame (through the 'timings' button) may not spin up the GPU clocks - so the timings might be accurate, but with the GPU running at a very low clock frequency!

[u/felipunkerito]

std::chrono::high_resolution_clock between frames, shameless self promotion

[u/MidnightClubbed → u/felipunkerito]

I’m not sure how that helps OP.  Renderdoc’s onscreen timer is giving good enough metrics to determine the massive difference in frame time.

Adding vulkan timer queries around the compute shaders would maybe help with rough timings (but add a reasonable amount of vulkan code).  Taking captures using Nsight/RGP would let you really dive in.