2020. 2. 15. 06:09ㆍ카테고리 없음
Depth Precision VisualizedJuly 3, 2015, Depth precision is a pain in the ass that every graphics programmer has to struggle with sooner orlater. Many articles and papers have been written on the topic, and a variety of different depthbuffer formats and setups are found across different games, engines, and devices.Because of the way it interacts with perspective projection, GPU hardware depth mapping is a littlerecondite and studying the equations may not make things immediately obvious. To get an intuitionfor how it works, it’s helpful to draw some pictures.This article has three main parts.
In the first part, I try to provide some motivation for nonlineardepth mapping. Second, I present some diagrams to help understand how nonlinear depth mapping worksin different situations, intuitively and visually. The third part is a discussion and reproductionof the main results ofby Paul Upchurch and Mathieu Desbrun (2012), concerning the effects of floating-point roundoff erroron depth precision.
that means triangles start voxelizing when you get further away from originThey can in a few edge cases, but in most cases they don’t.Simplifying many things, to render a model, a game engine uploads 2 things to GPU:1. Model’s vertex buffer + index buffer. The vertices are in mesh’s own coordinate system, and most 3D designers don’t design their meshes placed 100km away from origin.2. A single 4x4 matrix, containing ( world. view.
Z Buffer Recipe
projection ) transform. They can in a few edge cases, but in most cases they don’t. world transform will contain large values because you’re very far, view transform will also contain large values because camera’s also very far, but multiplied together they won’t have very large values, because model is near the camera.This is a good point; this problem is more prone to show up in a ray tracer than a rasterizer, since rasterizers have to apply the camera transform to the geometry, and ray tracers don't.It's pretty easy to see this problem while using Maya though. Z-buffer resolution in the editor drops off from the origin.We might see this issue crop up with increasing frequency as more and more people use GPUs for ray tracing. Note it's only voxely if you translate in all 3 dimensions. If you were far away in just x, but not y & z, you'd get a weird looking image that's slabby in x but detailed in y & z.It's cool that the pbrt renders hold up in voxel form, like the model's still solid and the shadows don't freak out or anything.The problem is fairly well known in film & games production. Artists, especially world designers, all know to model things near the origin and not far away because precision drops as you move away.
They will also sometimes avoid modeling small things in small units like millimeters even though they might prefer it, because the units dictate how big your floats get, which in turn determines how fast you lose precision.Here's the voxel prediction chart. Did you even read the article? In Mono, decades ago, we made the mistake of performing all 32-bit float computations as 64-bit floats while still storing the data in 32-bit locations. (.) Applications did pay a heavier price for the extra computation time, but in the 2003 era Mono was mostly used for Linux desktop application, serving HTTP pages and some server processes, so floating point performance was never an issue we faced day to day. (.) Nowadays, Games, 3D applications image processing, VR, AR and machine learning have made floating point operations a more common data type in modern applications.
When it rains, it pours, and this is no exception. Floats are no longer your friendly data type that you sprinkle in a few places in your code, here and there. They come in an avalanche and there is no place to hide.
There are so many of them, and they won’t stop coming at you.The raytracer is just a good performance test. In any real world code, slower floats doesn't matter at all. None of you who have commented have been able to or even tried to prove me wrong on that point.First of all, this is Burden of Proof fallacy: the onus is on you to prove this statement right, not on us to prove you wrong.Second of all, nobody has been trying to prove you wrong because you did not actually say that floating point performance does not matter in real world code. You may have had it in mind, but you cannot blame others for not picking up on something you did not communicate in the first place.What you did say was 'correctness speed', which is not the same thing. Furthermore, while this statement is true it needs a context to be applied to, which you have to give. Without further justification by you why using float32 operations for float32 data types would reduce correctness, it is a hollow truism.
Maybe GP misspoke with 'wrong', but a valid point was raised there, maybe not in the clearest way:If you are trying to write a super-fast raytracer or game or some such, you will get the best results by writing SIMD manually. Otherwise, you are benchmarking how well autovectorization works in the various compilers and JITs you are testing.Now, specifically here it looks like Mono had a bunch of other problems they had to fix to get to the right ballpark (not using the right data type, etc.), which is what the blogpost focuses on. And it's nice to see speedups for C# code there.Still, though, if you need maximal perf, raw SIMD is necessary. Comparing to a C version with SIMD might have been interesting, for example. (Likely the reason Burst is 'faster than C' is that it happens to autovectorize that code better.).