The main thread still waits for the worker thread, in order to keep
buffer resizing synchronized with presentation. As soon as buffer
presentation is offloaded to the worker thread too the wait can be
dropped.
In the following commits the worker thread will be used for actual
presenting and buffer resizing. In this way the worker thread can
wait on the vkd3d queue without blocking or even deadlocking the
application.
This is to eventually allow d3d12_swapchain_queue_present() to
operate on a certain VkImage even if current_buffer_index has
already been modified since the corresponding Present() call.
This is an oversight in eec9c3a2f6:
vk_format specifies the format used for the frontend resources. The backend
images could use a different format, depending on what the swapchain
supports.
Also, introduce the terms "frontend" and "backend" for the two sides
of the swapchain, which are probably easier to understand.
Instead of using wined3d_texture_update_desc(). This is safe, because:
* ddraw never exposes wined3d textures directly, and always retrieves them
directly from wined3d when rendering.
* d3d8 and d3d9 (non-extended) will only resize buffers during a reset, and
resetting is forbidden if the application holds any references to the
backbuffers. RTVs are also replaced during a reset, so there is no concern
about retrieving the old RTVs from the device state.
* d3d9ex allows resetting while holding references to the backbuffers, but tests
(fixed by this patch) show that the backbuffers should in fact be recreated.
* dxgi forbids holding references to back buffers during ResizeBuffers(),
including indirect references via command lists or device contexts.
This swapchain is never actually exposed, and effectively only exists due to
implementation constraints. When it was introduced, it was necessary or simplest
to create a dxgi swapchain object, but currently that's no longer necessary, and
avoiding that allows some code to be simplified.
Instead of having d3d11 create the wined3d texture, create it in dxgi instead,
and let d3d11 create a d3d_texture2d object to wrap it.
This is a step towards getting rid of the create_swapchain_texture() callback,
which is mildly difficult to work with and conceptually complex.
From the tests it behaves more like a semaphore than like an event.
I'm not testing explicitly because I'm not sure it's relevant, but
another indication is that calling ReleaseSemaphore() returns
ERROR_ACCESS_DENIED, while calling SetEvent() returns
ERROR_INVALID_HANDLE.
I am still deliberately not testing after which message the swapchain
state changes from the old state to the new until we find a game that
depends on this.
ddraw, d3d8 and d3d9 do not catch recursive SetDisplayMode or Reset()
calls. They will recurse for about 16 times and then return library
specific weird return values like 0xd0000510 (NTSTATUS, but
nonexistent facility) or 0x88760868 (non-existent HRESULT facility). I
suspect it aborts when the kernel-side message processing stack is
exhausted. As such, an application depending on nested calls in those
libraries would have to deliberately do it, but limit the amount of
nesting to a non-zero amount.
