Announcement

Collapse
No announcement yet.

Vulkan 1.0.12 Specification Update Adds VK_AMD_rasterization_order

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

  • Vulkan 1.0.12 Specification Update Adds VK_AMD_rasterization_order

    Phoronix: Vulkan 1.0.12 Specification Update Adds VK_AMD_rasterization_order

    Vulkan 1.0.12 is the latest specification update to the official Vulkan documentation from The Khronos Group...

    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
    "VK_AMD_rasterization_order"

    Oh an AMD extension to Vulkan? I'm sure the exact same people who screamed about how Nvidia was going to murder them and their dogs for adding in a few extensions to make it easier to port from OpenGL to Vulkan will show an incredible level of intellectual honesty and hold AMD to the exact same standard for adding its own extension. /s

    Comment


    • #3
      Originally posted by chuckula View Post
      "VK_AMD_rasterization_order"

      Oh an AMD extension to Vulkan? I'm sure the exact same people who screamed about how Nvidia was going to murder them and their dogs for adding in a few extensions to make it easier to port from OpenGL to Vulkan will show an incredible level of intellectual honesty and hold AMD to the exact same standard for adding its own extension. /s
      It just takes the name of the one that proposed the extension. I doesn't mean that is AMD only.

      Comment


      • #4
        At the same time as I'm not sure how I feel about vendor specific extensions; I don't see what prevents the other vendor from supporting the extension. They're open source, and can be adapted to work on both vendors products (or a third, vendor neutral extension with the same function could be created)

        As long as each vendor keeps up and competes with the other to never be missing any features another has when possible, this might actually turn out interesting.

        The stakes are just about as high for both AMD and Nvidia, a bit lower for intel though. AMD has PS4 (or PS4K) to be concerned about, I bet sony wants and is working on vulkan support at a high standard (and AMD is no doubt playing ball with them, they want to stay partners), whereas Nvidia needs it for shield.
        Last edited by rabcor; 30 April 2016, 03:44 PM.

        Comment


        • #5
          Originally posted by artivision View Post

          It just takes the name of the one that proposed the extension. I doesn't mean that is AMD only.
          Yeah, and there was exactly nothing about Nvidia's extensions that made them Nvidia-only either. But that didn't stop the usual suspects from screaming about how Nvidia was going to single-handedly kill Vulkan.

          Comment


          • #6
            Originally posted by chuckula View Post
            "VK_AMD_rasterization_order"

            Oh an AMD extension to Vulkan? I'm sure the exact same people who screamed about how Nvidia was going to murder them and their dogs for adding in a few extensions to make it easier to port from OpenGL to Vulkan will show an incredible level of intellectual honesty and hold AMD to the exact same standard for adding its own extension. /s
            I thought the complaints were about creating a whole OpenGL context in Vulkan was defeating the goal of Vulkan to start with a clean slate.

            Comment


            • #7
              Code:
              struct VkPipelineRasterizationStateRasterizationOrderAMD
              Dear lord

              Comment


              • #8
                Originally posted by Ancurio View Post
                Code:
                struct VkPipelineRasterizationStateRasterizationOrderAMD
                Dear lord
                I always thought those phrases had to start with 'public class', but I guess these kinds of naming schemes exist in C, as well …

                Comment


                • #9
                  Originally posted by rabcor View Post
                  At the same time as I'm not sure how I feel about vendor specific extensions; I don't see what prevents the other vendor from supporting the extension. They're open source, and can be adapted to work on both vendors products (or a third, vendor neutral extension with the same function could be created)

                  As long as each vendor keeps up and competes with the other to never be missing any features another has when possible, this might actually turn out interesting.

                  The stakes are just about as high for both AMD and Nvidia, a bit lower for intel though. AMD has PS4 (or PS4K) to be concerned about, I bet sony wants and is working on vulkan support at a high standard (and AMD is no doubt playing ball with them, they want to stay partners), whereas Nvidia needs it for shield.
                  It looks to me that they're just continuing the approach from OpenGL.

                  Step 1: vendors implement whatever the hell they want using a prefix like SGI_, IBM_, ATI_, NV_, etc. (Look at the "Vendor and EXT Extensions by number" section in the linked page)

                  Step 2: If it turns out to be a good idea, other vendors implement it too.

                  That's why, in practice, OpenGL is generally a bit more advanced than DirectX despite the core standard often lagging behind it. The core standard is just polishing up what was already available for a while via extensions.

                  Comment


                  • #10
                    Originally posted by artivision View Post

                    It just takes the name of the one that proposed the extension. I doesn't mean that is AMD only.

                    If extention used under Nvidia driver, will it work out of the box?
                    If not - problem, sense I.(in best Yoda voice)

                    Comment

                    Working...
                    X