[HN Gopher] Graphics Pipelines for Young Bloods
___________________________________________________________________
Graphics Pipelines for Young Bloods
Author : ingve
Score : 123 points
Date : 2021-05-21 10:59 UTC (1 days ago)
(HTM) web link (www.jeremyong.com)
(TXT) w3m dump (www.jeremyong.com)
| [deleted]
| arduinomancer wrote:
| I hope to one day move from web dev to graphics programming but
| it seems hard to break in to.
|
| I feel like backend dev has turned my brain to mush and I miss
| the math we used to do in university.
|
| Seems there a very few jobs in software dev where you actually
| get to use math/complex algorithms, graphics being one of them.
| Jasper_ wrote:
| This is somewhat of an incomplete analsysis, because you can use
| light tiling with either forward and deferred. And that's pretty
| common nowadays. The real advantage to deferred is to save on
| quad overshading and balance the use of the GPUs. By making
| lighting homogeneous across the scene you'll have a lot better
| utilization of the GPU's resources, since there's no wasted pixel
| effort during the expensive lighting loop.
|
| Downside is of course transparency and the need to dump your full
| material model into a G buffer...
| ninepoints wrote:
| Hey author here :) I actually deliberately kept the tiled
| lighting section hopefully devoid of any consideration for
| deferred vs forward since as you say we can (and do) do tiled
| light culling with both algorithms. Quad overshading and the
| use of "helper lanes" is worth mentioning in the article maybe
| as a footnote. It certainly is another way in which the GPU's
| silicon can be underutilized, but I'd hesitate to say it is the
| "main reason" for deferred so much as "one of the reasons". I
| definitely struggled to walk the balance between summarizing
| the concerns at a coarse level, vs providing all the gory
| details. So to your point, definitely wasn't comprehensive,
| there's RTR4 for that :). "... for young bloods" is in the
| title after all
| codefreakxff wrote:
| Sweet. I made an engine to learn OpenGL 2.0 and vertex
| shaders way back when, but moved on to other things in life.
| A couple of weeks ago I was curious what's changed with the
| latest pipeline techniques. This feels like it will be a
| great way for me to catch up. Thanks for writing this!
| ninepoints wrote:
| Awesome! Note that there are better writeups for learning
| the specific implementation details for any given
| technique, and this article was mainly written to give
| people a rough "mental model" when assessing a whitepaper
| or siggraph talk or something. If I have time I'll go back
| and add a section with references to the core techniques I
| see in use today.
| corysama wrote:
| > 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 wrote:
| Great 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.
| salawat wrote:
| Every time I look at anything about graphics programming, my head
| implodes.
|
| I just don't get it. I don't get how the matrix operations
| somehow magically work out. I don't get how it is that light
| bouncing/reflectivity works itself out in any reapectable amount
| of time. It all just sounds like a bunch of jargon, jumbled
| together, and pretty arrangement of pixels comes out.
|
| Like I get the camera being set in a scene. I get it forms a
| frustrum with everything in the field of view. I get that you
| have a bunch of geometry in it's own independent coordinate
| systems, that are then glued together by transformation
| matricies.
|
| I get U, V, W unwrap basically taking a 2D texture and mapping it
| to a 3D model. I get annotating fragments with material
| properties to aid on subsequent processing passes treating using
| linear trajectories and other Voodoo to figure out where
| reflections, shadows, and brightening should occur, and that part
| of what makes all of that doable is massively parallel co-
| processing devices divide and conquering the processing, which
| are orchestrated from the host system's memory space through
| driver API's.
|
| But that's where my internal stack blows out.
___________________________________________________________________
(page generated 2021-05-22 23:02 UTC)