Intel's SWR Removed From Mainline Mesa, More Classic Code Cleaning Continues

[phoronix]

Phoronix: Intel's SWR Removed From Mainline Mesa, More Classic Code Cleaning Continues

Last Friday Mesa classic drivers were removed from the mainline code-base and punted off to an "Amber" code branch where they will receive whatever attention moving forward. With that classic Mesa code removed, more code cleaning is now happening on top of the tens of thousands of lines of code already removed. Intel's OpenSWR driver has also now been removed from mainline...

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Drops-OpenSWR

[lectrode]

Intel merged OpenSWR into Mesa a few years ago a few years ago as an alternative

double the fun (typo)

[Quackdoc]

This should be good. a good incentive to make llvmpipe better.

[oiaohm]

This should be good. a good incentive to make llvmpipe better.

Its not just llvmpipe. You have to remember we still have two galluim software renders left. softpipe and llvmpipe. Yes OpenSWR was meaning we had three.

OpenSWR has a glaring large limitation as it only works on x86 processors. Yes OpenSWR is llvm based so x86 optimisations should be able to go into llvm core.

Really OpenSWR in lot of ways did not make sense.

At the worse of the in mesa tree software rendering solutions we had swrast, softpipe, llvmpipe and OpenSWR. So 4 solutions. December 2020 with Mesa 21.0 killed off swrast if that was still around that would have been moved to the classic tree as well.

Something else OpenSWR is a galluim3d driver. Being moved to classic branch really does not make sense because this will block trimming the galluim code out of the classic branch so making maintaining the classic branch more of a nightmare.

I really do wish parties involved with OpenSWR had just made the choice to terminate like what happened with swrast or made the choice to go into own individual branch for deprecated galluim drivers. The reality a galluim driver really does not have that much in common with classic mesa drivers.

Getting down to 2 should hopefully mean developers focus more so helping softpipe and llvmpipe to improve. Yes OpenSWR/llvmpipe/softpipe with them all being galluim3d drivers made doing alterations galluim3d a 3 way arguement just for software rendering. Remember a 3 way debate has the problem where one party can end up being attempted to be strong armed by two of the other parties todo something that does not suit their solution. Yes with OpenSWR and llvmpipe both being llvm based the softpipe developer were end up on the short end of the stick here.

Over all OpenSWR out the picture should be reduce maintenance and a better environment for developing the software rendering options. Problem is OpenSWR moving to the classic branch is not 100 percent out the picture.

[ms178]

Beware, there is some breakage on Mesa-git due to the recent house cleaning work. Currently Steam is not even starting anymore, hence games won't start up. I've filed: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5726 and hope it will get fixed soon. Some game testing would be great before breaking the world, but they call it the "bleeding edge" for a reason...

[tildearrow]

Good to hear. Never used SWR and it wasn't faster than llvmpipe...

[stormcrow]

Beware, there is some breakage on Mesa-git due to the recent house cleaning work. Currently Steam is not even starting anymore, hence games won't start up. I've filed: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5726 and hope it will get fixed soon. Some game testing would be great before breaking the world, but they call it the "bleeding edge" for a reason...

I doubt supporting proprietary games and the client for the proprietary game store made by a billion dollar company is high on their TODO list unless Valve is willing to push some of that money their way.

Steam is showing its age and general neglect these days despite popularity. Valve's erm... valves are rusty. It appears like a lot of legacy code and there may not be enough qualified programmers to handle its plumbing these days. It's been years and Steam is still only 64 bit on Mac, and even then it's been over a year since the ARM transition and Mac client is still Intel only. Before people object to the size of the Mac gaming community. It's over twice as large as the Linux gaming crowd by Steam's own numbers despite Valve trying to push Linux gaming. That doesn't explain why it's not transitioned to 64 bit on Windows. Nor does it explain why they haven't fixed some glaring security problems with their game deployment - like deploying all game files u+x regardless of file type.

[Developer12]

but it's pretty much time to consider moving on...if you've got tons of cash for a new GPU right now

[microcode]

but it's pretty much time to consider moving on...if you've got tons of cash for a new GPU right now

Literally any GPU only supported by classic drivers is bested by average integrated graphics for the last five years. You can find ewaste in most American cities that is faster than any classic-only hardware, and has a Gallium OpenGL driver (maybe even a Vulkan driver, by now).

[endlesseden]

Literally any GPU only supported by classic drivers is bested by average integrated graphics for the last five years. You can find ewaste in most American cities that is faster than any classic-only hardware, and has a Gallium OpenGL driver (maybe even a Vulkan driver, by now).

Many of those drivers were integrated graphics from sandy-bridge era... - i actually have 2 laptops, and several retro machines that run linux (dual-booting for usability reasons) with these drivers... its going to be a pain maintaining two separate packages now. They weren't fixing alot of the classic drivers bugs to begin with, starting to get worried soon ill get stuck on some old kernel version too that makes them a security risk...

Its a little worrisome for some like myself, but im more worried about developing countries which were donated systems from 2005-2011 for educational purposes, that are being repeatedly further depreciated... Mesa doesnt have a good track history of maintaining depreciated code branches or focusing on anything outside the flavor-of-the-week submissions.