Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Dener de Paula Pereira, Apr 12, 2019.
Anyone can tell me what is the new features in the wddm 2.6?
Windows 10 May 2019 Update (Version 1903) Includes WDDM 2.6. More info on features when Windows 10 1903 update is released some time in May 2019.
No info as a yet
Nowhere seems to have covered it yet but the info's gone up on MSDN : https://docs.microsoft.com/en-us/wi...-windows-threshold-display-drivers--wddm-2-0-
DXR was in 2.5
The only major notable feature for users in 2.6 is Variable Rate Shading.
repost, oops, sorry
Super Wet Ink
Super-Wet Ink is a feature that revolves around front-buffer rendering. IHV drivers can support the creation of “displayable” textures of formats or modes that are not supported by the hardware. They can do this by allocating the texture that the app requested, along with a “shadow” texture with a format/layout that can be displayed, and then copying between the two at present-time. This “shadow” may not necessarily be a texture in the normal way we think of it, but may just be compression data. Additionally, it may not be required to exist, but may be an optimization instead.
The runtime will evolve to understand these aspects of displayable surfaces:
Whether or not a shadow must exist for display on a particular VidPnSource/plane.
Whether it is more optimal for a shadow to exist.
When to transfer contents from the application surface to the shadow surface.
The runtime will be explicit about this operation, as opposed to it being implicit within Present.
How to request setting a mode or dynamically flipping between the original and shadow surfaces.
Scanout may begin shortly after a VBlank, scans vertically from top to bottom of the image, and completes shortly before the next VBlank. This is not always the case, depending on the timing of the pixel clock, and the layout of the data in the texture; especially if there is actually compression available.
New DDIs were added to separate and understand transformations which occur prior to scanout, in order to (when possible) enable front-buffer rendering. See D3DWDDM2_6DDI_SCANOUT_FLAGS and PFND3DWDDM2_6DDI_PREPARE_SCANOUT_TRANSFORMATION.
Variable Rate Shading
Variable rate shading, or coarse pixel shading, is a mechanism to enable allocation of rendering performance/power at varying rates across rendered images.
In the previous model, in order to use MSAA (multi-sample anti-aliasing) to reduce geometric aliasing:
The amount by which to reduce geometric aliasing needs to be known up-front when the target is allocated.
The amount by which to reduce geometric aliasing can’t be changed once the target is allocated.
In WDDM 2.6, the new model extends MSAA into the opposite, coarse pixel direction, by adding a new concept of coarse shading. This is where shading can be performed at a frequency coarser than a pixel. A group of pixels can be shaded as a single unit and the result is then broadcast to all samples in the group.
A coarse shading API allows apps to specify the number of pixels that belong to a shaded group. The coarse pixel size can be varied after the render target is allocated. So, different portions of the screen or different draw passes can have different course shading rates.
A multiple-tier implementation is available with two user-queryable caps. For Tiers 1 and 2, coarse shading is available for both single-sampled and MSAA resources. For MSAA resources, shading can be performed per-coarse-pixel or per-sample as usual. However, on Tiers 1 and 2, for MSAA resources, coarse sampling cannot be used to shade at a frequency between per-pixel and per-sample.
Shading rate can only be specified on a per-draw-basis; nothing more granular than that
Shading rate applies uniformly to what is drawn independently of where it lies within the render target
Shading rate can be specified on a per-draw-basis, as in Tier 1. It can also be specified by a combination of per-draw-basis, and of:
Semantic from the per-provoking-vertex, and
A screenspace image
Shading rates from the three sources are combined using a set of combiners
Screen space image tile size is 16x16 or smaller. Shading rate requested by the app is guaranteed to be delivered exactly (for precision of temporal and other reconstruction filters)
SV_ShadingRate PS input is supported. The per-provoking vertex rate, also referred to here as a per-primitive rate, is only valid when one viewport is used and SV_ViewportIndex is not written to.
The per-provoking vertex rate, also referred to as a per-primitive rate, can be used with more than one viewport if the SupportsPerVertexShadingRateWithMultipleViewports cap is marked true. Additionally, in that case, it can be used when SV_ViewportIndex is written to.
See PFND3D12DDI_RS_SET_SHADING_RATE_0062 and D3D12DDI_SHADING_RATE_0062.
Collect Diagnostic Info
Collect diagnostic info allows the OS to collect a private data from drivers for graphics adapters which consist of both rendering and display functions. This new feature is a requirement in WDDM 2.6.
The new DDI should allow the OS to collect information at any time a driver is loaded. Currently the OS uses DxgkDdiCollectDebugInfo function implemented by the miniport to query driver private data for TDR (timeout detection and recovery) related cases. The new DDI will be used to collect data for variety of reasons. The OS will call this DDI when diagnostic is needed providing a type of information being requested. The driver should collect all private information important to investigate the issue and submit it to the OS. DxgkDdiCollectDebugInfo will be eventually deprecated and replaced with DxgkDdiCollectDiagnosticInfo.
Background processing allows user mode drivers to express desired threading behavior, and the runtime to control/monitor it. User mode drivers would spin up background threads and assign the threads as low a priority as possible, and rely on the NT scheduler to ensure these threads don’t disrupt the critical-path threads, generally with success.
APIs allow apps to adjust what amount of background processing is appropriate for their workloads and when to perform that work.
Driver Hot Update
Driver hot update reduces server downtime as much as possible when an OS component needs to be updated.
Driver hot patch is used to apply a security patch to the kernel mode driver. In this case the driver is asked to save adapter memory, the adapter is stopped, the driver is unloaded, new driver is loaded and the adapter is started again.
SeeDXGKDDI_SAVEMEMORYFORHOTUPDATE and DXGKDDI_RESTOREMEMORYFORHOTUPDATE.