These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v7: kernelbase: Check for PERF_SIZE_DWORD and PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
As @nsivov pointed out, we are currently parsing matrix swizzles (e.g. mat._m12_m32) and creating an hlsl_ir_swizzle for the matrix itself. We are currently allowing shaders that use these to compile even though they are not working.
While our compilation passes don't expect hlsl_ir_swizzles with matrix values, turns out we need them as a parse-time construct because we don't know if they will be used as the lhs of an assignment during parsing, similarly to hlsl_ir_indexes.
This patch adds tests and a pass to lower these matrix swizzles.
Implementing assignments with matrix swizzles is still pending.
--
v2: vkd3d-shader/hlsl: Lower matrix swizzles.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/331
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v8: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Skip DCL semantic tokens properly.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v6: kernelbase: Check for PERF_SIZE_DWORD and PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
kernelbase : Check for PERF_ATTRIB_BY_REFERENCE attribute in PerfSetCounterRefValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v4: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v5: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v3: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
---
With past patches these two tests seem to pass reliably in the gitlab CI
environment:
https://gitlab.winehq.org/stefan/wine/-/merge_requests/8/pipelines
They passed in 5 out of 5 pipeline runs (and hopefully a 6th time in this
MR submission). Other tests failed though, so some of those pipeline runs
are marked as failures.
d3d9:d3d9ex still fails randomly on fvwm2/3 but passes on openbox.
d3d9:visual works on Mesa 21 and 23, but not Mesa 22. I'll look into these
tests in the next few weeks. I don't yet know why d3d8:visual is disabled.
I haven't looked at d3d10/11 at all yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3802
Based on a finding here: https://github.com/ValveSoftware/Proton/issues/6709#issuecomment-1626059391
On Windows, small (or 0) receive buffer works a bit differently when async IO is concerned. It is supposed to bypass some system buffering and receive the data directly to the user buffer if async receive is pending. So the apps may be using 0 buffer size as a small optimization to skip extra buffer copies in the system. On Unix, if the buffer is too small to receive the network packet the packet will just be dropped. As I interpret my tests though, Windows doesn't actually drop the packets with async socket even if there is no receive currently pending (looking like setting smaller buffer have no effect at all).
This behaves differently with synchronous IO, Windows can also drop packets which don't fit the smaller set buffer in this case.
I think that we can just never set receive buffers smaller than the default one on Unix sockets. The only effect of actually setting that which I can think of is that the system starts dropping packets more eagerly. Which is wrong for async socket I/O case. That might be not so wrong for sync socket I/O case, but implementing that specific to I/O type will add a lot of complication and will only lead that we will dropping packets more eagerly. While we are probably still won't be doing it exactly like on Windows as it depends on multiple factors in Unix and Windows network stack.
--
v2: server: Don't set SO_RCVBUF below Windows default value on Unix socket.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3705
This patch set is part of !3303
--
v4: winegstreamer: Create wg_muxer for media sink.
winegstreamer: Implement seeking query for wg_muxer sink pad.
winegstreamer: Introduce new wg_muxer struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3737
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v2: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
advapi32: Forward PerfSetULongCounterValue and PerfSetULongLongCounterValue to kernelbase
kernelbase: Add implementation of PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
--
v2: mshtml: Get rid of the custom qi for CSS Styles.
mshtml: Forward objects' IUnknown methods to the DispatchEx.
mshtml: Get rid of `outer` in DispatchEx.
mshtml: Use query_interface in the dispex vtbl for PerformanceTiming.
mshtml: Use query_interface in the dispex vtbl for PerformanceNavigation.
mshtml: Use query_interface in the dispex vtbl for Performance.
mshtml: Use query_interface in the dispex vtbl for MediaQueryList.
mshtml: Use query_interface in the dispex vtbl for Console.
mshtml: Use query_interface in the dispex vtbl for Navigator.
mshtml: Use query_interface in the dispex vtbl for History.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3796
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v7: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Ignore DCL source parameters.
vkd3d-shader/ir: Simplify the control flow in shader_instruction_normalise_io_params().
vkd3d-shader/ir: Fully reinitialize an instruction when making it a NOP.
vkd3d-shader: Rename shader_instruction_init().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317