Mesa RFC Changes To Help Worms WMD, Tropico 5 & Crookz

[starshipeleven]

Edit: And being bound to SteamOS or to several distributions forking MESA for gaming would be a disaster for our Linux ecosystem...

Not that much, people on AMD must use third party repos for Mesa anyway, and those on NVIDIA use the blob. So what happens is that this patch will get merged in the third party repos anyone is already using, and the situation remains more or less the same.

EDIT: actually the situation will improve for SteamOS, that will start to become a true pre-made gaming distro and not just a custom Debian thing.

Really, you are too negative about this.

[boltronics]

I don't like it. When the developers of these games don't want to care about their Linux compatibility it should be revoked. Valve is responsible to assure the quality of the products in their catalog.
It's Valves choice to fix bugs of others, but it's very bad for the state of open source distributions and starts an encapsulation of SteamOS. I'm extremely worried how this will turn out.

To be fair, Dying Light came out ages ago, back when Mesa probably had OpenGL 4.1 at best. It would upset a lot of people if Valve said "sorry Feral, you can't release Deus Ex: MD until you support Mesa". Likewise, it would upset a lot of people if Valve later said "Hey Feral, Mesa is now good enough to run your game but you still aren't supporting it - hence we're taking down your game from the store" - particularly if Feral is no longer paid to maintain that particular game or doesn't see enough future revenue potential for it.

Games can take years to develop. Valve would have to give developers a lot of notice before they start enforcing policies to not allow games unless they limit themselves to using features which Mesa supports.

Perhaps an okay compromise would be for Valve to remove all references to a game from the front page when the game is known to be problematic with Mesa without a good explanation. Even if any problems cited with Mesa were later fixed but the game requirements weren't updated to reflect that, losing access to the front page well after release wouldn't be such a significant issue. However taking a game off the front page at launch for not supporting Mesa (when there was no good reason for not doing so) would probably hurt the bottom line enough - especially since many AMD sales would already have been lost - to encourage developers to make sure the game works and is supported.

OTOH, if they still don't bother supporting Mesa and lost access to the Steam store front page promotion at launch for GNU/Linux, the developers/publishers could argue that sales for the game on GNU/Linux were not as high as expected, and refuse to create future GNU/Linux releases. It would be a hard balancing act, and Valve would have to work to demonstrate to the developer/publisher why those sales were unusually low in that case.

[oooverclocker]

If games are a priority for Mesa, then they are in too vulnerable a position to force their principles on the matter.

I wouldn't allow this for Vulkan. But OpenGL is an old API. The more old Windows games we get working under Linux no matter how the more people will use Steam on Linux. So the more devs will develop Vulkan games.
When they're dependent on SteamOS and Valve can make them fix internal bugs so RADV stays clean we would all profit! The only way to go must be the best way you can actually achieve, not the best way you can imagine.

Edit: And being bound to SteamOS or to several distributions forking MESA for gaming would be a disaster for our Linux ecosystem...

[roothorick]

If games are a priority for Mesa, then they are in too vulnerable a position to force their principles on the matter. Remember, Mesa 17 is kicking the snot out of AMDGPU Pro; as the fastest, most robust driver, staying away from application-specific fixes and optimizations would further reinforce nVidia's dominance on the Linux platform and all but ostracize Radeon owners tempted to transition away from win10.

The Mesa project certainly can work with developers to help them fix it properly, or even publicly shame those that don't want to fix it, but snubbing our noses at app-specific codepaths is only shit rolling downhill, directly at existing and would-be end users that invested in AMD graphics hardware. And that would snowball into the future as well. Many developers already target specifically and exclusively the nV proprietary drivers, writing off Radeons as "unsupported"; refusing to accommodate when nV does will only reinforce that behavior.

It is important, of course, to compartmentalize it, clearly marking and isolating game-specific codepaths so they don't interfere with developing to spec for the general case. But, unfortunately, it really needs to be there.

[starshipeleven]

When it comes to the whitelist: If there is really no other way, then for God's sake implement this damn piece into Mesa. But list this bad code for rework, force the game studios to fix their products to get them off the list and do everything to get this code in a universally working shape!

It's a catch-22, Valve might actually be doing the right thing here.

If games run better on Linux (or SteamOS + people using a PPA) because of this profiling (likely), then sales of those games should improve, and game studios will be more interested in targeting linux from the start with newer games.

Reworking old games is almost universally nonsense, something that does not happen even in Windows land.

[LibertyZero]

I supported Kalypso heavily in the past ...

I stopped buying Kalypso games when they started adding that register-at-kalyso-to-play-the-game-nag-screen that can only be omitted by forbidding access to their backend. I love Tropico 4, but because of that I wouldn't buy it again.

[oooverclocker]

I supported Kalypso heavily in the past buying many of their games but now I will not buy more of their products. Their studios used to support Windows very well but the Linux support is awful.

When it comes to the whitelist: If there is really no other way, then for God's sake implement this damn piece into Mesa. But list this bad code for rework, force the game studios to fix their products to get them off the list and do everything to get this code in a universally working shape!

[pal666]

I don't like it. When the developers of these games don't want to care about their Linux compatibility it should be revoked.

steamos uses nvidia blob for nvidia hardware and it supports cp. and obviously devs being nvidiots didn't test any other hardware

[oooverclocker]

I don't like it. When the developers of these games don't want to care about their Linux compatibility it should be revoked. Valve is responsible to assure the quality of the products in their catalog.
It's Valves choice to fix bugs of others, but it's very bad for the state of open source distributions and starts an encapsulation of SteamOS. I'm extremely worried how this will turn out.

[brent]

I kinda like the layout here...