The F1 2018 DX12 Beta Discussion Thread [UPDATE - 06/12]

Question

Patch 1.15 with DX12 Beta should be live at around 1pm UK
time (GMT). This update should mean that this version is now compatible with
version 1.15 of the main game and your save games should now be working correctly.

We do have some patch notes for you, which you can find
below. Please continue to use this thread for reporting any issues as usual,
including any new issues you find with the latest patch. Thanks!

DX12 Beta - Patch 1.15 Notes;

General

The mouse cursor should no longer remain visible

Graphical corruption should no longer be seen for Nvida graphics
cards users

Windows 10 v1809

You should now be able to go back to fullscreen after switching
to windows mode

Lower resolutions than the monitors native one should no longer
show the game in window mode

Frame rate should no longer be locked when using Gsync

[UPDATE – 03/12/2018]

Please note that the current DX12 Beta version is incompatible
with Patch 1.15. If you wish to update to version 1.15 of the main game then
you will be unable to play the DX12 Beta using your existing save. We are looking
at updating the DX12 beta and will let you know as soon as possible as to when
that will go live. Thank you for your patience and apologies for any inconvenience
this may cause.

[Original Post]

Hi all
and welcome to the F1 2018 DX12 Beta discussion
thread.

You can
find main The F1 2018 DX12 Beta post
here, which has all the information about the beta.

Please report any issues to us in this thread below –
especially if something’s happened in your game, something looks wrong, or you
encounter something you hadn’t noticed in the standard (DX11) version of the
game.

If we get numerous reports on the same issue then we may
break these out into their own support thread to make issues easier to track.

When reporting something, please be sure to add your basic
system specs in your post, so that you can help us identify issues with
specific hardware configurations.

Share this post

Link to post

Share on other sites

@Faya, I have a question, is this DirectX 12 technology being tested on Beta with the intention of a final game of F1 2018 or will this DirectX 12 version always be in Beta so that the experiments are only implemented in a final game of 2019?

Share this post

Link to post

Share on other sites

@Faya, I have a question, is this DirectX 12 technology being tested on Beta with the intention of a final game of F1 2018 or will this DirectX 12 version always be in Beta so that the experiments are only implemented in a final game of 2019?

Share this post

Link to post

Share on other sites

There should be very few visual changes between DX11 and DX12. Performance is likely to be the biggest difference (although this is still work in progress with this beta). The plan will be to build on this tech and take advantage of DX12 capabilities in the future.

Share this post

Link to post

Share on other sites

If you manage to lose Fullscreen, just revert back to DX11 (opt-out of the beta), delete the hardware_settings_config, launch the DX11 game put it in Fullscreen then exit and opt back in to the beta.

First launch of the game doesn't offer the pop-up, second one does.

You can right-click the library entry and pick to run the DX12 game or use the Steam Library PLAY button. Desktop shortcuts still play the DX11 game as the .exe isn't deleted when you opt-in (so you can choose either at the pop-up).

Right-clicking the Steam Tray icon also launches the DX11 version without a pop-up.

Share this post

Link to post

Share on other sites

@steviejay69 - frame locking appears to be caused by using Windows v1809 with Gync. Check out the known issues on the main DX12 beta announcement as it calls out some of the other issues (including the full-screen / windowed mode issue that you've also spotted): http://forums.codemasters.com/discussion/141667/the-f1-2018-dx12-beta.

You mentioned running Freesync in another thread, so perhaps disabling this will resolve the frame locking issue?

Share this post

Link to post

Share on other sites

@steviejay69 - frame locking appears to be caused by using Windows v1809 with Gync. Check out the known issues on the main DX12 beta announcement as it calls out some of the other issues (including the full-screen / windowed mode issue that you've also spotted): http://forums.codemasters.com/discussion/141667/the-f1-2018-dx12-beta.

You mentioned running Freesync in another thread, so perhaps disabling this will resolve the frame locking issue?

im using dx12 on bf5 with gsync and there is no frame locking.

So this is not a windows problem.

There is no reason for using dx12 on f1 if it locks the frames, im sorry but this is just senseless.

Share this post

Link to post

Share on other sites

@steviejay69 - frame locking appears to be caused by using Windows v1809 with Gync. Check out the known issues on the main DX12 beta announcement as it calls out some of the other issues (including the full-screen / windowed mode issue that you've also spotted): http://forums.codemasters.com/discussion/141667/the-f1-2018-dx12-beta.

You mentioned running Freesync in another thread, so perhaps disabling this will resolve the frame locking issue?

Yes. I did mention in the post earlier that I have disabled FreeSync and it is still locked.to 60FPS.

1809 and Adrenaline 18.11.1 are required to support WDDM 2.5

The post about the WORKAROUND for losing fullscreen was exactly that, plus a warning to others that the pop-up to pick versions DOES NOT APPEAR on first run. :) It's OK to read my posts!

Updates to Display driver development in Windows 10, version 1809 include the following[4]:

Raytracing - New Direct3D DDI's were created in parallel of Direct3D API's, in order to support hardware-accelerated raytracing. Example DDIs include: PFND3D12DDI_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_0054, PFND3D12DDI_COPY_RAYTRACING_ACCELERATION_STRUCTURE_0054. For more info about raytracing, see Announcing Microsoft DirectX Raytracing.

Universal Driver Requirements - WDDM 2.5 drivers will need to ensure their DirectX11 UMD, DirectX12 UMD, KMDs, and any other DLL loaded by these components, adhere to the Universal API.

SRV-Only Tiled Resource Tier 3 - In Windows 10, version 1809, Tiled Resource Tier 3 capabilities can be supported less-orthogonally by GPUs. Direct3D12 now supports sparse volume textures without requiring unordered-access and render-target operations. SRV-Only Tiled Resource Tier 3 is a conceptual tier that fits between Tier 2 and Tier 3. Hardware support is optional, just like orthogonal Tiled Resource Tier 3 support currently is. But, supporting SRV-Only Tiled Resource Tier 3 is a super-set tier that requires support for Tiled Resource Tier 2. Drivers that already advertise support for orthogonal Tiled Resource Tier 3 merely have to update their drivers to support the latest “options caps” DDI structure version. The runtime will advertise SRV-Only Tiled Resource Tier 3 support to applications for any hardware that already supports orthogonal Tiled Resource Tier 3.

Meta-commands - A Meta-command is Direct3D12 object that represents an IHV-accelerated algorithm. It’s an opaque reference to a command generator implemented by the driver. Meta-command updates include Descriptor Table Binding and Texture binding. See D3D12DDI_META_COMMAND_PARAMETER_TYPE and D3D12DDIARG_META_COMMAND_PARAMETER_DESC.

Enable Compute Algorithms to use Texture Resources (swizzled memory)

Enable Graphics Pipeline Algorithms

HDR Brightness Compensation - A new SDR brightness boost was introduced to raise the reference white of SDR content to the user-desired value, allowing SDR content to be reproduced to a typical 200-240 nits, which is equivalent to what users have expected for SDR displays. SDR brightness boost affects overall Brightness3 behavior in two ways:

This boost is applied pre-blend only on SDR content. HDR content is not affected. Meanwhile, for most laptop/brightness3 scenarios, users expect all content (SDR and HDR) to be adjusted.

When the Brightness3 stack in the OS is determines the desired nits value, it is not aware of the already applied SDR boost. The driver must then apply a compensation to the desired nits value coming from Brightness3 DDIs for HDR. Since Graphics drivers (and downstream TCON etc.) will be modifying the pixel values of the content to get desired nits value, there should also be a compensation applied to the HDR content metadata as provided by the applications via D3DDDI_HDR_METADATA_HDR10 or OS defaults via DxgkDdiSetTargetAdjustedColorimetry. Since Graphics driver (TCONs) are responsible for modifying the pixel data, it is the driver’s responsibility to compensate the HDR content metadata.

HDR Pixel Format Support - This kernel mode device driver interface (DDI) change is part of WDDM 2.5 to expose new capabilities to be reported by driver/device, providing information regarding the HDR functionality supported by the driver/device. Currently, OS determines if the driver/device supports HDR based on the HighColorSpace bit of the DXGK_MONITORLINKINFO_CAPABILITIES structure as read from DdiUpdateMonitorLinkInfo. The HighColorSpace bit gives a combination of driver/link/monitor capability to run in HDR mode. The HDR capabilities reporting by the driver now includes a Driver/Device level capabilities, which will let OS know if the Driver/Device supports true HDR (i.e. FP16HDR), or only supports a limited form of HDR (i.e. ARGB10HDR), as defined below:

ARGB10HDR: Driver/device can take ARGB10 pixel format surfaces which are already PQ/2084 encoded and scan out HDR10 signal. Driver/device can’t handle FP16HDR as defined above or cannot handle the extended numeric range of scRGB FP16. Graphics drivers can only report support for either FP16HDR or ARGB10HDR as they are not really superset/subset configurations and OS will fail the Start Adapter if both are reported as supported at the same time. See DXGK_MONITORLINKINFO_CAPABILITIES and _DXGK_DISPLAY_DRIVERCAPS_EXTENSION.

SDR White Level - A kernel mode device driver interface change includes adding new parameters to existing DDIs to let the Graphics drivers know the “SDR white level” value that is being applied by the OS compositor for all the SDR content, for a display which is running in HDR mode. See _DXGK_COLORIMETRY.