Summer of Code and Projects around Wine

[Stefan Dösinger]

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

[Aaryaman Vasishta]

On Fri, Feb 21, 2020 at 4:20 PM 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'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

[Zebediah Figura]

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.

[Joshua Ashton]

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

[Zebediah Figura]

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 
> <[e-mail] >* 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.

[Austin English]

On Fri, Feb 21, 2020, 23:53 Zebediah Figura  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 ;).
>

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

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

[Stefan Dösinger]

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.

[André Hentschel]

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

[Jactry Zeng]

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

[André Hentschel]

Am 22.03.20 um 15:34 schrieb Jactry Zeng:
> I'm not sure does it make sense to post a news about Wine's GSoC in WineHQ.org?

Yes, that'd be a good thing. Could you do that please?