Fixes: 010008f6
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56615

This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT,
with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option
enabled, which also improves performance with the game by itself.

Grounded generally makes about 4000 draw calls per frame, which seems not
atypical. This change makes it submit at most an extra 8 times per frame, but in
practice due to WINED3D_PERIODIC_SUBMIT_MAX_BUFFERS it submits less (usually
only 2-3).

The most demanding game I've seen made about 20,000 draw calls per frame, at
which point the overhead of adapter_vk_draw_primitive() itself becomes a serious
bottleneck. For such a game we would submit 40 more times per frame with these
settings, although WINED3D_PERIODIC_SUBMIT_MAX_BUFFERS means we would likely
submit less than that. In any case if submission itself becomes a bottleneck, we
should offload it to a separate thread.

Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that
periodic submission might make a difference.

Part of beginning a render pass involves executing an RTV barrier, which itself
needs to call wined3d_context_vk_get_command_buffer(). However, that function
may decide to submit the command buffer, in order to prevent resource buildup,
or [in the future] because it has been some length of time since the last
submission.

Therefore we cannot retrieve and store a VkCommandBuffer pointer before
executing an RTV barrier and then use it later.

Those parameters are not supported on multisample textures in the
first place (basically, GL mandates ARB_sampler_objects for those).

The combination COND_NP2 + ARB_texture_multisample is not expected to
happen without wined3d configuration overrides.

In the same vein as e106bbdd.

Which is really what it means nowadays: resources created by the
CS. It has mostly implications WRT thread safety.

In particular, the flag doesn't mean that the resource doesn't
participate in memory accounting (that was split into
WINED3DUSAGE_VIDMEM_ACCOUNTING by
723cd0a4), nor that it isn't checked
for Reset purposes (we use parent == NULL for that).

Note that this won't compile very many shaders until vkd3d-shader's GLSL
support is much more complete.

Much like we do for e.g. shader_glsl_generate_vertex_shader().

Also allowing r500's "normalized texrect" functionality. Keeping
WINED3D_GL_NORMALIZED_TEXRECT is far less invasive and painful than the
rest of the NP2 fixup code.

Do not remove the shader_backend setting entirely; it will eventually be useful for selecting the SPIR-V backend for GL.

FBOs are required now.

This can happen legitimately if the sampler access was optimized out.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56438

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56445

wined3d: Do not check the input signature element count for sm4+ shaders in shader_spirv_compile_arguments_init().

Shader model 4 fragment shaders can have more than 12 input varyings. That's
fine though, because we don't need to build a varying map for them in the
first place. Note that in principle the ERR in question could still be
triggered by e.g. attempting to use a shader model 4 fragment shader with a
shader model 3 vertex shader.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44514Signed-off-by: Andrew Wesie <awesie@gmail.com>

Following shader_apply_draw_state.

We're not necessarily compiling DXBC shaders here after commit
1474f5cc.

nvrc_update_color_op() takes care of this. Redirect WINED3D_TSS_RESULT_ARG to nvrc_colorop() so that the shader is invalidated.

nvrc_update_color_op() takes care of this. Redirect STATE_SAMPLER to nvrc_colorop() so that the shader is invalidated.