We could add a flag that suppresses the view -> texture reference for this case, which isn't great.
I tried to do this and it ends up getting bad. The big problem is we need to absolutely make sure that the resource is released after all the views are dead, which is a lot harder to guarantee if the views aren't holding a reference. The last straw, that made me decide to abandon this, was the case where the last reference to a resource is dropped while a view is still bound to the device state (i.e. the texture has already been unset in the stateblock but the stateblock hasn't been applied yet).
I see a few paths forward, and I'd appreciate opinions from other d3d developers, since I don't really know what's best:
* Feed SRVs instead of textures through wined3d_stateblock? This does result in some unfortunate duplication, though.
- Also, it was my tentative plan to implement texture LODs as *non-identity* SRVs, again doing this translation at stateblock application. [For GL, if we don't have ARB_texture_view, we'd detect the case where a view differs only by level bounds and set GL_TEXTURE_BASE_LEVEL.] Possibly we could also do sRGB toggle this way, but that's less trivial because GL_TEXTURE_SRGB_DECODE_EXT is a sampler state.
If we do this, we'll probably (but maybe not?) want to cache these views rather than creating them every time.
The idea here is again to let Vulkan work "for free", but on the other hand, it doesn't really help the GL side (unlike this patch series), so it ends up being a complexity trade, and maybe we don't actually want to do this part. One potential reason the trade is worthwhile though is that it avoids letting that extra logic exist on potentially hot paths for d3d10+, but I don't know if that's a real benefit worth considering.
* Just create the views every time instead of caching them? I worry about the performance impact of this. I can't claim to have measured it, though.
* Throw out this patch series and keep state->textures around. Not thrilled about this option though; I think the code simplification is a pretty substantial improvement.
* Create a high level texture object for d3d 1-9. Not sure how to name this. It would contain a wined3d_texture and the cached SRV(s), as well as the texture LOD, and probably the managed textures (CPU vs GPU) factored out from d3d8/9. Stateblocks would deal in these instead of wined3d_texture directly. I like this option architecturally, but it does mean more boilerplate, and adding new layers and structure like this is not something that should be taken lightly.