Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: OpenCL Support In GCC?

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,467

    Default OpenCL Support In GCC?

    Phoronix: OpenCL Support In GCC?

    In early December the OpenCL specification was unveiled, which is an open framework initially conceived by Apple for extending the power of graphics processors to better handle GPGPU computing in a unified way. Both ATI/AMD and NVIDIA are working on bringing Open Computing Language support to their proprietary Linux drivers, while nothing has yet to be started on the open-source side to integrate the support within Mesa...

    http://www.phoronix.com/vr.php?view=NzAzMA

  2. #2
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    If I want to write an application that uses OpenCL and want to compile this application with GCC, does GCC need to support OpenCL in this case?

  3. #3
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Only if the OpenCL implementation in the drivers makes use of gcc to parse the C99 code and feed it into the lower level compiler stack. Normally the app makes OpenCL calls to compile the compute kernel, and the driver can use whatever C99 implementation it wants.

    Note that the driver itself could be *compiled* with gcc and that would still not require OpenCL support in gcc. The only thing that matters is what the driver does when an OpenCL app says "Compile This !!".
    Last edited by bridgman; 02-01-2009 at 10:44 AM.

  4. #4
    Join Date
    May 2008
    Posts
    598

    Default

    I have seen OpenCL Python bindings, and OpenCL C like code. Are all code in both cases executed on the CPU during the entire process, or are the code made into GPU bytecode that is loaded into the GPU, so it is the GPU that executes the OpenCL code?

    There are pointers in the C like OpenCL. Does that mean that OpenCL can see and modify all of the GPU's memory?

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Good point - there may be some work (libs, bindings etc..) required to gcc in order to simply *use* OpenCL. I wasn't thinking about that side of it (driver-centric world view I guess ).

    The kernel program provided by the OpenCL app would normally be run on GPU, DSP, Cell, whatever -- but I expect many implementations will also allow execution on the CPU.

    I imagine that pointers could access the entire GPU address space unless blocked by memory management or by checking code generated by the compiler, but presumably the main purpose of them is to navigate predefined data structures.

  6. #6
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    The kernel program provided by the OpenCL app would normally be run on GPU, DSP, Cell, whatever -- but I expect many implementations will also allow execution on the CPU.
    So a GPU can have processes running? Does that mean, that there could be made a "ps" and "top" for GPU processes?

    It would be so cool to have a Gnome/KDE GPU load monitor

    It sounds quite complex, that the OpenCL kernel will be in the GPU, when the Mesa OpenCL driver will run on the CPU.

    Does that mean, that if the Mesa OpenCL driver crashes, the GPU will continue to do its OpenCL calculations?

    Quote Originally Posted by bridgman View Post
    I imagine that pointers could access the entire GPU address space unless blocked by memory management or by checking code generated by the compiler, but presumably the main purpose of them is to navigate predefined data structures.
    Quite cool feature

  7. #7
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Quote Originally Posted by Louise View Post
    So a GPU can have processes running? Does that mean, that there could be made a "ps" and "top" for GPU processes?

    It would be so cool to have a Gnome/KDE GPU load monitor

    [...]
    Sorry for dragging up an old thread, but yes, you can have "top" for the GPU, behold intel_gpu_top:



    I guess a someone still needs to write a load monitor for your favourite desktop

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Running a kernel under OpenCL is pretty similar to running a pixel shader program under OpenGL -- the app says "for every pixel run this program", then throws triangles or rectangles at the GPU. The GPU then runs the appropriate shader program on every pixel, and on modern GPUs that involves running hundreds of threads in parallel (an RV770 can execute 160 instructions in parallel, each doing up to 5 floating point MADs, or 10 FLOPs per instruction).

    The per-pixel output from the shader program usually goes to the screen, but it could go into a buffer which gets used elsewhere or read back into system memory. The Mesa driver runs on the CPU but the shader programs run on the GPU.

    Same with OpenCL; driver runs on the CPU but a bunch of copies of the kernel run in parallel on the GPU. The key point is that the GPU is only working on one task at a time, but within that task it can work on hundreds of data items in parallel. That's why GPUs are described as data-parallel rather than task-parallel.

    The data-parallel vs task-parallel distinction is also why the question of "how many cores does a GPU have ?" is so tricky to answer. Depending on your criteria, an RV770 can be described as single-core, 10 core, 160 core or 800 core. The 10-core answer is probably most technically correct, while the 160-core answer probably gives the most accurate idea of throughput relative to a conventional CPU.

    Anyways, since a GPU fundamentally works on one task at a time and the drriver time-slices between different tasks it should be possible to hook into the driver and track what percentage of the time is being used by each of the tasks. That hasn't been useful in the past (since all the GPU workload typically comes from whatever app you are running at the moment) but as we start juggling multiple tasks on the GPU that will probably become more important (and more interesting to watch ).
    Last edited by bridgman; 02-01-2009 at 03:08 PM.

  9. #9
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    Running a kernel under OpenCL is pretty similar to running a pixel shader program under OpenGL -- the app says "for every pixel run this program", then throws triangles or rectangles at the GPU. The GPU then runs the appropriate shader program on every pixel, and on modern GPUs that involves running hundreds of threads in parallel (an RV770 can execute 160 instructions in parallel, each doing up to 5 floating point MADs, or 10 FLOPs per instruction).

    The per-pixel output from the shader program usually goes to the screen, but it could go into a buffer which gets used elsewhere or read back into system memory. The Mesa driver runs on the CPU but the shader programs run on the GPU.

    Same with OpenCL; driver runs on the CPU but a bunch of copies of the kernel run in parallel on the GPU. The key point is that the GPU is only working on one task at a time, but within that task it can work on hundreds of data items in parallel. That's why GPUs are described as data-parallel rather than task-parallel.

    The data-parallel vs task-parallel distinction is also why the question of "how many cores does a GPU have ?" is so tricky to answer. Depending on your criteria, an RV770 can be described as single-core, 10 core, 160 core or 800 core. The 10-core answer is probably most technically correct, while the 160-core answer probably gives the most accurate idea of throughput relative to a conventional CPU.

    Anyways, since a GPU fundamentally works on one task at a time and the drriver time-slices between different tasks it should be possible to hook into the driver and track what percentage of the time is being used by each of the tasks. That hasn't been useful in the past (since all the GPU workload typically comes from whatever app you are running at the moment) but as we start juggling multiple tasks on the GPU that will probably become more important (and more interesting to watch ).
    Okay, so a pixel shader is more or less an infinite while-loop?

    So if we have OpenCL into play, does that mean, that the OpenGL and OpenCL driver schedule which turn it is to get data processed, as the GPU only can handle one task at a time?

    Let's say I write a OpenCL program that simulates a flow. Is that program the kernel for the GPU? Or is the kernel something Mesa would write to intercept my flow simulation program?

    How many kernels can the GPU have running?

  10. #10
    Join Date
    Jun 2007
    Location
    Albuquerque NM USA
    Posts
    342

    Default

    My head just exploded.

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
  •