Page 13 of 15 FirstFirst ... 31112131415 LastLast
Results 121 to 130 of 149

Thread: Another Look At The Latest Nouveau Gallium3D Driver

  1. #121
    Join Date
    Jul 2008
    Posts
    776

    Default

    Quote 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.

  2. #122
    Join Date
    Jan 2011
    Posts
    219

    Default

    Quote 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.

  3. #123
    Join Date
    Jul 2008
    Posts
    776

    Default

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

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

  4. #124
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote 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.

  5. #125
    Join Date
    Jan 2011
    Posts
    219

    Default

    Quote 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.

  6. #126
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote 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.

  7. #127
    Join Date
    Jan 2011
    Posts
    219

    Default

    Quote 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.

  8. #128
    Join Date
    Jan 2011
    Posts
    219

    Default

    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.

  9. #129
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,129

    Default

    Quote 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).

  10. #130
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •