3 ms·
> so we’re on the hook for handling things like computing finite-difference gradients for texture sampling, interpolating attributes, and computing barycentric
by corysama 5y ago
> so we’re on the hook for handling things like computing finite-difference gradients for texture sampling, interpolating attributes, and computing barycentric coordinates (either via intrinsic/SV_Barycentrics or manually).
> While we lose a bunch of work that hardware may have done for us, cutting the pipeline here
From what I’ve read, modern GPUs have moved most of this work from fixed function hardware to implicitly inserted shader assembly. So, we’re on the hook for manually writing that code. But, it’s not missing out on as much hardware magic as one might think.
If I understand correctly, there has been so much focus of cramming general compute into GPUs that the fixed function hardware for pixel work has been stripped down to visibility rasterization, barycentric generation (accessible through the SV_barycectric instruction), and texture sampling (given coordinates and derivatives).
- ninepoints 5y agoGreat points but I want to say that this is partially true. Yes you’ll see code in the shader assembly needed to sample a texture for example, but it will use instructions for vertex interpolation you just don’t have access to directly if you cut the pipeline for a visibility buffer technique. Also for barycentrics, we can query that from the hardware rasterizer, but the tradeoff there is storage. Also, if you do this in compute, unless you have access to the recently added compute derivatives, you’re still responsible for managing the bookkeeping needed to compute the finite differences. The general trend has been towards having general compute yes, but check the ISA and read your shader disassemblies before drawing any conclusions.
- corysama 5y agoAll great points as well. Thanks for putting all this together.
- ninepoints 5y agoMy pleasure! Thanks for reading and your comments