[Bug 48072] Everquest Classic: Textures not working correctly

WineHQ Bugzilla wine-bugs at winehq.org
Thu Nov 14 18:56:18 CST 2019


https://bugs.winehq.org/show_bug.cgi?id=48072

--- Comment #14 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to tram from comment #13)
> Ya this worked in 4.19 with the patch applied.  Good to go I'd say.
> Can the developer explain how the patch worked/what caused the issue just
> for my education?  Thanks :)

Sure. wined3d has an internal "command stream" thread, which serves the dual
purpose of serializing commands sent by multiple client d3d threads, and
improving performance by allowing those threads to execute asynchronously.
Because of its asynchronicity, the command stream thread has its own state.
That state doesn't carry a reference to resources which have a reference count
attached (e.g. textures), I think because destruction of resources also has to
go through the command stream.

When IDirectDraw7::SetCooperativeLevel() is called, we (among other things)
tear down and recreate the wined3d device. Commit 96547e622 fixed an error
where the CS might try to use a resource after it had been freed, since
state_cleanup() releases all resources bound to the current state in the
wined3d_device, but previously no corresponding call was made for the CS.

However, it in turn did not get rid of the discrepancy between device state
cleanup and CS state cleanup—since wined3d_cs_reset_state() resets *all* state,
but state_cleanup() only resets allocated resources. Now the CS is holding the
default state, whereas the device is holding stale sampler state. In practice,
this wouldn't matter—another part of SetCooperativeLevel() is restoring the
state from before it was called—except that the functions that set state skip
doing anything (including signaling the CS) if the device already has that
state.

So, in summary, before 96547e622, both bugs cancelled each other out:
wined3d_device_set_sampler_state() didn't update the CS state, but the CS state
was stale and so was correct anyway. 96547e622 fixed the second bug; the
attached patch essentially fixes the first, by making sure that the device
state is completely reset to the default state.

That may have been a bit long-winded, but I tried to include all the context
necessary for a newcomer to understand the problem.

-- 
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.


More information about the wine-bugs mailing list