Announcement

Collapse
No announcement yet.

The First NVIDIA GeForce Benchmarks On The SteamOS Beta

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

  • The First NVIDIA GeForce Benchmarks On The SteamOS Beta

    Phoronix: The First NVIDIA GeForce Benchmarks On The SteamOS Beta

    A comprehensive performance comparison is underway at Phoronix that pits SteamOS against other desktop Linux distributions, but for those anxious to see some performance numbers, here are benchmarks done so far this weekend from seven NVIDIA GeForce graphics cards on the public SteamOS 1.0 Beta operating system. In this article are early benchmarks from seven NVIDIA GeForce graphics cards running Valve's Debian Linux based SteamOS on an Intel Haswell system.

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

  • kwahoo
    replied
    Originally posted by gnufreex View Post
    They probably use RT kernel because of video capturing ability. They don't want to have huge spikes when video captring is stoped. RT gives more predictable change in performance.

    The Valve's use of rt kernel is great news because the developers were just looking to drop it https://lwn.net/Articles/572740/

    Now valve could pick up maintaining rt branch and mainline it eventualy.
    But Valve does not use rt kernel. See previous post.

    Leave a comment:


  • gnufreex
    replied
    They probably use RT kernel because of video capturing ability. They don't want to have huge spikes when video captring is stoped. RT gives more predictable change in performance.

    The Valve's use of rt kernel is great news because the developers were just looking to drop it https://lwn.net/Articles/572740/

    Now valve could pick up maintaining rt branch and mainline it eventualy.

    Leave a comment:


  • hjhamala
    replied
    Originally posted by ninez View Post
    You are assuming i am running SteamOS (with your uname -r comment). I'm not, only took a look through their source code to see if there was anything of interest....

    Thanks for clarifying the debian packaging, however, the assumption that because their beta ISO is using a generic kernel, that it automatically means their product will, may or may not be a good assumption to make... For example, If you want to be a senior software engineer at Valve; you *must* have knowledge / be able to solve problems on both non-realtime PCs *and* Realtime PCs. ~ note: it doesn't say realtime SoC<like in a peripheral or something like that, they say *PC*. (and neither MacOSX nor Windows are considered "realtime operating systems on PCs". (from their job postings); http://www.valvesoftware.com/job-SenSoftEngineer.html

    anyway, I'm not saying you're wrong (or that i am right), as a lot of this stuff is still up in the air, afaict. Maybe someone from Valve can clear that up.
    According to real time linux how to there is way to check is the kernel real time patched:
    https://rt.wiki.kernel.org/index.php...ing_the_Kernel
    Well I tried to test it. The results are:
    • Uname -a doesnt have RT string
    • Dmesg doesnt have string "Real-Time Preemption Support (C) 2004-2006 Ingo Molnar"
    • There is no kernel threads as [IRQ 7]
    • Proc interrupts doesnt look like Figure 9

    I think that this probably means that Valve is not using realtime patched kernel.

    Leave a comment:


  • ninez
    replied
    Originally posted by kwahoo View Post
    And? It's a part of the regular Debian kernel package. SteamOS does not use those patches. What is uname -r output? 3.10-3-amd64 instead 3.10-3-rt-amd64?
    You are assuming i am running SteamOS (with your uname -r comment). I'm not, only took a look through their source code to see if there was anything of interest....

    Thanks for clarifying the debian packaging, however, the assumption that because their beta ISO is using a generic kernel, that it automatically means their product will, may or may not be a good assumption to make... For example, If you want to be a senior software engineer at Valve; you *must* have knowledge / be able to solve problems on both non-realtime PCs *and* Realtime PCs. ~ note: it doesn't say realtime SoC<like in a peripheral or something like that, they say *PC*. (and neither MacOSX nor Windows are considered "realtime operating systems on PCs". (from their job postings); http://www.valvesoftware.com/job-SenSoftEngineer.html

    anyway, I'm not saying you're wrong (or that i am right), as a lot of this stuff is still up in the air, afaict. Maybe someone from Valve can clear that up.

    Leave a comment:


  • kwahoo
    replied
    Originally posted by ninez View Post
    You should probably look a little deeper in their packages... They ship a config for both PREEMPT_RT_FULL and non_rt;

    (from llinux-source-3.10_3.10.11-1+steamos5+bsos1_all.deb)

    /usr/src/linux-config-3.10/config.amd64_none_amd64.xz <- Generic
    /usr/src/linux-config-3.10/config.amd64_rt_amd64.xz <- PREEMPT_RT_FULL

    and;

    /usr/src/linux-source-3.10.tar.xz <- mainline kernel sources
    /usr/src/linux-patch-3.10-rt.patch.xz <- PREEMPT_RT_FULL patch

    ...

    IME, this is typical of any company that i have ever encountered who is using linux-rt patchset in their product... You include both, but usually in production, you are using RT with the vast majority of kernel debugging disabled, etc...

    ...and (again) in linux_3.10.11-1+steamos5.debian.tar.xz;

    .../patches/features/all/rt (contains linux-rt 3.10 patch, but broken down to individual commits/patches. 282 patches)
    And? It's a part of the regular Debian kernel package. SteamOS does not use those patches. What is uname -r output? 3.10-3-amd64 instead 3.10-3-rt-amd64?

    Leave a comment:


  • hjhamala
    replied
    Originally posted by justmy2cents View Post
    thanks on link

    PREEMPT RT enabled:
    - larger average
    - larger minimum
    + smaller maximum
    + more consistent

    please do correct me if i'm wrong, but i can't help my self but to see nothing but positive here, determinism simply could not exist without taking some toll. but, when you look at graph minimum didn't suffer much, maximum on the other hand did. as i see it input is constant small job that must be fitted to run constantly during larger processes and rt kernel seems to serve exactly that. i personally prefer predictable consistence.. worst case for game to be unplayable is that your input stutters like it did on some ps3 games i played where bluetooth 100ms lag was already norm. but, as i already said... i'm guessing here and i'd also say valve know why they decided on this one.
    Yes, I do agree with you. If this means much more constant experience for example in controller latency I will happily sacrifice some fps. Maybe also streaming from other computer will also benefit from this. Changing the kernel to the non-rt kernel should be also possible if these changes are not good for some one. This is Linux after all.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by hjhamala View Post
    According to these slides (Sony employee):
    http://elinux.org/images/5/51/Elce11_rowand.pdf
    We might expect next effects using realtime kernel (these are copied from the slides)
    - Variance of real-time task latency decreased
    + Maximum real-time task latency decreased
    - Average real-time task latency may be increased
    - Throughput decreased.
    thanks on link

    PREEMPT RT enabled:
    - larger average
    - larger minimum
    + smaller maximum
    + more consistent

    please do correct me if i'm wrong, but i can't help my self but to see nothing but positive here, determinism simply could not exist without taking some toll. but, when you look at graph minimum didn't suffer much, maximum on the other hand did. as i see it input is constant small job that must be fitted to run constantly during larger processes and rt kernel seems to serve exactly that. i personally prefer predictable consistence.. worst case for game to be unplayable is that your input stutters like it did on some ps3 games i played where bluetooth 100ms lag was already norm. but, as i already said... i'm guessing here and i'd also say valve know why they decided on this one.

    Leave a comment:


  • ninez
    replied
    Originally posted by kwahoo View Post
    You should probably look a little deeper in their packages... They ship a config for both PREEMPT_RT_FULL and non_rt;

    (from llinux-source-3.10_3.10.11-1+steamos5+bsos1_all.deb)

    /usr/src/linux-config-3.10/config.amd64_none_amd64.xz <- Generic
    /usr/src/linux-config-3.10/config.amd64_rt_amd64.xz <- PREEMPT_RT_FULL

    and;

    /usr/src/linux-source-3.10.tar.xz <- mainline kernel sources
    /usr/src/linux-patch-3.10-rt.patch.xz <- PREEMPT_RT_FULL patch

    ...

    IME, this is typical of any company that i have ever encountered who is using linux-rt patchset in their product... You include both, but usually in production, you are using RT with the vast majority of kernel debugging disabled, etc...

    ...and (again) in linux_3.10.11-1+steamos5.debian.tar.xz;

    .../patches/features/all/rt (contains linux-rt 3.10 patch, but broken down to individual commits/patches. 282 patches)

    Leave a comment:


  • kwahoo
    replied
    Originally posted by hjhamala View Post
    This is quite understandable because Valve has modified Linux kernel with real time patches.
    It has not. http://pastebin.com/PnEtb1aG

    Leave a comment:

Working...
X