Valve Has Been Developing A New Mesa Vulkan Shader Compiler For Radeon

[andrei_me]

What does ACO stand for? Advanced Compiler Optimizations?

[bridgman]

I hadn't finished my coffee yet and remembered the wrong name.

I sure understand that. I'm jumping back and forth between Shanghai and NA time so need morning coffee at least twice a day now

[Almindor]

And that is why I have no problem with Steam's monopoly. They are a good company that cares about the whole community and not just about profit. Screw all the other launchers who just want a piece of the pie.

They only "care" because that's what it takes to keep their business model atm. and the only reason for that is the other monopoly, Microsoft.

As soon as they'd gotten true dominance they'd stop caring whatsoever. Companies only care about revenue.

[skeevy420]

When you say "quit using RadeonSI" what are you using for OpenGL ? AFAIK your options are either Mesa with RadeonSI or our closed source OpenGL driver from the -PRO packages. I suspect you are using amdgpu kernel driver plus Mesa/RadeonSI GL driver.

The Radeon and AMDGPU kernel drivers are what I was referring to there. I hadn't finished my coffee yet and remembered the wrong name.

Good on Valve. Even though I have no AMD cards around right now (and it's unlikely I will, I'm waiting for Intel cards to come to market), I still want to support Valve because they try to make gaming better by improving the infrastructure.

[bridgman]

Thank goodness AMDGPU worked really well for me with the games I was playing from 2015+ which allowed me to quit using RadeonSI.

When you say "quit using RadeonSI" what are you using for OpenGL ? AFAIK your options are either Mesa with RadeonSI or our closed source OpenGL driver from the -PRO packages. I suspect you are using amdgpu kernel driver plus Mesa/RadeonSI GL driver.

[skeevy420]

I can definitely see the idea behind this, but what worries me somewhat is that this will further fragment AMD drivers on Linux creating something akin to the infamous (and untrue) FUD about how you have to test and debug for loads of different distros if you want to release software on Linux.

Discounting long since discontinued hardware we've already got Mesa with LLVM for those who want as much of their graphics driver stack to be open, AMD's own AMDGPU-PRO for those who want certified drivers and their ROC stack for those who want to do compute with an open stack. As such I hope that this either ends up as a learning experience used for those whose job it is to optimize the LLVM-based stacks or then that it becomes part of the de-facto stack, at least for the open source AMD graphics.

I agree. When I was using my R7 260x, for a while there my choices for drivers were RadeonSI and AMDGPU (or AMDGPU-Pro, but I'm an Arch/Manjaro person); with Vulkan, and every thing past this is true of my RX 580 as well, there's RADV, AMDVLK, and AMDVLK-Pro to choose from; then there were/are still environment variables, configuration files, kernel command lines, driconf, Wine with and without DXVK and other such Wine stuff, and more.

Thank goodness AMDGPU worked really well for me with the games I was playing from 2015+ which allowed me to quit using RadeonSI. I'm glad we have all the choices available, but, honestly, some days it does feel like there are too damn many but they've also saved my ass a few times so I'm not gonna complain that much

[L_A_G]

I can definitely see the idea behind this, but what worries me somewhat is that this will further fragment AMD drivers on Linux creating something akin to the infamous (and untrue) FUD about how you have to test and debug for loads of different distros if you want to release software on Linux.

Discounting long since discontinued hardware we've already got Mesa with LLVM for those who want as much of their graphics driver stack to be open, AMD's own AMDGPU-PRO for those who want certified drivers and their ROC stack for those who want to do compute with an open stack. As such I hope that this either ends up as a learning experience used for those whose job it is to optimize the LLVM-based stacks or then that it becomes part of the de-facto stack, at least for the open source AMD graphics.

[humbug]

And that is why I have no problem with Steam's monopoly. They are a good company that cares about the whole community and not just about profit. Screw all the other launchers who just want a piece of the pie.

Steam doesn't have a monopoly though. They are the most dominant PC store but nothing close to a monopoly. There are lots of other PC stores and it's a multi billion dollar industry even outside of steam. And they are not gate keepers of the platform.

[skeevy420]

I use vanilla arch as I wanted to learn the process of installing it from scratch, it certainly helped me fix any issues ive run into as I'm more familiar.

For a newbie Manjaro is a good starting point. Like the other guy said, Antergos is excellent (I have it on my parents machine) but they're dropping support for it.

I'm not sure I would use Antergos for server, but its doable of course.

Pure Arch is what I started using 12 years ago. Switched to ArchBang and then Antergos for quick reinstalls for the times I shot myself in the foot; switched to Manjaro on and off over the past 4 years and Arch was what I went to after I played around with Suse for a little while...a week later I got hit with a systemd bug that slipped into Arch Stable that left my system unbootable and I've been on Manjaro since.

Once some of their more annoying helpers are removed it is like running Arch with an extra layer of testing for the stable branch because Manjaro's Testing is Arch Stable with the Manjaro stuff -- I like Arch, but I also like a stable and very well tested system and Manjaro, due to being downstream from Arch to catch random Stable Repo bugs, is just a more stable OS.