January 2022 - Wine-Devel - list.winehq.org

[PATCH 3/4] msvcrt: Don't use fegetenv in nearbyint.

by Piotr Caban

The fegetenv/feupdateenv functions are broken in msvcr120 and are causing unintentional SSE control word changes. Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> --- dlls/msvcr120/tests/msvcr120.c | 29 +++++++++++++++++++++++++++++ dlls/msvcrt/math.c | 27 ++++++++++++++++++++++----- 2 files changed, 51 insertions(+), 5 deletions(-)

Jan. 31, 2022

[PATCH 2/4] msvcrt: Don't set SSE control word in _except1.

by Piotr Caban

Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> --- dlls/msvcrt/math.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Jan. 31, 2022

[PATCH 1/4] msvcrt: Fix fmaf not to depend on rounding mode.

by Piotr Caban

Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> --- dlls/msvcrt/math.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Stefan Dösinger

Am Montag, 31. Jänner 2022, 20:45:38 EAT schrieb Fabian Maurer: > Hello Stefan, > > Of course it couldn't be easy.. > > > Netscape 4 is the application where I came across the problem. Microsoft > > has some floating point sample applications that also show the issue. > > Do we have a bugreport for those already? None that I know of, but I also didn't search extensively. I came across it when toying around with dosemu2 for fun: https://github.com/dosemu2/dosemu2/ issues/976 . https://stackoverflow.com/questions/10511506/old-16-bit-application-causing… talks about the issues with modern CPUs. > > The correct thing would be to bring > > the Win16 float exception handling code from winevdm back to Wine. > > Their implementation actually isn't too different from Wine's, unless you > mean the part where they use the MAME emulator. They added quite a chunk of code Wine does not have re x87 exceptions. https://github.com/otya128/winevdm/blob/master/win87em/win87em.c#L199 is the most obvious tip of the iceberg, but I guess there is more stuff hidden in their DPMI interrupt code.

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Stefan Dösinger

Am Montag, 31. Jänner 2022, 21:47:41 EAT schrieb Austin English: > On Mon, Jan 31, 2022 at 11:45 AM Fabian Maurer <dark.shadow4(a)web.de> wrote: > > It's still the case that we can't really write tests for Win16, correct? > > Currently not in tree; some people have made standalone tests (either > attached to bugzilla tickets, or > https://github.com/austin987/win16test) In a recent hacker news discussion I came across the Digital Mars C++ compiler: https://digitalmars.com/ctg/win16-programming.html , https:// github.com/DigitalMars/dmc . Boost license, which I don't really know, but FSF says it's GPL compatible: https://www.gnu.org/licenses/license-list.html#boost

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Austin English

On Mon, Jan 31, 2022 at 11:45 AM Fabian Maurer <dark.shadow4(a)web.de> wrote: > It's still the case that we can't really write tests for Win16, correct? Currently not in tree; some people have made standalone tests (either attached to bugzilla tickets, or https://github.com/austin987/win16test) The main blocker is the lack of a LGPL compatible compiler. Openwatcom can compile win16 binaries, but the license isn't compatible, but last year SAP (current owner of the original codebase) have agreed to relicense it, so there may be hope in the future: https://github.com/open-watcom/open-watcom-v2/discussions/271#discussioncom…

Jan. 31, 2022

Re: [PATCH 3/4] wined3d: Keep track of whether a BO is persistently mapped in a per-BO field.

by Zebediah Figura

On 1/31/22 11:33, Henri Verbeet wrote: > On Mon, 31 Jan 2022 at 18:22, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >> On 1/31/22 08:11, Henri Verbeet wrote: >>> On Mon, 31 Jan 2022 at 04:05, Zebediah Figura <zfigura(a)codeweavers.com> wrote: >>>> The ultimate idea being to set a cap on the amount of persistent BO memory, in >>>> which case we need to arbitrarily mark BOs as persistent. >>>> >>> Could the "arbitrary" part be avoided? In particular, what would >>> prevent us from unmapping less recently used mappings when we run into >>> the cap? >> >> Nothing, really. We could relatively easily use an LRU list, or >> periodically garbage-collect unused mappings, for two possibilities. >> >> I think it's a bit orthogonal to this patch, though. No matter what >> criteria we use to determine whether a mapping is persistent in >> wined3d_bo_*_map(), or to possibly unmap it later, we'll at least want >> some of these users of bo->persistent. >> >> I'm also inclined to argue there's no reason not to accept 4/4 now, and >> later (assuming we need to) implement a more complex and optimized >> scheme on top of that. Although it could probably do with a bit more >> factored out into the "adjust_mapped_memory" helpers. > > To some extent, yes. However, the follow-up question then becomes what > the "persistent" field really means. Or put a different way, under > what circumstances should we use "bo->persistent" instead of > "bo->map_ptr"? Note that we use "bo->map_ptr" inconsistently between the OpenGL and Vulkan backends—the OpenGL backend only sets it for persistent mappings, whereas the Vulkan backend sets it for all mappings. This patch standardizes on the latter behaviour. The reason we want this is basically patch 2/4. Namely, if the BO is mapped, then wined3d_device_context_map() can return its map pointer to the caller (assuming we just got it from a DISCARD map). If it is mapped persistently, we can also store that map pointer and use it for subsequent NOOVERWRITE maps. I don't anticipate any other places that would care, though.

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Fabian Maurer

Hello Stefan, Of course it couldn't be easy.. > Netscape 4 is the application where I came across the problem. Microsoft has > some floating point sample applications that also show the issue. Do we have a bugreport for those already? > The correct thing would be to bring > the Win16 float exception handling code from winevdm back to Wine. Their implementation actually isn't too different from Wine's, unless you mean the part where they use the MAME emulator. I'd like to help, but the problem is that I don't really understand what's going on. We have a similar bug (34867) where we have a divide by zero that's not handled properly. And advice an how to proceed? It's still the case that we can't really write tests for Win16, correct? Regards, Fabian Maurer On Montag, 31. Januar 2022 10:52:51 CET you wrote: > Am Montag, 31. Jänner 2022, 01:14:25 EAT schrieb Fabian Maurer: > > Hello wine-devel, > > > > attaching a patch that works around a floating point issue, this is how > > they do it on otya128/winevdm, the win16 wine fork. > > Is this the correct way to do it, or why does Wine code do what it does? > > A while back (circa 2019 I think) I spent some spare time learning about > Win16 and came across floating point exceptions. Wine has pretty much no > handling of float exceptions. To make matters worse, new-ish CPUs have bugs > / features that break things. I think Sandy Bridge and newer Intel CPUs set > the %cs segment to 0 in fxrstor. That breaks a pile of Win16 applications > even when run inside a virtual machine (but not when run inside a full CPU > emulator). > > Netscape 4 is the application where I came across the problem. Microsoft has > some floating point sample applications that also show the issue. > > So to answer your question: I don't really know, but I suspect the patch > just hides the real problem by luck. The correct thing would be to bring > the Win16 float exception handling code from winevdm back to Wine. I don't > know how correct it is though. And on top of that try to find workarounds > for whatever CPU errata there are nowadays :-/

Jan. 31, 2022

Re: [PATCH 3/4] wined3d: Keep track of whether a BO is persistently mapped in a per-BO field.

by Henri Verbeet

On Mon, 31 Jan 2022 at 18:22, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > On 1/31/22 08:11, Henri Verbeet wrote: > > On Mon, 31 Jan 2022 at 04:05, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > >> The ultimate idea being to set a cap on the amount of persistent BO memory, in > >> which case we need to arbitrarily mark BOs as persistent. > >> > > Could the "arbitrary" part be avoided? In particular, what would > > prevent us from unmapping less recently used mappings when we run into > > the cap? > > Nothing, really. We could relatively easily use an LRU list, or > periodically garbage-collect unused mappings, for two possibilities. > > I think it's a bit orthogonal to this patch, though. No matter what > criteria we use to determine whether a mapping is persistent in > wined3d_bo_*_map(), or to possibly unmap it later, we'll at least want > some of these users of bo->persistent. > > I'm also inclined to argue there's no reason not to accept 4/4 now, and > later (assuming we need to) implement a more complex and optimized > scheme on top of that. Although it could probably do with a bit more > factored out into the "adjust_mapped_memory" helpers. To some extent, yes. However, the follow-up question then becomes what the "persistent" field really means. Or put a different way, under what circumstances should we use "bo->persistent" instead of "bo->map_ptr"?

Jan. 31, 2022

[PATCH v2] quartz/tests: Avoid "misleading indentation" warnings.

by Zebediah Figura

From: Fabian Maurer <dark.shadow4(a)web.de> Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- v2: Use consistent formatting with other tests. dlls/quartz/tests/acmwrapper.c | 6 ++--- dlls/quartz/tests/filtergraph.c | 38 +++++++++++-------------------- dlls/quartz/tests/videorenderer.c | 3 +-- 3 files changed, 16 insertions(+), 31 deletions(-) diff --git a/dlls/quartz/tests/acmwrapper.c b/dlls/quartz/tests/acmwrapper.c index 31b32b53ac9..8b9a472c0f3 100644 --- a/dlls/quartz/tests/acmwrapper.c +++ b/dlls/quartz/tests/acmwrapper.c @@ -380,8 +380,7 @@ static void test_pin_info(void) ok(hr == S_OK, "Got hr %#x.\n", hr); ok(info.pFilter == filter, "Expected filter %p, got %p.\n", filter, info.pFilter); ok(info.dir == PINDIR_INPUT, "Got direction %d.\n", info.dir); -todo_wine - ok(!wcscmp(info.achName, L"Input"), "Got name %s.\n", wine_dbgstr_w(info.achName)); + todo_wine ok(!wcscmp(info.achName, L"Input"), "Got name %s.\n", debugstr_w(info.achName)); ref = get_refcount(filter); ok(ref == 3, "Got unexpected refcount %d.\n", ref); ref = get_refcount(pin); @@ -412,8 +411,7 @@ todo_wine ok(hr == S_OK, "Got hr %#x.\n", hr); ok(info.pFilter == filter, "Expected filter %p, got %p.\n", filter, info.pFilter); ok(info.dir == PINDIR_OUTPUT, "Got direction %d.\n", info.dir); -todo_wine - ok(!wcscmp(info.achName, L"Output"), "Got name %s.\n", wine_dbgstr_w(info.achName)); + todo_wine ok(!wcscmp(info.achName, L"Output"), "Got name %s.\n", debugstr_w(info.achName)); IBaseFilter_Release(info.pFilter); hr = IPin_QueryDirection(pin, &dir); diff --git a/dlls/quartz/tests/filtergraph.c b/dlls/quartz/tests/filtergraph.c index a83bfde0806..620a1a56bad 100644 --- a/dlls/quartz/tests/filtergraph.c +++ b/dlls/quartz/tests/filtergraph.c @@ -2474,8 +2474,7 @@ static void test_graph_builder_connect(void) IFilterGraph2_AddFilter(graph, &sink2.IBaseFilter_iface, NULL); hr = IFilterGraph2_Connect(graph, &source_pin.IPin_iface, &sink_pin.IPin_iface); -todo_wine - ok(hr == VFW_S_PARTIAL_RENDER, "Got hr %#x.\n", hr); + todo_wine ok(hr == VFW_S_PARTIAL_RENDER, "Got hr %#x.\n", hr); ok(source_pin.peer == &parser1_pins[0].IPin_iface, "Got peer %p.\n", source_pin.peer); ok(sink_pin.peer == &parser1_pins[1].IPin_iface, "Got peer %p.\n", sink_pin.peer); ok(!parser1_pins[2].peer, "Got peer %p.\n", parser1_pins[2].peer); @@ -3105,32 +3104,24 @@ static void test_connect_direct(void) /* Swap the pins when connecting. */ hr = IFilterGraph2_ConnectDirect(graph, &sink_pin.IPin_iface, &source_pin.IPin_iface, NULL); ok(hr == S_OK, "Got hr %#x.\n", hr); -todo_wine - ok(sink_pin.peer == &source_pin.IPin_iface, "Got peer %p.\n", sink_pin.peer); + todo_wine ok(sink_pin.peer == &source_pin.IPin_iface, "Got peer %p.\n", sink_pin.peer); ok(!sink_pin.mt, "Got mt %p.\n", sink_pin.mt); -todo_wine - ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); + todo_wine ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); hr = IFilterGraph2_Disconnect(graph, &sink_pin.IPin_iface); -todo_wine - ok(hr == S_OK, "Got hr %#x.\n", hr); -todo_wine - ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); + todo_wine ok(hr == S_OK, "Got hr %#x.\n", hr); + todo_wine ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); ok(!sink_pin.peer, "Got peer %p.\n", sink_pin.peer); hr = IFilterGraph2_Connect(graph, &sink_pin.IPin_iface, &source_pin.IPin_iface); ok(hr == S_OK, "Got hr %#x.\n", hr); -todo_wine - ok(sink_pin.peer == &source_pin.IPin_iface, "Got peer %p.\n", sink_pin.peer); + todo_wine ok(sink_pin.peer == &source_pin.IPin_iface, "Got peer %p.\n", sink_pin.peer); ok(!sink_pin.mt, "Got mt %p.\n", sink_pin.mt); -todo_wine - ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); + todo_wine ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); hr = IFilterGraph2_Disconnect(graph, &sink_pin.IPin_iface); -todo_wine - ok(hr == S_OK, "Got hr %#x.\n", hr); -todo_wine - ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); + todo_wine ok(hr == S_OK, "Got hr %#x.\n", hr); + todo_wine ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); ok(!sink_pin.peer, "Got peer %p.\n", sink_pin.peer); /* Disconnect() does not disconnect the peer. */ @@ -3304,8 +3295,7 @@ todo_wine ok(source.ref == 1, "Got outstanding refcount %d.\n", source.ref); ok(sink.ref == 1, "Got outstanding refcount %d.\n", sink.ref); ok(source_pin.ref == 1, "Got outstanding refcount %d.\n", source_pin.ref); -todo_wine - ok(sink_pin.ref == 1, "Got outstanding refcount %d.\n", sink_pin.ref); + todo_wine ok(sink_pin.ref == 1, "Got outstanding refcount %d.\n", sink_pin.ref); ok(!source_pin.peer, "Got peer %p.\n", source_pin.peer); ok(!sink_pin.peer, "Got peer %p.\n", sink_pin.peer); } @@ -3350,8 +3340,7 @@ static void test_sync_source(void) ok(!filter2.clock, "Got clock %p.\n", filter2.clock); hr = IMediaFilter_GetSyncSource(filter, &clock); -todo_wine - ok(hr == S_FALSE, "Got hr %#x.\n", hr); + todo_wine ok(hr == S_FALSE, "Got hr %#x.\n", hr); ok(!clock, "Got clock %p.\n", clock); IReferenceClock_Release(systemclock); @@ -3647,9 +3636,8 @@ static void test_filter_state(void) hr = IMediaControl_Run(control); ok(hr == S_OK, "Got hr %#x.\n", hr); check_filter_state(graph, State_Running); -todo_wine - ok(source.start_time > 0 && source.start_time < 500 * 10000, - "Got time %s.\n", wine_dbgstr_longlong(source.start_time)); + todo_wine ok(source.start_time > 0 && source.start_time < 500 * 10000, + "Got time %s.\n", wine_dbgstr_longlong(source.start_time)); ok(sink.start_time == source.start_time, "Expected time %s, got %s.\n", wine_dbgstr_longlong(source.start_time), wine_dbgstr_longlong(sink.start_time)); diff --git a/dlls/quartz/tests/videorenderer.c b/dlls/quartz/tests/videorenderer.c index 5625971426b..ec212f1b5d6 100644 --- a/dlls/quartz/tests/videorenderer.c +++ b/dlls/quartz/tests/videorenderer.c @@ -347,8 +347,7 @@ static void test_pin_info(void) ok(hr == S_OK, "Got hr %#x.\n", hr); ok(info.pFilter == filter, "Expected filter %p, got %p.\n", filter, info.pFilter); ok(info.dir == PINDIR_INPUT, "Got direction %d.\n", info.dir); -todo_wine - ok(!wcscmp(info.achName, L"Input"), "Got name %s.\n", wine_dbgstr_w(info.achName)); + todo_wine ok(!wcscmp(info.achName, L"Input"), "Got name %s.\n", debugstr_w(info.achName)); ref = get_refcount(filter); ok(ref == 3, "Got unexpected refcount %d.\n", ref); ref = get_refcount(pin); -- 2.34.1

Jan. 31, 2022