Announcement

Collapse
No announcement yet.

Another Look At The Latest Nouveau Gallium3D Driver

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

  • Originally posted by Thatguy View Post
    here ya go, 4 of the same h264 video being decoded at the same time, using only a vesa 2.0 renderer.
    deanjo said some problems with your benchmarks, but even if its possible to watch x264 1080p video with a phenom with 3,2ghz or what you have. But on my slightly older athlon x3800 (2ghz) its a dia-show. Maybe this movie would work it have surely not that high bitrates, but normal videos does not work. And even if I have update it it will maybe will work, but with high cpu usage. On my atom netbook not even 720p works under linux (x264).
    So I have maybe luck if I buy a strong fusion thing as netbook that the cpu work with 720p, but akku-time will then surely go down a strongly. here would gpu-acceleration provide me first double the accu time and 1080p (ok I dont need that there ^^) capability.

    Comment


    • Originally posted by blackiwid View Post
      deanjo said some problems with your benchmarks, but even if its possible to watch x264 1080p video with a phenom with 3,2ghz or what you have. But on my slightly older athlon x3800 (2ghz) its a dia-show. Maybe this movie would work it have surely not that high bitrates, but normal videos does not work. And even if I have update it it will maybe will work, but with high cpu usage. On my atom netbook not even 720p works under linux (x264).
      So I have maybe luck if I buy a strong fusion thing as netbook that the cpu work with 720p, but akku-time will then surely go down a strongly. here would gpu-acceleration provide me first double the accu time and 1080p (ok I dont need that there ^^) capability.
      People seem to forget that the size and wieght of the kernel and its use of resources can have a dramatic effect on system performance. the lighter the kernel, the more you can do with it, to a point.

      the linux kernel is pretty damn heavy these days.

      try a different OS and a different kernel design, you might find a great deal of performance to be had in some areas and less in others. I will tell you my 2.8ghz single core p4 system cannot play this video at all. However my athalon AMD1.9ghz xp3800 system does it without a hitch.

      Comment


      • what do you mean with different os a different distribution or windows or bsd? ^^

        We talk about the free radeon driver do we ^^.

        Comment


        • Originally posted by Thatguy View Post
          People seem to forget that the size and wieght of the kernel and its use of resources can have a dramatic effect on system performance. the lighter the kernel, the more you can do with it, to a point.

          the linux kernel is pretty damn heavy these days.

          try a different OS and a different kernel design, you might find a great deal of performance to be had in some areas and less in others. I will tell you my 2.8ghz single core p4 system cannot play this video at all. However my athalon AMD1.9ghz xp3800 system does it without a hitch.
          Kernel overhead has very little to do with video playback. You might as well say receiving email bogs down video playback. Almost all of the load from video playback comes from video playback. Never the less with video decode acceleration you can pretty much max out all cores doing other stuff such as compiling with many threads and still have glitch free video playback. One of my HTPC's for example is running a local build server in the background pretty much 24/7 maxing out the quad core without any noticable loss of compiling performance but yet it still can deliver a flawless hiccup free 1080p HD playback in true full 1080p resolutions (not scaled down) playback even with a lowly IGP that had video decode acceleration. If kernel overhead does start interfering you are running way to marginal of a setup for it to be counted on for reliable playback anyways.

          Comment


          • Originally posted by deanjo View Post
            Kernel overhead has very little to do with video playback. You might as well say receiving email bogs down video playback. Almost all of the load from video playback comes from video playback. Never the less with video decode acceleration you can pretty much max out all cores doing other stuff such as compiling with many threads and still have glitch free video playback. One of my HTPC's for example is running a local build server in the background pretty much 24/7 maxing out the quad core without any noticable loss of compiling performance but yet it still can deliver a flawless hiccup free 1080p HD playback in true full 1080p resolutions (not scaled down) playback even with a lowly IGP that had video decode acceleration. If kernel overhead does start interfering you are running way to marginal of a setup for it to be counted on for reliable playback anyways.
            Not true, the length of the primary code loop has a effect on the execution of subroutines. Mind you we are talking non excelerated video here where the kernel is decoding video not hardware.

            Comment


            • Originally posted by Thatguy View Post
              Not true, the length of the primary code loop has a effect on the execution of subroutines. Mind you we are talking non excelerated video here where the kernel is decoding video not hardware.
              No where near where the impact that you make it out to be. Even with ultralow latency kernels the overhead is a negligible factor in video playback.

              Comment


              • Originally posted by deanjo View Post
                No where near where the impact that you make it out to be. Even with ultralow latency kernels the overhead is a negligible factor in video playback.
                Thats not true, what comes into play is how many clock cycles it takes to run through the kernel before you can execute a subroutine. Once your kernel starts to overtake that subroutine for execution then your kernel is impossing overhead, but the scenario we are discussing here is relevant to slow processors and large kernels.

                But thats even if you subroutine can be run inside a single kernel loop for a given clock speed.

                Comment


                • if you have 5000 cycles per frame of video available of computation power and your kernel needs 4000 of the cycles and the video need 3000 cycles, your kernel is impossing overhead.What really killing alot of cpu power is that its kernel + other services.

                  Now mind you this in in a processor limited scenario.

                  Comment


                  • Originally posted by Thatguy View Post
                    if you have 5000 cycles per frame of video available of computation power and your kernel needs 4000 of the cycles and the video need 3000 cycles, your kernel is impossing overhead.What really killing alot of cpu power is that its kernel + other services.

                    Now mind you this in in a processor limited scenario.
                    If that was the case, then upping the process priority would reduce context switches and improve video playback performance. However, when I tested on my Athlon XP 2500+, this didn't seem to make any difference at all.

                    It's unlikely that the kernel is the limiting factor here (indeed, you can see exactly how much kernel time your CPU is spending).

                    Comment


                    • Originally posted by Thatguy View Post
                      if you have 5000 cycles per frame of video available of computation power and your kernel needs 4000 of the cycles and the video need 3000 cycles, your kernel is impossing overhead.What really killing alot of cpu power is that its kernel + other services.

                      Now mind you this in in a processor limited scenario.
                      Ya that might be a concern on a 8088 but not on a modern processor. Your scenario only occurs if the processor can only marginally run the kernel on it's own.

                      Comment


                      • Originally posted by deanjo View Post
                        Ya that might be a concern on a 8088 but not on a modern processor. Your scenario only occurs if the processor can only marginally run the kernel on it's own.
                        define marginally ? thats kind of my point to. Its all about system overhead " at a certain point it becomes meaningless" but it can be a big factor in how capable hardware can be in a given situation.

                        Comment


                        • Originally posted by Thatguy View Post
                          define marginally ?
                          Barely able to

                          Comment


                          • Originally posted by deanjo View Post
                            Barely able to
                            I think those days "aside from ARM' are pretty much way behind us. even the most basic systems at walmart 2 cores can easily play video without any acceleration at all.

                            Comment


                            • Originally posted by Thatguy View Post
                              I think those days "aside from ARM' are pretty much way behind us. even the most basic systems at walmart 2 cores can easily play video without any acceleration at all.
                              You would be surprised. Your "tests" are not for example using sound methodology. As I pointed out before:

                              1) You have selected a fairly light example of video, I gave you a more "typical" encode that falls within many hd program streams. Even it however is nowhere close to being a typical h264 stream on say a bluray.

                              2) you are not playing them back at full resolution, by the looks of it you are running your system @ 1280x1024 which equates to less then 1/2 the amount of pixels (output of the video would be if running fullscreen 1280x720) the display has to render as it would on a 1080p machine. For any meaningful results you would have to be rendering the output at the videos native resolution.

                              Comment


                              • Originally posted by deanjo View Post
                                You would be surprised. Your "tests" are not for example using sound methodology. As I pointed out before:

                                1) You have selected a fairly light example of video, I gave you a more "typical" encode that falls within many hd program streams. Even it however is nowhere close to being a typical h264 stream on say a bluray.

                                2) you are not playing them back at full resolution, by the looks of it you are running your system @ 1280x1024 which equates to less then 1/2 the amount of pixels (output of the video would be if running fullscreen 1280x720) the display has to render as it would on a 1080p machine. For any meaningful results you would have to be rendering the output at the videos native resolution.
                                It doesn't make a difference, it still also has to cut bitrate and dither which costs clock. being as my video hardware is unsupported I can only display at that resolution currently.

                                But seriously. Its a non issue. 99% of users aren't compiling a kernel while watching a video. Usually they are watching just the video.

                                Also the bit rate of big buck bunny is typical of most video streaming bit rates. I have no idea where your comming up with the counter argument.

                                I can even play 4 of the same video in the same size simultanoeusly which was my point.

                                In todays day and age of fast cpu for x86, we simply don't have a huge pressing need for video accelration.

                                Its like chasing a white elephant, it only makes you tired.

                                Now if your saying that ARM needs vide accelration. I whole heartedly agree. But most of todays modern dual core and up systems are completely cpabale of playing video with zero acceleration and 1980x1020 isn't even all that popular. most video on pcs are DVD or lower quality. blue Ray players aren't even very common acesseories yet.

                                Comment

                                Working...
                                X