ratGPU OpenCL PathTracing Benchmark

Discussion in 'GPGPU Technology & Programming' started by trinibwoy, Oct 31, 2010.

  1. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    11,618
    Likes Received:
    2,474
    Location:
    New York
    www.ratgpu.com

    Looks somewhat interesting. The author has a thread over at XS.

    [​IMG]

    Note on performance:

     
  2. CarstenS

    Legend Veteran Subscriber

    Joined:
    May 31, 2002
    Messages:
    5,644
    Likes Received:
    3,626
    Location:
    Germany
    GTX 480 in 3-way-SLI are hard to beat, I guess.

    For my system, it took almost 15 times longer - which exactly scales with the number of ALUs present in the chip. Nice.
    edit: Damn, didn't notice that the 3 GTX 480 were OCed.

    edit2: Damn again, I didn't notice, that the processors clock is wrong in older drivers.
     

    Attached Files:

    #2 CarstenS, Nov 1, 2010
    Last edited by a moderator: Nov 3, 2010
  3. Ethatron

    Regular Subscriber

    Joined:
    Jan 24, 2010
    Messages:
    942
    Likes Received:
    402
    Freezes the display-driver on my Cypress, without recovery.

    Treiber-Paketversion 8.782.1-101020a-106976E
    OpenCL 2.2

    edit: Well ...
     
  4. CarstenS

    Legend Veteran Subscriber

    Joined:
    May 31, 2002
    Messages:
    5,644
    Likes Received:
    3,626
    Location:
    Germany
    Same here, that's why I didn't post a score. And I won't be going back to 10.9 anytime soon. :) But it's an application in alpha status, such things happen.
     
  5. Ethatron

    Regular Subscriber

    Joined:
    Jan 24, 2010
    Messages:
    942
    Likes Received:
    402
    LOL, he blames ATI, you blame him (like I do too).

    He should opensource it, I would debug the code, as others would too. As long as the SDK's are so stubborn (maybe not really buggy, maybe yes), I'd advise one-man-shows to opensource right away. It's just win-win for everybody.

    Wouldn't return either, MLAA is too important ... I'm a NERD, tss. :oops:
     
  6. Karoshi

    Newcomer

    Joined:
    Aug 31, 2005
    Messages:
    181
    Likes Received:
    0
    Location:
    Mars
    A user level application should never, ever, crash your computer. Blame AMD here. And I'm looking at you, qualcomm's android libEGL.so, too.
     
  7. neliz

    neliz GIGABYTE Man
    Veteran

    Joined:
    Mar 30, 2005
    Messages:
    4,904
    Likes Received:
    23
    Location:
    In the know
    Ever since there's been compilers there have been ways to crash your system.
     
  8. EduardoS

    Newcomer

    Joined:
    Nov 8, 2008
    Messages:
    131
    Likes Received:
    0
    Yeah, they are called "system level bugs" wich may be from OS or drivers.
     
  9. Karoshi

    Newcomer

    Joined:
    Aug 31, 2005
    Messages:
    181
    Likes Received:
    0
    Location:
    Mars
    And even before there were compilers. Still, unprivileged application -> HLSL -> crash or unprivileged app -> OpenCL -> crash, is not the way to go.
    Considering the involved code paths it could be an AMD or a MS bug.
     
  10. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    Reminds me of the Win98 times where I clicked Strg-S every couple lines when programming because earlier runs of your program couldve already screwed up the system and crashing it any time.
    I fail to understand how such a system behavior is excusable nowadays, you should never be able to kill the OS from user-land code. But if its ATI apparently then its ok or not expected otherwise and the app is at fault.
     
  11. neliz

    neliz GIGABYTE Man
    Veteran

    Joined:
    Mar 30, 2005
    Messages:
    4,904
    Likes Received:
    23
    Location:
    In the know
    That's how you identify a German ;)

    The only country in the world that felt the need to translate keyboard shortcuts, not even the Chinese do that!
     
  12. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    Right language, wrong country :grin:
     
  13. neliz

    neliz GIGABYTE Man
    Veteran

    Joined:
    Mar 30, 2005
    Messages:
    4,904
    Likes Received:
    23
    Location:
    In the know
    Austria..

    I forgot "Der Grosse anschluss" wasn't final :(
     
  14. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,977
    Likes Received:
    510
    Location:
    Taiwan
    Right now there are too many possible problems with GPGPU. The most serious one is that currently GPU can't "multitask," that is, when you are running some GPGPU program the whole GPU is locked. Therefore, the "2 seconds rule" applies (or "5 seconds rule" in the case of Windows XP). However, even if one carefully makes sure all kernels take no more than 2 seconds to run, it's still unacceptable because a long kernel run makes the whole Windows UI unresponsive. So to make a GPGPU program "well behave" it generally has to run in like 0.1 seconds or less. Unfortunately, since there are many different GPU out there with very different performance level, an application will have to "guess" the performance level of a GPU intelligently to avoid possible problems. This is being tackled with and we will see some improvements in future GPUs.

    There are also other problems, such as memory protection (or lack of). Right now it's possible to "overwrite" some memory space to make it a whole mess (or even crash). Basically what's happening is "CPUization" or GPU, which shouldn't be surprising for anyone familiar with computer history :)
     
  15. CarstenS

    Legend Veteran Subscriber

    Joined:
    May 31, 2002
    Messages:
    5,644
    Likes Received:
    3,626
    Location:
    Germany
    I think it goes with the line of „alpha level” of the application. If it wasn't explicitly for that, I'd be way less merciful in my asessment. ;)
     
  16. Ethatron

    Regular Subscriber

    Joined:
    Jan 24, 2010
    Messages:
    942
    Likes Received:
    402
    I also had the impression it was a non-preemptive lock. It just didn't feel (let's say) killed enough. F.e. when my display-driver crashes because of some OpenGL-mess (I got one such application), mouse works for quite some time, music works even longer, when the driver is dead all PCI-devices delay I think (or all processes are halted till recovery). Then the driver comes up again.
    ratGPU I could maintain 15 minutes like that with Winamp playing in the BG before being too annoying. :smile: So either a compiler bug (creates infinite loop), or a programmer bug (created infinite loop, or another hammerer of some sort). Time will tell.

    The worst is you couldn't manually kill an infinite loop GPGPU-application if you wanted, right? I still don't understand that really, my OpenGL-raytracer (0.5-1.0 fpm) definitely does not slow down not even neighbour OpenGL-viewports. So why does OpenCL, from the inception even? It's not that we have a hard realtime scheduling requirement for any of them programs, no? :?:
     
  17. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,977
    Likes Received:
    510
    Location:
    Taiwan
    Technically, Windows should reset a non-responsive display driver. That's why we have a "5 seconds rule" for Windows XP and "2 seconds rule" for Vista/7. Basically, if a display driver becomes non-responsive for more than 2 seconds (or 5 seconds) it should be reset by the OS so everything should be fine. But it's possible that some driver bugs may prevent a reset in this case and cause an apparent "crash." This actually is not restricted to OpenCL only, because as you mentioned an OpenGL program could do the same (i.e. it's possible to issue an extremely long OpenGL shader to make a GPU busy for more than 2 seconds).

    If a GPU supports pre-emptive multi-tasking, it'd be able to maintain basic display functions while running GPGPU programs. Therefore the "2 seconds rule" wouldn't apply (because it never becomes non-responsive). Of course, you'd want to be able to kill any GPGPU program currently running on the GPU in case if it's stuck in an infinite loop, so you need a "task manager" on the GPU.
     
  18. Ethatron

    Regular Subscriber

    Joined:
    Jan 24, 2010
    Messages:
    942
    Likes Received:
    402
    We do have one, in hardware, on all architectures. The smart engineers just seemed to have forgotten "pause" and "abort" for the threads, just in case all ~500 running 'programms' are infinite loops. Removing the loop-count restriction some time ago anyway should have made some alarms ring. Now we have to wait for OpenCL 4.1. :frown:
    I'm well aware it's quite a complex, doesn't reduce the urge and need for pressure for real solutions though, right? Maybe we'd should be able to assign shader-affinity then we could at least recover from those cases, simplistic solution.
    BTW ... killing a GPU infinite-loop carrying OS-process, kills the GPU threads as well? If there is no "abort" they'll run forever? I don't know any analysis of the possible GPU states in respect to program flow and control. For example what exactly makes a driver think the GPU crashed? Are there any yellow, orange states? Are shaders "pingable", is there a program-counter, an instruction counter, so infinite loops can be detected by handlers? How exactly does the shader-debugger work? With diagram please. :smile:

    Hmm, there should be a 5000 pages GPU bible from Addison-Wesley, I just always got too much questions. A GPU cut open like the OCS/ECS/AGA chips, nice thought.
     
  19. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,977
    Likes Received:
    510
    Location:
    Taiwan
    Right now all we have is the "2 seconds rule" (or "5 seconds rule"). That is, if a GPU is busying running a shader/kernel, no matter whether it's an infinite loop or not (which is, of course, impossible to know anyway), the OS resets it after 2 seconds (or 5 seconds). This should always work for a normal display driver.

    For now shader debugger only works with non-displaying GPU (that is, you need two display cards on your system, or using network to connect to another computer). Basically, with current GPU you can't "pause" it while doing otherwise useful works (such as handling normal OS UI process).

    What we need now is the ability for a GPU to run some long shader/kernel while doing useful works at the same time. Given that current GPU have multiple MPs it should be possible, but unfortunately it's not the case for now.
     
  20. CarstenS

    Legend Veteran Subscriber

    Joined:
    May 31, 2002
    Messages:
    5,644
    Likes Received:
    3,626
    Location:
    Germany
    Returning to topic, I've run both a GTX 580 and a HD 5870/2G (with Cat 10.9 +Open CL) through this test - let's just say that something seems to be wrong with either the benchmark, the drivers or the hardware on AMDs side with the GTX 580 being more than twice as fast.

    I wonder, what it is this time that keeps AMD from getting their potential FLOPS advantage to show in real world tests. Did anyone look at the code of ratgpu yet?
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...