http://bugs.winehq.org/show_bug.cgi?id=59847 --- Comment #8 from Zeb Figura <z.figura12@gmail.com> --- Sorry I missed this reply. (In reply to Artem S. Tashkinov from comment #6)
(In reply to Zeb Figura from comment #5) That said, from a user perspective, long-standing gaps tend to push people toward workarounds such as DXVK, especially when those alternatives appear to work better for many real-world applications. I understand that third-party libraries are not Wine's responsibility and that this tracker is for Wine itself.
Believe me, I am well aware that wined3d lags behind DXVK. I do not need to be reminded day in and day out that our d3d implementation isn't good enough and that it's my fault people use DXVK. I do not ask people to use wined3d instead of DXVK in general. However, if people are going to file a bug in our bug tracker, it needs to be a bug against Wine. DXVK has very clearly communicated that they do not want to be associated with Wine. Bugs in DXVK are not our responsibility. Furthermore, we have only a fraction of the bandwidth that we need to respond to user reports in general, so if a bug looks like it *might* be DXVK's, we ask the user to test with upstream Wine instead, instead of potentially spending our time debugging DXVK's bug.
So the later crash may well be DXVK-specific and outside the scope of Wine's bug tracker. But the no-overrides WineD3D failure still seems to be a real missing-feature issue, not an invalid report. Is the intended conclusion that this should simply be tracked under bug 46594 instead?
Since we already have the bug, I think so.
There is also the separate complication that 3DMark Vantage appears to require native d3dx10_43.dll and d3dcompiler_43 to get this far. That makes relying on Wine's built-in components alone difficult even for an application from the D3D10 era.
There is some leeway when it comes to native components, or DXVK for that matter; I don't always ask a user to test only builtin components if it doesn't look like they matter. It's worth noting on the other hand that Wine developers generally can't debug with Microsoft DLLs in the prefix, lest we risk seeing what calls those DLLs make under the hood. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.