This is required by https://bugs.winehq.org/show_bug.cgi?id=54660 .
--
v10: vkd3d-shader/hlsl: Consider duplicated input semantic types equivalent in SM1.
vkd3d-shader/hlsl: Handle possibly different types in input semantic var load.
vkd3d-shader/hlsl: Error out when a semantic is used with incompatible types.
vkd3d-shader/hlsl: Error out when an output semantic is used more than once.
vkd3d-shader/hlsl: Support semantics for array types.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/148
From what I can tell, the recent work on SampleBias/SampleLevel did all of the work for us, we just need to take the same framework and include the case for the `sample_l` instruction.
Tested with some shaders from the native Linux version of Little Racers STREET.
--
v5: vkd3d-shader/tpf: For sample_l/sample_b, set lod swizzle to SCALAR.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/188
> > In practice I see a number of difficulties:
> >
> > * Shaders are not just code; they also embed interface information (input and output signatures, uniforms, buffers, object bindings, ...) and other random metadata (for example for the hull shaders). Should this be representable in the common IR?
>
> We need *some* way to represent that information so it doesn't get lost, at least. I think we don't want side channels, to be clear: I think that there should be a point where all of the information relevant to a shader is represented in v_s_i format, including metadata.
>
> And contrary to the instructions themselves, I think we want this information to be in a relatively simple and well-designed form. In a sense, it doesn't need to be "complex" like the instructions since we're not doing optimization passes over it \[if that makes sense\]. I think Conor has basically been pushing v_s_i in this direction in order to accommodate sm6 (at least wrt semantics), and given the tribulations I've had to endure to get sm1 to work, I think that's the right approach.
Yes, although I don't think that necessarily means storing these as "instructions". The approach I'm personally leaning towards at this point is to rebrand "struct vkd3d_shader_instruction_array" as "struct vkd3d_shader_program" (or something along those lines), and then add the input/output/patch constant signatures and the shader version structure to that structure. I think a similar approach should work for e.g. RDEF as well.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31631
This is causing several GStreamer-Video-CRITICAL messages to be printed while running the tests:
```
(wine:363): GStreamer-Video-CRITICAL **: 09:01:22.664: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2546#note_31623
Please note that with this MR the following `TRACE()` calls are removed:
- `"ALSA does not support volume control\n"`
- `"OSS doesn't support setting volume\n"`
- `"PulseAudio does not support session volume control\n"`
Should I perhaps move them to the specific drivers' unixlib instead?
--
v2: winepulse: Use mmdevapi's SimpleAudioVolume.
wineoss: Use mmdevapi's SimpleAudioVolume.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2726
According to the tests in 23b72ad, when we are reading a compressed stream, the type returned by `stream_props_GetMediaType()` should reflect compressed format even if we finnally output uncomressed data. For example, if we use wmvcore reader to read a WMV3 stream and output RGB24, the format information returned by `stream_props_GetMediaType()` should be WMV3, not RGB24.
--
v8: winegstreamer: Use codec format in stream_props_GetMediaType.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2387