Announcement

Collapse
No announcement yet.

Intel To Split Off Their Old Haswell/Broadwell Vulkan Code Into Separate Driver

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

  • Intel To Split Off Their Old Haswell/Broadwell Vulkan Code Into Separate Driver

    Phoronix: Intel Looking To Split Off Their Old Haswell/Broadwell Vulkan Code Into Separate Driver

    The current Intel open-source "ANV" Vulkan driver within Mesa supports graphics hardware going back to the "Gen7" graphics found with Haswell. However, Intel open-source Linux graphics driver engineers are preparing to separate the old Haswell (Gen7) and Broadwell (Gen8) graphics into a separate Mesa driver so they can better focus on improving their modern Vulkan driver that would then be limited to Skylake Gen9 graphics and newer...

    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
    Gen 7 is Ivy Bridge (which is not really Vulkan 1.0 compliant), Gen 7.5 (Haswell) is Vulkan 1.0 compliant.

    Comment


    • #3
      Oh that is very good news actually! This gives me a hope the lousy Gen 7 support will stop degrading over time because of shallow testing.

      It was quite promising at some point, despite being weak and holed with missing features. But for a moment the Gen7 is mostly broken, stuttering and locking up. So, there is a hope now that early hardware quirks and workarounds could be properly isolated and reorganized.

      Comment


      • #4
        This is great news, and a wonderful explanation!

        Honestly rather than dropping support: branching support off like this is great. New devices see improvements (and old devices could... theoretically... as well, so long as someone is there to make them-without support affecting each other).

        Divergence makes sense with a gap this large. Opting for this strategy vs. some much, much worse alternatives definitely is the way to go! Whoo hoo!
        Last edited by Eirikr1848; 02 September 2022, 02:41 AM.

        Comment


        • #5
          Not that it makes much of a difference, but wouldn't it make more sense to put everything after Haswell on a separate driver? That way, there's more continuity with older distros/repos for those running older GPUs.

          In any case, splitting the code is a good decision.
          Last edited by schmidtbag; 24 August 2022, 09:02 AM.

          Comment


          • #6
            Random thought: Does this mean that along with Beignet for OpenCL: a theoretical HASVK + Beignet driver stack could make a "Legacy Intel Graphics Compiler" or "Legacy Open Intel SDK" to preserve and expand upon legacy compute abilities / allow for backporting of new features when able (OpenVINO and Osprey for use in conjunction with a Neural Compute stick, for example)

            Moving on...

            Originally posted by schmidtbag View Post
            Not that it makes much of a difference, but wouldn't it make more sense to put everything after Haswell on a separate driver? That way, there's more continuity with older distros/repos for those running older GPUs.

            In any case, splitting the code is a good decision.
            What do you mean?

            This is splitting Ivy Bridge, Haswell, Broadwell (and Bay Trail I presume) into their own driver so that the focus can be on Skylake and newer...

            Comment


            • #7
              Originally posted by Eirikr1848 View Post
              What do you mean?

              This is splitting Ivy Bridge, Haswell, Broadwell (and Bay Trail I presume) into their own driver so that the focus can be on Skylake and newer...
              I know. I'm saying that's a little backwards, where Skylake and newer should be split into their own new driver, since they are new devices.
              Think of it like this:
              Let's say a car company for decades released a sports coupe with the same name. But in the 2022 model year, there's a big performance boost and more aggressive styling. It makes the older models look slow and plain, but does that mean all of them should be rebranded as just coupes? Rather than meddle with what is already established, I would say it makes more sense for the new model to become a new category.

              Again - it doesn't really make that much of a difference in the end. I am nitpicking here, because while the impact of this isn't a big deal, splitting Haswell/Broadwell complicates things more than to split post-Broadwell. This is due to things like how older documentation or outdated repos might work.
              Last edited by schmidtbag; 24 August 2022, 11:09 AM.

              Comment


              • #8
                The Intel graphics driver team must be on a immense pressure right now, especially on Windows, to deliver a working driver for their new dGPUs. Dumping old stuff like those is more than understandable given the circumstances. On Linux, the older driver could at least expect little fixes from time to time by the community.

                Comment


                • #9
                  Dumping old code like that is common on windows, newer drivers just only target the newer cards and leave behind only the most recent, Nividia does it and AMD aswell, so why not Intel ?

                  Comment


                  • #10
                    Originally posted by Eirikr1848 View Post
                    What do you mean?

                    This is splitting Ivy Bridge, Haswell, Broadwell (and Bay Trail I presume) into their own driver so that the focus can be on Skylake and newer...
                    If I understand what they're saying correctly, they're asking "Why do the new targets get to keep the original name, rather than letting the old ones that were there first have it?"

                    Comment

                    Working...
                    X