protonscr

wine's test suite

dxvkclosed enhancement
doitsujin/dxvk#206 · opened 2018-03-26 by notaz · updated 2019-06-15 · 2 comments · github
Nnotaz 2018-03-26 github

I think dxvk would benefit greatly from being able to run wine's tests, not only for demonstration of Windows behavior, but also for regression testing. Wine's build process is already able to build a test exe for running on native Windows ("make crosstest"), and that can be run under dxvk. However that doesn't get far.

most dxgi tests are doing something like:

D3D10CreateDevice1(..., &device);
ID3D10Device1_QueryInterface(device, &IID_IDXGIDevice, (void **)&dxgi_device);
IDXGIFactory_CreateSwapChain(factory, (IUnknown *)dxgi_device, &swapchain_desc, &swapchain);

D3D10* can be easily replaced with D3D11* equivalents, however swapchain creation always fails with

warn: DxgiDevice::QueryInterface: Unknown interface query
warn: 79352328-16f2-4f81-9746-9c2e2ccd43cf
err: DxgiSwapChain::DxgiSwapChain: Invalid device

So it seems swapchain creation only works if D3D11Device is passed, while it should work with DxgiDevice too. Seems to be a design issue, can it be fixed?

Ddoitsujin maintainer 2018-03-26 github

It's probably trying to pass a device created by wined3d, which doesn't work. IDXGIDevice is not the issue (in fact, my swap chain code queries that interface), but that error message means, that either the device doesn't implement IDXGIDevice or an internal interface that connects the DXGI swapchain to the D3D11 device. In this case, it's probably the latter.

But yes, I agree that some sort of testing would be useful, but DXVK still doesn't implement everything that wine does (and vice versa) so there are going to be problems.

Ddoitsujin maintainer 2019-06-15 github

So after fixing a bunch of bugs that caused test failures, my conclusion is as follows:

  • There's still a large number of failures due to incorrect reference counting behaviour. It is not obvious what a correct implementation would look like, so I'm going to leave it this way for now.
  • Most other failures come from the fact that DXVK has more lenient validation than native D3D. It's better to be more lenient than to be too strict, and in some cases it isn't immediately obvious what the correct fix is, so most of this can probably be ignored for now as well.
  • There's also a whole bunch of "test succeeded inside todo block", which wine counts as test failures even though they pass (!?).

I'm going to keep testing this against wine's test suite going forward, but blindly aiming for passing all of them might do more harm than good.

Nothing extracted yet.