Summer of Code and Projects around Wine
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
On Fri, Feb 21, 2020 at 4:20 PM Stefan Dösinger <stefandoesinger(a)gmail.com> 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'm on-board for this. I think we can at least try to find out what ideas they have and gauge their usefulness to Wine itself. An ideal situation could be a project involving contributions to both Wine upstream and the other projects. I guess it'll depend on how compatible the ideas are, as you mentioned.
Cheers, Aaryaman
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.
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(a)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.
Hello Joshua, On 2/21/20 9:05 PM, Joshua Ashton wrote:
*//*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) 🐸
It's not my intent to personally attack you, DXVK, D9VK, or anyone else. For that matter, Philip Rebohle has several times contributed patches to Wine. I'm simply trying to make the point that it doesn't make much sense to sponsor projects that aren't part of Wine, if the work that comes out of those projects isn't directly flowing back into Wine. Many projects benefit Wine indirectly—DXVK is of course one—but it would not make sense for Wine to sponsor a GSoC project to work on, say, GStreamer, or the Linux kernel. On the other hand, it might make sense to sponsor a GSoC project to work on Wine-Staging—it's essentially a forked codebase, but its patches flow upstream (given enough time on the part of the Staging maintainers...)
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 <z.figura12(a)gmail.com <mailto:z.figura12(a)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.
On Fri, Feb 21, 2020, 23:53 Zebediah Figura <z.figura12(a)gmail.com> wrote:
Many projects benefit Wine indirectly—DXVK is of course one—but it would not make sense for Wine to sponsor a GSoC project to work on, say, GStreamer, or the Linux kernel.
IMO GStreamer or the kernel would be acceptable, if it's focused on something that wine needs. I.e. some new codec or a kernel feature that would benefit DRM, etc. We did such a project a few years ago with GStreamer, though I wouldn't use the results from that project to influence the current discussion ;).
So I'll hijack this thread a bit... Would a GSOC project to improve the TestBot make sense / fit into the GSOC mandate? Like some other proposals it would not be on the Wine codebase but still the Wine infrastructure. Here are some ideas: * Javascript-ification of the site The goal would be to avoid reloading pages all the time. - A prime target would be the job details page which reloads every time one shows / hides a log or a screenshot. Screenshots would be easy. The interesting part would be to have the website provide an API to retrieve the logs which the JavaScript code would then insert in the right place. - Another target could be the main page. Instead of reloading all of it JavaScript could use an API to retrieve just the updates and refresh the page accordingly. - The job submit page could also benefit from this. * Swap TestBot's Object Relational Mapper - The TestBot uses its own Perl ORM implementation which has a lot of issues: https://bugs.winehq.org/show_bug.cgi?id=45023 - These issues were quite troublesome at some point but the TestBot code works around them and they are not hindering the kind current development. So replacing the ORM is low priority now. However performance is pretty bad. My feeling is that it's an order of magnitude slower than it should. See for instance the load times for the home and activity pages. - So swapping it for an ORM we don't have to maintain would be nice. I don't know if it would fit for a GSOC though. There's one part which is figuring out if there's a way to implement the old API on top of the new one to ease the transition. That would probably be a good fit for part of a GSOC. The second part is switching the code to the new API and which may be repetitive and not particularly educational. - Also if reimplementing the old API on top of the new one is not possible it the only way to test and perform the switch may be with one big commit that changes everything :-( * Implement load balancing and failover https://bugs.winehq.org/show_bug.cgi?id=39412 This implies: - Adding a middle layer between tasks and the VM configurations they are supposed to run on. - Modifying the database schema to represent the VM exclusions: - If the w1064 VM has French and English configurations only one instance can be run at a time because both are in the same VM. - For most VMs we only have a single OS license so only one instance must run at a time even if the VM is present on two hosts. For others (e.g. Debian) we could allow more than one instance to run at a time. (use IP addresses as a proxy for license counts?) - Update the code that depends on the above changes (essentially everything). - Update the task scheduler to take into account all these constraints. That may be too much for a GSOC though. * Research VM isolation and resource allocation The goal would be to be able to run multiple VMs simultaneously without having one VM interfere with the timing of the tests in another VM. Once it works it opens up a number of issues though: - Core pinning seems like it would be required. Then how do we allocate cores to VMs? Can we make it so the TestBot runs 4 2-core Windows VMs while the Debian VM that normally gets 8 cores is powered off? Or is that so complex that only a static core allocation is workable? (it would certainly be better than the current scheme anyway) - How do we make it so the TestBot does not start two VMs that need the same PCI-passthrough graphics card at the same time? Note that this is probably closely related to the exclusion mechanism for the failover project above. - Can we assume that the number of cores will always be the limiting factor or should we add memory constraints? The TestBot hardware may not be ready for this type of work in time for this year's GSOC though, and it may be hard for a student to get hold of a beefy enough system to meaningfully test these issues (or to work on them remotely). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation
Am 26.02.20 um 04:31 schrieb Francois Gouget:
So I'll hijack this thread a bit...
Would a GSOC project to improve the TestBot make sense / fit into the GSOC mandate? Like some other proposals it would not be on the Wine codebase but still the Wine infrastructure.
We had a gsoc project in 2018 about extending my automated performance tests, so personally I would say the testbot qualifies too.
Am 26.02.20 um 02:31 schrieb Francois Gouget:
So I'll hijack this thread a bit...
Would a GSOC project to improve the TestBot make sense / fit into the GSOC mandate? Like some other proposals it would not be on the Wine codebase but still the Wine infrastructure.
I'd say testbot is totally qualified for GSoC, please add your ideas to the list on the wiki
I'm not sure does it make sense to post a news about Wine's GSoC in WineHQ.org? On Tue, Mar 3, 2020 at 8:16 PM André Hentschel <nerv(a)dawncrow.de> wrote:
Am 26.02.20 um 02:31 schrieb Francois Gouget:
So I'll hijack this thread a bit...
Would a GSOC project to improve the TestBot make sense / fit into the GSOC mandate? Like some other proposals it would not be on the Wine codebase but still the Wine infrastructure.
I'd say testbot is totally qualified for GSoC, please add your ideas to the list on the wiki
-- Regards, Jactry Zeng
participants (8)
-
Aaryaman Vasishta -
André Hentschel -
Austin English -
Francois Gouget -
Jactry Zeng -
Joshua Ashton -
Stefan Dösinger -
Zebediah Figura