Announcement

Collapse
No announcement yet.

Steam Machines Prototypes: Intel CPU, NVIDIA GPU

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

  • #21
    Originally posted by Fenrin View Post
    If I look on this Steam Machine specs, it looks not like a usual game console, but rather like a gaming PC. I'm hoping the steam controller will work on standard gaming PC's too, because I'm not willing to replace my PC yet!
    I'm sure it will also work with regular PCs...nothing so far tells otherwise...and if "real world" reviews about it are good, i will buy one myself.

    Comment


    • #22
      Originally posted by AJSB View Post
      What they did with Nouveau devs was more a PR stunt to make them look better to Linux "hardcore" users

      (...and i'm sure they will give more stuff with time to Nouveau devs...)

      The machines will use blobs so what they gave to Nouveau is irrelevant from that direct point...but was a nice PR stunt...
      I agree its irrelevant from that direct point. As for being "a nice PR stunt"... not so much. Or rather a tad bit more. Have you checked with the Nouveau devs? Open sourcing their blob probably isn't legally realistic and isn't going to happen. Publishing hardware specs and dropping some working code fragments as subtle hints is a whole 'nother story. Puts Nvidia playing catch-up on the same open source field as AMD, assuming Nvidia continues to follow through. We'll see. But if you want direct OEM-authored open source graphics drivers, stick with Intel.

      Comment


      • #23
        Thats actually a tad stupid from Valve. Maybe.

        Could have supported opensource drivers instead, since they were talking about SteamOS being opensource. That would deliver Wayland to you and faster, cheaper development. Cross company cooperation would have been sweet to customer wallet and long term stability.

        Its understandable, that they need OpenGL4 now and open drivers still can't deliver it. That is a slap in AMD face, in face of management part who disbelieved in open drivers and instead voted to ignore them, to sleep with m$ or said fglrx is sufficient. All in one, secured inability for them to catch up in terms of features.

        Still, could have helped put the stuff together here, Valve, could have managed that. Went stable, yet old and questionable ("f**ck'u", Linus-style) route. Or maybe AMD ties with m$ are just too firm to allow thinking in that direction.. With m$ supporters inside, stuff can get very very unstable quick - ask Elop.

        Yet, Nvidia are proprietary lovers. Valve is DRM company. One-two wrong internal suggestions and SteamOS will be open/closed sandwich, just like Android. Running own (closed?) desktop, binary incompatible, with nvidia drivers impossible for Linux and Valve's output/optimizations being held behind the NDA wall. It can all go "just another proprietary console/PC"-way very quick and will cut Linux userbase even further (with Ubuntu userbase filling the most of its ranks first, I think).

        Lets just get some popcorn and watch the show, at least we still have AMD/Intel open drivers, whose development is luckily not stagnating even a bit.

        Originally posted by pipe13 View Post
        But if you want direct OEM-authored open source graphics drivers, stick with Intel.
        Thats not correct, AMD's open drivers are really part of the company. At least now. Still,.. no opensauce center, like Intel.

        Originally posted by AJSB View Post
        I'm sure it will also work with regular PCs...nothing so far tells otherwise...and if "real world" reviews about it are good, i will buy one myself.
        How much will this blob be different from m$ blob?
        Last edited by brosis; 04 October 2013, 06:01 PM.

        Comment


        • #24
          Hmm, it seems AMD is trying to improve the catalyst on linux, at least - so it seems they really want a bite from this pie as well.

          Anyway, gentleman, calm down - this is a prototype HW - maybe the farthest one could go would be that it is somewhat a reference HW, but all this may change dramatically. If this gets successful we may see all kinds of manufacturers do steam HW. I can imagine something similar to intel NUC with NV GPU onboard, next to a massive passive cooler, for example.

          It will sure be interesting if manufacturers manage to price this adequately - console HW has a lot of price optimizations going on.

          Another thing - with linux under steam, one can imagine all kinds of weird things - for example a fuse filesystem enabling one to immediately play a game without waiting for it to completely download (game would download and cache locally in the background as one plays).

          Comment


          • #25
            Originally posted by Ritche Corpus/AMD View Post
            There is no counter.

            The reason is we are working just as closely with Valve.
            I think the difference is one side of that conversation is being more vocal than the other.
            If you go to Valve right now and ask them which hardware partners are going to be
            the partner of choice, they won?t pick one or the other.
            They are going to be agnostic. They mention that it?s an open ecosystem.
            Hey, Mr. Corpus,

            do some smart stuff - kill fglrx already and overclock the opensource driver development. IF you trust your own understanding of "open ecosystem". Because in closed source, there will be no agnosticism, ever. You know how maximum profits a.k.a. cartels work, right?

            Comment


            • #26
              Originally posted by AJSB View Post
              What they did with Nouveau devs was more a PR stunt to make them look better to Linux "hardcore" users

              (...and i'm sure they will give more stuff with time to Nouveau devs...)

              The machines will use blobs so what they gave to Nouveau is irrelevant from that direct point...but was a nice PR stunt...
              How would you have acted if you were in NVidia's shoes to create an acceptable compromise for both OSS/Linux as well as NVidia?

              Comment


              • #27
                Originally posted by alexThunder View Post
                Is there any device out there able to do this (in general, not linux-specific)? Afaik no. Even if it was, it'd very difficult to utilize (see heterogeneous parallelism). You'd have to find a balanced workload for different devices with different strengths and weaknesses. And now imagine, users could freely combine as many heterogenous devices for rendering, as they wanted - that'd be a pure nightmare for devs. Remember, they're already struggeling to supporting several single-GPU devices (compare the level of optimizations console- and pc-games get) :/
                I don't know if there is any device out there that can do this, but theoretically you have two processors running on the machine and you should be able to give each of them different tasks. For example, use one GPU to render the frame layers, and then pass that over to the other GPU to do post processing while the original GPU works on the next frame. Or, use one GPU as a GPGPU to calculate physics and use the other to do the rendering. I don't see why this can't be achieved.

                Comment


                • #28
                  Originally posted by sarmad View Post
                  I don't know if there is any device out there that can do this, but theoretically you have two processors running on the machine and you should be able to give each of them different tasks. For example, use one GPU to render the frame layers, and then pass that over to the other GPU to do post processing while the original GPU works on the next frame. Or, use one GPU as a GPGPU to calculate physics and use the other to do the rendering. I don't see why this can't be achieved.
                  It surely can be achieved. It's more a question about how complicated it's going to be. In the case of one GPU doing most of the rendering and the other one just some post-processing, you'd need to very well balance the tasks - they'd need to be completed in (nearly) exactly the same time, otherwise one GPU will bottleneck the other one. If that happens, the theoretical advantage about having two heterogenous GPUs sharing the workload is quickly gone.

                  Letting these hypothetical devices do independet tasks is some other story.

                  Comment


                  • #29
                    Still very, very worried about GPL violation

                    The specs are amazing, the use of Linux is amazing. BUT... kernel BLOBs & GPL don't go together well. I hope that this isn't going to be the first real test of "are kernel modules derivative works of the kernel"?

                    I hope that they have gone through this with a few lawyers when they figure out how to distribute SteamOS. Maybe it could pull the NVidia driver directly from NVidia's website, so technically it is the end user who "decides" to install the BLOB into their kernel.


                    In more open-source friendly news, I would imagine that the Bridgman and co. aren't going to sit around and let Stream not work nicely on Radeon chips with MESA. Then we purists can be happy too!

                    Comment


                    • #30
                      Originally posted by alexThunder View Post
                      It surely can be achieved. It's more a question about how complicated it's going to be. In the case of one GPU doing most of the rendering and the other one just some post-processing, you'd need to very well balance the tasks - they'd need to be completed in (nearly) exactly the same time, otherwise one GPU will bottleneck the other one. If that happens, the theoretical advantage about having two heterogenous GPUs sharing the workload is quickly gone.

                      Letting these hypothetical devices do independet tasks is some other story.
                      When you say it can be achieved, are you talking theoretically or practically? In terms of drivers and graphics stack, is Linux in its current status capable of achieving this?

                      Comment

                      Working...
                      X