You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have no plans to add Linux support to our sample framework, but we are fully supportive of anyone that wants to attempt a Cauldron port to non-Windows platforms and will happily answer questions and help out where we can.
Reacted by LilPupGimu, Sidney Just and Bruno George de Moraes
Reacted by Sean Genabe, Lorenzo Bertini and iMonZ
Reacted by Hari Rana, Linz, Sebastian Łuc, zarikx, Isaac Schultz, Alex Disibio, lamka02sk, Kolja, Faisal Hakim, Marcus Howser and 16 more
We have no plans to add Linux support to our sample framework, but we are fully supportive of anyone that wants to attempt a Cauldron port to non-Windows platforms and will happily answer questions and help out where we can.
But Cauldron was ported to Linux. The main problem is that Cauldron itself is unmaintained project. It has some legitimate Windows fixes with no reply since 2019.
So, are you going to support specifically the porting work? Should we ping @Zakhrov who did the port to reopen their PR? I don't see in github any mention of changeset-conflicts, so really the Linux port might be just a matter of merging this PR.
Reacted by Gavin Fitzgerald, Sebastian Łuc, Aleksandar Rašković, Ryein Goddard, Lahcéne Belbachir, LilPupGimu, iMonZ and Bruno George de Moraes
We have no plans to add Linux support to our sample framework, but we are fully supportive of anyone that wants to attempt a Cauldron port to non-Windows platforms and will happily answer questions and help out where we can.
But Cauldron was ported to Linux. The main problem is that Cauldron itself is unmaintained project. It has some legitimate Windows fixes with no reply since 2019.
So, are you going to support specifically the porting work? Should we ping @Zakhrov who did the port to reopen their PR? I don't see in github any mention of changeset-conflicts, so really the Linux port might be just a matter of merging this PR.
I had attempted to port it back when Cauldron was first out. I've pulled in the latest Cauldron code and will try a fresh attempt.
Reacted by Konstantin K, Nyanmisaka, Milo de Vries, Ryein Goddard, LilPupGimu, iMonZ, Arthur Silva and Bruno George de Moraes
Reacted by Lahcéne Belbachir, iMonZ and Arthur Silva
We have no plans to add Linux support to our sample framework, but we are fully supportive of anyone that wants to attempt a Cauldron port to non-Windows platforms and will happily answer questions and help out where we can.
But Cauldron was ported to Linux. The main problem is that Cauldron itself is unmaintained project. It has some legitimate Windows fixes with no reply since 2019.
So, are you going to support specifically the porting work? Should we ping @Zakhrov who did the port to reopen their PR? I don't see in github any mention of changeset-conflicts, so really the Linux port might be just a matter of merging this PR.
I had attempted to port it back when Cauldron was first out. I've pulled in the latest Cauldron code and will try a fresh attempt.
This is cool! However, to make sure that effort won't be spent in vain I'd wait for @rys to reply first
First of all, I need to apologise that PRs for Cauldron have been ignored during the project's life and our dev process means it can look abandoned while we develop it internally, rather than develop it out in the open.
It's not our intention to release a project as open source code and then not support it properly when the open source community interacts with it, and we want to do better there with Cauldron and all of the GPUOpen open source projects.
If the Linux port is brought up-to-date with current HEAD (v1.4.1) and looks good, and I can add support for building it with our internal CI, then we will work to try and find a good way to bring it into the project. I can't promise anything at this stage.
I'll work with you in my personal spare time on this effort when I can. Let's open a new issue against Cauldron and take it from there.
Reacted by Konstantin K, codehippo, Gregor Kistler, SmallJoker, Isaac Schultz, Lucas Holt, Mikael Öhman, Alex Disibio, Hari Rana, Kolja and 25 more
Reacted by BLOGDRON, cantalupo555, iMonZ and Bruno George de Moraes
Reacted by Bret Curtis, Robbert van der Helm, Kristjan Krušič, Sebastian Łuc, Scott Kostyshak, Isaac Schultz, Mikael Öhman, Alex Disibio, Kolja, Hari Rana and 17 more
Reacted by Lahcéne Belbachir, Shichao Wu, taotieren, BLOGDRON, cantalupo555 and iMonZ
I've re-opened the pull request and have updated my fork to the latest Cauldron sources. I've fixed the build errors on Linux but there is still a long way to go
Reacted by LilPupGimu and Bruno George de Moraes
Reacted by Lahcéne Belbachir and Bruno George de Moraes
@psi29a we've discussed it internally a couple of times but there's no project-related justification for non-Windows platform support at the moment.
@Zakhrov great, I'm sure it's a good starting point. Please bear with me when it comes to review + helping get it into the right shape to hopefully try and land it.
Reacted by Milo de Vries, cantalupo555 and LilPupGimu
@psi29a we've discussed it internally a couple of times but there's no project-related justification for non-Windows platform support at the moment.
Portable code(especially low level libs/tools for a hardware company like AMD) sometimes can open the door to new opportunities, just the things that popped into the head while reading that:
Support for Linux also means easier support for Android(maybe even helps the partnership with Samsung?), with an easier potential port to other Unix systems: macOS over MoltenVK.
Linux does not mean only desktop/games, it's potential areas for your code(any AMD code) to extend to: car infotainment(helped Nvidia get into cars - which is almost exclusively Linux), kiosks, digital walls, fridges, etc...
Using Linux tools for quality checks: sanitizers, fuzzers, GCC/Clang warnings
Some developers could be more productive on Linux with significantly faster I/O(compilation times), idk
Reacted by Adam Stachowicz, Konstantin K, Gabriele, André Posso, Karthik Kumar Viswanathan, Mikhail Abbas, cantalupo555, LilPupGimu, Stax124, 第四号破壁者 and 6 more
Activity
bkdwt commentedon Jul 15, 2021
Yeah, gives us Linux support!
Rybens92 commentedon Jul 15, 2021
As I heard before, it's working without any issues through Wine/Proton
rys commentedon Jul 15, 2021
We have no plans to add Linux support to our sample framework, but we are fully supportive of anyone that wants to attempt a Cauldron port to non-Windows platforms and will happily answer questions and help out where we can.
Hi-Angel commentedon Jul 15, 2021
But Cauldron was ported to Linux. The main problem is that Cauldron itself is unmaintained project. It has some legitimate Windows fixes with no reply since 2019.
So, are you going to support specifically the porting work? Should we ping @Zakhrov who did the port to reopen their PR? I don't see in github any mention of changeset-conflicts, so really the Linux port might be just a matter of merging this PR.
Zakhrov commentedon Jul 16, 2021
I had attempted to port it back when Cauldron was first out. I've pulled in the latest Cauldron code and will try a fresh attempt.
Hi-Angel commentedon Jul 16, 2021
This is cool! However, to make sure that effort won't be spent in vain I'd wait for @rys to reply first
rys commentedon Jul 16, 2021
First of all, I need to apologise that PRs for Cauldron have been ignored during the project's life and our dev process means it can look abandoned while we develop it internally, rather than develop it out in the open.
It's not our intention to release a project as open source code and then not support it properly when the open source community interacts with it, and we want to do better there with Cauldron and all of the GPUOpen open source projects.
If the Linux port is brought up-to-date with current
HEAD(v1.4.1) and looks good, and I can add support for building it with our internal CI, then we will work to try and find a good way to bring it into the project. I can't promise anything at this stage.I'll work with you in my personal spare time on this effort when I can. Let's open a new issue against Cauldron and take it from there.
psi29a commentedon Jul 16, 2021
One would hope that AMD would help you carve out a bit of time in the week for you to focus on this.
Thank you for willing to go above and beyond. :)
Zakhrov commentedon Jul 16, 2021
I've re-opened the pull request and have updated my fork to the latest Cauldron sources. I've fixed the build errors on Linux but there is still a long way to go
rys commentedon Jul 16, 2021
@psi29a we've discussed it internally a couple of times but there's no project-related justification for non-Windows platform support at the moment.
@Zakhrov great, I'm sure it's a good starting point. Please bear with me when it comes to review + helping get it into the right shape to hopefully try and land it.
cb88 commentedon Jul 16, 2021
In the man-hours spend discussing... it could have been implemented twice over typically is how it goes.
isc30 commentedon Jul 18, 2021
As a clarification, FSR is supported in Linux since it uses standard vulkan GLSL.
What isn't supported at this moment is building the demo project in linux, which uses Cauldron that isn't supported there.
Nothing is stopping you from creating a Vulkan App that uses the FSR1 shader in Linux.
Right, @rys ?
rys commentedon Jul 18, 2021
Correct, we're discussing Linux support for the Cauldron-based FSR sample, not the core FSR technology.
lilianmoraru commentedon Jul 20, 2021
Portable code(especially low level libs/tools for a hardware company like AMD) sometimes can open the door to new opportunities, just the things that popped into the head while reading that:
Linux does not mean only desktop/games, it's potential areas for your code(any AMD code) to extend to: car infotainment(helped Nvidia get into cars - which is almost exclusively Linux), kiosks, digital walls, fridges, etc...
iMonZ commentedon Dec 24, 2021
Any news here?
linckosz commentedon May 12, 2024
It has been 3 years since the last message, wondering if there is a way to support FSR1 in Linux.