Announcement

Collapse
No announcement yet.

Intel Publishes More Haswell Graphics Driver Code

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

  • Intel Publishes More Haswell Graphics Driver Code

    Phoronix: Intel Publishes More Haswell Graphics Driver Code

    While Intel's Ivy Bridge launch is imminent, and I'm still digging through information concerning today's Intel Valleyview code drop that brings Ivy Bridge graphics to their next-generation Atom as they do away with PowerVR graphics for their SoCs, more graphics driver code to enable Haswell support has landed this evening...

    http://www.phoronix.com/vr.php?view=MTA3NDg

  • #2
    Awesome!! Thank you, Intel!!

    Comment


    • #3
      Originally posted by phoronix View Post
      Phoronix: Intel Publishes More Haswell Graphics Driver Code

      While Intel's Ivy Bridge launch is imminent, and I'm still digging through information concerning today's Intel Valleyview code drop that brings Ivy Bridge graphics to their next-generation Atom as they do away with PowerVR graphics for their SoCs, more graphics driver code to enable Haswell support has landed this evening...

      http://www.phoronix.com/vr.php?view=MTA3NDg

      While I'm a bit uncertain what those "power wells" are, given what someone else mentioned in another thread (namely that GT3 has 40EU), being able to power down unused EUs would be really useful since power usage is, again, a big reason to use their IGP.

      Comment


      • #4
        If AMD were landing the first Radeon HD8000 series support a year or more before the card launch, I'd buy their products, too. Dang, Intel, you guys are really good at this "planning" thing!

        Just imagine if AMD could do something similar for their discrete cards... WOW.... that would have meant that the code drop which came to us this week for HD7000 support would've landed back in, oh I don't know, mid-2011? And we'd have the Gallium3d driver already committed to mesa master by January 2012 or so? And we'd have color tiling and a shader compiler and OpenGL 3 by the end of 2012 for a chip that launched that same year?

        Oh, who am I kidding. AMD's open source guys are so overworked, and they have such a huge backlog of generations to catch up on, that I can't see this ever happening unless they quadruple (or more) their current manpower.

        So, my next laptop is going to have an Intel CPU and an Intel IGP. This is the deciding factor for me. Are you listening, AMD? Your "let's play catch-up several months after our GPUs are released" open source strategy is costing you money. And I tend to spend at least 3-5 thousand dollars on a laptop, so you're really missing out! If I could buy a Trinity laptop with confidence that I could at least have hardware-accelerated compositing when I bring it home and install a current distro (compiling from git is also okay), I would totally do that. Instead, Intel gets my money.

        I'll still buy your discrete GPUs, because I'm a sucker and because I boot Windows to play games. But I ONLY ever run Linux on my laptops, and I DON'T use it to play games, but I want a low-power GPU that can do basic 3d stuff and play flash in a browser without lagging. Right now I have no reason to believe that Trinity will be that far along in the open source drivers by the time I'm ready to buy a new laptop.

        Comment


        • #5
          Originally posted by allquixotic View Post
          Right now I have no reason to believe that Trinity will be that far along in the open source drivers by the time I'm ready to buy a new laptop.
          «AMD has finally released the open-source driver code to support the Radeon HD 7000 "Southern Islands" GPUs and next-generation Fusion "Trinity" APUs under Linux with their open-source driver.» (Source)

          Comment


          • #6
            Originally posted by Nedanfor View Post
            «AMD has finally released the open-source driver code to support the Radeon HD 7000 "Southern Islands" GPUs and next-generation Fusion "Trinity" APUs under Linux with their open-source driver.» (Source)
            Trinity is basically a Cayman part, as i understand it. I'm sure there will be some specific differences it has, but I'd guess support for it will be pretty good by the time it comes out.

            Comment


            • #7
              Originally posted by Nedanfor View Post
              «AMD has finally released the open-source driver code to support the Radeon HD 7000 "Southern Islands" GPUs and next-generation Fusion "Trinity" APUs under Linux with their open-source driver.» (Source)
              From the article:

              Originally posted by Phoronix
              As of right now, however, I haven't seen the new Gallium3D driver for Mesa be introduced yet for the Radeon HD 7000 series nor any Trinity patches. The Radeon DRM patches were published just minutes ago, so hopefully the Gallium3D and xf86-video-ati patches are still on the agenda for this afternoon.
              Having the kernel bits without the Gallium3d bits is like having loose hydrogen atoms without oxygen. No oxygen, no water. No Gallium3d, no driver. Having half the pieces is better than none from a theoretical perspective, but from a practical perspective of actually using the hardware to do interesting things, it's exactly equal to having zero support. Unless you've found a way to survive by imbibing liquid hydrogen...?

              The other interesting thing to note is that it took the Evergreen ASICs over two years (or if you want to be extremely charitable, a year and a half) from the time their Gallium3d driver was first introduced, until the time when they brought up a majority of the hardware support features and got their OpenGL 2.1 acceleration working well.

              Assuming that AMD pulls a miracle and manages to halve the time it takes to go from "bare bones G3D driver that crashes running glxgears" to "something we can ship by default in distros", then the wait time is reduced to between 0.75 years and 1 year depending on your optimism factor.

              0.75 years from Trinity release would be about January 2013 if Trinity is released within the next 30-60 days. And that's an extremely optimistic projection. Assuming that they release it just in time for it to get picked up by 6-month distros, that means it would show up no earlier than Ubuntu 13.04 for end-users who don't compile from git (which, by the Phoronix surveys, is something like 94% of Phoronix viewers). Ubuntu 13.04 will be released about one full year after the anticipated release date of Trinity.

              When you consider that end-users and enthusiasts upgrade between every 2 and 4 years, you are basically cutting the usable Linux lifespan of the hardware between 25 and 50% for people who want open drivers for their (eventual) stability, performance and lack of proprietary goo. The only people who will feel the wait noticeably less are the "late adopters", such as businesses, who are just now starting to upgrade their hardware to mid-grade HD3000 series chips.

              It's basically a disincentive to live on the edge. And yet, if AMD's marketing department gets their way, they'll have you buy the chip as soon as it's out, because it's the latest and greatest thing. Slight problem: you can't use it unless you want to bow down to Bill Gates or the proprietary alligators in your kernel.
              Last edited by allquixotic; 03-22-2012, 05:54 PM.

              Comment


              • #8
                The userspace bits for Trinity were published the same afternoon, as Michael hinted. Maybe look in the commit log before badmouthing us ?

                http://cgit.freedesktop.org/xorg/dri...video-ati/log/
                http://cgit.freedesktop.org/mesa/mesa/log/

                Originally posted by allquixotic View Post
                The other interesting thing to note is that it took the Evergreen ASICs over two years (or if you want to be extremely charitable, a year and a half) from the time their Gallium3d driver was first introduced, until the time when they brought up a majority of the hardware support features and got their OpenGL 2.1 acceleration working well.
                That's because the foundation work required for GL 2.1 was being added at the same time, and the Gallium3D paths were brand new as well. That only has to happen once.
                Last edited by bridgman; 03-22-2012, 06:07 PM.

                Comment


                • #9
                  So Trinity will be supported at launch?

                  Tempest in a teapot?

                  Anyway, I'm looking forward to a fanless HD 7000-based card (7550?)

                  Comment


                  • #10
                    That is the expectation. I'm sure we'll find some issues with specific SKUs that didn't appear on the engineering boards, but other than testing on a broad range of hardware all the support should be in place now.

                    Comment


                    • #11
                      Originally posted by bridgman View Post
                      The userspace bits for Trinity were published the same afternoon, as Michael hinted. Maybe look in the commit log before badmouthing us ?

                      http://cgit.freedesktop.org/xorg/dri...video-ati/log/
                      http://cgit.freedesktop.org/mesa/mesa/log/



                      That's because the foundation work required for GL 2.1 was being added at the same time, and the Gallium3D paths were brand new as well. That only has to happen once.
                      I wasn't badmouthing anyone; I was just saying that the article said the support wasn't there yet, and I figured that since Michael is so hyper about posting articles whenever someone makes a git commit, we'd hear about it in a new article if the support had actually landed. I guess I should have checked first. But I was explaining to the other guy that, going on what Michael said that it was only kernel support at that time, this wasn't enough to start using the driver.

                      I'll definitely take a look (or take a compile :P) of the stuff out there right now, and see if I can report some bugs... that said, I have a much less "unusual" part this time around, because I'm guessing that you guys pretty much put a lot of effort into supporting the 7970 "Tahiti" during your internal testing. I mean it would be very awkward if you spent less time on your flagship GPU than the others in the series. Last time around I had the dual GPU, which for a while was somewhat of a bastard child due to the variances in its hardware compared to the 5870. I've learned my lesson on that point.

                      Question: Does all the tiling work that Jerome Glisse did for Evergreen have to happen all over again for the Northern Islands series? Or will the existing tiling work provide at least a springboard with which to more rapidly bring up tiling on NI?

                      Just asking, because I saw the very visible performance improvements of 1D and then 2D tiling on Evergreen, and I'd wager that the NI will perform worse than Evergreen during the period where Evergreen has tiling and NI doesn't.

                      Then again, maybe you guys went all-out and NI already has tiling in the initial release?! I haven't trawled that far into the source yet to tell, so I figure it's easier to just ask here.

                      Or, heck, don't even answer me here on the forum. Instead, a constructive request! We like positive suggestions around here, don't we?

                      Please edit http://www.x.org/wiki/RadeonFeature (once x.org is up; the site is down for me at the moment) and update it with any changes which have occurred due to the public release of the driver.

                      EDIT: I erroneously called the HD7000 series "Northern Islands" in this post. It's Southern Islands. I knew that, but I'm still thinking in terms of last generation. Silly me!

                      Comment


                      • #12
                        Originally posted by allquixotic View Post
                        I wasn't badmouthing anyone; I was just saying that the article said the support wasn't there yet, and I figured that since Michael is so hyper about posting articles whenever someone makes a git commit, we'd hear about it in a new article if the support had actually landed.
                        Fair point

                        Originally posted by allquixotic View Post
                        But I was explaining to the other guy that, going on what Michael said that it was only kernel support at that time, this wasn't enough to start using the driver.
                        Dave (aka airlied) was working on a generic modesetting driver for X which just needs KMS to operate... sort of like VESA but with native modesetting support. I don't know whether that X driver is working with the current SI KMS code but I imagine it either does work or is really close.

                        The generic modesetting driver is a really useful idea (something I only realized in the last couple of weeks), because it makes it worthwhile to release initial kernel driver support at the modesetting stage without waiting for accel support before you release... and in many cases modesetting code is the "safest" and therefore the best candidate for releasing *before* hardware launch.

                        Originally posted by allquixotic View Post
                        I'll definitely take a look (or take a compile :P) of the stuff out there right now, and see if I can report some bugs... that said, I have a much less "unusual" part this time around, because I'm guessing that you guys pretty much put a lot of effort into supporting the 7970 "Tahiti" during your internal testing. I mean it would be very awkward if you spent less time on your flagship GPU than the others in the series.
                        It might sound funny, but we don't actually gate release of open source code on testing or bug fixing, just "does it include enough to be useful" and "have we jumped through the IP/legal hoops". Testing and bug fixing can be done better once the code is in public.

                        Strictly speaking the code doesn't even have to work before we make the initial release, but we normally find that making something actually work is a real good guide to identifying the information we need to review before release. We may end up pushing the userspace code for SI before it actually works, for example, depending on whether "making it work" or "being able to release" happens first.

                        In terms of which hardware we use for testing, the general rule is "use whatever you can lay hands on", which usually means a mix of whatever chip was first and whatever chip had the best early yields

                        Originally posted by allquixotic View Post
                        Question: Does all the tiling work that Jerome Glisse did for Evergreen have to happen all over again for the Northern Islands series? Or will the existing tiling work provide at least a springboard with which to more rapidly bring up tiling on NI?
                        IIRC the tiling work was done for all generations supported by r600g at the same time, including NI, but each hardware generation tends to have some unique quirks and therefore some unique bugs. See below...

                        Originally posted by allquixotic View Post
                        Then again, maybe you guys went all-out and NI already has tiling in the initial release?! I haven't trawled that far into the source yet to tell, so I figure it's easier to just ask here.
                        The general rule is that when adding new features you add to all the hardware generations supported by the driver when you start work, and when adding support for new hardware you add support for all the features & functionality that the driver supported when you start. You don't see a lot of "add this feature to only that generation" except in cases where all the earlier chips are too old to support the feature (when adding a feature) or there are radical changes in programming model which make it worth omitting a feature from the initial support in order to get the rest of the functionality into users hands more quickly (when adding new hardware support).
                        Last edited by bridgman; 03-22-2012, 09:15 PM.

                        Comment


                        • #13
                          Looks like http://www.x.org/wiki/RadeonFeature is back online; it was down earlier.

                          Can someone very familiar with the recent HD7000 code, add a column to the features table for SI? And fill in the boxes to the best of your knowledge?

                          I'd like to know the details of which of the RadeonFeatures are supported in the latest SI code, versus NI and Evergreen.

                          Comment


                          • #14
                            I started making changes, but quickly concluded we should wait until userspace is actually running.

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              I started making changes, but quickly concluded we should wait until userspace is actually running.
                              That's disappointing. I was hoping the code was at least up to legal review, but if it's not even running yet it sounds like we've got a while to wait for it.

                              Comment

                              Working...
                              X