In graphics programming we use a lot of awesome sounding names for techniques, which often trigger fantastic mental imagery (as well as actual imagery). Too many to list them all, the top 3 of my favourite ones, in no particular order, probably are: (1/4)
1) "Ambient occlusion": the percentage of rays cast from a point over the hemisphere centred around the surface normal that are not occluded (do not collide with) by geometry. A value of 0 means all rays collide, 1 means none does. (2/4)
2) "Shadow pancaking": project shadowcasting meshes that lie in front of the near plane of a light (and would normally get culled), on the near plane so that they will still cast shadows. Used to enable tightening of the shadow projection volume to increase the resolution. (3/4)
3) "Waterfall loop": in cases where data vary per wavefront thread and can't fully scalarise execution, partially scalarise it by grouping threads by data and looping over the groups executing the instruction on parts of the wavefront in a scalar fashion. (4/4)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Managed to clear the DM backlog, the large majority involved how to start learning gfx programming and how to find a job in the industry. There's a lot of anxiety, given the complex nature of graphics and the amount of learning resources available nowadays is overwhelming. (1/4)
However complex it may seem, the core of graphics programming hasn't changed, it's still about lighting and shading. Understanding and implementing a lighting model and materials to begin with will take you quite far and can gradually extend it as your knowledge increases. (2/4)
Also trying not to juggle too many balls may help, focus on the graphics techniques first and look into a graphics API later. There are many options that will hide the complexity of the graphics API and make implementing a technique easier, like bkaradzic.github.io/bgfx/overview.…. (3/4)
During my years in graphics there have been many great conference presentations but also a few that I found "eye opening" and changed the way I think about and approach gfx programming. My top 3, in no particular order, probably are (1/4):
People starting to learn graphics techniques and a graphics API to implement them may find the whole process intimidating. In such a case there is the option to use a rendering framework that hides the API complexity, and handles asset and resource management. (1/4)
There are quite a few frameworks out there, for example:
Some are closer to the API, some hide it completely. They still offer the opportunity to learn about asset loading, shaders, render states, render targets etc at a more granular level than a full blown engine while allowing the user to focus on the gfx tech implementation (3/4).
Great question from DMs: "How bad are small triangles really"? Let me count the ways:
1) When a triangle goes pixel size it may miss the pixel centre and not get rasterised at all, wasting all the work done during vertex shading docs.microsoft.com/en-us/windows/… (1/6)
3) GPUs perform a coarse rasterisation pass to decide which (eg 8x8 pixel) tiles are touched by a triangle. Small tris that cover few pixels are wasting much of the tile. Thin and long triangles can have the same effect. g-truc.net/post-0662.html, fgiesen.wordpress.com/2011/07/06/a-t… (3/6)
Good DM question: "is it better to dispatch 1 threadgroup with 100 threads or 100 groups with 1 thread in each?" The GPU will assign a threadgroup to a Compute Unit (or SM), and will batch its threads into wavefronts (64 threads, on AMD GCN) or warps (32 threads on NVidia). (1/4)
Those wavefronts/warps are executed on the CU's SIMDs, 64/32 threads at a time (per clock), in lockstep. If you have only one thread in the threadgroup you will waste most of the wavefront/warp as they can't contain threads from different threadgroups. (2/4)
The general advice is that the threadgroup should fill at least a few wavefronts/warps, for eg 128/256 threads on GCN. The number also depends on the registers used per thread, to achieve good occupancy, and the need to share data between the threads of the group or not. (3/4)
A mini Importance Sampling adventure: imagine a signal that we need to integrate (sum it's samples) over its domain. It could for example be an environment map convolution for diffuse lighting (1/6).
Capturing and processing many samples is expensive so we often randomly select a few and sum these only. If we uniformly (with same probability) select which samples to use though we risk missing important features in the signal, eg areas with large radiance (2/6).
If the signal are non negative (like an image), we can normalise its values (divide by the sum of all values) and treat it as a probability density function (pdf). Using this, we can calculate the cumulative distribution function (CDF) (3/6).