MOOR security

Dieser Eintrag ist auf Englisch verfasst.

Typed UAV loads, and three bgfx differences that were bgfx's

Entry 037771 of 906 tests pass

The layer now lets shaders read and write the same texture in 18 common formats. The last three bgfx examples that differed from bgfx's native Metal renderer turned out to differ because bgfx treats a missing vertex attribute differently on each backend.

What changed

A UAV (unordered access view: a texture or buffer that a shader may both read and write) could only be read back in the three 32-bit single-channel formats. D3D12 has an optional feature, TypedUAVLoadAdditionalFormats, that extends this to a fixed set of 18 formats: four-channel and single-channel 32-, 16- and 8-bit formats, as float, uint and sint (unorm instead of float for the 8-bit ones). Metal's "read-write texture tier 2" covers exactly that list, and this Mac reports tier 2. The layer now reports the feature and the per-format UAV_TYPED_LOAD flag. A new api test, typed_uav_load, checks the capability bits and then does read-modify-write passes on textures and typed buffers in six formats (143 checks).

bgfx turns that flag into its "image read" capability. Its 21-deferred example stopped saying "UAV is not supported" and now offers a UAV path.

For GUI programs, whose stderr Wine loses, the Windows-side DLLs can now log to a file with MTL12_LOG_FILE.

Two renders of a field of hollow box frames over a grey checkered floor. Left, through D3D12: the frames are covered in a dark, mottled rock texture with bright speckles along their edges. Right, the native Metal reference: the frames are flat, smooth dark teal.
45-bokeh with depth-of-field off, our D3D12 run (left, textured cubes) against bgfx's Metal renderer (right, flat cubes).
How bgfx's two backends fill the missing texture coordinate.hollowcube mesh: position, normal, colour → vertex shader reads a_texcoord0; vertex shader reads a_texcoord0 → bgfx renderer; bgfx renderer → input element TEXCOORD0: float2 at offset 0 (D3D12); input element TEXCOORD0: float2 at offset 0 → UV = position x, y: stone texture on the cubes; UV = position x, y: stone texture on the cubes → mtl12 draws what D3D12 asks for; bgfx renderer → fallback attribute: UChar2 at offset 0 (Metal); fallback attribute: UChar2 at offset 0 → integer UVs: one texel, flat cubes; integer UVs: one texel, flat cubes → the reference differs from the D3D12 imagehollowcube mesh:position, normal, colourvertex shaderreads a_texcoord0bgfx rendererinput element TEXCOORD0:float2 at offset 0UV = position x, y:stone texture on the cubesmtl12 draws whatD3D12 asks forfallback attribute:UChar2 at offset 0integer UVs:one texel, flat cubesthe reference differsfrom the D3D12 imageD3D12Metal
How bgfx's two backends fill the missing texture coordinate. (Mermaid source)
Gallery scene typeduav: typed UAV loads: a compute pass reads each texel of an R16_UINT UAV and writes it back advanced by its ring's speed (read-modify-write, TypedUAVLoadAdditionalFormats); the phase colours five colour wheels. All scenes in the gallery

The interesting part

Entry 036 left three bgfx examples (43-denoise, 44-sss, 45-bokeh) that differed from bgfx's own Metal renderer. 45-bokeh looked wrong everywhere: blurrier, and noisy in the blur. I read the translated Metal code of all four depth-of-field passes and found nothing. Then I turned the depth-of-field off in both builds. The plain forward pass already differed: our cubes had a stone texture, the Metal ones were flat.

The cube mesh has no texture coordinates, but the vertex shader reads them. bgfx does not treat that as an error, and each of its backends fills the gap in its own way. Its D3D12 backend adds an input element that reads a float2 at byte offset 0, which is the position, so the texture shows. Its Metal backend binds an 8-bit integer pair at offset 0, which samples one texel everywhere. bgfx's own screenshot of 45-bokeh, taken on D3D, shows textured cubes, as ours does. 43-denoise and 44-sss draw the same kinds of meshes with shaders that read texture coordinates too. So the Metal renderer is simply not a valid reference for these three, and they are now excluded with that reason. With that, every bgfx example is either compared and passing or excluded for a documented reason, and the bgfx feature is marked passing.

The lesson: before debugging the last pass of a pipeline, switch the post-processing off and compare what goes into it.

Numbers

  • Full run: 771 pass, 27 fail, 108 skip of 906; 0 newly failing, 1 newly passing (typed_uav_load) against entry 036.
  • typed_uav_load: 143 checks, 0 failed (same log).
  • apps suite: 76 of 76 pass, 46 of them bgfx examples (same log).
Tests by suite at the end of this entry: 771 of 906 pass (data as CSV)
  • pass
  • fail
  • skip

suite · share of each row's total

  1. vkd3d-proton455 pass, 18 fail, 104 skip of 577
  2. vkd3d177 pass, 9 fail, 4 skip of 190
  3. apps76 pass, 0 fail, 0 skip of 76
  4. api (+1)59 pass, 0 fail, 0 skip of 59
  5. samples4 pass, 0 fail, 0 skip of 4
Zur Eintragsliste