Constantine Galkin wiseConst

What is "Work Expansion"

In a GPU-driven renderer, "work expansion" is a commonly occurring problem. "Work Expansion" means that a single item of work spawns N following work items. Typically one work item will be executed by one shader thread/invocation.

An example for work expansion is gpu driven meshlet culling following mesh culling. In this example a "work item" is culling a mesh, where each mesh cull work item spawns N following meshlet cull work items.

There are many diverse cases of this problem and many solutions. Some are trivial to solve, for example, when N (how many work items are spawned) is fixed.

Computer Graphics Programming Resources

List of freely available resources to study computer graphics programming.

Basic Path

The Sane Rendering Manifesto

The goal of this manifesto is to provide an easy to follow and reasonable rules that realtime and video game renderers can follow.

These rules highly prioritize image clarity/stability and pleasant gameplay experience over photorealism and excess graphics fidelity.

Keep in mind that shipping a game has priority over everything else and it is allowed to break the rules of the manifesto when there are no other good options in order to ship the game.

Do not use dynamic resolution.

Index

This list is an attempt to collect as many free resources about computer graphics- / rendering- techniques, game- / render-engine architecture and optimization techniques. This list doesn't contain every resource that is out there so it'll be expanded in time whenever I find another resource that may help one person or the other.

How do you descriptor set?

Descriptor sets have vexed me at every step of development. They're new and different and they have a lot of rules which aren't all that obvious. This document will hopefully lay out everything in one convenient place that I - and also you - can refer to

First, let's talk about what we're trying to do

Use Case

Most renderers need some way for shaders to access resources like textures, buffers, etc. For the Vulkan API, this way is the almighty descriptor set. Descriptors, as I understand them, are essentially a pointer to a resource. You update your descriptor sets with your resources, then you bind the descriptor sets to your command buffer, then shaders involved in subsequent drawcalls can look at the descriptors to know what resources they should actually read from. I'm not entirely sure why there's this indirection - and in fact, on AMD GPUs descriptor sets are actually just pointers - but the indirection exists, and we all have to find a way to deal with it

	#version 450

	// 2D Polyhedral Bounds of a Clipped, Perspective-Projected 3D Sphere. Michael Mara, Morgan McGuire. 2013
	bool projectSphereView(vec3 c, float r, float znear, float P00, float P11, out vec4 aabb)
	{
	if (c.z < r + znear) return false;

	vec3 cr = c * r;
	float czr2 = c.z * c.z - r * r;

	Вопросы на rendering engineer Huawei

	- в чем разница между forward и deferred rendering? Какие плюсы и минусы у каждого из двух подходов (производительность / ограничения)
	- какие способы рендерить прозрачную геометрию вы знаете?
	- что такое алиасинг? Из-за чего он происходит? Какие есть алгоритмы антиалиасинга? Как реализован встроенный MSAA и чем он лучше SSAA?
	- как работает TAA и какие дефекты он вызывает?

	- как оптимально рисовать большое число объектов на экране? Какие есть способы отсечения? (на GPU и CPU)
	- как работает Kd-дерево, bvh, bsp? Какая у них асимптотика и от чего она зависит?
	- для чего нужны mip-уровни текстур и фильтрация текстур?

	// these matrices are for left-handed coordinate systems, with depth mapped to [1;0]
	// the derivation for other matrices is analogous

	// to get a perspective matrix with reversed z, simply swap the near and far plane
	glm::mat4 perspectiveFovReverseZLH_ZO(float fov, float width, float height, float zNear, float zFar) {
	return glm::perspectiveFovLH_ZO(fov, width, height, zFar, zNear);
	};

	// now let zFar go towards infinity
	glm::mat4 infinitePerspectiveFovReverseZLH_ZO(float fov, float width, float height, float zNear) {

	struct vec3f {float x, y, z;};
	struct vec4f {float x, y, z, w;};
	struct mat44f {vec4f x, y, z, w;};

	//============================================================================
	// sphere_screen_extents
	//============================================================================
	// Calculates the exact screen extents xyzw=[left, bottom, right, top] in
	// normalized screen coordinates [-1, 1] for a sphere in view space. For
	// performance, the projection matrix (v2p) is assumed to be setup so that

	// cofactor matrix. drop-in replacement for the traditional transpose(inverse(m)) normal matrix calculation.
	// this is a substantial performance improvement.
	// short form found via shadertoy: https://www.shadertoy.com/view/3s33z
	mat3 cofactor(mat4 m) {
	return mat3(
	cross(m[1].xyz, m[2].xyz),
	cross(m[2].xyz, m[0].xyz),
	cross(m[0].xyz, m[1].xyz)
	);
	}