On 6 October 2014 10:51, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2014-10-06 08:13, schrieb Henri Verbeet:
There's no reason the D3D command stream work couldn't have been done against upstream Wine, and in fact that's exactly what I did before handing it over to Stefan. (For reference, one of the first commits for that is 1ef4f075c160a826a57e8cf5613a3211005c8eb9.)
I don't think so, mostly because it's next to impossible to upstream something that has a reasonable probability to need reworking later on. E.g. I went through a number of iterations of ways to handle
In my experience that's not true at all, unless you actually mean "is obviously going in the wrong direction" with "has a reasonable probability to need reworking later on".
resource updates until I found one that actually works with real-world OpenGL implementations, and I know even the current way is flawed, even though it works in practice. Yet I believe writing the current code was essential to find out what the actual driver limitations are and which requirements/bugs games have.
There's of course no reason you can't test your own code without a staging tree. And quite frankly, almost all the work I did on the command stream without a staging tree is upstream, and very little of yours is.
There are probably legitimate arguments for having a staging tree, but the wined3d-csmt tree is more of an argument against than for. Properly maintaining a staging tree is real work, and not necessarily a lot of fun. Historically these kinds of trees haven't ended up being an overwhelming success, but who knows, perhaps this time will be different. As long as it doesn't take away too much from the already somewhat limited testing done against the main tree, I just wish everyone the best of luck. (I.e., I'm fairly skeptical this will work out, but as long as it doesn't cause the project too much trouble I see no reason to tell other people what to do with their free time.)