Subject: Graphics Cards | March 19, 2019 - 08:29 PM | Scott Michaud
Tagged: microsoft, DirectX 12, turing, nvidia
To align with the Game Developers Conference, GDC 2019, Microsoft has announced Variable Rate Shading for DirectX 12. This feature increases performance by allowing the GPU to lower its shading resolution for specific parts of the scene (without the developer doing explicit, render texture-based tricks).
An NVIDIA speech from SIGGRAPH 2018 (last August)
The feature is divided into three parts:
- Lowering the resolution of specific draw calls (tier 1)
- Lowering the resolution within a draw call by using an image mask (tier 2)
- Lowering the resolution within a draw call per primitive (ex: triangle) (tier 2)
The last two points are tagged as “tier 2” because they can reduce the workload within a single draw call, which is an item of work that is sent to the GPU. A typical draw call for a 3D engine is a set of triangles (vertices and indices) paired with a material (a shader program, textures, and properties). While it is sometimes useful to lower the resolution for particularly complex draw calls that take up a lot of screen space but whose output is also relatively low detail, such as water, there are real benefits to being more granular.
The second part, an image mask, allows detail to be reduced for certain areas of the screen. This can be useful in several situations:
- The edges of a VR field of view
- Anywhere that will be brutalized by a blur or distortion effect
- Objects behind some translucent overlays
- Even negating a tier 1-optimized section to re-add quality where needed
The latter example was the one that Microsoft focused on with their blog. Unfortunately, I am struggling to figure out what specifically is going on, because the changes that I see (ex: the coral reef, fish, and dirt) don’t line up with their red/blue visualizer. The claim is that they use an edge detection algorithm to force high-frequency shading where there would be high-frequency detail.
Right side reduces shading by 75% for terrain and water
Right side reclaims some lost fidelity based on edge detection algorithm
Visualization of where shading complexity is spent.
(Red is per-pixel. Blue is 1 shade per 2x2 block.)
Images Source: Firaxis via Microsoft
Microsoft claims that this feature will only be available for DirectX 12. That said, NVIDIA, when Turing launched, claims that Variable Rate Shading will be available for DirectX 11, DirectX 12, Vulkan, and OpenGL. I’m not sure what’s different between Microsoft’s implementation that lets them separate it from NVIDIA’s extension.
Microsoft will have good tools support, however. They claim that their PIX for Windows performance analysis tool will support this feature on Day 1.
Subject: Graphics Cards | March 14, 2019 - 08:38 PM | Sebastian Peak
Tagged: Windows 7, The Division 2, radeon, graphics, gpu, gaming, dx12, driver, DirectX 12, amd, Adrenalin, 19.3.2
AMD has released Radeon 19.3.2 drivers, adding support for Tom Clancy’s The Division 2 and offering a performance boost with Civilization VI: Gathering Storm. This update also adds a number of new Vulkan extensions. But wait, there's more: "DirectX 12 on Windows 7 for supported game titles." The DX12-ening is upon us.
Here are AMD's release notes for 19.3.2:
Radeon Software Adrenalin 2019 Edition 19.3.2 Highlights
- Tom Clancy’s The Division® 2
- Sid Meier’s Civilization® VI: Gathering Storm
- Up to 4% average performance gains on AMD Radeon VII with Radeon™ Software Adrenalin 2019 Edition 19.3.2 vs 19.2.3. RS-288
- DirectX® 12 on Windows®7 for supported game titles
- AMD is thrilled to help expand DirectX® 12 adoption across a broader range of Windows operating systems with Radeon Software Adrenalin 2019 Edition 18.12.2 and onward, which enables consumers to experience exceptional levels of detail and performance in their games.
- Radeon ReLive for VR may sometimes fail to install during Radeon Software installation.
- Fan curve may fail to switch to manual mode after the manual toggle is switched when fan curve is still set to default behavior.
- Changes made in Radeon WattMan settings via Radeon Overlay may sometimes not save or take effect once Radeon Overlay is closed.
- Rainbow Six Siege™ may experience intermittent corruption or flickering on some game textures during gameplay.
- DOTA™2 VR may experience stutter on some HMD devices when using the Vulkan® API.
- Mouse cursors may disappear or move out of the boundary of the top of a display on AMD Ryzen Mobile Processors with Radeon Vega Graphics.
- Performance metrics overlay and Radeon WattMan gauges may experience inaccurate fluctuating readings on AMD Radeon VII..
Subject: General Tech | March 14, 2019 - 11:25 AM | Jim Tanous
Tagged: video, podcast, phoenix point, Mellanox, halo, gtx 1660, DirectX 12, corsair
PC Perspective Podcast #536 - 3/13/2019
Join us this week as we review the new NVIDIA GTX 1660 and a high-end case from Corsair, discuss NVIDIA's Mellanox acquisition, get excited over Halo for PC, and more!
Subscribe to the PC Perspective Podcast
Check out previous podcast episodes: http://pcper.com/podcast
00:00:06 - Intro
00:03:47 - Review: NVIDIA GTX 1660
00:22:22 - Review: Corsair Crystal Series 680X RGB Case
00:37:48 - News: NVIDIA Acquires Mellanox
00:47:58 - News: DirectX 12 for Windows 7
00:53:25 - News: Halo: The Master Chief Collection for PC
00:58:21 - News: Windows 10 KB4482887 Issues & Fix
01:00:40 - News: AMD Navi Launch Date Rumors
01:02:29 - News: Navi GPU Benchmarks?
01:10:03 - News: Phoenix Point Jumps Ship to Epic Games Store
01:25:22 - News: Samsung eMRAM for IoT
01:30:12 - News: The Web's 30th B-Day
01:34:40 - News: Corsair Carbide Series 678C Low-Noise Case
01:37:38 - Picks of the Week
Subject: General Tech, Graphics Cards | March 12, 2019 - 04:53 PM | Scott Michaud
Tagged: pc gaming, wow, blizzard, microsoft, DirectX 12, dx12
Microsoft has just announced that they ported the DirectX 12 runtime to Windows 7 for World of Warcraft and other, unannounced games. This allows those games to run the new graphics API with its more-efficient framework of queuing work on GPUs, with support from Microsoft. I should note that the benchmarks for DirectX 12 in WoW are hit or miss, so I’m not sure whether it’s better to select DX11 or DX12 for any given PC, but you are free to try.
This does not port other graphics features, like the updated driver model, which leads to this excerpt from the DirectX blog post:
How are DirectX 12 games different between Windows 10 and Windows 7?
Windows 10 has critical OS improvements which make modern low-level graphics APIs (including DirectX 12) run more efficiently. If you enjoy your favorite games running with DirectX 12 on Windows 7, you should check how those games run even better on Windows 10!
Just make sure you don’t install KB4482887? Trollolololol. Such unfortunate timing.
Of course, Vulkan also exists, and has supported Windows 7 since its creation. Further, both DirectX 12 and Vulkan have forked away from Mantle, which, of course, supported Windows 7. (AMD’s Mantle API pre-dates Windows 10.) The biggest surprise is that Microsoft released such a big API onto Windows 7 even though it is in extended support. I am curious what lead to this exception, such as cyber cafés or other international trends, because I really have no idea.
As for graphics drivers? I am guessing that we will see it pop up in new releases. The latest GeForce release notes claim that DirectX 12 is only available on Windows 10, although undocumented features are not exactly uncommon in the software and hardware industry. Speaking of undocumented features, World of Warcraft 8.1.5 is required for DirectX 12 on Windows 7, although this is not listed anywhere in the release notes on their blog.
Subject: Graphics Cards | February 12, 2019 - 03:56 PM | Scott Michaud
Tagged: pc gaming, ue4, epic games, dxr, DirectX 12, microsoft
The upcoming version of Unreal Engine, 4.22, will include several new features.
The most interesting addition for our audience is probably “Early Access” support for DirectX 12 Raytracing (DXR) on DirectX 12. This includes the low-level framework to cast and evaluate rays in shaders (although they don’t clarify whether that means written shaders, nodes for graph-based shaders, or both) as well as higher-level features that use DXR, such as area lights, soft shadows, and reflections. They have also added a denoiser for shadows, reflections, and ambient occlusion, which will improve image quality with lower sample counts.
If you remember NVIDIA’s RTX announcement, many of their first-party demos were built using Unreal Engine 4. This includes the Star Wars demo with the two Stormtroopers putting their feet in their mouths on an elevator with their boss. It makes sense that Epic would be relatively far along in RTX support, especially just before GDC.
A few other additions include Visual Studio 2019 support (although Visual Studio 2017 is still the default). The new Unreal Audio Engine is now enabled by default for new projects, which was a complete re-write of the original system that started a few years ago. The old audio system was a bit of a mess, and, worse, varied from platform to platform.
Unreal Engine 4.22 also (experimentally) opts-in to the much longer file and paths names that were introduced with the Windows 10 Anniversary Update. The previous limit was 260 characters for a full path, which was defined as MAX_PATH in Win32. I’m not sure what the new limit is, but I think it’s 32,767 characters after expansion. I could be wrong, though.
If you have the Epic Launcher installed, whether it’s for Unreal Engine, Fortnite, something from the Epic Store, Unreal Tournament 4, or whatever, then you can check out Unreal Engine 4.22 for free. (Royalties apply under certain circumstances… but, at that point, you are making money off of it.)
Subject: General Tech | September 14, 2018 - 10:32 PM | Scott Michaud
Tagged: rtx, Unity, ray tracing, directx raytracing, DirectX 12
As Ken wrote up his take in a separate post, NVIDIA has made Turing architecture details public, which will bring real-time ray tracing to PC gaming later this month. When it was announced, NVIDIA had some demos in Unreal Engine 4, and a few partnered games (Battlefield V, Shadow of the Tomb Raider, and Metro Exodus) showed off their implementations.
As we expected, Unity is working on supporting it too.
Not ray tracing, but from the same project at Unity.
The first commit showed up on Unity’s GitHub for their Scriptable Render Pipelines project, dated earlier today. Looking through the changes, it appears to just generate the acceleration structure based on the objects of type renderer in the current scene (as well as define the toggle properties of course). It looks like we are still a long way out.
I’m looking forward to ray tracing implementations, though. I tend to like art styles with anisotropic metal trims and soft shadows, which is difficult to get right with rasterization alone due to the reliance on other objects in the scene. In the case of metal, reflections dominate the look and feel of the material. In the case of soft shadows, you really need to keep track of how much of a light has been blocked between the rendered fragment and the non-point light.
And yes, it will depend on the art style, but mine just happens to be computationally expensive.
O Rayly? Ya Rayly. No Ray!
Microsoft has just announced a raytracing extension to DirectX 12, called DirectX Raytracing (DXR), at the 2018 Game Developer's Conference in San Francisco.
The goal is not to completely replace rasterization… at least not yet. This effect will be mostly implemented for effects that require supplementary datasets, such as reflections, ambient occlusion, and refraction. Rasterization, the typical way that 3D geometry gets drawn on a 2D display, converts triangle coordinates into screen coordinates, and then a point-in-triangle test runs across every sample. This will likely occur once per AA sample (minus pixels that the triangle can’t possibly cover -- such as a pixel outside of the triangle's bounding box -- but that's just optimization).
For rasterization, each triangle is laid on a 2D grid corresponding to the draw surface.
If any sample is in the triangle, the pixel shader is run.
This example shows the rotated grid MSAA case.
A program, called a pixel shader, is then run with some set of data that the GPU could gather on every valid pixel in the triangle. This set of data typically includes things like world coordinate, screen coordinate, texture coordinates, nearby vertices, and so forth. This lacks a lot of information, especially things that are not visible to the camera. The application is free to provide other sources of data for the shader to crawl… but what?
- Cubemaps are useful for reflections, but they don’t necessarily match the scene.
- Voxels are useful for lighting, as seen with NVIDIA’s VXGI and VXAO.
This is where DirectX Raytracing comes in. There’s quite a few components to it, but it’s basically a new pipeline that handles how rays are cast into the environment. After being queued, it starts out with a ray-generation stage, and then, depending on what happens to the ray in the scene, there are close-hit, any-hit, and miss shaders. Ray generation allows the developer to set up how the rays are cast, where they call an HLSL instrinsic instruction, TraceRay (which is a clever way of invoking them, by the way). This function takes an origin and a direction, so you can choose to, for example, cast rays only in the direction of lights if your algorithm was to, for instance, approximate partially occluded soft shadows from a non-point light. (There are better algorithms to do that, but it's just the first example that came off the top of my head.) The close-hit, any-hit, and miss shaders occur at the point where the traced ray ends.
To connect this with current technology, imagine that ray-generation is like a vertex shader in rasterization, where it sets up the triangle to be rasterized, leading to pixel shaders being called.
Even more interesting – the close-hit, any-hit, and miss shaders can call TraceRay themselves, which is used for multi-bounce and other recursive algorithms (see: figure above). The obvious use case might be reflections, which is the headline of the GDC talk, but they want it to be as general as possible, aligning with the evolution of GPUs. Looking at NVIDIA’s VXAO implementation, it also seems like a natural fit for a raytracing algorithm.
Speaking of data structures, Microsoft also detailed what they call the acceleration structure. Each object is composed of two levels. The top level contains per-object metadata, like its transformation and whatever else data that the developer wants to add to it. The bottom level contains the geometry. The briefing states, “essentially vertex and index buffers” so we asked for clarification. DXR requires that triangle geometry be specified as vertex positions in either 32-bit float3 or 16-bit float3 values. There is also a stride property, so developers can tweak data alignment and use their rasterization vertex buffer, as long as it's HLSL float3, either 16-bit or 32-bit.
As for the tools to develop this in…
Microsoft announced PIX back in January 2017. This is a debugging and performance analyzer for 64-bit, DirectX 12 applications. Microsoft will upgrade it to support DXR as soon as the API is released (specifically, “Day 1”). This includes the API calls, the raytracing pipeline resources, the acceleration structure, and so forth. As usual, you can expect Microsoft to support their APIs with quite decent – not perfect, but decent – documentation and tools. They do it well, and they want to make sure it’s available when the API is.
Example of DXR via EA's in-development SEED engine.
In short, raytracing is here, but it’s not taking over rasterization. It doesn’t need to. Microsoft is just giving game developers another, standardized mechanism to gather supplementary data for their games. Several game engines have already announced support for this technology, including the usual suspects of anything top-tier game technology:
- Frostbite (EA/DICE)
- SEED (EA)
- 3DMark (Futuremark)
- Unreal Engine 4 (Epic Games)
- Unity Engine (Unity Technologies)
They also said, “and several others we can’t disclose yet”, so this list is not even complete. But, yeah, if you have Frostbite, Unreal Engine, and Unity, then you have a sizeable market as it is. There is always a question about how much each of these engines will support the technology. Currently, raytracing is not portable outside of DirectX 12, because it’s literally being announced today, and each of these engines intend to support more than just Windows 10 and Xbox.
Still, we finally have a standard for raytracing, which should drive vendors to optimize in a specific direction. From there, it's just a matter of someone taking the risk to actually use the technology for a cool work of art.
If you want to read more, check out Ryan's post about the also-announced RTX, NVIDIA's raytracing technology.
Subject: Graphics Cards | March 28, 2017 - 04:32 PM | Scott Michaud
Tagged: vulkan, DirectX 12, Futuremark, 3dmark
The latest update to 3DMark adds Vulkan support to its API Overhead test, which attempts to render as many simple objects as possible while keeping above 30 FPS. This branch of game performance allows developers to add more objects into a scene, and design these art assets in a more simple, straight-forward way. This is, now, one of the first tests that can directly compare DirectX 12 and Vulkan, which we expect to be roughly equivalent, but we couldn’t tell for sure.
While I wasn’t able to run the tests myself, Luca Rocchi of Ocaholic gave it a shot on their Core i7-5820K and GTX 980. Apparently, Vulkan was just under 10% faster than DirectX 12 in their results, reaching 22.6 million draw calls in Vulkan, but 20.6 million in DirectX 12. Again, this is one test, done by a third-party, for a single system, and a single GPU driver, on a single 3D engine, and one that is designed to stress a specific portion of the API at that; take it with a grain of salt. Still, this suggests that Vulkan can keep pace with the slightly-older DirectX 12 API, and maybe even beat it.
This update also removed Mantle support. I just thought I’d mention that.
Linked Multi-GPU Arrives... for Developers
The Khronos Group has released the Vulkan 18.104.22.168 specification, which includes experimental (more on that in a couple of paragraphs) support for VR enhancements, sharing resources between processes, and linking similar GPUs. This spec was released alongside a LunarG SDK and NVIDIA drivers, which are intended for developers, not gamers, that fully implement these extensions.
I would expect that the most interesting feature is experimental support for linking similar GPUs together, similar to DirectX 12’s Explicit Linked Multiadapter, which Vulkan calls a “Device Group”. The idea is that the physical GPUs hidden behind this layer can do things like share resources, such as rendering a texture on one GPU and consuming it in another, without the host code being involved. I’m guessing that some studios, like maybe Oxide Games, will decide to not use this feature. While it’s not explicitly stated, I cannot see how this (or DirectX 12’s Explicit Linked mode) would be compatible in cross-vendor modes. Unless I’m mistaken, that would require AMD, NVIDIA, and/or Intel restructuring their drivers to inter-operate at this level. Still, the assumptions that could be made with grouped devices are apparently popular with enough developers for both the Khronos Group and Microsoft to bother.
A slide from Microsoft's DirectX 12 reveal, long ago.
As for the “experimental” comment that I made in the introduction... I was expecting to see this news around SIGGRAPH, which occurs in late-July / early-August, alongside a minor version bump (to Vulkan 1.1).
I might still be right, though.
The major new features of Vulkan 22.214.171.124 are implemented as a new classification of extensions: KHX. In the past, vendors, like NVIDIA and AMD, would add new features as vendor-prefixed extensions. Games could query the graphics driver for these abilities, and enable them if available. If these features became popular enough for multiple vendors to have their own implementation of it, a committee would consider an EXT extension. This would behave the same across all implementations (give or take) but not be officially adopted by the Khronos Group. If they did take it under their wing, it would be given a KHR extension (or added as a required feature).
The Khronos Group has added a new layer: KHX. This level of extension sits below KHR, and is not intended for production code. You might see where this is headed. The VR multiview, multi-GPU, and cross-process extensions are not supposed to be used in released video games until they leave KHX status. Unlike a vendor extension, the Khronos Group wants old KHX standards to drop out of existence at some point after they graduate to full KHR status. It’s not something that NVIDIA owns and will keep it around for 20 years after its usable lifespan just so old games can behave expectedly.
How long will that take? No idea. I’ve already mentioned my logical but uneducated guess a few paragraphs ago, but I’m not going to repeat it; I have literally zero facts to base it on, and I don’t want our readers to think that I do. I don’t. It’s just based on what the Khronos Group typically announces at certain trade shows, and the length of time since their first announcement.
The benefit that KHX does bring us is that, whenever these features make it to public release, developers will have already been using it... internally... since around now. When it hits KHR, it’s done, and anyone can theoretically be ready for it when that time comes.
Subject: Graphics Cards | October 5, 2016 - 09:01 PM | Scott Michaud
Tagged: amd, frame pacing, DirectX 12
When I first read this post, it was on the same day that AMD released their Radeon Software Crimson Edition 16.10.1 drivers, although it was apparently posted the day prior. As a result, I thought that their reference to 16.9.1 was a typo, but it apparently wasn't. These changes have been in the driver for a month, at least internally, but it's unclear how much it was enabled until today. (The Scott Wasson video suggests 16.10.1.) It would have been nice to see it on their release notes as a new feature, but at least they made up for it with a blog post and a video.
If you don't recognize him, Scott Wasson used to run The Tech Report, and he shared notes with Ryan while we were developing our Frame Rating testing methodology. He was focused on benchmarking GPUs by frame time, rather than frame rate, because the number of frames that the user sees means less than how smooth the animation they present is. Our sites diverged on implementation, though, as The Tech Report focused on software, while Ryan determined that capturing and analyzing output frames, intercepted between the GPU and the monitor, would tell a more complete story. Regardless, Scott Wasson left his site to work for AMD last year, with the intent to lead User Experience.
We're now seeing AMD announce frame pacing for DirectX 12 Multi-GPU.
This feature particularly interesting, because, depending on the multi-adapter mode, a lot of that control should be in the hands of the game developers. It seems like the three titles they announced, 3D Mark: Time Spy, Rise of the Tomb Raider, and Total War: Warhammer, would be using implicit linked multi-adapter, which basically maps to CrossFire. I'd be interested to see if they can affect this in explicit mode via driver updates as well, but we'll need to wait and see for that (and there isn't many explicit mode titles anyway -- basically just Ashes of the Singularity for now).
If you're interested to see how multi-GPU load-balancing works, we published an animation a little over a month ago that explains three different algorithms, and how explicit APIs differ from OpenGL and DirectX 11. It is also embedded above.