Announcement

Collapse
No announcement yet.

AMD Posts FidelityFX Super Resolution Source Code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Posts FidelityFX Super Resolution Source Code

    Phoronix: AMD Posts FidelityFX Super Resolution Source Code

    After AMD posted FidelityFX Super Resolution last month with various initial launch titles, the source code to this NVIDIA DLSS alternative is now publicly available...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Holy crap, what the hell is that source code haha.

    I have never seen C code that was so weird. I guess it makes sense considering its purpose, but still...

    "AH4 ACpySgnH4(AH4 d,AH4 s){return AH4_AW4(AW4_AH4(d)|(AW4_AH4(s)&AW4_(0x8000u)));}"
    Man I need to go relearn C haha.
    Last edited by kvuj; 15 July 2021, 01:06 PM.

    Comment


    • #3
      Originally posted by kvuj View Post
      Holy crap, what the hell is that source code haha.

      I have never seen C code that was so weird. I guess it makes sense considering its purpose, but still...
      Well, C is used for portability, but really C is the assembler, and it'll be 90% macros.

      Comment


      • #4
        "However, it is catering to a Windows workflow with Windows 10 and Visual Studio being listed as being required."

        Sad to read. Not really a Linux friendly move IMHO.

        Comment


        • #5
          Originally posted by obri View Post
          "However, it is catering to a Windows workflow with Windows 10 and Visual Studio being listed as being required."

          Sad to read. Not really a Linux friendly move IMHO.
          Dude, it's like two header files full of macros, so it's mostly a build system thing.

          Comment


          • #6
            Originally posted by microcode View Post

            Dude, it's like two header files full of macros, so it's mostly a build system thing.
            Not to mention that it uses cmake for "building". Adding FSR to the build system of any project should be pretty much trivial.

            Comment


            • #7
              I like how their entire commit history consists of a single commit. Best development practices at AMD! 😄
              Last edited by Hi-Angel; 15 July 2021, 02:34 PM.

              Comment


              • #8
                So, I looked at this project to see how hard would it be to make the build system work on Linux (since it's Cmake), and here's the thing: it relies on another AMD project called "Cauldron", which also doesn't support Linux. Then the question is: how hard would it be to add support there?

                So, I looked at PRs in Cauldron, and I found out it has some legitimate Windows fixes waiting there since 2019 year! So, this is an unmaintained project. There's no point in adding any features, fixes, including Linux support, unless you want to also fork and maintain it.

                It's really not the first one. Every time GPUOpen AMD initiative gets brought up, it's always yet another unmaintained project. Like, what is the point.
                Last edited by Hi-Angel; 15 July 2021, 02:51 PM.

                Comment


                • #9
                  Originally posted by Hi-Angel View Post
                  I like how their entire commit history consists of a single commit. Best development practices at AMD! 😄
                  I'm guessing most of the work was done on a separate tracker with a separate history.

                  Comment


                  • #10
                    So basically FSR seems to be just interpolating the image at higher resolution with an improved lanczos filter.
                    Nice. Surprising such a thing was never done before (maybe with lighter interpolations like bicubic).

                    Comment

                    Working...
                    X