Interesting.
I'm not sure why this is supposed to be correct since this means that resource views can legally have dangling pointers to already deleted resources, undermining the whole idea behind reference counting. This looks wrong on so many levels.
Also I'm not sure why games would actually care about the internal reference count of a d3d object.
Anyway, I'll look into that, thanks for linking the relevant wine bug reports.
You can reproduce it with the Elemental Tech demo: http://www.techpowerup.com/downloads/2368/Unreal_Engine_4_Elemental_Tech_Demo.html (can be downloaded from that page without registration)
About how this is supposed to be correct my guess is it's expecting d3d11 to keep just one ref, and doing an assertion based on that to find out if the application bookkeeping is being done properly, but tbh I don't know much about internals so I can be completely wrong.
the problem is that d3d11 isn't supposed to keep any refs to resources (otherwise you wouldn't be able to destroy resources), only to views of resources. Which is what makes this matter so weird.
Anyway, thanks for pointing me to the Elemental demo, will try that.
Ok, just note I set the title following up on the wine bug, but maybe it's wrong as well, we just know apps are getting that error about backbuffer->GetResource() (i think the error in ue4 is always about the backbuffer resource so might not be something general about all resources as the title implies).
Fixed in master, although I'm rather unhappy with the current solution.
At least some UE4 games will bail out on start with a message similar to the following one:
(they show a popup window with the error and they quit)
Seems to be some kind of internal assert by the engine to ensure no leaks on their part, but it depends on having the same refcount as original d3d11 (just guessing :)).
This already happened and was fixed in wined3d:
I have tried locally implementing a similar fix with the following (incorrect) patch:
This worked in getting the detected refcount down, but seems dxvk is still keeping one more reference somewhere, so removing the view's strong references is not enough (I went from "has 4 refs" to "has 2 refs").
Software information
Not specific to one game but see wine bug 40938 for some examples
Can be reproduced with the UE4 Elemental Tech Demo
System information