Buffers could be used with 'shared' and 'single' modifiers. There is a bit more work left to do to support this - 'shared' needs a compiler flag to enable child effects to be useful, and 'single' is not a keyword.
--
v2: vkd3d-shader/hlsl: Allow modifiers on buffer declarations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/666
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 20 fps (renders correctly)
Unigine Heaven (OpenGL): ~17 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (renders correctly)
BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly)
Massive step up from getting 2 fps across many wined3d games, but it's still pretty bad, and sometimes runs worse than the original code
Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range.
--
v6: opengl32: speed up wow64 mapping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 3 fps to 40 fps (renders correctly)
Unigine Heaven (OpenGL): ~17 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (renders correctly)
BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly)
These numbers are from my memory, I will update them with the more accurate numbers when I get home.
Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range.
--
v5: opengl32: speed up wow64 mapping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 3 fps to 40 fps (renders correctly)
Unigine Heaven (OpenGL): ~17 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (broken intro videos, ingame rendering looks correct, old mapping code works just fine in the intro videos)
BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly)
These numbers are from my memory, I will update them with the more accurate numbers when I get home.
Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range.
--
v3: opengl32: speed up wow64 mapping
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 3 fps to 40 fps (renders correctly)
Unigine Heaven (OpenGL): ~17 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (broken intro videos, ingame rendering looks correct, old mapping code works just fine in the intro videos)
BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly)
These numbers are from my memory, I will update them with the more accurate numbers when I get home.
Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range.
--
v2: opengl32: speed up wow64 mapping
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 3 fps to 40 fps (renders correctly)
Unigine Heaven (OpenGL): ~17 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (broken intro videos, ingame rendering looks correct, old mapping code works just fine in the intro videos)
These numbers are from my memory, I will update them with the more accurate numbers when I get home.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
~~This applies on top of !656, the last three commits belong here.~~
--
v8: vkd3d-shader/ir: Sort each loop by block label.
vkd3d-shader/ir: Dump the loops in the control flow graph.
vkd3d-shader/ir: Keep track of loops by header block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
This was implemented in vkd3d 1.10. Another known feature that has to be enabled with compatibility flag is d3d9 style sampling functions. We currently don't do that, making them supported unconditionally.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5146
Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
v3: tests: Get detailed information on failing tests.
tests: Copy autotool's testsuite driver script.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
On Fri Feb 23 13:38:55 2024 +0000, Conor McCarthy wrote:
> Indeed it's a bit fragile. It could instead copy up to four components
> to the temp, if available, just in case, but I don't like the idea of
> doing that each time a scalar is loaded. It's pretty spammy in SPIR-V
> code, and the temp is often used for other purposes later, where the
> written values could still be floating around if not overwritten. That's
> unlikely to interfere with optimisation, but I'm not sure.
It's a fair concern. Although if it only matters for clip/cull—not even stores, but *loads*—maybe we don't need to worry about optimization anyway? I'd be (naïvely) surprised if those are frequent.
Longer term we should think about storing this information in a friendlier format at parse time...
I would at least advocate for not using an empty default: case like that; vsir is awfully extensible and we should have a FIXME for unhandled instructions.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564#note_62432
Wine currently runs all processes with an elevated administrator token. As
described in bug 40613, some applications refuse to be run with such a token.
This patch set addresses the situation by creating all processes with an
unelevated adminstrator token by default. When a process attempts to elevate
itself through one of several mechanisms—which would show a UAC prompt on
Windows—we instead silently elevate the process, as if the user had granted
access through the UAC prompt.
This works for almost all applications. I have found only one application which
didn't get the memo, and actually asks the user to right click and run as
administrator, namely PaintTool SAI. Fortunately, 063a377df4f, combined with the
shell32 patch in this series, allows a Wine user to elevate that process by
opening explorer.exe, right-clicking, and selecting Run as Administrator, just
like on Windows.
This patch series has been in Wine-Staging for about three years. This was
partly to try to find and fix all the different creative ways that applications
tried to elevate themselves, but mostly because I needed to find a solution for
PaintTool SAI, and never quite got the time to implement run-as-administrator in
shell32.
--
v2: server: Create processes using a limited administrator token by default.
winetest: Elevate test processes on Wine.
ntdll: Always start the initial process through start.exe.
ntdll: Elevate processes if requested in RtlCreateUserProcess().
kernelbase: Elevate processes if requested in CreateProcessInternal().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5118
~~This applies on top of !656, the last three commits belong here.~~
--
v7: vkd3d-shader/ir: Sort each loop by block label.
vkd3d-shader/ir: Dump the loops in the control flow graph.
vkd3d-shader/ir: Keep track of loops by header block.
vkd3d-shader/ir: Keep a reference to the parser inside struct vsir_cfg.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
On Thu Feb 22 14:13:20 2024 +0000, Giovanni Mascellani wrote:
> Can this happen? Unless I'm missing something, it seems that for domain
> shaders `normaliser_signature_transform_clip_cull()` is never called, so
> `has_normalised_clip_cull` is never set and the normaliser returns
> before reaching here.
I moved it to the next commit, where `normaliser_signature_transform_clip_cull()` is called on other signatures.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564#note_62426
--
v17: tests/d3d12: Test multiple clip distance inputs in test_clip_distance().
tests/d3d12: Use five clip distances for the multiple test in test_clip_distance().
vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays.
vkd3d-shader/ir: Transform clip/cull inputs into an array.
vkd3d-shader/spirv: Support no-op signature elements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564
~~This applies on top of !656, the last three commits belong here.~~
--
v6: vkd3d-shader/ir: Sort each loop by block label.
vkd3d-shader/ir: Dump the loops in the control flow graph.
vkd3d-shader/ir: Keep track of loops by header block.
vkd3d-shader/ir: Keep a reference to the parser inside struct vsir_cfg.
vkd3d-shader/ir: Compute the loops in the control flow graph.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
Create a bandtrack for MIDI files by picking out the MIDI 0xCn events, and creating matching DMUS_PATCH_PMSG.
* * *
This also has a commit adding a stub chordtrack, which is small so I think a separate MR is unwarranted. Can be split out if necessary.
--
v2: dmime: Add a stub chordtrack for MIDI segments.
dmime: Parse MIDI program change events and generate a bandtrack.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5141
Buffers could be used with 'shared' and 'single' modifiers. There is a bit more work left to do to support this - 'shared' needs a compiler flag to enable child effects to be useful, and 'single' is not a keyword.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/666
Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
v2: tests: Get detailed information on failing tests.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
This applies on top of !656, the last three commits belong here.
--
v5: vkd3d-shader/ir: Sort each loop by block label.
vkd3d-shader/ir: Dump the loops in the control flow graph.
vkd3d-shader/ir: Keep track of loops by header block.
vkd3d-shader/ir: Compute the loops in the control flow graph.
vkd3d-shader/ir: Introduce a helper to express block domination.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
This applies on top of !662, the last four commits belong here.
Here we compute a topological order (plus some additional properties) of the shader blocks. Eventually the blocks will be emitted precisely in this order, after having been enriched with structured control flow information.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/672
This applies on top of !656, the last three commits belong here.
--
v4: vkd3d-shader/ir: Compute the loops in the control flow graph.
vkd3d-shader/ir: Add a debug buffer to struct vsir_cfg.
vkd3d-shader/ir: Properly handle function-local indexable temps when flattening control flow.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
As per discussion in 606, plumbing constant buffer reflection through
vkd3d-shader requires interface design and API documentation for an interface
which is inherently quite specific to one format. Instead of wasting time on
this interface, just implement RDEF parsing in vkd3d-utils itself. If we change
our mind about this, we can always move the implementation to vkd3d-shader
anyway.
This does not copy the existing implementation from Wine, because:
* Wine does not validate offsets; adding this changes the parsing code
significantly;
* Wine incorrectly handles types, deduplicating them into an rbtree;
* Wine skips several fields which I have been able to find the purpose of.
The implementation is not that complex to begin with, so reimplementing it from
scratch is not much work.
--
v5: tests: Add more tests for resource and struct RDEF contents.
tests: Test constant and resource reflection via D3DReflect().
vkd3d-shader/tpf: Set the user-packed flag for sm5.0 resources as well.
vkd3d-shader/tpf: Write the component count as the column count for structs.
vkd3d-shader/tpf: Explicitly write the class and base type for non-numeric types.
vkd3d-shader/tpf: Do not write structs with no numeric fields into the RDEF.
vkd3d-shader/hlsl: Allocate register reservations for structs as well.
vkd3d-shader/tpf: Do not write non-numeric struct fields into the RDEF.
vkd3d-utils: Implement ID3D12ShaderReflectionType::GetMemberTypeByIndex().
vkd3d-utils: Implement ID3D12ShaderReflectionVariable::GetType().
vkd3d-utils: Implement ID3D12ShaderReflectionConstantBuffer::GetVariableByIndex().
vkd3d-utils: Parse the RD11 section.
vkd3d-utils: Implement ID3D12ShaderReflection::GetConstantBufferByIndex().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/626
--
v6: vkd3d-shader/dxil: Implement DX intrinsic GetDimensions.
vkd3d-shader/dxil: Move the resource kind helper functions up.
vkd3d-shader/spirv: Introduce a sample info flag value for a scalar uint dst parameter.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/629
This first MR create an internal structured representation of the CFG and computes the domination relationship. Over a few other MRs I will implement an algorithm inspired to [this article](https://medium.com/leaningtech/solving-the-structured-control-flow… to compute a better structure than the one we already have, but for the moment the computed data is immediately wasted. A working prototype of the new structurizer is now available in https://gitlab.winehq.org/giomasce/vkd3d/-/commits/cfg4, though further improvement is planned on top of that too.
--
v7: vkd3d-shader/ir: Dump the domination relationship.
vkd3d-shader/ir: Compute the domination relationship.
vkd3d-shader/ir: Dump the control flow graph in the GraphViz format.
vkd3d-shader/ir: Build a representation of the control flow graph.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/656
--
v10: vkd3d-shader/dxil: Implement DX intrinsic RawBufferStore.
vkd3d-shader/dxil: Handle raw and structured buffers in sm6_parser_emit_dx_buffer_store().
vkd3d-shader/dxil: Implement DX intrinsic BufferStore.
tests/shader-runner: Add a test for a signed int structured buffer UAV.
tests/shader-runner: Add a test for a signed int typed buffer UAV.
tests/shader-runner: Support structured buffer UAVs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/642
Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
--
v16: tests/d3d12: Test multiple clip distance inputs in test_clip_distance().
tests/d3d12: Use five clip distances for the multiple test in test_clip_distance().
vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays.
vkd3d-shader/ir: Transform clip/cull inputs into an array.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564
On Wed Feb 21 23:31:56 2024 +0000, Alex Henrie wrote:
> At Nikolay's suggestion, I have pushed a new version that puts
> `debugstr_time` in wine/strmbase.h and does not rename it.
This does not touch media foundation modules, except for evr which is usable in both systems. So I'm going to unassign myself.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4461#note_62272
--
v15: tests/d3d12: Test multiple clip distance inputs in test_clip_distance().
tests/d3d12: Use five clip distances for the multiple test in test_clip_distance().
vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays.
vkd3d-shader/ir: Transform clip/cull inputs into an array.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564
This applies on top of !656, the last three commits belong here.
--
v2: vkd3d-shader/ir: Compute the loops in the control flow graph.
vkd3d-shader/ir: Add a debug buffer to struct vsir_cfg.
vkd3d-shader/ir: Properly handle function-local indexable temps when flattening control flow.
vkd3d-shader/ir: Dump the domination relationship.
vkd3d-shader/ir: Compute the domination relationship.
vkd3d-shader/ir: Dump the control flow graph in the GraphViz format.
vkd3d-shader/ir: Build a representation of the control flow graph.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
Add a dummy track parser, that reads through MIDI tracks and events. To make sure we understand the file structure correctly, no actual tracks or events are generated.
Also add test cases to make sure we read through a MIDI file correctly.
This is skeleton of the actual MIDI parser. Pending on the merge of !4982
--
v19: dmime/tests: Improve error reporting from expect_track.
dmime: Read through a MIDI file.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5081