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

                      Working...
                      X