In the Fall Creator\u2019s Update, we\u2019ve added features that make it easier for developers to debug their code. In this article, we\u2019ll explore how these features work and offer a recap of what we added in Spring Creator\u2019s Update.<\/p>\n
But first, let\u2019s cover how debugging a game or a program utilizing the GPU is different from debugging other programs.<\/p>\n
As covered previously, DirectX 12 offers developers unprecedented low-level access to the GPU (check out Matt Sandy\u2019s detailed post<\/a> for more info). But even though this enables developers to write code that\u2019s substantially faster and more efficient, this comes at a cost: the API is more complicated, which means that there are more opportunities for mistakes.<\/p>\n Many of these mistakes happen GPU-side, which means they are a lot more difficult to fix. When the GPU crashes, it can be difficult to determine exactly what went wrong. After a crash, we\u2019re often left with little information besides a cryptic error message. The reason why these error messages can be vague is because of the inherent differences between CPUs and GPUs. Readers familiar with how GPUs work should feel free to skip the next section.<\/p>\n Most of the processing that happens in your machine happens in the CPU, as it\u2019s a component that\u2019s designed to resolve almost any computation it it\u2019s given. It does many things, and for some operations, foregoes efficiency for versatility. This is the entire reason that GPUs exist: to perform better than the CPU at the kinds of calculations that power the graphically intensive applications of today. Basically, rendering calculations (i.e. the math behind generating images from 2D or 3D objects) are small and many: performing them in parallel makes a lot more sense than doing them consecutively. The GPU excels at these kinds of calculations. This is why game logic, which often involves long, varied and complicated computations, happens on the CPU, while the rendering happens GPU-side.<\/p>\n Even though applications run on the CPU, many modern-day applications require a lot of GPU support. These applications send instructions to the GPU, and then receive processed work back. For example, an application that uses 3D graphics will tell the GPU the positions of every object that needs to be drawn. The GPU will then move each object to its correct position in the 3D world, taking into account things like lighting conditions and the position of the camera, and then does the math to work out what all of this should look like from the perspective of the user. The GPU then sends back the image that should be displayed on system\u2019s monitor.<\/p>\n To the left, we see a camera, three objects and a light source in Unity, a game development engine. <\/i>To the right, we see how the GPU renders these 3-dimensional objects onto a 2-dimensional screen, given the camera position and light source.\u00a0<\/i><\/p>\n <\/i>For high-end games with thousands of objects in every scene, this process of turning complicated 3-dimensional scenes into 2-dimensional images happens at least 60 times a second and would be impossible to do using the CPU alone!<\/p>\n Because of hardware differences, the CPU can\u2019t talk to the GPU directly: when GPU work needs to be done, CPU-side orders need to be translated into native machine instructions that our system\u2019s GPU can understand. This work is done by hardwire drivers, but because each GPU model is different, this means that the instructions delivered by each driver is different! Don\u2019t worry though, here at Microsoft, we devote a substantial amount of time to make sure that GPU manufacturers (AMD, Nvidia and Intel) provide drivers that DirectX can communicate with across devices. This is one of the things that our API does; we can see DirectX as the software layer between the CPU and GPU hardware drivers.<\/p>\n When games run error-free, DirectX simply sends orders (commands) from the CPU via hardware drivers to the GPU. The GPU then sends processed images back. After commands are translated and sent to the GPU, the CPU cannot track them anymore, which means that when the GPU crashes, it\u2019s really difficult to find out what happened. Finding out which command caused it to crash used to be almost impossible, but we\u2019re in the process of changing this, with two awesome new features that will help developers figure out what exactly happened when things go wrong in their programs.<\/p>\n One kind of error happens when the GPU becomes temporarily unavailable to the application, known as device removed or device lost errors. Most of these errors happen when a driver update occurs in the middle of a game. But sometimes, these errors happen because of mistakes in the programming of the game itself. Once the device has been logically removed, communication between the GPU and the application is terminated and access to GPU data is lost.<\/p>\n During the rendering process, the GPU writes to and reads from data structures called resources. Because it takes time to do translation work between the CPU and GPU, if we already know that the GPU is going to use the same data repeatedly, we might as well just put that data straight into the GPU. In a racing game, a developer will likely want to do this for all the cars, and the track that they\u2019re going to be racing on. All this data will then be put into resources. To draw just a single frame, the GPU will write to and read from many thousands of resources.<\/p>\n Before the Fall Creator\u2019s Update, applications had no direct control over the underlying resource memory. However, there are rare but important cases where applications may need to access resource memory contents, such as right after device removed errors.<\/p>\n We\u2019ve implemented a tool that does exactly this. Developers with access to the contents of resource memory now have substantially more useful information to help them determine exactly where an error occurred. Developers can now optimize time spent trying to determine the causes of errors, offering them more time to fix them across systems.<\/p>\n For technical details, see the OpenExistingHeapFromAddress\u00a0<\/a>documentation.<\/p>\n We\u2019ve implemented another tool to be used alongside the previous one. Essentially, it can be used to create markers that record which commands sent from the CPU have already been executed and which ones are in the process of executing. Right after a crash, even a device removed crash, this information remains behind, which means we can quickly figure out which commands might have caused it\u2014information that can significantly reduce the time needed for game development and bug fixing.<\/p>\n For technical details, see the <\/span>WriteBufferImmediate<\/a> documentation.<\/span><\/p>\n What does this mean for gamers? Having these tools offers direct ways to detect and inform around the root causes of what\u2019s going on inside your machine. It’s like the difference between trying to figure out what\u2019s wrong with your pickup truck based on hot smoke coming from the front versus having your Tesla\u2019s internal computer system telling you exactly which part failed and needs to be replaced.<\/p>\n Developers using these tools will have more time to build high-performance, reliable games instead of continuously searching for the root causes of a particular bug.<\/p>\n In the Spring Creator\u2019s Update, we introduced two new features: Depth Bounds Testing and Programmable MSAA. Where the features we rolled out for the Fall Creator\u2019s Update were mainly for making it easier for developers to fix crashes, Depth Bounds Testing and Programmable MSAA are focused on making it easier to program games that run faster with better visuals. These features can be seen as additional tools that have been added to a DirectX developer\u2019s already extensive tool belt.<\/p>\n Assigning depth values to pixels is a technique with a variety of applications: once we know how far away pixels are from a camera, we can throw away the ones too close or too far away. The same can be done to figure out which pixels fall inside and outside a light\u2019s influence (in a 3D environment), which means that we can darken and lighten parts of the scene accordingly. We can also assign depth values to pixels to help us figure out where shadows are. These are only some of the applications of assigning depth values to pixels; it\u2019s a versatile technique!<\/p>\n We now enable developers to specify a pixel\u2019s minimum and maximum depth value; pixels outside of this range get discarded. Because doing this is now an integral part of the API and because the API is closer to the hardware than any software written on top of it, discarding pixels that don\u2019t meet depth requirements is now something that can happen faster and more efficiently than before.<\/p>\n Simply put, developers will now be able to make better use of depth values in their code and can free GPU resources to perform other tasks on pixels or parts of the image that aren\u2019t going to be thrown away.<\/p>\n Now that developers have another tool at their disposal, for gamers, this means that games will be able to do more for every scene.<\/p>\n For technical details, see the OMSetDepthBounds<\/a> documentation.<\/p>\n Before we explore this feature, let\u2019s first discuss anti-aliasing.<\/p>\n Aliasing refers to the unwanted distortions that happen during the rendering of a scene in a game. There are two kinds of aliasing that happen in games: spatial and temporal.<\/p>\n Spatial aliasing refers to the visual distortions that happen when an image is represented digitally. Because pixels in a monitor\/television screen are not infinitely small, there isn\u2019t a way of representing lines that aren\u2019t perfectly vertical or horizontal on a monitor. This means that most lines, instead of being straight lines on our screen, are not straight but rather approximations of straight lines. Sometimes the illusion of straight lines is broken: this may appear as stair-like rough edges, or \u2018jaggies\u2019, and spatial anti-aliasing refers to the techniques that programmers use to make these kinds edges smoother and less noticeable. The solution to these distortions is baked into the API, with hardware-accelerated MSAA (Multi-Sample Anti-Aliasing), an efficient anti-aliasing technique that combines quality with speed. Before the Spring Creator\u2019s Update, developers already had the tools to enable MSAA and specify its granularity (the amount of anti-aliasing done per scene) with DirectX.<\/p>\n Side-by-side comparison of the same scene with spatial aliasing (left) and without (right). Notice in particular the jagged outlines of the building and sides of the road in the aliased image. This still was taken from Forza Motorsport 6: Apex<\/a>.<\/em><\/p>\n But what about temporal aliasing? Temporal aliasing refers to the aliasing that happens over time and is caused by the sampling rate (or number of frames drawn a second) being slower than the movement that happens in scene. To the user, things in the scene jump around instead of moving smoothly. This<\/a> YouTube video does an excellent job showing what temporal aliasing looks like in a game.<\/p>\n In the Spring Creator\u2019s Update, we offer developers more control of MSAA, by making it a lot more programmable. At each frame, developers can specify how MSAA works on a sub-pixel level. By alternating MSAA on each frame, the effects of temporal aliasing become significantly less noticeable.<\/p>\n Programmable MSAA means that developers have a useful tool in their belt. Our API not only has native spatial anti-aliasing but now also has a feature that makes temporal anti-aliasing a lot easier. With DirectX 12 on Windows 10, PC gamers can expect upcoming games to look better than before.<\/p>\n For technical details, see the SetSamplePositions<\/a> documentation.<\/p>\nThe CPU-GPU Divide<\/h3>\n
![\"\"](\"http:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2017\/11\/Capture5.png\")
<\/a><\/p>\nDevice Removed Errors<\/h3>\n
Improved Debugging: Data<\/h3>\n
Improved Debugging: Commands<\/h3>\n
Recap of Spring Creator\u2019s Update<\/strong><\/h2>\n
Depth Bounds Testing<\/h3>\n
Programmable MSAA<\/h3>\n
![\"\"](\"http:\/\/devblogs.microsoft.com\/directx\/wp-content\/uploads\/sites\/42\/2017\/11\/sidebyside.png\")
<\/a><\/a><\/p>\nOther Changes<\/h3>\n