Announcement

Collapse
No announcement yet.

Croteam Updates Talos Principle With Better Vulkan Performance & Stability

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

  • Croteam Updates Talos Principle With Better Vulkan Performance & Stability

    Phoronix: Croteam Updates Talos Principle With Better Vulkan Performance & Stability

    In time for any weekend Linux gaming you might do or Linux GPU driver testing, The Talos Principle has a new public beta available and it offers improvements to its Vulkan renderer...

    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
    It performs great under Vulkan on my GTX-1080.... until it crashes randomly that is. Getting the stability improved is a very good thing, but can be hard with these "low level" APIs that make it easier to shoot yourself in the foot.

    Comment


    • #3
      It sounds like Michael has a new shiny

      Comment


      • #4
        It's really amusing to see things revert back nowadays: In the past APIs like Directx aimed for lesser hardware access, like EAX support was wiped out of it. It's also the same with hardware acceleration regarding video, aes and such: In the past they wanted to abstract from those, nowadays everything gets reimplemented on a separate chip again. (;

        Comment


        • #5
          Originally posted by cRaZy-bisCuiT View Post
          It's really amusing to see things revert back nowadays: In the past APIs like Directx aimed for lesser hardware access, like EAX support was wiped out of it. It's also the same with hardware acceleration regarding video, aes and such: In the past they wanted to abstract from those, nowadays everything gets reimplemented on a separate chip again. (;
          And probably it will go into a full cycle, once less experienced developers start making their side-scrollers using Vulkan and such APIs and keep breaking things.

          Comment


          • #6
            Originally posted by cRaZy-bisCuiT View Post
            It's really amusing to see things revert back nowadays: In the past APIs like Directx aimed for lesser hardware access, like EAX support was wiped out of it.
            No, we just made a smart transition, instead of having ONLY a high-abstraction API trying to fit all now you can have both. Vulkan for low abstraction, and a third-party game engine (using Vulkan probably but the game developer never has to deal with that anyway) for high abstraction.

            It's also the same with hardware acceleration regarding video, aes and such: In the past they wanted to abstract from those, nowadays everything gets reimplemented on a separate chip again. (;
            It's not on a separate chip, but on a separate piece of silicon in the same chip of the CPU/GPU, sharing the same high-speed busses and interfaces, and built with the same high-quality silicon/manufacturing process.

            And afaik this "integrate all crucial stuff in main die" has been going on since a long time, for example the inclusion of ALU coprocessor in main CPU die happened ages ago.

            Comment


            • #7
              Originally posted by eydee View Post
              And probably it will go into a full cycle, once less experienced developers start making their side-scrollers using Vulkan and such APIs and keep breaking things.
              less experienced developers can always use a third party engine and stfu.
              Experienced devs need low-abstraction APIs and this won't change.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                less experienced developers can always use a third party engine and stfu.
                I'm actually waiting to see how this works out. Layering an engine on top of Vulkan, may deny the developer exactly the kind of flexibility Vulkan is made for. Since I'm out of touch with OpenGL and know basically squat about Vulkan, I have no idea where this is going. We may even end up with something like asm routines in C, where developers stick with OpenGL and from there go to Vulkan only for critical code paths. I'm just guessing, while feverishly waiting to see where this is all going.

                Comment


                • #9
                  Originally posted by bug77 View Post

                  I'm actually waiting to see how this works out. Layering an engine on top of Vulkan, may deny the developer exactly the kind of flexibility Vulkan is made for. Since I'm out of touch with OpenGL and know basically squat about Vulkan, I have no idea where this is going. We may even end up with something like asm routines in C, where developers stick with OpenGL and from there go to Vulkan only for critical code paths. I'm just guessing, while feverishly waiting to see where this is all going.
                  I will never understand these kind of arguments an engine takes in textures, models , locations etc. Thats it. The engine is free to optimize to opengl or vulkan or whatever it wishes to use.

                  Comment


                  • #10
                    Originally posted by cj.wijtmans View Post

                    I will never understand these kind of arguments an engine takes in textures, models , locations etc. Thats it. The engine is free to optimize to opengl or vulkan or whatever it wishes to use.
                    The point of Vulkan is to do per-title optimizations. I just don't know whether that can be abstracted or by abstracting it you lose the performance edge. I'm not saying it can't be done, I'm saying I'm waiting to see it done.

                    Comment

                    Working...
                    X