[PATCH 0/1] MR11612: wined3d: Support WINE_D3D_CONFIG=no_create_flags=0x800 and any flags
This MR is a continuation/preservation of original more expansive patch from MR-11398 which was minimized to only support D3D11_CREATE_DEVICE_VIDEO_SUPPORT instead of all d3d/ddraw device creation flags. The primary use case is to support `WINE_D3D_CONFIG=no_create_flags=0x800` to force UnityPlayer.dll to fallback to software video decoding. However the patch also supports all other d3d/ddraw device creation flags if ever needed for debugging purposes. I will test it for other bugs to determine if it may have wider scope to further prove it's use case as a useful convenience tool that may allow users to discover fixes, workarounds, or causes of bugs by minimizing dev skills otherwise required. Perhaps to be considered more worthy for merge a design spec should be provided to clarify how to mitigate potential risks raised by MR-11398. Concerns were raised that expanding support for d3d create flag overrides may open the door for too many other overrides such as feature levels, format supports, etc which may be considered leading to maintenance nightmares. Therefore deliberate planning for how to deal with such cases as a guide may be needed before these changes may be considered ready for merge. In the meantime it exists open for feedback/discussion and for anyone who may find it convenient. Maybe its considered appropriate enough as is to include for wine-staging without requiring the other requirements to be fulfilled first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612
From: Stian Low <wineryyyyy@gmail.com> --- dlls/d3d8/device.c | 2 +- dlls/d3d9/device.c | 2 +- dlls/ddraw/ddraw.c | 2 +- dlls/dxgi/device.c | 5 ++--- dlls/dxgi/dxgi_main.c | 2 +- dlls/dxgi/dxgi_private.h | 2 +- dlls/wined3d/directx.c | 12 ++++++++++-- dlls/wined3d/wined3d.spec | 2 +- dlls/wined3d/wined3d_main.c | 2 ++ dlls/wined3d/wined3d_private.h | 1 + include/wine/wined3d.h | 4 ++-- 11 files changed, 23 insertions(+), 13 deletions(-) diff --git a/dlls/d3d8/device.c b/dlls/d3d8/device.c index c04283c1ad4..b7352f3fe63 100644 --- a/dlls/d3d8/device.c +++ b/dlls/d3d8/device.c @@ -3707,7 +3707,7 @@ HRESULT device_init(struct d3d8_device *device, struct d3d8 *parent, struct wine wined3d_output = parent->wined3d_outputs[output_idx]; wined3d_adapter = wined3d_output_get_adapter(wined3d_output); if (FAILED(hr = wined3d_device_create(wined3d, wined3d_adapter, wined3d_device_type_from_d3d(device_type), - focus_window, flags, 4, feature_levels, ARRAY_SIZE(feature_levels), + focus_window, flags, flags, 4, feature_levels, ARRAY_SIZE(feature_levels), &device->device_parent, &device->wined3d_device))) { WARN("Failed to create wined3d device, hr %#lx.\n", hr); diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c index 2d036f2c22e..384cd8e0362 100644 --- a/dlls/d3d9/device.c +++ b/dlls/d3d9/device.c @@ -4785,7 +4785,7 @@ HRESULT device_init(struct d3d9_device *device, struct d3d9 *parent, struct wine wined3d_mutex_lock(); wined3d_adapter = wined3d_output_get_adapter(parent->wined3d_outputs[output_idx]); if (FAILED(hr = wined3d_device_create(wined3d, wined3d_adapter, wined3d_device_type_from_d3d(device_type), - focus_window, flags, 4, feature_levels, ARRAY_SIZE(feature_levels), + focus_window, flags, flags, 4, feature_levels, ARRAY_SIZE(feature_levels), &device->device_parent, &device->wined3d_device))) { WARN("Failed to create wined3d device, hr %#lx.\n", hr); diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c index 8814c32447d..a286edf20e7 100644 --- a/dlls/ddraw/ddraw.c +++ b/dlls/ddraw/ddraw.c @@ -5169,7 +5169,7 @@ HRESULT ddraw_init(struct ddraw *ddraw, DWORD flags, enum wined3d_device_type de } if (FAILED(hr = wined3d_device_create(ddraw->wined3d, ddraw->wined3d_adapter, device_type, - NULL, 0, DDRAW_STRIDE_ALIGNMENT, feature_levels, ARRAY_SIZE(feature_levels), + NULL, 0, ddraw->flags, DDRAW_STRIDE_ALIGNMENT, feature_levels, ARRAY_SIZE(feature_levels), &ddraw->device_parent, &ddraw->wined3d_device))) { WARN("Failed to create a wined3d device, hr %#lx.\n", hr); diff --git a/dlls/dxgi/device.c b/dlls/dxgi/device.c index eedcc81d845..62a2465ad94 100644 --- a/dlls/dxgi/device.c +++ b/dlls/dxgi/device.c @@ -485,7 +485,7 @@ static const struct IWineDXGISwapChainFactoryVtbl dxgi_swapchain_factory_vtbl = }; HRESULT dxgi_device_init(struct dxgi_device *device, struct dxgi_device_layer *layer, - IDXGIFactory *factory, IDXGIAdapter *adapter, + IDXGIFactory *factory, IDXGIAdapter *adapter, unsigned int flags, const D3D_FEATURE_LEVEL *feature_levels, unsigned int level_count) { struct wined3d_device_parent *wined3d_device_parent; @@ -539,9 +539,8 @@ HRESULT dxgi_device_init(struct dxgi_device *device, struct dxgi_device_layer *l } wined3d_device_parent = IWineDXGIDeviceParent_get_wined3d_device_parent(dxgi_device_parent); IWineDXGIDeviceParent_Release(dxgi_device_parent); - if (FAILED(hr = wined3d_device_create(dxgi_factory->wined3d, - dxgi_adapter->wined3d_adapter, WINED3D_DEVICE_TYPE_HAL, NULL, 0, 4, + dxgi_adapter->wined3d_adapter, WINED3D_DEVICE_TYPE_HAL, NULL, 0, flags, 4, (const enum wined3d_feature_level *)feature_levels, level_count, wined3d_device_parent, &device->wined3d_device))) { diff --git a/dlls/dxgi/dxgi_main.c b/dlls/dxgi/dxgi_main.c index ca1fb525535..36ce309db37 100644 --- a/dlls/dxgi/dxgi_main.c +++ b/dlls/dxgi/dxgi_main.c @@ -191,7 +191,7 @@ HRESULT WINAPI DXGID3D10CreateDevice(HMODULE d3d10core, IDXGIFactory *factory, I return E_OUTOFMEMORY; } - hr = dxgi_device_init(dxgi_device, &d3d10_layer, factory, adapter, feature_levels, level_count); + hr = dxgi_device_init(dxgi_device, &d3d10_layer, factory, adapter, flags, feature_levels, level_count); if (FAILED(hr)) { WARN("Failed to initialize device, hr %#lx.\n", hr); diff --git a/dlls/dxgi/dxgi_private.h b/dlls/dxgi/dxgi_private.h index ed82d366799..679854afd3c 100644 --- a/dlls/dxgi/dxgi_private.h +++ b/dlls/dxgi/dxgi_private.h @@ -138,7 +138,7 @@ struct dxgi_device }; HRESULT dxgi_device_init(struct dxgi_device *device, struct dxgi_device_layer *layer, - IDXGIFactory *factory, IDXGIAdapter *adapter, + IDXGIFactory *factory, IDXGIAdapter *adapter, unsigned int flags, const D3D_FEATURE_LEVEL *feature_levels, unsigned int level_count); /* IDXGIOutput */ diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index e75c3cf625e..0214d7323a9 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -2783,8 +2783,8 @@ HRESULT CDECL wined3d_get_device_caps(const struct wined3d_adapter *adapter, } HRESULT CDECL wined3d_device_create(struct wined3d *wined3d, struct wined3d_adapter *adapter, - enum wined3d_device_type device_type, HWND focus_window, uint32_t flags, BYTE surface_alignment, - const enum wined3d_feature_level *feature_levels, unsigned int feature_level_count, + enum wined3d_device_type device_type, HWND focus_window, uint32_t flags, uint32_t orig_flags, + BYTE surface_alignment, const enum wined3d_feature_level *feature_levels, unsigned int feature_level_count, struct wined3d_device_parent *device_parent, struct wined3d_device **device) { struct wined3d_device *object; @@ -2795,6 +2795,14 @@ HRESULT CDECL wined3d_device_create(struct wined3d *wined3d, struct wined3d_adap wined3d, adapter, device_type, focus_window, flags, surface_alignment, feature_levels, feature_level_count, device_parent, device); + /* Unity uses shared resources if D3D11_CREATE_DEVICE_VIDEO_SUPPORT succeeds, + * so allow failing for now */ + if (orig_flags != (orig_flags & ~wined3d_settings.no_create_flags)) + { + FIXME("Failing for device create flags 0x%x forced unsupported.\n", wined3d_settings.no_create_flags); + return E_FAIL; + } + if (FAILED(hr = adapter->adapter_ops->adapter_create_device(wined3d, adapter, device_type, focus_window, flags, surface_alignment, feature_levels, feature_level_count, device_parent, &object))) diff --git a/dlls/wined3d/wined3d.spec b/dlls/wined3d/wined3d.spec index da7db0c2184..ddd5939d89b 100644 --- a/dlls/wined3d/wined3d.spec +++ b/dlls/wined3d/wined3d.spec @@ -65,7 +65,7 @@ @ cdecl wined3d_device_apply_stateblock(ptr ptr) @ cdecl wined3d_device_begin_scene(ptr) @ cdecl wined3d_device_clear(ptr long ptr long ptr float long) -@ cdecl wined3d_device_create(ptr ptr long ptr long long ptr long ptr ptr) +@ cdecl wined3d_device_create(ptr ptr long ptr long long long ptr long ptr ptr) @ cdecl wined3d_device_decref(ptr) @ cdecl wined3d_device_end_scene(ptr) @ cdecl wined3d_device_evict_managed_resources(ptr) diff --git a/dlls/wined3d/wined3d_main.c b/dlls/wined3d/wined3d_main.c index 91d8dd567ff..2deefb127b7 100644 --- a/dlls/wined3d/wined3d_main.c +++ b/dlls/wined3d/wined3d_main.c @@ -344,6 +344,8 @@ static BOOL wined3d_dll_init(HINSTANCE hInstDLL) { if (!get_config_key_dword(hkey, appkey, env, "csmt", &wined3d_settings.cs_multithreaded)) ERR_(winediag)("Setting multithreaded command stream to %#x.\n", wined3d_settings.cs_multithreaded); + if (!get_config_key_dword(hkey, appkey, env, "no_create_flags", &wined3d_settings.no_create_flags)) + ERR_(winediag)("Force D3D device creation without support for flags %#x.\n", wined3d_settings.no_create_flags); if (!get_config_key_dword(hkey, appkey, env, "MaxVersionGL", &tmpvalue)) { ERR_(winediag)("Setting maximum allowed wined3d GL version to %u.%u.\n", diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 9537670f7c5..8f6d777168c 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -466,6 +466,7 @@ struct wined3d_settings { unsigned int cs_multithreaded; unsigned int max_gl_version; + unsigned int no_create_flags; unsigned short pci_vendor_id; unsigned short pci_device_id; /* Memory tracking and object counting. */ diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h index 49c6672fa3f..e15982cce54 100644 --- a/include/wine/wined3d.h +++ b/include/wine/wined3d.h @@ -2429,8 +2429,8 @@ HRESULT __cdecl wined3d_device_begin_scene(struct wined3d_device *device); HRESULT __cdecl wined3d_device_clear(struct wined3d_device *device, unsigned int rect_count, const RECT *rects, uint32_t flags, const struct wined3d_color *color, float z, unsigned int stencil); HRESULT __cdecl wined3d_device_create(struct wined3d *wined3d, struct wined3d_adapter *adapter, - enum wined3d_device_type device_type, HWND focus_window, unsigned int behaviour_flags, BYTE surface_alignment, - const enum wined3d_feature_level *feature_levels, unsigned int feature_level_count, + enum wined3d_device_type device_type, HWND focus_window, unsigned int behaviour_flags, unsigned int orig_flags, + BYTE surface_alignment, const enum wined3d_feature_level *feature_levels, unsigned int feature_level_count, struct wined3d_device_parent *device_parent, struct wined3d_device **device); ULONG __cdecl wined3d_device_decref(struct wined3d_device *device); HRESULT __cdecl wined3d_device_end_scene(struct wined3d_device *device); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/11612
Like Henri said on !11398, a config option is a bad solution. Yeah, it is tempting to add an easy workaround for a complicated problem (shared resources), but ultimately it is a dead end. Cross-device and especially cross-process resources (which as I understand it is the real issue for Unity here, not video decoding) is tricky, but we've usually had a policy of leaving these painful bugs open rather than cover them up to create motivation for them to be fixed somewhen. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149074
Like Henri said on !11398, a config option is a bad solution.
Very well. Maybe for staging folks only then. Seemed not too different from winedmo config option so figured worth a try.
Yeah, it is tempting to add an easy workaround for a complicated problem (shared resources),
winetricks and wine-staging seem to add workarounds which may result in similar "cover ups" of bugs that also seem to demotivate fixes indefinitely
but ultimately it is a dead end.
Dead end like DXVK? - https://www.reddit.com/r/linux_gaming/comments/bxy02u/lead_wined3d_developer... NieR bug from DXVK is still open and part of the reason Steam funded independently of what they seem to have considered more dead end: - https://www.gamingonlinux.com/2018/09/an-interview-with-the-developer-of-dxv... - https://bugs.winehq.org/show_bug.cgi?id=44345
Cross-device and especially cross-process resources (which as I understand it is the real issue for Unity here, not video decoding) is tricky,
I'll pull from DXVK as recommended by other Codeweavers for MR-11404. Feels odd pulling from a dead-end as if upstream. Trickest part seems how not to waste tremendous amounts of free time trying to get solutions merged.
but we've usually had a policy of leaving these painful bugs open rather than cover them up to create motivation for them to be fixed somewhen.
For folks giving their free time away to relieve users their frustration with long standing bugs there's nothing quite as motivating as the satisfaction of being able to help them and nothing quite as demotivating as being deprived of it. For folks paid for the same effort I understand may not appreciate the same level of pain. For future folks, I tried removing the stumbling stone for you but it's quite immovable so maybe better to just avoid: - https://bugs.winehq.org/show_bug.cgi?id=54716#c1 - https://bugs.winehq.org/attachment.cgi?id=81854 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149079
This merge request was closed by Stian Low. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612
Your's if you want it @alesliehughes -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149081
On Mon Aug 17 19:34:34 2026 +0000, Stian Low wrote:
Your's if you want it @alesliehughes If so then you may want to add one line to patch so that no_create_flags=0x800 is default:
``` @@ -129,6 +129,7 @@ struct wined3d_settings wined3d_settings = .max_sm_cs = UINT_MAX, .renderer = WINED3D_RENDERER_AUTO, .shader_backend = WINED3D_SHADER_BACKEND_AUTO, + .no_create_flags = 0x800, }; ``` Fixes many long standing UnityPlayer.dll video bugs until D3D11_CREATE_DEVICE_VIDEO_SUPPORT is fully supported. Unknown to break anything after much testing except one app that could neither be named nor described in any detail to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149098
On Mon Aug 17 18:01:49 2026 +0000, Stian Low wrote: > > Like Henri said on !11398, a config option is a bad solution. > Very well. Maybe for staging folks only then. > Seemed not too different from winedmo config option so figured worth a try. > > Yeah, it is tempting to add an easy workaround for a complicated > problem (shared resources), > winetricks and wine-staging seem to add workarounds which may result in > similar "cover ups" of bugs that also seem to demotivate fixes indefinitely > > but ultimately it is a dead end. > Dead end like DXVK? > - https://www.reddit.com/r/linux_gaming/comments/bxy02u/lead_wined3d_developer_henri_verbeet_calls_dxvk_a/ > NieR bug from DXVK is still open and part of the reason Steam funded > independently of what they seem to have considered more dead end: > - https://www.gamingonlinux.com/2018/09/an-interview-with-the-developer-of-dxvk-part-of-what-makes-valves-steam-play-tick/ > - https://bugs.winehq.org/show_bug.cgi?id=44345 > > > Cross-device and especially cross-process resources (which as I > understand it is the real issue for Unity here, not video decoding) is tricky, > I'll pull from DXVK as recommended by other Codeweavers for MR-11404. > Feels odd pulling from a dead-end as if upstream. Trickest part seems > how not to waste tremendous amounts of free time trying to get solutions merged. > > but we've usually had a policy of leaving these painful bugs open > rather than cover them up to create motivation for them to be fixed somewhen. > For folks giving their free time away to relieve users their frustration > with long standing bugs there's nothing quite as motivating as the > satisfaction of being able to help them and nothing quite as > demotivating as being deprived of it. > For folks paid for the same effort I understand may not appreciate the > same level of pain. > For future folks, I tried removing the stumbling stone for you but it's > quite immovable so maybe better to just avoid: > - https://bugs.winehq.org/show_bug.cgi?id=54716#c1 > - https://bugs.winehq.org/attachment.cgi?id=81854 Can we please refrain from attacking wined3d? I cannot express how much the worst part of my job is listening to people comparing our project to DXVK, calling it pointless, accusing us of NIH (a hilarious accusation against a project that existed over a decade earlier), and generally making this my least favourite part of Wine to work on. Having that happen in the Wine patch tracker of all places makes this even worse. Yes, DXVK works better, and a lot of people prefer to contribute to it, and at this point it's probably proven that the "hack around it now, fix it later maybe" style of development is better than our "get the design right first" style. Despite that I'm still sticking to it, and I would even if it wasn't more or less implied by the way the rest of Wine works, because I simply hate the alternative. I don't think you can understand how important code quality is until you've had to maintain a code base like this for multiple years. The one thing I've always loved about wined3d is the code itself; it's been the easiest thing to read and understand in the entire code base, whereas DXVK apparently managed to become unmaintainable after just over two years of development, so maybe not a unilateral win there. (Frankly, I'd also attribute some of the difference to the sudden and tragic loss of one of our most valuable and prolific contributors, as well as CodeWeavers investing in direct Metal-based solutions, the lead maintainer of wined3d burning out, and the current maintainer fighting both health problems and burnout, to the point that I'm still here mostly because someone has to be. But yes, DXVK has its advantages.) Anyway, I understand that you find it tedious and unnecessary, and lack the time, to work on solutions that fit within our planned design, so I've taken what spare time I can muster to implement shared resources properly. That's time I was hoping to spend on getting Damavand to parity sooner, but it's clear this is a higher priority. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149322
Can we please refrain from attacking wined3d?
There's a difference between attacking vs giving an accurate analysis and assessment based on my own account and research to better understand if my account is indeed most accurate.
I cannot express how much the worst part of my job is listening to people comparing our project to DXVK, calling it pointless, accusing us of NIH (a hilarious accusation against a project that existed over a decade earlier),
I am fully aware of the wined3d's sentiments towards DXVK but comparisons are inevitable when decisions are made to deliberately impair users freedom to run their apps how they want. Seeing "dead end" used again to describe my bug fix felt very appropriate to bring up DXVK as another "dead end" for comparison since construction plans to close that road are still delayed indefinitely which may equally apply to my bug fix. I preferred to contribute to wined3d not DXVK. Failing for `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` was not a hack. It was a bug fix until properly supported. And once properly supported it is a feature that promotes users freedom who may not care whether someone refers to it as a workaround and just want the freedom to use it especially when it breaks nothing else for wine.
and generally making this my least favourite part of Wine to work on.
Likewise. My intent was course correction not further disruption. Prioritizing user freedom even over design docs may lead out of further degradation and lack of enthusiasm.
Having that happen in the Wine patch tracker of all places makes this even worse.
Patch tracker is appropriate to raise concerns and comparisons as someone who has spent considerable spare time working on wined3d to acquire an accurate and valid critique and not some of random misinformed troll on reddit from 7 years.
"hack around it now, fix it later maybe" style of development is better than our "get the design right first"
Perhaps DXVK "hacks around" instead of "design right" but I have not looked closely enough to say either way. However failing for `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` was not a hack and simply a bug fix and also a feature that respects users freedom.
I don't think you can understand how important code quality is until you've had to maintain a code base like this for multiple years.
I don't think you understand anything about my background to make a judgement call about my lack of understanding about code quality. My patch did not degrade code quality and was inline with it. It simply added an option to promote users freedom and fix a bug.
The one thing I've always loved about wined3d is the code itself; it's been the easiest thing to read and understand in the entire code base, whereas DXVK apparently managed to become unmaintainable after just over two years of development, so maybe not a unilateral win there.
I have spent little time with DXVK code base but much with wined3d which has felt much less maintainable compared to the few other wine modules I've worked. My assessment is simply about effectiveness to address bugs without compromising users freedom unnecessarily.
(Frankly, I'd also attribute some of the difference to the sudden and tragic loss of one of our most valuable and prolific contributors, as well as CodeWeavers investing in direct Metal-based solutions, the lead maintainer of wined3d burning out, and the current maintainer fighting both health problems and burnout, to the point that I'm still here mostly because someone has to be. But yes, DXVK has its advantages.)
If my experience with wined3d recently is not how it operated in the past of some far better era then it is indeed very tragic and whoever may have been lost who steered the ship in a better direction is dearly missed and their quality and loss is felt among those who have never met them.
Anyway, I understand that you find it tedious and unnecessary, and lack the time, to work on solutions that fit within our planned design,
Design plan was absent but would have avoided tedious unnecessary work I put in to relate 8 years of bugs and finally mark them duplicates and explain to users the problem with clarity and fix their bugs while promoting their freedom which did not conflict with a design plan.
so I've taken what spare time I can muster to implement shared resources properly.
Your spare time seems much more valued more than mine. If I'd submitted identical work it may have been delayed indefinitely. There's an uneven burden of trust and proof that discourages contributors from wasting more of their time when not even their most trivial harmless patches are merged.
That's time I was hoping to spend on getting Damavand to parity sooner, but it's clear this is a higher priority.
My understanding is that shared resources solution only supports to Damavand so it seems to have contributed to higher parity regardless. Based on the number of on-going collected of unmarked duplicates over 8 years, these bugs should have been considered higher priority long before now and should not have required me to raise the priority per missing planned design in any comments. This merge and MR-11398 fix both Damavand and gl. Therefore if your latest Damavand shared resources solution fixes videos alternatively then it is still hidden from users without requiring them to use a special flag like `renderer=vulkan` which is functionality equivalent of `no_create_flags=0x800` Regardless of shared resources, users should still have the freedom to play games using whatever methods UnityPlayer offers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149343
I don't think you understand anything about my background to make a judgement call about my lack of understanding about code quality. My patch did not degrade code quality and was inline with it. It simply added an option to promote users freedom and fix a bug.
For a little clarity regarding my background and understanding importance of code quality: Projects involved years of R&D for mission critical highly available GPGPU accelerated algorithmic solutions for machine vision industrial robotic guidance where moments of downtime accumulate to hundreds of thousands to millions of dollars lost over minutes. I'm not claiming that means the code was pristine but it certainly had to remain maintainable to minimize downtime and support most expeditious fixes if/when bugs occurred. I'm unaware of wine being used for such highly critical and bug sensitive operations but my impression so far is that the urgency and risks are far lower than my experience with other industries. In fact Wine's more laid back and less stressful environment is what I find most appealing. Not to imply the work isn't just as important but that it is able to be performed in what I consider a more healthy mode of operation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149415
On Thu Aug 20 16:06:32 2026 +0000, Stian Low wrote:
I don't think you understand anything about my background to make a judgement call about my lack of understanding about code quality. My patch did not degrade code quality and was inline with it. It simply added an option to promote users freedom and fix a bug. For a little clarity regarding my background and understanding importance of code quality: Projects involved years of R&D for mission critical highly available GPGPU accelerated algorithmic solutions for machine vision industrial robotic guidance where moments of downtime accumulate to hundreds of thousands to millions of dollars lost over minutes. I'm not claiming that means the code was pristine but it certainly had to remain maintainable to minimize downtime and support most expeditious fixes if/when bugs occurred. I'm unaware of wine being used for such highly critical and bug sensitive operations but my impression so far is that the urgency and risks are far lower than my experience with other industries. In fact Wine's more laid back and less stressful environment is what I find most appealing. Not to imply the work isn't just as important but that it is able to be performed in what I consider a more healthy mode of operation. If my GPGPU background is better suited for modules outside of wined3d please let me know so that I cause no more unnecessary disruptions and time wasted for anyone. wined3d and graphics in general are parallel with GPGPU background which is why I engaged with spare time.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149416
Prioritizing user freedom even over design docs may lead out of further degradation and lack of enthusiasm.
Design docs should always prioritize user freedom which will likely lead to bugs caught and fixed much more easily in the future which is very obvious in this case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149439
Your spare time seems much more valued more than mine. If I'd submitted identical work it may have been delayed indefinitely. There's an uneven burden of trust and proof that discourages contributors from wasting more of their time when not even their most trivial harmless patches are merged.
Projects involved years of R&D for mission critical highly available GPGPU accelerated algorithmic solutions for machine vision industrial robotic guidance where moments of downtime accumulate to hundreds of thousands to millions of dollars lost over minutes.
Level of trust to lead R&D projects vs adding simple optional flag to fix video bugs to promotes user freedom is so drastically different that it begins to approach absurd. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149440
On Thu Aug 20 18:28:58 2026 +0000, Stian Low wrote:
Your spare time seems much more valued more than mine. If I'd submitted identical work it may have been delayed indefinitely. There's an uneven burden of trust and proof that discourages contributors from wasting more of their time when not even their most trivial harmless patches are merged. Projects involved years of R&D for mission critical highly available GPGPU accelerated algorithmic solutions for machine vision industrial robotic guidance where moments of downtime accumulate to hundreds of thousands to millions of dollars lost over minutes. Level of trust to lead R&D projects vs adding simple optional flag to fix video bugs to promote user freedom is so drastically different that it begins to approach absurd. Calling another config option a "dead end" was probably too strong a word on my side, and for that I apologise. Maybe "slippery slope" would be better. Add one option here, add another there and you end up maintaining options instead of the code itself. Remove an option that becomes bothersome and someone will be angry about it. I am happy for wine-staging to carry something like this - which is what a lot of distributions ship by default. That's what staging was intended for: Keeping quality of life improvements and new features that we know have value, but also problems, and can become stumbling blocks in the future.
Now staging is maintained by a volunteer and we all have to take care of our energy as well. So Alistair may or may not take it, I'll leave it up to him. (MESA has envars to disable selected OpenGL extensions or limit the advertised GL version. To my knowledge no such thing exists for Vulkan, likely for the same reason. It would have been at least a driver specific workaround to disable video decoding support.) We're well aware that dxvk is working better for gaming on Linux, so the question if our approach is suitable for 3D libraries or games is a fair one to ask. To give two examples of how/why Wine prefers to look for a "proper" solution over aiming to ship something that provides immediate user value: Elizabeth is the developer who got ntsync into the kernel. Doing so involved painstaking work to convince the Linux kernel developers (and ourselves) that putting NT sync primitives into the Linux kernel was the only way to go. To get to a convincing conclusion she spent years attempting a more targeted adjustment (e.g. add a WaitForMultipleObjectsEx-like call and use it via esync/fync). To get other developers to agree to your design takes a lot of effort. Those other developers (kernel devs in this case) are on the hook for keeping it working in the future. Similar painstaking infrastructure work was adding arm64 and arm64ec support to compilers and mingw. I had some x86 Windows applications running on arm64 in 2017 in Hangover, but became clear that the approach would hit a wall. It took 9 years to build the infrastructure to replicate what Windows is doing. And good thing we have it, because in the meantime DRM and Anti-Cheat systems started poking at the x86/x86_64/arm64 boundaries. So why not ship esync for games and let users enable/disable it (as e.g. Proton and CrossOver did/do): We'd be spending time trying to patch up one corner case after another to make one more thing work while the interest on both our and the kernel's end to fix the design flaws is low - because it's kinda sorta working anyhow. Likewise if Hangover was taken as the "it works now" solution I'd still be patching up corner cases in my autogenerated Win32 API thunks. And yes, that is a value judgement / guess on the future that is contentious since about as long as Wine exists. Make the better (there sadly is no perfect) the enemy of the useful? I hope my wordy comment succeeded at calming things instead of making things worse :-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149444
I hope my wordy comment succeeded at calming things instead of making things worse :-)
Your comments have helped along with !11720 and related to override !11398 to use existing flag with new value `backend_decoder=none` to support equivalent user freedom to fix bugs. Therefore rephrasing from "dead end" to "slippery slope" to its latest form as more "narrowed vs wide open pathway" is appreciated. My philosophy will always drive me toward advocating for maximizing user freedom which is the reason I still support this merge but top priority for me was providing solutions for users video bugs as immediately as possible which will be fulfilled soon by some combination of in-process merges. I appreciate more historical perspective and hope I don't rock the boat too much as a newer contributor with competing priorities. Hopefully overall it leads to more positive outcomes despite rough waters sometimes. Regarding those other lost irreplaceable wined3d contributors, you're their legacy now so lets honor and make them proud. Fwiw these efforts have renewed wined3d enthusiasm for me so I feel I owe wined3d more payback work. If that does not sounds like too much of nightmare to maintainers then I'll continue. Otherwise please let me know if I may provide better relief elsewhere. I'm here to serve however I may be needed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149523
participants (4)
-
Elizabeth Figura (＠zfigura) -
Stefan Dösinger (＠stefan)
-
Stian Low
-
Stian Low (＠stianlow)