December 2023 - Wine-gitlab

[PATCH 0/4] MR4591: amstream, winegstreamer: Quality control improvements.
by Anton Baskanov (＠baskanov) 05 Dec '23

05 Dec '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4591

5 7

[PATCH v5 0/11] MR498: Draft: vkd3d-shader/dxil: Implement the DXIL ALLOCA and STORE instructions.
by Conor McCarthy (＠cmccarthy) 05 Dec '23

05 Dec '23

Goes atop !477. The last two commits belong to this MR. -- v5: tests/shader-runner: Add a non-const-indexing test for asfloat() result storage. vkd3d-shader/spirv: Bitcast if necessary in the spirv_compiler_emit_mov() general implementation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498

2 11

[PATCH v4 0/9] MR498: Draft: vkd3d-shader/dxil: Implement the DXIL ALLOCA and STORE instructions.
by Conor McCarthy (＠cmccarthy) 05 Dec '23

05 Dec '23

Goes atop !477. The last two commits belong to this MR. -- v4: vkd3d-shader/dxil: Implement the DXIL STORE instruction. vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction. tests/shader-runner: Test an uninitialised indexable temp. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498

2 9

Re: [PATCH v9 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Zebediah Figura (＠zfigura) 05 Dec '23

05 Dec '23

On Tue Dec 5 01:23:40 2023 +0000, Alfred Agrell wrote: > I don't know what Microsoft's intention is or what's officially > supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri > does, in fact, call ChangeD3DDevice while the graph is connected but > stopped. It's the last thing it does before IMediaControl::Run(). > (Kirikiri doesn't pause the graph, it just goes directly to Run.) > Kirikiri's source code also shows that the function is called if > IDirect3DDevice9::Present returns D3DERR_DEVICELOST; Present() is only > plausible while paused or running, though I don't know if that code path > was ever tested. > (Also rebased this thing. No other changes.) Fair enough, I can only assume they avoid the race somehow else then, e.g. by always happening to wait the few ms necessary to ensure the asynchronous reconnect completes. It certainly wouldn't surprise me. In any case I think the best thing we can do for the tests is to not test that case. We want the tests to pass consistently, and experience has taught me that the only way to achieve that is to never rely on Sleep(). The stopped case should be interesting enough by itself anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_55004

1 0

Re: [PATCH v3 0/1] MR4578: include: Add Windows.Storage.Streams.InMemoryRandomAccessStream runtimeclass definition.
by Fabian Maurer (＠DarkShadow44) 05 Dec '23

05 Dec '23

On Fri Dec 1 21:45:23 2023 +0000, Vijay Kiran Kamuju wrote: > According the idl its activatable, but I was not sure how to add the > activatable as its in hex > [activatable(0x06020000)] Probably just `activatable(Windows.Foundation.UniversalApiContract, 1.0)`. But I'm pretty sure you need that activatable if you want it to be usable later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4578#note_54999

1 0

Re: [PATCH v8 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Alfred Agrell (＠Alcaro) 05 Dec '23

05 Dec '23

On Tue Dec 5 01:21:52 2023 +0000, Zebediah Figura wrote: > I did some more digging on this one, and here is what my testing suggests: > * native ChangeD3DDevice() *just* reconnects the filter, i.e. it doesn't > directly call any of the same methods. > * This reconnection is done on a separate thread, for some reason. IPin > methods and IVMRSurfaceAllocator::TerminateDevice() are called from that thread. > * The filter graph documentation claims that IFilterGraph::Reconnect() > and IFilterGraph2::ReconnectEx() execute on a separate thread, but > according to my tests this is not true. > * ChangeD3DDevice() can be called while the filter is running, in which > case it will stop the graph, reconnnect, and then run. This is all done > on the same thread. Note that ReconnectEx() *cannot* be called while the > filter is running. > * ChangeD3DDevice() can be called while the filter is not connected. > * InitializeDevice() is not called immediately on connection. Rather, it > seems to be deferred until IMemAllocator::SetProperties(). > VFW_E_NOT_COMMITTED happens because reconnecting evidently decommits the > allocator, and we manage to race exactly such that the pins have been > disconnected but not yet reconnected when trying to send a frame. > As far as I can tell there is no actual way to synchronize this thread. > I suspect that in practice ChangeD3DDevice() is not expected to be > called while connected and stopped. I don't know if it's meant to be > called while disconnected or while running, or both. Either will avoid > this race, although ChangeD3DDevice() while running will definitely run > into other races surrounding state change (e.g. what happens if you > ChangeD3DDevice() and then decide to stop the graph?) > I think the only case we can really reliably test is the stopped case. I don't know what Microsoft's intention is or what's officially supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri does, in fact, call ChangeD3DDevice while the graph is connected but stopped. It's the last thing it does before IMediaControl::Run(). (Kirikiri doesn't pause the graph, it just goes directly to Run.) Kirikiri's source code also shows that the function is called if IDirect3DDevice9::Present returns D3DERR_DEVICELOST, which only happens while paused or running, though I don't know if that code path was ever tested. (Also rebased this thing. No other changes.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_54997

1 0

[PATCH v10 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 05 Dec '23

05 Dec '23

Along with !4450, this fixes WMV videos in microkiri (https://bugs.winehq.org/show_bug.cgi?id=9127#c102) and Wagamama High Spec Trial Edition (https://wagahigh.com/download_trial.php#normal ; ダウンロード means download). -- v10: wmvcore/tests: Add tests for compressed output. winegstreamer: Implement compressed output support in WMSyncReader. winegstreamer: Leave pts/duration unchanged if they're not set. winegstreamer: Introduce mutex for wm_reader read_thread_shutdown. winegstreamer: Move file size to struct wm_reader. winegstreamer: Fill in a few more pieces of WMV format handling. winegstreamer: Add codec_data to WMVs. https://gitlab.winehq.org/wine/wine/-/merge_requests/4449

2 7

[PATCH v9 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 05 Dec '23

05 Dec '23

Along with !4450, this fixes WMV videos in microkiri (https://bugs.winehq.org/show_bug.cgi?id=9127#c102) and Wagamama High Spec Trial Edition (https://wagahigh.com/download_trial.php#normal ; ダウンロード means download). -- v9: wmvcore/tests: Add tests for compressed output. winegstreamer: Implement compressed output support in WMSyncReader. winegstreamer: Leave pts/duration unchanged if they're not set. winegstreamer: Introduce mutex for wm_reader read_thread_shutdown. winegstreamer: Move file size to struct wm_reader. winegstreamer: Fill in a few more pieces of WMV format handling. winegstreamer: Add codec_data to WMVs. https://gitlab.winehq.org/wine/wine/-/merge_requests/4449

4 18

Re: [PATCH v8 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Zebediah Figura (＠zfigura) 04 Dec '23

04 Dec '23

I did some more digging on this one, and here is what my testing suggests: * native ChangeD3DDevice() *just* reconnects the filter, i.e. it doesn't directly call any of the same methods. * This reconnection is done on a separate thread, for some reason. IPin methods and IVMRSurfaceAllocator::TerminateDevice() are called from that thread. * The filter graph documentation claims that IFilterGraph::Reconnect() and IFilterGraph2::ReconnectEx() execute on a separate thread, but according to my tests this is not true. * ChangeD3DDevice() can be called while the filter is running, in which case it will stop the graph, reconnnect, and then run. This is all done on the same thread. Note that ReconnectEx() *cannot* be called while the filter is running. * ChangeD3DDevice() can be called while the filter is not connected. * InitializeDevice() is not called immediately on connection. Rather, it seems to be deferred until IMemAllocator::SetProperties(). VFW_E_NOT_COMMITTED happens because reconnecting evidently decommits the allocator, and we manage to race exactly such that the pins have been disconnected but not yet reconnected when trying to send a frame. As far as I can tell there is no actual way to synchronize this thread. I suspect that in practice ChangeD3DDevice() is not expected to be called while connected and stopped. I don't know if it's meant to be called while disconnected or while running, or both. Either will avoid this race, although ChangeD3DDevice() while running will definitely run into other races surrounding state change (e.g. what happens if you ChangeD3DDevice() and then decide to stop the graph?) I think the only case we can really reliably test is the stopped case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_54992

1 0

[PATCH 0/1] MR4598: po: Update Lithuanian translation.
by Aurimas Fišeras 04 Dec '23

04 Dec '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4598

2 2