MR-11612 has been closed for support of more expanded form of this solution per wined3d reviewer feedback so this is an update regarding it. - https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149079 MR-11612 was referred to as a "dead end" which wined3d maintainers also seem to consider this patch despite expressing that it may be merged if narrowed to its current form so it may still be at risk of rejection. However MR-11404 as share resources alternative has been recommended to be pulled from DXVK implementation which wined3d maintainers have also called a "dead end." Therefore both solutions seem at risk of rejection for similar sentiments with the latter due to affiliation with DXVK as a source of contention for wined3d maintainers. It is unfortunate but it seems supporting user freedom is not top priority for wined3d team but rather secondary to other priorities which seems imbalanced and misaligned with what should be core values. DXVK seems so successful because users are more top priority. If wined3d team were to prioritize supporting user freedom more then these video bugs probably would have been fixed sometime over the past 8 years. Since providing this trivial solution to fix these video bugs, wined3d maintainers have indicated that these bugs are deliberately not fixed either to not "cover up" other bugs or to not break 1 unknown app that still cannot be named nor explained in any detail. Deliberately undermining user freedom over priority to not "cover up" other bugs seems to have proven ineffective and instead led to a different "cover up" of the underlying problem that lead to 8 years of unnecessary confusion and frustration also. If the strategy not to "cover up" were effective then at very least bugs would have been marked duplicate and clarified by those who chose to deliberately limited users freedom to have their apps work. Because `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` was believed to be supported until proven false during this merge request, it seems these bugs may not have actually been left deliberately broken but rather by some accident which introduced bugs that unnecessarily limit users freedom. Bottom line, UnityPlayer is meant to support fallback video playback so users should have the freedom to use it. It's possible there may be performance differences that further justify it but regardless users should have the freedom to choose which this merge and MR-11612 promoted over any other priorities like unclear maintenance concerns or one mysterious app which would not be broken by this merge. Therefore my advice to any users who wanted this merged is to choose to align with the team that cares most about your freedom which at this moment is DXVK and proton teams rallied around it. Solutions that prioritize user freedom referred to by wined3d team as "dead end" seem to come from a place of misaligned priorities. Some paths are still wide open and free flowing with solutions despite wined3d wishing they were closed as dead ends as soon as possible. If user freedom is not eventually better prioritized by wind3d then perhaps a new d3d1ring to rule them all may be appropriate to be trusted in the hands of those who always put user freedom first. Part of my focus on wine d3d was to better understand how to most universally support indie game endeavors. My hope was to add more universality but some dependencies seem too immovable and gate kept from the most trivial progress in a most counterintuitive way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11398#note_149268