Results 1 to 5 of 5

Thread: multiple command-queues in the same context for one device

  1. #1
    Junior Member
    Join Date
    Nov 2011
    Posts
    6

    multiple command-queues in the same context for one device

    Hello everyone!
    I have a problem with implementation of two command queues in the same context. The goal is to develope application, that could work in "two streams" mode. That means, that while the first queue processing executing the kernel, second processing copying from host to device.
    It can be implemented like this:
    Code :
    ...
    cl_command_queue queue[2];
    ...
    for (int i = 0; i < n; i++)
    {
      ...
      clEnqueueWriteBuffer(queue[0], buf,***);
      clEnqueueNDRangeKernel(queue[0], kernel,**);
    //then refreshing buf on the host
      if (i < n-1)
      clEnqueueWriteBuffer(queue[1], buf,***);
      ...
    }
    It's a humble peace of code, written just to present the idea.
    So, is this kind of programm is possible to be created with OpenCL? I know that CUDA lets develop algorithms like this.

    Any help is greatly appreciated!

  2. #2
    Senior Member
    Join Date
    May 2010
    Location
    Toronto, Canada
    Posts
    845

    Re: multiple command-queues in the same context for one devi

    The goal is to develope application, that could work in "two streams" mode. That means, that while the first queue processing executing the kernel, second processing copying from host to device.
    It is possible to create an application with multiple threads. However, you need to be aware of not introducing any race conditions. What you describe as "two streams mode" sounds a lot like double buffering.

    Notice that when double buffering is used, you must duplicate your surfaces/buffers/images so that, for example, while the NDRange is executing reading data from buffer0 there is a concurrent operation that is writing data for the next iteration into buffer1. If both of them were reading/writing into the same buffer you would have a race condition and the output would be incorrect most of the time.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  3. #3

    Re: multiple command-queues in the same context for one devi

    To use two different buffers should be pretty self-explanatory, but as far as I understood, the question then was: Does he need to use two queues or would be possible to use double-buffering with only one?

  4. #4
    Senior Member
    Join Date
    May 2010
    Location
    Toronto, Canada
    Posts
    845

    Re: multiple command-queues in the same context for one devi

    To use two different buffers should be pretty self-explanatory
    I pointed that out because his example code used only one buffer.

    Does he need to use two queues or would be possible to use double-buffering with only one?
    Command queues by default execute commands in order. That means that a command does not start executing until all previously enqueued commands have completed. In that case double buffering cannot improve performance.

    To implement double buffering with a chance of performance gains you need either an out-of-order queue or two queues. In any case you will need to set up event dependencies to prevent race conditions. If you are running all in the same device it is unlikely (but still possible) that you will see performance gains.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  5. #5
    Junior Member
    Join Date
    Nov 2011
    Posts
    6

    Re: multiple command-queues in the same context for one devi

    Thanks! I'll take into account youre advices!

Similar Threads

  1. Replies: 30
    Last Post: 07-23-2011, 06:40 PM
  2. Replies: 3
    Last Post: 12-08-2009, 10:29 AM

Posting Permissions

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