Overall this is simpler, results in less verbose SPIR-V code which is easier to debug, and eliminates stuttering issues in Horizon Zero Dawn when run in an SM 6 dev branch with Gio's cfg4 structuriser branch.
--
v3: vkd3d-shader/ir: Materialise SSAs to temps before lowering switch instructions.
vkd3d-shader/ir: Convert SSAs to temps only if the block of origin does not dominate all uses.
vkd3d-shader/spirv: Handle uint2 to double bitcast in spirv_compiler_emit_mov().
vkd3d-shader/spirv: Emit a uint result for RESINFO_UINT if the dst register is SSA.
vkd3d-shader/ir: Materialise phis to temps in the incoming blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/749
Overall this is simpler, results in less verbose SPIR-V code which is easier to debug, and eliminates stuttering issues in Horizon Zero Dawn when run in an SM 6 dev branch with Gio's cfg4 structuriser branch.
--
v2: vkd3d-shader/ir: Materialise SSAs to temps before lowering switch instructions.
vkd3d-shader/ir: Convert SSAs to temps only if the block of origin does not dominate all uses.
vkd3d-shader/spirv: Emit a uint result for RESINFO_UINT if the dst register is SSA.
vkd3d-shader/ir: Materialise phis to temps in the incoming blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/749
--
v2: vkd3d-shader/hlsl: Use LOGIC_AND instead of MUL in all().
vkd3d-shader/hlsl: Use LOGIC_OR instead of BIT_OR in any().
vkd3d-shader/ir: Add missing src swizzle in vsir_program_lower_texkills().
tests: Add failing test for clip.shader_test in SM1.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/744
--
v2: vkd3d-shader/spirv: Ensure the data register is UINT in spirv_compiler_emit_store_tgsm().
vkd3d-shader/spirv: Bitcast if necessary in spirv_compiler_emit_store_dst_components().
vkd3d-shader/dxil: Support constexpr GEP.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/750
HLSL_CLASS_OBJECT does not really have much in common, and a lot of code currently uses it assuming that all objects are resources, which is not actually true. Most users of HLSL_CLASS_OBJECT want to check for specific types, and so we can simplify code a fair amount by promoting all object "base types" to top-level classes.
This series is a first step, comprising some cleanup towards that goal.
--
v3: vkd3d-shader/hlsl: Use hlsl_is_numeric_type() in type_has_object_components().
vkd3d-shader/hlsl: Simplify type_has_object_components().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745
The Mesa version in Debian bookworm (22.3.6) we use for testing is now a bit outdated. While it's valuable to test on older drivers because they might be more representative of what users are running, it's also useful to test on recent drivers, which gives a less noisy signal to developers.
For the moment we enable it only for llvmpipe, because RADV is already passing all the tests anyway. And we don't bother with 32 bit here.
On llvmpipe using Mesa 24 fixes three shader runner tests.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/743
Overall this is simpler, results in less verbose SPIR-V code which is easier to debug, and eliminates stuttering issues in Horizon Zero Dawn when run in an SM 6 dev branch with Gio's cfg4 structuriser branch.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/749
vsir_program_normalise() has function calls to basically everything in
ir.c, so it's useful to have it in an easily reachable place to
quickly jump to wherever you need using your favorite code editor's
features.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/752
The BURIKO visual novel engine (as seen in, for example, https://store.steampowered.com/app/1200720/MakingLovers/) demands that the upstream filter tries to connect with a MPEG format type.
Then it memorizes the resolution, rejects the connection, and expects upstream to try RGB32 or RGB24 instead.
It also passes an empty string as filename, and demands this exact error code.
I have no idea why.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56491
--
v3: quartz: Fix memory leak on failure path.
tests/quartz: Test the new error codes.
quartz: Fix error code on empty filename.
tests/quartz: Test the new compressed output support.
quartz: Permit compressed output from CLSID_decodebin_parser.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5419
Type size_t is used in the file without importing any header which
defines it. This only works when the translation unit includes one of
the appropriate headers anyway or when the appropriate header is included
internally by other standard C headers; none of those strategies should
be relied upon.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/747
In substring expansion of variables, the length computation wasn't the same between:
- magic variables: length doesn't include terminating NUL
- regular variables: length does include terminating NUL
This led to incorrect substring operation for magic variables.
Always set length to not include terminating NUL. Took the opportunity to not
recompute length (as it's already computed by called functions).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5428
I'm working on adding all the intrinsics we haven't implemented yet. Here's sinh, cosh, and tanh.
Sinh/cosh are implemented in the same commit because they forward to the same backing function (because the identities used only differ by a plus or minus).
--
v2: vkd3d-shader/hlsl: Implement tanh.
vkd3d-shader/hlsl: Implement hyperbolic sin and cos.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/740
I'm working on adding all the intrinsics we haven't implemented yet. Here's sinh, cosh, and tanh.
Sinh/cosh are implemented in the same commit because they forward to the same backing function (because the identities used only differ by a plus or minus).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/740
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v12: handle command buffer differently
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
Adds the registry key
`HKEY_CURRENT_USER\\Software\\Wine\\Wayland Driver\\unaccelerated_pointer`
witch allows raw input. This makes it easier
to calculate the same sensitivity in different games,
use sensitivity calculators, and easily change values
when changing DPI and do not depend on the compositor or OS.
For example, you want to set the sensitivity to half as much,
and sensitivity curves in libinput are more difficult
to calculate than in the games themselves.
--
v6: winewayland.drv: Add unaccelerated pointer support
https://gitlab.winehq.org/wine/wine/-/merge_requests/4698
Francisco Casas (@fcasas) commented about libs/vkd3d-shader/hlsl.y:
> if (!(modifiers & HLSL_STORAGE_STATIC))
> var->storage_modifiers |= HLSL_STORAGE_UNIFORM;
>
> - if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM) &&
> - type_has_object_components(var->data_type, true))
> + if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM)
> + && var->data_type->class == HLSL_CLASS_STRUCT && type_has_object_components(var->data_type))
I think we would lose coverage for when we have an array of structs with object components.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745#note_66419
HLSL_CLASS_OBJECT does not really have much in common, and a lot of code currently uses it assuming that all objects are resources, which is not actually true. Most users of HLSL_CLASS_OBJECT want to check for specific types, and so we can simplify code a fair amount by promoting all object "base types" to top-level classes.
This series is a first step, comprising some cleanup towards that goal.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745
I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally.
As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata.
A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with.
Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators.
--
v4: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs.
vkd3d-shader/hlsl: Store state block on pass variables.
vkd3d-shader/hlsl: Parse list of state blocks.
vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant.
vkd3d-shader/hlsl: Parse and store state blocks on variables.
tests: Add tests for "compile" and CompileShader() syntax.
tests: Add tests for fxgroup syntax.
tests: Test function call syntax for state blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739
This is an attempt to invent a vkd3d-shader interface, and begin to implement
the relevant parts of ID3D12ShaderReflection in vkd3d-utils.
This series is missing most Doxygen documentation, mostly because I feel very
uncertain about this interface and don't want to put in the significant effort
to write documentation until I'm sure it's settled.
This series also has tests for bindings but not the implementation, mainly
because I didn't want to bother splitting those tests out to a separate patch
right now, and I see no harm in having them already there and marked todo...
Here is a long list of already open questions:
* As always, should anything be named differently?
* In particular, I've decided to give the variables names that make it clear
this is d3d-specific code. I think trying to make this generic enough to work
for other shader types is a fool's errand.
* Should we even try to use this interface for sm1? It's mostly already a
subset of dxbc; the only addition is the constant register set...
* Should we bother with interfaces? These count as "constant buffers", they have
a distinct type, and they have some extra data that we'd need to account for.
* Should we bother with lib_* targets? This mostly means allowing for a single
shader to hold multiple sets of reflection data. Note that this would also
affect descriptor info and STAT info, although not signature info.
* I've tried to pass through most data directly, partly out of a concern that
that's what d3dcompiler probably does, and so trying to interpret it could
break an extremely hypothetical and unlikely application. More saliently,
converting to a more sensible representation just to convert back is extra
work that I'm not really sure I see a point for.
But if we want to change the interface regardless, here are some ideas:
- enum vkd3d_shader_d3d_buffer_type could just be more flags.
- I think a buffer's size is redundant and can be calculated from its
contained variables.
Same for field offsets (unless packoffset affects this?)
- "constant_register" could be flags too? But we already have a type for them,
so I don't think that's better.
- The kind/type interface is weird in several ways. Majority could be a type
or var flag; objects could be classes...
* Fields of struct vkd3d_shader_d3d_type could be 16-bit (like they are in the
RDEF section). The main reason I didn't do this is because we can't force a
16-bit enum, although we could define the field as uint16_t. But we could also
just define the other "count" fields as 16-bit.
* I suspect I already know the answer to this one, but... If this is all going
to be d3d specific anyway... do we really care about having this in
vkd3d-shader?
Or, alternatively, we could provide an interface that's friendlier than COM,
but still use the d3d struct types instead of copy-pasting and changing all
the names to vkd3d-shader (which is a bit exhausting, honestly—not just
because of rewriting but because of documentation. The latter is certainly a
self-created problem, but so is the former.)
* vkd3d_shader_d3d_field currently has a hole in it on LP64; is that a problem?
(I think it's the only structure with a hole in it.)
* As long as this is a d3d interface, should we go ahead and make it
"scan_d3d_info" and add all the d3d-specific STAT block stuff?
One extra anticipatory note on how this differs from Wine's implementation:
This implementation does *not* store types in an rbtree, nor deduplicate them.
The main reason for this is that native doesn't deduplicate types (I have tests
for this, later in my local branch) and it avoids what seems like a significant
complication to the vkd3d-shader interface.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/606
Here is a preview of my shader cache work for early comments. It isn't complete, but does successfully cache things.
What's there:
* A new vkd3d API that is used internally for caching, can be used to implement the ID3D12ShaderCacheSession interface and hopefully be used by wined3d as well
* Simple saving and loading of the cached objects
* It is used to cache render passes, root signatures and pipeline states
What is not yet there
* Partial cache loading and eviction
* ID3D12ShaderCacheSession - largely because it needs bumping ID3D12Device up to version 9, which may bring unrelated regressions. For this and tests see my "cache-rework" branch (which
* Cache file compression
* Incremental updates of cache files - right now they are rewritten from scratch on exit
* Loading the cache in an extra thread. The pipeline state creation code will need some refactor for that
I am not quite happy yet with the two patches that write and reload actual graphics pipelines. The way I am storing the d3d settings aren't quite consistent yet either - in some cases I use the d3d input data as key directly, in others I store them as values attached to a hash value. The latter is usually the case if I need to cross-reference something, e.g. have a link from the pipeline state to the root signature. This kind of setup shows how wined3d can build a chain of linked state though.
There are also known issues with locking, explained in comments in the patches.
--
v3: DEBUG: Make cache profiling more visible
Revert "simple benchmark"
simple benchmark
tests: Add tests for ID3D12ShaderCacheSession.
vkd3d: Implement ID3D12ShaderCacheSession::SetDeleteOnDestroy.
vkd3d: Implement ID3D12ShaderCacheSession on top of vkd3d_shader_cache.
vkd3d: Add a stub ID3D12ShaderCacheSession implementation.
vkd3d: Stub device methods up to D3D12Device9.
vkd3d: Load cached pipelines in a separate thread.
vkd3d: Try to find a read-only cache in C:\windows\scache
vkd3d: Remove the custom render pass lock.
vkd3d: Cache and preload compute pipelines.
vkd3d: Add some cache efficiency debug code.
vkd3d: Add EXT_pipeline_creation_feedback.
vkd3d: Catch and release graphics pipelines.
vkd3d: Store graphics pipelines in the cache.
vkd3d: Precreate root signatures from cache
vkd3d: Keep root signatures around.
vkd3d: Store render passes in the on-disk cache and recreate them on startup.
vkd3d: Store the VK pipeline cache in an on-disk vkd3d cache.
vkd3d: Keep the application name around.
vkd3d: Add a win32 version of vkd3d_get_program_name.
vkd3d: Basic shader cache writing and reading.
vkd3d: Replace the custom render pass cache with vkd3d_shader_cache.
vkd3d: Implement vkd3d_shader_cache_enumerate.
vkd3d: Add cache locking.
vkd3d: Implement vkd3d_shader_cache_get.
vkd3d: Implement vkd3d_shader_cache_put.
vkd3d: Create and destroy the shader cache tree.
vkd3d: Implement shader_cache_open/close.
vkd3d: Define and stub the shader cache API.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/541
~~This applies on top of !711, the last three commits belong here.~~
This MR and the following ones will introduce a number of optimization passes on the structured representation of the shader, with the goal of fixing the idiosyncrasies of the code generated by the new structurizer. The general pattern is that we want to recognize when the combination of loops and jumps can be rather written with selection constructs. Ideally that should bring to removing all the synthesized loop intervals, but that cannot be guaranteed in general. We still want to do remove all the loops we can, first to make the generated code easier to read and to recompile, and second because having fewer loops also means that more multilevel jumps become ordinary single level jumps, which do not require overhead to be represented in SPIR-V.
--
v4: vkd3d-shader/ir: Synthesize selection constructs from conditional jumps.
vkd3d-shader/ir: Remove trailing `continue's.
vkd3d-shader/ir: Move `continue's to the false branch when possible.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/722
With the info I now have, I don't think updating the expected sequence is the right approach. Since it only occurs in a full test run on testbot, my options for investigating are limited. We need to either figure out what's weird about the state when newtb-w11pro64-amd-64 runs this test, or isolate it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5413
Some times the test can be aborted for reasons others than failed assertions, such as segmentation faults or reaching unreacheable code.
To speed up noticing these problems, the `[SIGABRT]` and `[SIGSEGV]` tags are printed on the corresponding exit codes.
Also, "reached unreachable code" lines are also detected and printed with an [AF] tag.
An error may look like this:
```
FAIL: tests/hlsl/some-test.shader_test
(SM4.0-SM5.1)OpenGL/SPIR-V 43[XF] 79[XF] 126[XF] 149[XF] 159[XF]
[AF] vkd3d/libs/vkd3d-shader/hlsl.c:246: Aborting, reached unreachable code.
[SIGABRT] Aborted (core dumped)
```
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/738
SM1 support for LOGIC_NOT, LOGIC_OR, and LOGIC_AND.
--
v5: vkd3d-shader/spirv: Throw compiler error on unrecognized register.
vkd3d-shader/spirv: Implement VKD3DSIH_ABS.
vkd3d-shader/d3dbc: Implement HLSL_OP2_LOGIC_AND for SM1.
vkd3d-shader/d3dbc: Implement HLSL_OP2_LOGIC_OR for SM1.
vkd3d-shader/hlsl: Cast to bool before applying LOGIC_NOT.
vkd3d-shader/hlsl: Support LOGIC_NOT for SM1.
tests: Add tests for LOGIC_NOT on uniforms.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/724
--
v11: vkd3d-shader/spirv: Handle the sequentially consistent ordering flag for atomic instructions.
vkd3d-shader/spirv: Emit a warning if the atomic instruction volatile flag is unhandled.
vkd3d-shader/dxil: Implement the DXIL ATOMICRMW instruction.
vkd3d-shader/dxil: Implement DX instructions ThreadId, GroupId, ThreadIdInGroup and FlattenedThreadIdInGroup.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/707
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.
--
v9: 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
This would eliminate the todo for the precise mad() test in !718. Maybe we need test results on nvidia and intel to decide if we actually want this.
--
v3: vkd3d-shader/spirv: Implement MAD in two operations if flagged as precise.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/723
First change also avoids a leak of classes (later activates) when the transform is successfully connected.
The use of MFTEnumEx is necessary so that the tests work, as they use a locally registered transform.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5412
I'm not completely sure what the expectations are regarding these registry key paths, but @afrantzis said Wayland reports adapters in an arbitrary order and this would let us find the right adapter config and their current settings based on their unique name instead.
Other drivers simply format the numeric ID themselves, though might not be 0-based index anymore.
--
v3: win32u: Use named sources instead of struct gdi_adapter.
win32u: Rename struct adapter to struct source.
win32u: Use a symlink for the logically indexed adapter config key.
win32u: Split writing adapter to registry to a separate helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5137
Since we are adding more and more media formats to wg_format, the current wg_format struct is getting ugly.
Everytime we add a video format, we need to duplicate width, height, fps. Everytime we add a audio format, we need to duplicate channels, rate. So it would be better if we could share width, height, fps fields between different video formats, also share channels and rate fields between different audio formats.
What makes me found the current wg_format is not in a good shape is when I was writting code for Proton, I found that I need to write some code like this if want to get width/height/fps from a wg_format:
```
static bool get_video_info_from_wg_format(struct wg_format *format,
int32_t *width, int32_t *height, uint32_t *fps_n, uint32_t *fps_d)
{
switch (format->major_type)
{
case WG_MAJOR_TYPE_VIDEO:
*width = format->u.video.width;
*height = format->u.video.height;
*fps_n = format->u.video.fps_n;
*fps_d = format->u.video.fps_d;
return true;
case WG_MAJOR_TYPE_VIDEO_CINEPAK:
*width = format->u.video_cinepak.width;
*height = format->u.video_cinepak.height;
*fps_n = format->u.video_cinepak.fps_n;
*fps_d = format->u.video_cinepak.fps_d;
return true;
case WG_MAJOR_TYPE_VIDEO_H264:
*width = format->u.video_h264.width;
*height = format->u.video_h264.height;
*fps_n = format->u.video_h264.fps_n;
*fps_d = format->u.video_h264.fps_d;
return true;
case WG_MAJOR_TYPE_VIDEO_WMV:
*width = format->u.video_wmv.width;
*height = format->u.video_wmv.height;
*fps_n = format->u.video_wmv.fps_n;
*fps_d = format->u.video_wmv.fps_d;
return true;
case WG_MAJOR_TYPE_VIDEO_INDEO:
*width = format->u.video_indeo.width;
*height = format->u.video_indeo.height;
*fps_n = format->u.video_indeo.fps_n;
*fps_d = format->u.video_indeo.fps_d;
return true;
case WG_MAJOR_TYPE_VIDEO_MPEG1:
*width = format->u.video_mpeg1.width;
*height = format->u.video_mpeg1.height;
*fps_n = format->u.video_mpeg1.fps_n;
*fps_d = format->u.video_mpeg1.fps_d;
return true;
default:
GST_ERROR("Type %d is not a video format.\n", format->major_type);
return false;
}
}
```
Apparently, the code above is ugly. By refactoring wg_format, we can avoid code like this.
This patch is a draft now, it only contains unixlib.h code.
Zeb, I'd like to confirm that if this refactoring would be acceptable for you. If do, I'll continue finishing the remaining parts.
--
v5: winegstreamer: Refactor wg_format.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5369
I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally.
As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata.
A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with.
Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators.
--
v3: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs.
vkd3d-shader/hlsl: Store state block on pass variables.
vkd3d-shader/hlsl: Parse list of state blocks.
vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant.
vkd3d-shader/hlsl: Parse and store state blocks on variables.
tests: Add tests for "compile" and CompileShader() syntax.
tests: Add tests for fxgroup syntax.
tests: Test function call syntax for state blocks.
tests: Add more state block syntax tests.
vkd3d-shader/hlsl: Also call dce before lowering deref paths.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v9: wmic.exe: Support interactive mode and piped commands.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v6: put processing args in seperate function
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v5: wmic.exe: Support interactive mode and piped commands.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
See also https://bugs.winehq.org/show_bug.cgi?id=56361
This patch makes piped commands work like for example "echo os get version|wmic" or "type file.txt | wmic" where file.txt contains some commands.
(probably used by program in aforementioned bugreport)
Also support interactive mode (wine wmic.exe)
Marked for now as draft.
--
v3: wmic.exe: Support interactive mode and piped commands.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5402
Udev monitor monitors the whole input subsystem, but not all devices
in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just
simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without
a devnode was processed:
```
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null)
10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were
handled too and `find_device_from_devnode()` choked on NULL argument.
--
v3: winebus: change debugging class of an error case from WARN to ERR.
winebus: change debugging class of an error case from FIXME to ERR
winebus: group local variable declarations
winebus: ignore udev events of devices which do not have devnodes
winebus: log ERR if find_device_from_devnode() somehow gets called with NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/5385
Udev monitor monitors the whole input subsystem, but not all devices
in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just
simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without
a devnode was processed:
```
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null)
10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were
handled too and `find_device_from_devnode()` choked on NULL argument.
--
v2: winebus: group local variable declarations
https://gitlab.winehq.org/wine/wine/-/merge_requests/5385