Unity 2019 DX12 and CommandBuffer.DrawProceduralIndirect= not works in standalone

Unity Engine
1

I play with Marching Cubes algorithm (using compute shader), which works well with Unity 2018.4.29f1 (in both editor mode and standalone executable). After upgrade to Unity 2019.4.17f1, in DX12 mode, it works correctly in editor mode, but not in standalone mode, there is an error “d3d12: upload buffer was full! Waited for COPY queue…”.

GfxDevice: creating device client; threaded=1
d3d12: loaded!
Direct3D:
    Version:         Direct3D 12 [level 12.1]
    Renderer:        NVIDIA GeForce RTX 2070 (ID=0x1f02)
    Vendor:         
    VRAM:            8031 MB
    App VRAM Budget: 6826 MB
    Driver:          27.21.14.6079
d3d12: Profiler is enabled, but stable power state is not. GPU timing errors are expected.
(Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d12/GfxDeviceD3D12.cpp Line: 529)

Begin MonoManager ReloadAssembly
- Completed reload, in  0.107 seconds
D3D11 device created for Microsoft Media Foundation video decoding.
<RI> Initializing input.

<RI> Input initialized.

<RI> Initialized touch support.

d3d12: upload buffer was full! Waited for COPY queue for 1.406 ms.
d3d12: upload buffer was full! Waited for COPY queue for 1.402 ms.
UnloadTime: 0.710100 ms
d3d12: CreateGraphicsPipelineState failed.
(Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d12/GfxDeviceD3D12.cpp Line: 1156)

Error disappears when I comment this line of code, which is required to visualise procedural triangle mesh:

_CommandBuffer.DrawProceduralIndirect(Matrix4x4.identity, _Material, 0, MeshTopology.Triangles, _IndirectBuffer);

It is Unity bug or I have to initialize/use append/indirect buffers under DX12 in different way ? But why it works in editor, and not in standalone. Also I tried with turned on/off graphics jobs option, without success.

2

The same situation is under DX12 with Unity 2020.2.1f1, also with different GPU (project works properly in editor mode, errors only in Windows Standalone x64).

GfxDevice: creating device client; threaded=1
d3d12: loaded!
Direct3D:
    Version:         Direct3D 12 [level 12.1]
    Renderer:        NVIDIA GeForce GTX 1660 SUPER (ID=0x21c4)
    Vendor:         
    VRAM:            5991 MB
    App VRAM Budget: 5223 MB
    Driver:          26.21.14.4614
d3d12: Profiler is enabled, but stable power state is not. GPU timing errors are expected.

Begin MonoManager ReloadAssembly
- Completed reload, in  0.069 seconds
D3D11 device created for Microsoft Media Foundation video decoding.
<RI> Initializing input.

<RI> Input initialized.

<RI> Initialized touch support.

UnloadTime: 0.720800 ms
d3d12: CreateGraphicsPipelineState failed.

Does somebody had similar problems ?

3
4

Thank you for reporting this bug.
Just so you know the “d3d12: upload buffer was full!” message does not mean there was an error, only the failed pipeline state is an actual error. We will investigate this.

2 Likes
5

Thanks for info ! In this case, DirectX 12 support in Windows Standalone is very important to me, due to raytracing support. I made tech demo where player can sculpt 3D shapes. In “Sculpt Mode” player uses a sphere as virtual brush to create or remove fragments of geometry. In this mode (Image 1), shape is visualised as wireframe with normal vectors debugging (via _CommandBuffer.DrawProceduralIndirect). In every moment player can finish sculpting, then press a key, to apply and create static gameobject with mesh collider. In DX12 Standalone, sculpt mode is invisible (all images I taken from Editor). To increase rendering quality, I added raytraced global illumination support via Unity RayTracingShader and RayTracingAccelerationStructure classes and custom DXR shaders (I don’t use HDRP). Comparison: image 2 (with raytracing enabled), image 3 (raytracing disabled).

6728401--774400--upload_2021-1-15_15-58-23.png
6728401--774400--upload_2021-1-15_15-58-23.png1275×717 1.37 MB

6728401--774403--upload_2021-1-15_15-58-39.png
6728401--774403--upload_2021-1-15_15-58-39.png1275×716 1.25 MB

6728401--774406--upload_2021-1-15_15-59-2.png
6728401--774406--upload_2021-1-15_15-59-2.png1276×718 1.13 MB

1 Like
6

I had a look at the bug and there was a comment not sent out to you:

In the MarchingCubes.shader
void VSMain(inout float4 vertex : POSITION,
Declaring the vertex inout means that the input layout ought to include vertex data, which is incorrect for null geometry drawcalls. The shader doesn’t require the vertex input, so changing the declaration to:
void VSMain(out float4 vertex : POSITION,

will fix the issue.

This combined with some code that fixes up the declaration internally in the editor makes this fail only on stand alone. I think the code will be fixed but now you can work around it at least.

1 Like