The || and && operators to chain commands rely on the LHS command
to be successful (or unsucessful) to decide upon launching the RHS
command.
Unfortunately, success/failure is not always when errorlevel is
0 (non zero).
Some exmaples:
- if a redirection fails (eg. appending to a non existing file),
the command (builtin/external) is always unsuccessful (and the
error level is untouched,
- external command (when redirection is ok) is succesful when
program exit code is zero,
- ditto for a call to a label inside the batch file, with
the 'exit /b' parameter,
- it's way more complicated for builtins. Eg 'type' is unsuccessful
on a non existing file, while 'dir' (on the same unexisting file)
succeeds.
So start adding some tests about success / failure of some commands.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
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.
This fixes the following C++ compiler error
mfmediaengine.h:1216:18: error: expected ',' or '...' before 'protected'
1216 | BOOL *protected) = 0;
| ^~~~~~~~~
After commit 898ab8dab1 wine would no longer
build on musl.
Issue is that apparently TCSETS2 isn't defined when including sys/ioctl.h.
A little digging shows that glibc goes ahead and includes asm/ioctls.h in
sys/ioctl.h, providing said macro. Musl on the other hand doesn't and relies
on bits/ioctl.h, which lacks said macro.
Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
