Announcement

Collapse
No announcement yet.

Valve Ships An AMD Preview Driver For SteamOS

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

  • #11
    This is really disapointing news... I was hoping they would land a boatload of fixes to bring the open drivers up to par. Well, i hope thats still the target in the long run.

    I don't know if the fact that they are in the consoles is a reason to undermine the steam machine iniciative. Afterall, the same can be said about each concole, nobody argues amd favors sony instead of microsoft, why would they favor them instead of valve? Furthemroe, steam machines don't need amd to move forward, they may very well be successful relying on intel+nvidia combo, so it would be really shortsighted to not provide top notch SteamOS drivers at this point.

    Comment


    • #12
      what i don't understand is, when they launch a new graphic card they add a Whole new set of OpenGL functionality in the drivers in no time at all, while all these devs on mesa are taking a monstrous time to develop even most basic of them; Why is that?

      Comment


      • #13
        Originally posted by Figueiredo View Post
        I was hoping they would land a boatload of fixes to bring the open drivers up to par.
        I wouldn't count on that. There's so much infrastructure that needs to be put into place in so many places that this process will take a while to occur.

        In order to get to GL 4.4, there's many changes that will need to be made to the mesa core, the glsl compiler, the gallium state trackers, gallium shared core, and the radeon drivers. These changes affect not only AMD, but also Intel, Nouveau, VMWare, and the software rasterizers (softpipe/llvmpipe and swrast).

        Even if AMD dropped a giant patchbomb that implemented everything from OpenGL 3.2 (which r600/radeonsi almost handle) to 4.4 today, it'd still take a while to review and get the Intel/VMware/other people to sign off on merging the changes.

        That's also assuming that AMD simultaneously added unit tests in piglit for all of the new functionality being added... which would be a lot of new unit tests.

        I'd rather see a more incremental evolution where features get reviewed/merged as they're completed. It'll make regressions and bug hunting easier on everyone. Not that I'd complain if the pace of new features and the number of contributors increased.

        Comment


        • #14
          Originally posted by sireangelus View Post
          what i don't understand is, when they launch a new graphic card they add a Whole new set of OpenGL functionality in the drivers in no time at all, while all these devs on mesa are taking a monstrous time to develop even most basic of them; Why is that?
          There are several reasons. One is that they have documentation on how they must program it before it even enters production lines, another is that they usually recycle a good deal of the design, so in more cases than not it's just polishing details over the already implemented bits. This happens in the open drivers too, you don't see everyone starting over from scratch everytime a new card is out there.

          Comment


          • #15
            Originally posted by sireangelus View Post
            what i don't understand is, when they launch a new graphic card they add a Whole new set of OpenGL functionality in the drivers in no time at all, while all these devs on mesa are taking a monstrous time to develop even most basic of them; Why is that?
            2 reasons that I can see:

            1) The mesa guys are all playing catch-up. AMD's Catalyst already supports GL versions up to 4.3 (or maybe 4.4). So when a new card is launched, they have most of the front-end work done, and they just have to do the chip-specific bits which can often be based on the previous generation.

            2) The Catalyst driver team outnumbers the r600g/radeonsi team 100:1. Don't forget that the Catalyst Linux driver shares 90+% (probably 95+%) of its code with the Windows driver.

            Comment


            • #16
              Originally posted by Figueiredo View Post
              This is really disapointing news... I was hoping they would land a boatload of fixes to bring the open drivers up to par. Well, i hope thats still the target in the long run.
              exactly my sentiment.


              Originally posted by d2kx View Post
              Even if they did that, the opensource driver would not support OpenGL 4.x with high performance by the time Steam Machines ship.
              If intel chips with mesa are suitable for steamOS, then I don't see why amd + mesa shouldn't be. Games can't rely on openGL 4.x yet, anyway.


              Originally posted by mmrezaie View Post
              I think Catalyst is in so a bad condition that I just hope they fix the kde and flash bugs and forget about the gaming. I will never ever buy a notebook with ati graphics on board since I am just Linux user.
              Use the open source drivers then. Using them has been pretty painfree for me so far.

              Comment


              • #17
                Originally posted by Veerappan View Post
                I wouldn't count on that. There's so much infrastructure that needs to be put into place in so many places that this process will take a while to occur.

                In order to get to GL 4.4, there's many changes that will need to be made to the mesa core, the glsl compiler, the gallium state trackers, gallium shared core, and the radeon drivers. These changes affect not only AMD, but also Intel, Nouveau, VMWare, and the software rasterizers (softpipe/llvmpipe and swrast).

                Even if AMD dropped a giant patchbomb that implemented everything from OpenGL 3.2 (which r600/radeonsi almost handle) to 4.4 today, it'd still take a while to review and get the Intel/VMware/other people to sign off on merging the changes.

                That's also assuming that AMD simultaneously added unit tests in piglit for all of the new functionality being added... which would be a lot of new unit tests.

                I'd rather see a more incremental evolution where features get reviewed/merged as they're completed. It'll make regressions and bug hunting easier on everyone. Not that I'd complain if the pace of new features and the number of contributors increased.
                Well, it doesn't need to be that way. AMD could very well release a custom kernel+mesa+gallium stack for the specific SKUs featured in steam machines (which will most probably be all GNC anyway), while patches are commited to mainstream latter on, if ever. SteamOS already uses a out of tree kernel anyway... Obviously this may not be the optimal way to develop, but would certainly speed things up and put them in a better competitive position with regard to nvidia. But odds are I'm daydreaming and amd custumers that need linux+bleeding edge functionallity will have to endure with fglrx for several years still...

                Comment


                • #18
                  Originally posted by Figueiredo View Post
                  This is really disapointing news... I was hoping they would land a boatload of fixes to bring the open drivers up to par. Well, i hope thats still the target in the long run.

                  I don't know if the fact that they are in the consoles is a reason to undermine the steam machine iniciative. Afterall, the same can be said about each concole, nobody argues amd favors sony instead of microsoft, why would they favor them instead of valve? Furthemroe, steam machines don't need amd to move forward, they may very well be successful relying on intel+nvidia combo, so it would be really shortsighted to not provide top notch SteamOS drivers at this point.
                  Why would you assume that? They didn't use open drivers for nvidia, why would they for AMD? Not to mention legal/support reasons.

                  Comment


                  • #19
                    Originally posted by Figueiredo View Post
                    Well, it doesn't need to be that way. AMD could very well release a custom kernel+mesa+gallium stack for the specific SKUs featured in steam machines (which will most probably be all GNC anyway), while patches are commited to mainstream latter on, if ever. SteamOS already uses a out of tree kernel anyway... Obviously this may not be the optimal way to develop, but would certainly speed things up and put them in a better competitive position with regard to nvidia. But odds are I'm daydreaming and amd custumers that need linux+bleeding edge functionallity will have to endure with fglrx for several years still...
                    Glad to see you ignore reality and this thing called MESA being a design by committee venture.

                    Comment


                    • #20
                      Originally posted by Figueiredo View Post
                      Furthemroe, steam machines don't need amd to move forward, they may very well be successful relying on intel+nvidia combo, so it would be really shortsighted to not provide top notch SteamOS drivers at this point.
                      So when did you see AMD making a good marketing decision the last time? It must be for years now, that AMD marketing sucks.

                      Comment

                      Working...
                      X