My dude,
You don't need to be so subtle in your wording given you've told me explicitly before when I reported an esync bug that was *completely unrelated* to D9VK:
"anyway, your project does not benefit Wine at all, so I have no incentive to help it. if you ever feel like benefiting Wine, come back and then we'll talk"
If you genuinely feel that DXVK has no benefit to and no part in the "Wine ecosystem" then /shrug
Our projects serve entirely different purposes and have entirely different development philosophies.
The whole reason I left CW and perused D9VK independently was simply because I wanted to *avoid* all the potential drama of me working on D9VK full-time because I knew it was inevitable and I didn't want to sacrifice my career safety over stupid petty drama that always seems to come up.
WineD3D is good at what it does, and it serves its purpose well, but:
When I was brought on to work on that, I was way more interested in what could potentially be done without caring about the limits of maintaining such immense backwards compatibility (ie. OpenGL and especially super ancient GL.)
I think that the WineD3D backend is completely GL-centric and detaching that in a way where both renderers work using common code and you still get any advantage from using Vulkan seemed waaayyy more work than adding a D3D9 frontend to DXVK from scratch.
I wanted to do things my way as well -- and my way would not be accepted in Wine due to the C89 mandate; to me, implementing COM + D3D in C++ is much nicer: having genuine shared bases for unknown, device children, RAII for ref counting (COM, private COM, and internally.)
I'm really not a fan of WineD3D's command stream implementation, it's really annoying to follow what a function is actually doing -- but I understand that doing that in C89, it's probably the cleanest it is going to be.
Defining command stream functions via lambdas (ie. we can combine stuff into a unique (or automatically shared if it's the same!) CS func in a function) is super nice and easy to follow and something I definitely wouldn't want to give up.
I am not saying I think C++ is a good language overall, but for implementing a C++ API, I would definitely say it is a good choice. :P
I also don't have to maintain compatibility with however many versions of Office, GCC, etc -- nor do I have commercial customers that depend on that. I'd prefer to make an effort to improve performance and have some regressions from stupid mistakes I make than to have to worry about "if it ain't broke don't fix it." -- I don't have that concern, but you guys' commitment to compatibility like that is certainly respectable and commendable. :)
Hopefully this helps you to understand my viewpoint...
I don't have any disdain, grudge or hatred against you or what you work on; (at the very least) the d3d9 frontend of DXVK wouldn't exist without WineD3D as an occasional reference.
I would like to improve our relationships and for us all to get along without this weird tension and passive aggressiveness -- admittedly from both sides at times.
We're all human! (or frogs in my case. :P) 🐸
If you want to speak more you can always email me or whatever. :)
- Josh 🐸
---- On Fri, 21 Feb 2020 16:06:15 +0000 Zebediah Figura mailto:z.figura12@gmail.com wrote ----
On 2/21/20 1:20 AM, Stefan Dösinger wrote:
Hi,
Since we had troubles getting GSoC students and project ideas in the past year I'd like to bring up a controversial suggestion: Talk to the projects that popped up around Wine like PlayOnLinux, Lutris, DXVK if they have GSoC-compatible ideas and host them as a Wine GSoC project.
Ideally those projects would be something that reduces friction between upstream Wine and other projects. E.g. on FOSDEM I talked with Josh Ashton and he mentioned d3d behaviors that some games depend on for which we don't have tests and that sometimes work in wined3d by accident or don't work. Syncing those lessons by writing and upstreaming proper Wine tests would be a valuable thing for everyone.
I don't know enough about PlayOnLinux or Lutris to suggest anything outright, but I still think it's worth asking them.
Cheers, Stefan
I think it's worth asking at least if helping the project will benefit Wine in some way. I know that some of those projects have helped the Wine ecosystem and even sent patches upstream, whereas some have decided not to do so and instead to be an independent fork.