Valve Developer Andres Rodriguez Lands First Patches Into RADV Vulkan Driver

[Geopirate]

Talos Principle is developed by Croteam and published by Devolver Digitial who are a quite DRM-free friendly publisher (many of the games published by them are sold on GOG, including recent ones). So it's not about Croteam being interested in DRM. It's about them not caring about lock-in and not being interested in releasing anything to non Steam users. They said so explicitly. This demonstrates how "open" Steam ecosystem really is. I.e. it's not, because many Steam tools introduce lock-in for developers.

I explicitly said AAA games. It costs a lot more to have a team of 100+ work on something for 4+ years vs a dozen people for a year. What AAA games from them went straight to GOG?

[bridgman]

I understand all your reasoning already bridgman however not coordinating kernel work openly is wrong and that is the crux of the problem.

Yep, in hindsight I should have asked you and others up-front how much time you expected to have available, and then we could have figured out a "who does what" plan based on that. I ended up being surprised by the amount of time you put into amdkfd - based on our discussions I was expecting less time and in different areas - and that understanding persisted until you had actually done quite a bit of work and started talking about your patches.

I am not so naive to understand certain things are done behind firewalls for all sorts of reasons and there is a balance to be had there.

In fairness, we are doing frequent pushes to a public repository. On the graphics side we have already shifted to a model where most of the component work is done directly in upstream repos, and we are trying to move our kernel work in that direction as well. It's not trivial, because a lot of our business does rely on shared code across multiple OSes, but we are doing it.

But `drivers/gpu/drm/amd/amdkfd` isn't a AMD silo where only AMD are allowed to touch, I could have just as easily sent in patches to make my own take on ioctl() pinning semantics and where would AMD be then if they wanted a variation on that?

We had published an RFC which had been reviewed and discussed a bit, nobody had expressed any interest in implementing the functionality in the RFC, and so I saw getting that functionality ready as the top priority. Do you disagree with that ?

If you had responded to the RFC with a different proposal that would have been welcome.

I literally didn't out of being mindful of it but why should I be mindful if AMD isn't coordinating? That isn't how kernel development works as you well know by now and that is my point, I am not trying to flame you I am trying to coordinate effort with you.

I guess I wasn't envisioning a community following upstream conventions until the dGPU code was actually upstream. Maybe that was wrong, I don't know. It certainly would have been better if I had had enough free time for informal discussion over the last year - that would have probably avoided any of these disconnects - but last year there just weren't enough hours in the day. I am hopeful this year will be better.