You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4e8881a
Browse filesBrowse the repository at this point in the historyBrowse files
Direct3D: allocations during play counted, and none left but the shaders made ahead
tools/rend/d3d_allocs.sh runs the test discs under d3d_hdr with Direct3D
11 and 12, each renderer, threaded rendering on and off, counting from
frame 20 on the core's heap - what it imports for it pointed at
tools/rend/alloc_count.c's Windows half, the C++ runtime linked into it
included - and the Direct3D objects it makes through the device's
methods, named by the build's symbol table, against
tools/rend/d3d_allocs.allowed. In CI.
A render read back takes its room from one readback buffer (12) or one
staging picture (11), a ring made with the renderer: nothing is made in
the fault handler. A texture's name for the log is written into the
caller's room. The thread that makes shaders and pipelines ahead is
started with the renderer and parks on an eventcount, not started for
each batch. Direct3D 11's shader sources are put together once, and what
it compiles is kept as the compiler's blob in a fixed map. The texture
pool has render targets four times as long as they are wide, to 256.
Left on the list: a polygon's own Direct3D 11 pixel shader, made on that
thread when a frame first wants it.
d3d_warm_test, dx11_shaders_ahead_test and dx12_pipelines_ahead_test run
in CI, the last two brought up to the renderers as they are; Direct3D
12's on wine's own vkd3d, with its virtual heaps.
0 commit comments