Wine Direct3D Command Stream Not Landing Anytime Soon
As a continuation of the article earlier about a kernel-like staging tree for Wine, there's one mailing list post in particular that deserves its own post... It appears for at least the time being that the Direct3D command stream patches have been stalled from being mainlined.
Many Phoronix readers have been after these patches as the D3D command stream patches offer significant performance gains by offloading some of the Direct3D workload to a separate CPU thread. These patches have been talked about for more than a year, have been expressed as a potential requirement for Wine 1.8's release, but sadly have not been mainlined.
This past week was an explanation by Stefan Dösinger on the Wine staging tree mailing list thread that he's stopped pursuing the process of mainlining the work for the time being:
Many Phoronix readers have been after these patches as the D3D command stream patches offer significant performance gains by offloading some of the Direct3D workload to a separate CPU thread. These patches have been talked about for more than a year, have been expressed as a potential requirement for Wine 1.8's release, but sadly have not been mainlined.
This past week was an explanation by Stefan Dösinger on the Wine staging tree mailing list thread that he's stopped pursuing the process of mainlining the work for the time being:
I stopped working on upstreaming the command stream after you [Henri Verbeet] made a d3d10/11-like resource interface the de-facto requirement for merging location management in a (sub-) resource class (https://www.winehq.org/pipermail/wine-patches/2013-October/127312.html, and later on a series that introduced a subresource class in the wrong way). I worked on moving away some surface and volume methods as time permitted but gave up on upstreaming the CS until you're done with d3d10/d2d.Until Wine is done with its Direct3D 10 support might be a while...
The same concern regarding resource structures would apply to 694cdcc41cc74eff8c1d96ac0e18895862b22476 and the draw_binding counterpart in my eyes. Maybe it's time to re-visit merging location management in the resource class without first eliminating surfaces and volumes entirely after I'm done with the focus loss work? (Otherwise I'll go on moving away more calls to surfaces and volumes.)
23 Comments