Announcement

Collapse
No announcement yet.

iBuyPower Launching An AMD-Based Steam Machine

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

  • #31
    Originally posted by borsook View Post
    Not that nvidia is in any way better than AMD when it comes to graphics, but saying that games are not CPU bound assumes people play only FPS games. Strategy games (and I mean strategy games, not RTS) are and always will be CPU bound.
    Nvidia and AMD are equal in a hardware perspective. In a linux software perspective, nvidia is blatantly better. I'm not hating on AMD either, my main computer is an all-AMD system.

    Aside from turn-based strategy games and RTSs, what else is there? And I know they're undoubtedly CPU focused but how many of them will actually use 100% of a CPU? If the game uses 100% of 1 core and no others, then the game is poorly designed - you shouldn't have to rely on an Intel system to play a game at a decent frame rate.

    Either way, once the Excavator architecture comes out, AMD CPUs will be fine for single-threaded tasks.

    Comment


    • #32
      Originally posted by Figueiredo View Post
      Since only contributions to the linux kernel were mentioned, but no mention of frglx is given, I would assume that the open drivers are the one they will be betting at in the near future.
      That would be even more awesome than bettering fglrx.

      Originally posted by Figueiredo View Post
      Obviously this is purely speculation on my part, but steamachines are halfway between consoles and pcs. That meaning the builds are somewhat fixed. Thus, they may very well use custom kernels/mesa/gallium which are not yet thoroughly tested but support more features and/or have better performance than the mainline stack...
      The kernel is under the GPL (not sure about mesa), so distributing a patched kernel means they have to give us the patches. What should stop us to apply these patches to our own kernels? Also I don't believe with its limited manpower AMD wants to maintain a third linux graphic driver.

      Comment


      • #33
        Originally posted by TAXI View Post
        The kernel is under the GPL (not sure about mesa), so distributing a patched kernel means they have to give us the patches. What should stop us to apply these patches to our own kernels? Also I don't believe with its limited manpower AMD wants to maintain a third linux graphic driver.
        I don't think its about holding patches from upstream, i'm only hinting at the possibility that there may be more than meets the eye being developed behind closed doors, such as was the case with UVD and DPM. Obviously we could apply such patches and, if they indeed exist, AMD would most probably send them upstream when deemed stable. But, we all know that it takes several releases and much testing to get in a reasonable state for the wild variety of hardware out there. Thus, it is not impossible that it is initianlly being developed focused, for example, on the two or three radeonsi skus that will be featured in steamachines and pushed upstream when in a better shape.

        Nvidia will also come around as well, tegra 5 is kepler based, so the kms driver for kepler will also be made public when tegra 5 is released (in the form of an out of tree kernel for android). I don't know how much more is needed on the gallium side, but noveau should probably be in much better shape in a year from now.

        Comment


        • #34
          Originally posted by TAXI View Post
          Do you count companies like Valve as users?
          There's going to be both Nvidia and AMD steam machines if users don't buy the amd based ones then the companies will switch to nvidia, if amd don't want this they just have to improve the driver, i'm sure that the freebsd driver for the ps4 is better than the linux driver right now.

          Comment


          • #35
            Originally posted by schmidtbag View Post
            Aside from turn-based strategy games and RTSs, what else is there?
            Strategy games with tick-based timing schemes, which are not RT as such, as time moves in discrete steps, but there are no clearly distinct turns either.

            Comment


            • #36
              Originally posted by dee. View Post
              Strategy games with tick-based timing schemes, which are not RT as such, as time moves in discrete steps, but there are no clearly distinct turns either.
              Ok, and what's an example of one that would put an AMD CPU to it's knees? I'm legitimately wondering - I don't know many games of that type.

              Comment


              • #37
                I have an AMD 7870 card, and I'm not really going to complain about the OpenGL performance because on the games I run, it seems to work fine (though from what I understand, there are issues for other games/software that just don't happen to affect me). However, one thing that really irks me about the Catalyst driver is the video performance, especially screen tearing. I can work around the difficulties in media players by setting them to use OpenGL for video output (though this should not be necessary, or even desirable, but it does work). However this doesn't work, of course, for Flash video within a browser, or even HTML 5 video within a browser. The performance for this is terrible. It seems worse than it used to be with Catalyst drivers on my laptop with a mobile 4850 AMD card.

                The really good part of this (from a sarcastic viewpoint), though, is that the open source drivers now work great on my laptop for video -- much better than the Catalyst drivers ever worked. It doesn't even seem to matter whether I use VDPAU or just the textured xv overlay; it all works very well. The open source drivers seem to work reasonably well for OpenGL as well. I don't have any games loaded that seem to be a problem, though I haven't tried my most demanding games. The question that I just have to ask is, if the open source drivers can work great for video, why can't AMD make their drivers work acceptably? My conclusion is that they just don't care enough.

                This leaves us in this funny situation where AMD is the sweet spot for three or four year old hardware, but not for new hardware. Is that what AMD really wants, to be the best old hardware for Linux to run on, but arguably the worst new hardware?

                Comment


                • #38
                  Originally posted by darkbasic View Post
                  Valve should prohibit using the Steam name with AMD hardware.
                  Valve wouldn't be stupid enough to simply throw away all the extra money they would receive through licensing.
                  You on the other hand have no idea how to effectively run a company, so I suggest you stop pretending that you do.

                  Comment


                  • #39
                    Workaround for Catalyst Full Motion Video Tearing

                    I happened to figure out a workaround for tearing in Flash/HTML5 videos in a browser that seems to work OK for me. I am running XFCE as a desktop, and I have to turn off the built-in compositing on all of my hardware because it actually makes video card/driver combinations that normally work great tear when it's turned on. XFCE developers really have to fix that if they want to include the compositor as a useful feature. However, on my desktop with a 7870 I have found that the Compton compositor actually mitigates tearing of Flash/HTML5 videos played in a browser (no doubt because it sends the whole desktop through OpenGL for display on the screen). It seems to interfere with at least some games, however, so I have to turn it on and off as I switch between different activities. It's not as good as properly working drivers, but it's better than nothing.

                    Comment


                    • #40
                      Originally posted by TAXI View Post
                      That would be even more awesome than bettering fglrx.


                      The kernel is under the GPL (not sure about mesa), so distributing a patched kernel means they have to give us the patches. What should stop us to apply these patches to our own kernels? Also I don't believe with its limited manpower AMD wants to maintain a third linux graphic driver.
                      There is literally nothing stopping these guys from shipping kernel patches or proprietary modules separate from the kernel, then at the first boot, running a script that compiles these changes into the kernel. This doesn't count as distribution, so the GPL doesn't kick in.

                      Comment

                      Working...
                      X