1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  1. Dener de Paula Pereira

    Dener de Paula Pereira Member

    Messages:
    49
    Likes Received:
    4
    GPU:
    Vega 56 Pulse
    Anyone can tell me what is the new features in the wddm 2.6?
     
  2. NvidiaFreak650

    NvidiaFreak650 Master Guru

    Messages:
    315
    Likes Received:
    124
    GPU:
    Nvidia RTX 2080 FE
    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
     
  3. Yakumo.unr

    Yakumo.unr New Member

    Messages:
    1
    Likes Received:
    1
    GPU:
    1060 6gb
    Strange Times likes this.
  4. Undying

    Undying Ancient Guru

    Messages:
    11,752
    Likes Received:
    1,478
    GPU:
    Aorus RX580 XTR 8GB

  5. nevcairiel

    nevcairiel Master Guru

    Messages:
    597
    Likes Received:
    187
    GPU:
    MSI 1080 Gaming X
    DXR was in 2.5

    The only major notable feature for users in 2.6 is Variable Rate Shading.
     
    Undying likes this.
  6. Vidik

    Vidik Master Guru

    Messages:
    545
    Likes Received:
    130
    GPU:
    MSI 1070 Gaming Z
    repost, oops, sorry
     
  7. Astyanax

    Astyanax Ancient Guru

    Messages:
    3,283
    Likes Received:
    853
    GPU:
    GTX 1080ti
    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.

    Tier 1:

    • 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
    Tier 2:

    • 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.

    See DXGKDDI_COLLECTDIAGNOSTICINFO.

    Background Processing
    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.

    See PFND3D12DDI_QUEUEPROCESSINGWORK_CB_0062.

    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.
     
    BuildeR2, MoKiChU and Indy like this.

Share This Page