Announcement

Collapse
No announcement yet.

Intel Media Stack Updated With Full Support For Lunar Lake, Initial Battlemage Support

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

  • Intel Media Stack Updated With Full Support For Lunar Lake, Initial Battlemage Support

    Phoronix: Intel Media Stack Updated With Full Support For Lunar Lake, Initial Battlemage Support

    Intel today released the Intel Media Driver 2024Q3 release to provide updated Video Acceleration API (VA-API) support for Linux systems along with an updated oneVPL GPU Runtime...

    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
    I think the Arrow Lake (Core Ultra 2 for desktop) has worse GPU than Lunar Lake (Core Ultra 2 for laptops) ?
    Or maybe it has worse GPU than the older generation desktop processor? Quite disappointing.

    Comment


    • #3
      Just got it a little bit ago on Fedora 41:
      Code:
      intel-media-driver-24.3.4-1.fc41.x86_64

      Comment


      • #4
        And all us Alchemist owners left out in the cold. Man, it was cheap, but I still feel a little ripped off.

        Comment


        • #5
          Originally posted by Forge View Post
          And all us Alchemist owners left out in the cold. Man, it was cheap, but I still feel a little ripped off.
          ? What about Alchemist is being left in the cold?
          It only lacks VP8 decode vs. Battlemage (and requires the 'non-free' driver for AV1 encode while Battlemage doesn't).

          Comment


          • #6
            Originally posted by Ranguvar View Post

            ? What about Alchemist is being left in the cold?
            It only lacks VP8 decode vs. Battlemage (and requires the 'non-free' driver for AV1 encode while Battlemage doesn't).
            Back at the beginning of summer, after a couple of disagreements about how to handle Alchemist and Xe, Intel decided that Alchemist was going to stay on i915 and not move to Xe. Under Xe (the more modern, featureful driver, which works on architectures other than x86), there is no support whatever for loading the GUC on Alchemist, so it has no media support whatever, it becomes a dumb renderer. No encode or decode support for any format. If you stay on i915, you get older, less functional 3D support (Vulkan level is an early and obvious one, but more will show up over time), and you can only run on x86. There are lots of things available or coming soon in Xe (SR-IOV is the one I care most about) which will not be backported to i915. That list will also only get longer with time.

            So yes, today it's not too bad, but there is basically very little coming in the future for Alchemist, while Battlemage and above will be defaulting to Xe, and getting all the great new features they are working on there.

            Comment


            • #7
              Originally posted by Forge View Post

              Back at the beginning of summer, after a couple of disagreements about how to handle Alchemist and Xe, Intel decided that Alchemist was going to stay on i915 and not move to Xe. Under Xe (the more modern, featureful driver, which works on architectures other than x86), there is no support whatever for loading the GUC on Alchemist, so it has no media support whatever, it becomes a dumb renderer. No encode or decode support for any format.
              Is there something preventing GuC loading for Alchemist to be implemented on Xe? If it's possible on i915, and if there's hardware that works both i915 and Xe for GuC, does it load the same firmware? Or is it something like Intel needing to provided signed files/loader and not wanting to support it? Or the GuC firmware being unofficially loadable by Xe but not having any hook-up to the driver?

              Comment


              • #8
                Originally posted by Espionage724 View Post
                Is there something preventing GuC loading for Alchemist to be implemented on Xe?
                Intel. Their engineers said it would require a lot of work to set up, and they don't want to/can't get it justified. I will, therefore, be very unlikely to buy any other Intel hardware for which the features are not already complete/functional. Intel indirectly promised SR-IOV and performance improvements for Alchemist, and they've flat out decided not to do one of those at all, and the other is getting done, but with a ton of caveats. No sale.

                Comment


                • #9
                  Originally posted by Forge View Post

                  Intel. Their engineers said it would require a lot of work to set up, and they don't want to/can't get it justified. I will, therefore, be very unlikely to buy any other Intel hardware for which the features are not already complete/functional. Intel indirectly promised SR-IOV and performance improvements for Alchemist, and they've flat out decided not to do one of those at all, and the other is getting done, but with a ton of caveats. No sale.
                  Can someone else do it? If the documentation exists to hook-up a method to load GuC, and as long as Intel isn't doing anything like outright blocking GuC on Alchemist through blobs, it sounds like someone other than Intel can do the work? Like, where is the specific problem? Can a bunch of people get together, take an existing i915 GuC loading method, and duct-tape it in a way to work on Alchemist regardless of Intel not doing it themselves? Or is there no GuC blob existing, and Intel has to provide one to get started? Also what about HuC?

                  Intel has bureaucracy, but isn't the point of open-sourcing stuff so that others can do what bureaucracy doesn't allow?

                  I wouldn't be happy with Intel not doing the efforts themselves, but I'm wondering how far the decision reaches; will they let others do the work?
                  Last edited by Espionage724; 13 November 2024, 04:22 PM.

                  Comment


                  • #10
                    Originally posted by Espionage724 View Post

                    Can someone else do it? If the documentation exists to hook-up a method to load GuC, and as long as Intel isn't doing anything like outright blocking GuC on Alchemist through blobs, it sounds like someone other than Intel can do the work? Like, where is the specific problem? Can a bunch of people get together, take an existing i915 GuC loading method, and duct-tape it in a way to work on Alchemist regardless of Intel not doing it themselves? Or is there no GuC blob existing, and Intel has to provide one to get started? Also what about HuC?

                    Intel has bureaucracy, but isn't the point of open-sourcing stuff so that others can do what bureaucracy doesn't allow?

                    I wouldn't be happy with Intel not doing the efforts themselves, but I'm wondering how far the decision reaches; will they let others do the work?
                    I didn't read that deeply into it, and rather than misunderstand/misquote, I should just link you to some other discussions.

                    Here's the Git thread on it: https://gitlab.freedesktop.org/drm/x...l/-/issues/234

                    More info, maybe more readable but less reliable, from reddit: https://www.reddit.com/r/IntelArc/co...linux_lacking/

                    Comment

                    Working...
                    X