Announcement

Collapse
No announcement yet.

Nouveau vs. NVIDIA Linux vs. NVIDIA Windows 8.1

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

  • #31
    Originally posted by Michael View Post
    Cost isn't a matter, repeatability/automation is the entire matter.
    Well, unigine benches in the advanced and pro versions provide command line automation support; are you sure cost doesn't matter?

    By the way, i can understand the problem; have you ever considered applications like mouse click and movement simulators?
    The "start benchmark" button will ever be in the same position on the screen , so this task could be automated too.

    Michael, seriously, if a solution like that would make you use unigine benches more, let us know and i will do my best to write a launcher that automates the process even in the basic unigine versions.
    Last edited by kokoko3k; 11-01-2013, 08:56 AM.

    Comment


    • #32
      Originally posted by johnc View Post
      I'm eager to find out what these "significant performance improvements" are that Valve was touting with SteamOS.
      I think they are referring to this:
      http://blogs.valvesoftware.com/linux/faster-zombies/

      Comment


      • #33
        Originally posted by sarmad View Post
        I think they are referring to this:
        http://blogs.valvesoftware.com/linux/faster-zombies/
        I think they would need to bring a better example than that if they want to convince the public. Direct3D 9 is old and slow as molasses. Comparing it to modern OpenGL isn't going to cut it.

        Comment


        • #34
          Originally posted by kokoko3k View Post
          Well, unigine benches in the advanced and pro versions provide command line automation support; are you sure cost doesn't matter?

          By the way, i can understand the problem; have you ever considered applications like mouse click and movement simulators?
          The "start benchmark" button will ever be in the same position on the screen , so this task could be automated too.

          Michael, seriously, if a solution like that would make you use unigine benches more, let us know and i will do my best to write a launcher that automates the process even in the basic unigine versions.
          Unigine folks have troubles with proper OpenGL. (Missing glsl #version sic!!!)
          Or there are bad OpenGL implementations out there...

          We need multiplaform, multiapi OpenGL Conformance Test Suite...
          Anyone tried to run Piglit on Windows or OSX?

          Comment


          • #35
            Originally posted by kokoko3k View Post
            Well, unigine benches in the advanced and pro versions provide command line automation support; are you sure cost doesn't matter?

            By the way, i can understand the problem; have you ever considered applications like mouse click and movement simulators?
            The "start benchmark" button will ever be in the same position on the screen , so this task could be automated too.

            Michael, seriously, if a solution like that would make you use unigine benches more, let us know and i will do my best to write a launcher that automates the process even in the basic unigine versions.
            Phoronix Test Suite has full support for all of Unigine Engine tech demos... I work very closely with Unigine and have access to demos pre-launch, etc. There's even special code-paths that can be activated via a Phoronix switch for the Unigine Engine to make it more automated friendly.

            The issue doesn't come down to not wanting to use Unigine but often being buggy or problematic on different drivers, etc. Also would be nice if they did 64-bit builds.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #36
              Originally posted by Michael View Post
              Phoronix Test Suite has full support for all of Unigine Engine tech demos... I work very closely with Unigine and have access to demos pre-launch, etc. There's even special code-paths that can be activated via a Phoronix switch for the Unigine Engine to make it more automated friendly.

              The issue doesn't come down to not wanting to use Unigine but often being buggy or problematic on different drivers, etc. Also would be nice if they did 64-bit builds.
              Michael,

              Don't Stress.

              As the Romans ages ago learned. There is just no pleasing the masses.

              Keep up the good work as I enjoy the benches and the insights they provide.

              I think very few of the folks posting here actually understand the amount of vendor co-ordination required to get some things up and going.

              Once again, thank you for your efforts.

              Arno

              Comment


              • #37
                Originally posted by sarmad View Post
                What I still don't understand is why hardware manufacturers like AMD and nVidia keep their drivers closed source. If they are making profit from the hardware only, why close the software? What is so secret about it that they have to keep it closed source? In fact, I think open sourcing it should help them reduce the cost since the community would be doing some of the work on their behalf. Am I missing something?
                In the case of graphics, drivers matter. They play a huge role in performance. This is why Nvidia and AMD bounce back and forth every couple of months on who's cards currently holds the performance crown during the current generation. Releasing the drivers as open source would also be releasing hardware documentation on the cards. Nvidia and AMD definitely don't want each other knowing how their cards are designed and how they work. Then you run into licensed technology from other vendors to showing dirty hacks.

                The software is equally important as the hardware in the graphics arena.

                Comment


                • #38
                  Originally posted by middy View Post
                  In the case of graphics, drivers matter. They play a huge role in performance. This is why Nvidia and AMD bounce back and forth every couple of months on who's cards currently holds the performance crown during the current generation. Releasing the drivers as open source would also be releasing hardware documentation on the cards. Nvidia and AMD definitely don't want each other knowing how their cards are designed and how they work. Then you run into licensed technology from other vendors to showing dirty hacks.

                  The software is equally important as the hardware in the graphics arena.
                  How come this applies to GPUs but not CPUs, and how come Intel doesn't care about revealing hardware specs?

                  Comment


                  • #39
                    Originally posted by sarmad View Post
                    How come this applies to GPUs but not CPUs, and how come Intel doesn't care about revealing hardware specs?
                    It applies to GPUs but not CPUs because with a CPU the "published API" is the instruction set of the CPU so that part kinda has to be open. With a GPU the "published API" is a software abstraction, ie the top of a Direct3D or OpenGL stack, and vendors change the GPU HW instruction sets & configuration registers on a regular basis in order to improve performance and efficiency with recent and upcoming applications.

                    The best analogy is that the programming interface of a GPU is like the highly parallel micro-operation layer of an x86 CPU that sits behind the instruction decoder, which isn't open either.

                    I don't think it's correct to say "Intel doesn't care about releasing hardware specs" -- I'm sure their open source teams had to jump through just as many internal hoops as we did in order to get information out.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      The best analogy is that the programming interface of a GPU is like the highly parallel micro-operation layer of an x86 CPU that sits behind the instruction decoder, which isn't open either.
                      This analogy explains a lot, thanks.

                      Comment

                      Working...
                      X