Goes atop MR 388 and 401. The last five commits belong to this MR.
--
v2: vkd3d-shader/dxil: Implement the DXIL EXTRACTVAL instruction.
vkd3d-shader/spirv: Support scalar swizzle of vector SSA registers.
vkd3d-shader/dxil: Implement DX instruction CBufferLoadLegacy.
vkd3d-shader/dxil: Implement DX instruction CreateHandle.
vkd3d-shader/dxil: Move the register_address_init() index parameter to position 2.
vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
vkd3d-shader/dxil: Validate the descriptor list metadata nodes.
vkd3d-shader/spirv: Align constant buffer sizes to 16 bytes.
vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/408
Goes atop MR 388 (the error codes would clash otherwise). The last four commits belong to this MR.
--
v8: vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
vkd3d-shader/dxil: Validate the descriptor list metadata nodes.
vkd3d-shader/spirv: Align constant buffer sizes to 16 bytes.
vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/401
On Mon Oct 16 22:21:57 2023 +0000, Zebediah Figura wrote:
> Hrm, that's suspicious, IMemAllocator::GetBuffer() returns
> VFW_E_NOT_COMMITTED. Does the VMR's IMemAllocator change by any chance
> when we reconnect? I.e. is IMemInputPin::GetAllocator() actually
> returning the same allocator that it was returning before?
Worth checking, but the answer is they're the same. https://testbot.winehq.org/JobDetails.pl?Key=138797&f101=exe64.report (First - the one already acquired. Second - after changing and sleeping. Third - after decommitting and recommitting.)
As I may have said, I have a vague suspicion this component is haunted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_48919
Hi, really sorry about the very late review on this one (I was out for a while, and then spent a lot of time catching up on review while I was out, and then trying to get some more important Wine work done...)
2/7, seeking parts aside, is broadly doing the right thing (from my perspective) but I would like to see it arranged differently. What I would like to see is something like the following, in a series of individual patches:
* Introduce a wg_parser_create option to use the encoded format; this should end up being translated to "chain_decodebins" basically as you have it. I would also rename that to something like "output_compressed" (with inverted meaning).
Note that in this case autoplug-continue already does what we want, you shouldn't need to set the "caps" property on top of that.
* Use this property, plus WG_PARSER_DECODEBIN, in the existing frontend instead of WG_PARSER_MPEGAUDIOPARSE. Delete WG_PARSER_MPEGAUDIOPARSE.
* Ideally patch 1/7 should be moved from the beginning of the series to here.
* Add MPEG-1 system stream support to the quartz frontend.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48918
On Tue Oct 3 09:21:16 2023 +0000, Rémi Bernon wrote:
> I don't know whether this is correct or not, I think it'd be better to
> leave this aspect aside for now as like you said this is going a bit out
> of the scope of this MR.
I would expect quartz to do one of three things, although others are possible:
* ignore format changes entirely,
* report the new format in the sample itself, via IMediaSample::GetMediaType(),
* reconnect the downstream pin.
In this case, as I understand, there's no real format change, it's just that GStreamer gains a bit of information more asynchronously; in that case nothing should happen.
Probably we shouldn't even be reporting a format change if the translated wg_format doesn't change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48917
Zebediah Figura (@zfigura) commented about dlls/quartz/tests/mpegvideo.c:
> + HRESULT hr = CoCreateInstance(&CLSID_CMpegVideoCodec, NULL, CLSCTX_INPROC_SERVER,
> + &IID_IBaseFilter, (void **)&filter);
> + ok(hr == S_OK, "Got hr %#lx.\n", hr);
> + return filter;
> +}
> +
> +static inline BOOL compare_media_types(const AM_MEDIA_TYPE *a, const AM_MEDIA_TYPE *b)
> +{
> + return !memcmp(a, b, offsetof(AM_MEDIA_TYPE, pbFormat))
> + && !memcmp(a->pbFormat, b->pbFormat, a->cbFormat);
> +}
> +
> +enum video_type_t {
> + vt_yv12, vt_y41p, vt_yuy2, vt_uyvy,
> + vt_rgb24, vt_rgb32, vt_rgb565, vt_rgb555, vt_rgb8,
> +};
Usually enum values are capitalized; also, _t is usually reserved for typedefs. That said, do we even want this enum? Is there any instance where we shouldn't just iterate over the whole array?
Two of these formats are todo, but I think something like "todo_wine_if (i == 1 || i == 8)" would be fine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48916