MOOR security

Dieser Eintrag ist auf Englisch verfasst.

Asking a device about itself: ID3D12DeviceConfiguration1

Entry 073869 of 963 tests pass

mtl12 devices and device factories now answer ID3D12DeviceConfiguration1, which reports how the device was set up and can pull a root signature out of a compiled shader library by name.

What changed

Direct3D 12's Agility SDK (the version of D3D12 that an application ships with itself) adds a small interface, ID3D12DeviceConfiguration1. Both a device and a device factory (an object that makes independent devices) hand it out. It does four things:

  • It reports the SDK version and any debug or experimental settings. mtl12 has none of those, so it reports zeros and SDK version 619.
  • It turns a root signature description into bytes. A root signature is the table that tells shaders where their buffers and textures come from.
  • It reads such bytes back.
  • It finds a root signature stored by name inside a DXIL library, a compiled bundle of shaders used for ray tracing.

The first three just call functions mtl12 already had. The fourth reuses the code that reads libraries for ray-tracing state objects. A helper on the Metal side of the layer already returned each named root signature as raw bytes. I split that reader out of the state-object code. The new method now takes the root signature with the requested name and wraps it in the container format the deserializer expects.

One device object, two interfaces, one reference count.one Device object: ID3D12Device15 (primary base), one reference count; application → ID3D12DeviceConfiguration1 (second base) (QueryInterface for the configuration IID); ID3D12DeviceConfiguration1 (second base) → ID3D12Device15 (primary base) (AddRef, Release, QueryInterface); ID3D12Device15 (primary base) → one reference countapplicationID3D12DeviceConfiguration1(second base)ID3D12Device15(primary base)one reference countone Device objectQueryInterface forthe configuration IIDAddRef, Release,QueryInterface
One device object, two interfaces, one reference count. (Mermaid source)
How a root signature is found by name in a DXIL library and read back.DXIL library bytes + subobject name, e.g. grs → MTL12_LIBRARY_INFO (unix side) reads the library's RDAT tables; MTL12_LIBRARY_INFO (unix side) reads the library's RDAT tables → entry points and subobjects each root signature as bare RTS0; entry points and subobjects each root signature as bare RTS0 → GLOBAL or LOCAL root signature with that name?; GLOBAL or LOCAL root signature with that name? → E_INVALIDARG (no); GLOBAL or LOCAL root signature with that name? → wrap RTS0 in a DXBC container (yes); wrap RTS0 in a DXBC container → D3D12CreateVersioned RootSignatureDeserializer; D3D12CreateVersioned RootSignatureDeserializer → deserializer: version 1.1, one UAV at u0, space 0DXIL library bytes+ subobject name, e.g. grsMTL12_LIBRARY_INFO (unix side)reads the library's RDAT tablesentry points and subobjectseach root signature as bare RTS0GLOBAL or LOCAL root signaturewith that name?E_INVALIDARGwrap RTS0 in a DXBC containerD3D12CreateVersionedRootSignatureDeserializerdeserializer: version 1.1,one UAV at u0, space 0noyes
How a root signature is found by name in a DXIL library and read back. (Mermaid source)

The interesting part

The new interface is not a new object. It is the same device seen through a second interface, in COM terms (COM is the Windows object model D3D12 is built on). Asking it for IUnknown must give back the device itself. A reference added through it must count on the device. vkd3d-proton's test checks this exactly: after releasing interfaces in turn, the counts have to come out as 2, 1 and 0.

In C++ this means a second base class, whose AddRef, Release and QueryInterface forward to the device's own. The layer already did this for one other object, its command queue. The first diagram shows the shape.

The mingw headers that the Windows side builds against don't declare ID3D12DeviceConfiguration1, so the layer declares it itself. Its interface ID comes from the vkd3d-proton tests.

Numbers

  • vkd3d-proton test_device_configuration: 6 failed checks before, 52 ok and 0 failed after.
  • The api test device_interfaces went from 52 to 63 checks.
  • Full run: 869 pass, 26 fail and 68 skip of 963. 1 test newly passes and none newly fail.
Tests by suite at the end of this entry: 869 of 963 pass (data as CSV)
  • pass
  • fail
  • skip

suite · share of each row's total

  1. vkd3d-proton (+1)499 pass, 13 fail, 65 skip of 577
  2. vkd3d178 pass, 9 fail, 3 skip of 190
  3. api92 pass, 0 fail, 0 skip of 92
  4. apps80 pass, 0 fail, 0 skip of 80
  5. wine-dxgi16 pass, 4 fail, 0 skip of 20
  6. samples4 pass, 0 fail, 0 skip of 4
Zur Eintragsliste