Announcement

Collapse
No announcement yet.

Vulkan 1.0 Released: What You Need To Know About This Cross-Platform, High-Performance Graphics API

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

  • #51
    Originally posted by haagch View Post
    Thanks for the links to the compiled version. I tried compiling the sources, but it seems cmake tries to link the windows .dll libraries. (???) and I didn't look too much into it.

    Still, none of the demos run on my GPU which is:
    Intel graphics drivers for Linux don't yet support Vulkan. Exercise patience.

    Comment


    • #52
      Originally posted by smitty3268 View Post

      It was obvious we weren't going to get launch day linux support because of the amdgpu requirements. That code is barely in the kernel, and PM is still disabled by default.

      However, I was expecting launch day support on Windows with a validated driver. I'm really surprised they haven't had it tested.
      Now GamingOnLinux reports that new driver doesn't even support DirectX12. It seems Vulkan and DirectX12 low level access API support has been caught into driver reorganization chaos/rush.

      Comment


      • #53
        Originally posted by birdie View Post
        Intel graphics drivers for Linux don't yet support Vulkan. Exercise patience.
        Ah okay. On IRC I got
        < idr> haagch: I don't think anyone has done anything with IVB in ages. The conformance submissions were all on much newer GPUs (Broadwell and later).
        < idr> haagch: Haswell and Ivybridge are "next".
        < idr> So, seeing catastrophic failures like that on IVB is not too surprising to me.

        Comment


        • #54
          Originally posted by haagch View Post
          Next one, tried the "cube" and "tri" demos from the Vulkan SDK. Both hang the Ivy Bridge GPU (archlinux stock 4.4 kernel), but it recovers after a couple of seconds with the demos crashing without rendering anything:
          Oh, you'll need a newer kernel.

          Comment


          • #55
            Originally posted by daniels View Post
            Oh, you'll need a newer kernel.
            Good idea, but with linus' current git it still doesn't work.
            dmesg: http://haagch.frickel.club/files/dmesg-vulkan-hang
            Error file: http://haagch.frickel.club/files/error

            Also my laptop still doesn't suspend with it, which probably means that I'll have to bisect between rc1 and rc2...
            Last edited by haagch; 02-16-2016, 04:55 PM.

            Comment


            • #56
              Originally posted by DEN
              engine design for Vulkan is basically consited of three major parts:\

              1)
              Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos.

              2)
              Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet.
              That being said, this is the next step what we'll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain. That's just one of reasons why we decided to stick with our own approach for MT renderer for that long. :/

              3)
              Redesign engine for Vulkan. This is the biggest step and can be split in two:

              3a)
              Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls.

              3b)
              Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time.

              3rd part of port is, obviously, the most complex one, and it'll take time to change engine design for it, step-by-step.

              Hope I explained this well.
              DEN
              http://steamcommunity.com/app/257510...47331651997070

              Comment


              • #57
                Originally posted by haagch View Post
                So The Talos Principle Benchmarks when?

                But that's the thing. We are already seeing performance that is far from what it should be. Remember the recent Talos Principle benchmark with AMD's open source drivers?...
                The only way to properly benchmark the performance of the APIs would be to make complete optimal pipelines for each API, but "no game" will do that and create some sort of wrapper around the APIs.

                In general engines slike Unity, Unreal, etc. all the APIs are beneath a layer of abstraction. This means drawing is performed in small batches where the APIs create some overhead. When drivers mature we can expect Vulkan (and Direct3D 12) to offer some performance improvement here, but not any huge improvements. The major CPU overhead will still be in the game engine itself. Ironically, well optimized and non-abstracted engines will benefit less from the reduction in overhead, since the overhead is low already with efficient batching.

                Originally posted by chuckula View Post
                As I noted a little earlier, I'm willing to give AMD a few months of time to "catch up" but considering all the hype about how Vulkan was just a slightly tweaked version of Mantle -- hype that I guess was wrong - it looks like AMD still has a lot of work to do and drivers still matter even if Vulkan is "low level".
                Well, we know it's not a tweaked version of Mantle. Mantle was one source of input, but the underlying API is new. Many fanboys predicted that AMD would rock Vulkan and Nvidia would struggle, but we can clearly see that those people were wrong.

                Originally posted by andreano View Post
                AMD were the pioneers here, with Mantle, which Vulkan is said to be derived from. Assuming they could reuse some of that code for Vulkan, I would expect support from AMD first. Unless they continued pushing Mantle, that is…
                Thanks for proving my point.

                Originally posted by cl333r View Post
                I have a Fermi card and Nvidia's beta driver supports Kepler and later. Will they add Fermi support later on?
                Yes. Kepler and Maxwell is vastly different from Fermi so it will take some time.

                Comment


                • #58
                  Originally posted by phoronix View Post

                  On the NVIDIA side, . . . their Windows support goes . . . back to Windows 7.

                  http://www.phoronix.com/vr.php?view=22837
                  AMD Vulkan support for Windows is limited to Windows ≥ 7 as well. So Windows XP and Vista aren't really receiving Vulkan support after all, contrary to the trumpeting from the peanut gallery. Not unexpected, as reality rarely fully lives up to evangelism.
                  Last edited by eidolon; 02-16-2016, 08:18 PM.

                  Comment


                  • #59
                    Originally posted by zanny View Post
                    So we get dead links for Intel, no driver from AMD, more proprietary bullshit from Nvidia, and a PDF. Sounds like just another day in the Linux graphics shitshow.
                    Peeing vinegar just makes you dance harder.

                    Comment


                    • #60
                      Originally posted by birdie View Post

                      Intel graphics drivers for Linux don't yet support Vulkan. Exercise patience.
                      Too much patience in FOSS. things need to CHANGE.

                      Comment

                      Working...
                      X