The following table shows how each intrinsic maps to d3d assembly and the
flags that appear in the tpf bytecode, in binary.
GroupMemoryBarrier() sync_g 0010
GroupMemoryBarrierWithGroupSync() sync_g_t 0011
DeviceMemoryBarrier() sync_uglobal 1000
DeviceMemoryBarrierWithGroupSync() sync_uglobal_t 1001
AllMemoryBarrier() sync_uglobal_g 1010
AllMemoryBarrierWithGroupSync() sync_uglobal_g_t 1011
The idea is that sm6_value and related structures should not commit
to a specific vsir register representation yet, because at the time
they are created some information might be still unavailable. For
instance, it might be not yet known whether the program is using
native 16-bit types or minimum precision types. vsir registers
should only be synthesized during instruction emission.
Field "reg" in struct sm6_value will be handled in a later commit.
Commit 02fe9f5bdf introduced linking the
Windows build of the demos with d3d12 and dxgi, while also still linking
to libvkd3d-utils.la. That happens to more or less work on Wine; we get
vkd3d-utils' D3D12CreateDevice(), and Wine's
IDXGIFactory2_CreateSwapChainForHwnd(), but because Wine's
implementation of d3d12 swapchains uses vkd3d, we're able to use the
resulting swapchain buffers even though the instance of vkd3d used by
Wine may not be the same instance of vkd3d used by the demos. Perhaps
unsurprisingly, things don't go nearly as well on Windows.
We could of course stop linking the demos to vkd3d-utils on Windows, but
that's not that interesting; we're trying to show what vkd3d can do
here, not what d3d12 can do.
Much like we did for demo_xcb.h, demo_win32.h now just has the bits for
creating windows and handling events, while demo_d3d12.h has the d3d12
and dxgi bits.
For the build-mingw-32 and build-mingw-64 jobs. These currently end up
picking up Linux pkg-config instead of MinGW pkg-config, which in turn
causes configure to pick up Linux OpenGL and XCB. We happen to get away
with that at the moment because none of the code using HAVE_OPENGL or
HAVE_XCB ends up getting built for Windows, but that's about to change.
Specifically, we'd like to build the vkd3d versions of the demos for
Windows.
All stream output objects need to have a stream index allocated,
whether they are used or not.
We allocate stream outputs here, before other objects are allocated,
because the stream index is needed to create the appropriate output
semantic variables during append_output_copy(), which will be called
in a lowering pass for the Append() method.
