Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: are clCreateProgramWithSource & clBuildProgram thread-safe?

  1. #11
    Junior Member
    Join Date
    Apr 2011
    Posts
    13

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    Quote Originally Posted by david.garcia
    Since we have split the input data into different buffer objects for different devices, you will need different kernel objects for different devices as well. For example, if we have assigned buffer B1 and B2 to device D1, then you will create a kernel object K1 and set the kernel arguments to B1 and B2, then you will enqueue an NDRange using K1 on D1. Do the same for buffers B3 and B4 assigned to device D2: create a kernel K2, set the kernel arguments to B3 and B4, then enqueue an NDRange using K2 on D2. Etc.
    thank you again for your quick reply, but I am still not quite clear.

    let me ask this way: in your pseudo-code, the context and program are created for all devices, but kernel is created for each device. However, in clCreateKernel(), I can not find an argument to specify which device to associate with. I can only give "program" as the first argument, but it is already associated with all devices.

    Can you explain a little bit more?

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

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    let me ask this way: in your pseudo-code, the context and program are created for all devices, but kernel is created for each device. However, in clCreateKernel(), I can not find an argument to specify which device to associate with. I can only give "program" as the first argument, but it is already associated with all devices.
    Right. Kernel objects are associated with contexts, not with specific devices. However, kernel objects are nothing more than containers for the arguments that you will pass to the kernel function.

    Notice the sentence "you will enqueue an NDRange using K1 on D1". What that means is that when you call clEnqueueNDRange() you will pass it K1 and a command queue created from D1.

    It's important to distinguish between kernel objects (containers of function arguments), kernel functions (the actual function that is executed in the device) and NDRanges, that describe the amount of workload that will be executed and on what device it will be executed.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  3. #13
    Junior Member
    Join Date
    Apr 2011
    Posts
    13

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    Quote Originally Posted by david.garcia
    Right. Kernel objects are associated with contexts, not with specific devices. However, kernel objects are nothing more than containers for the arguments that you will pass to the kernel function.

    Notice the sentence "you will enqueue an NDRange using K1 on D1". What that means is that when you call clEnqueueNDRange() you will pass it K1 and a command queue created from D1.

    It's important to distinguish between kernel objects (containers of function arguments), kernel functions (the actual function that is executed in the device) and NDRanges, that describe the amount of workload that will be executed and on what device it will be executed.
    sorry for not being so careful reading your comments. Now I seem to get it. I modified the code and create multiple kernel objects for each device,setting arguments separately and pass it to clEnqueueNDRange. My first test went smoothly, except some compiling issues with NVIDIA drivers (I somehow got around by tweaking the cl code a bit).

    Comparing with the structure you recommended, I found one difference: I moved all clCreateBuffer() calls outside of the device loop, as it is only associated with the context. Is this ok? will these buffers get messed up when I feed them to different kernel objects?

  4. #14
    Junior Member
    Join Date
    Apr 2011
    Posts
    13

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    also, I saw your comments on memory transfer between multiple devices, can you explain this a bit more? or point me to the resources to explain what might be happening? thanks

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

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    Comparing with the structure you recommended, I found one difference: I moved all clCreateBuffer() calls outside of the device loop, as it is only associated with the context. Is this ok? will these buffers get messed up when I feed them to different kernel objects?
    The problem you have if you declare buffers outside of the device loop is that if any of the devices attempts to write to a buffer while other devices are reading or writing to it, the results will be undefined. If all devices are reading from the same buffers that's okay.

    That's why I recommended the simple approach where each device has its own buffer objects.

    I saw your comments on memory transfer between multiple devices, can you explain this a bit more?
    It's pretty simple, actually. Let's say you have a context with two different devices, and let's say that these devices have physically separate memory, like for example a discrete PCI-Express GPU and a CPU. According to OpenCL, buffers are shared among all the devices in the context, right? However, these devices have physically separate memory, so they can't actually share buffer objects.

    What's going on then? The driver will detect when a device needs to access a buffer and it will transfer it to that device. If later a different device needs to access the same buffer, the driver will transfer it to this second device. The application doesn't need to do anything: from the application's point of view buffer objects exist in global memory and all devices access that same global memory.

    Notice that there are platforms like cell phones where all devices share the same physical memory so these memory transfers are unnecessary.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  6. #16
    Junior Member
    Join Date
    Apr 2011
    Posts
    13

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    Quote Originally Posted by david.garcia
    The problem you have if you declare buffers outside of the device loop is that if any of the devices attempts to write to a buffer while other devices are reading or writing to it, the results will be undefined. If all devices are reading from the same buffers that's okay.
    thank you so much David! that is really helpful.
    I followed your advice, and created buffers for all devices, now the code works beautifully!

    Just want to make sure, I leave the read-only (including __constant) variables outside of the loop, as you pointed out, they will be sent to the device per request, thus does not seem to introduce additional overhead.

    I also have a __local variable, I call clSetKernelArg() per device to set the buffer length for each device. Is this the right way to do it?

    thanks again.

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

    Re: are clCreateProgramWithSource & clBuildProgram thread-sa

    I call clSetKernelArg() per device to set the buffer length for each device. Is this the right way to do it?
    Yes It looks like you have it all figured out already Congrats!
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. WFD Error Codes Thread Safe?
    By lewk in forum OpenWF
    Replies: 2
    Last Post: 07-12-2011, 09:04 AM
  2. is clGetEventInfo thread-safe?
    By diegor in forum OpenCL
    Replies: 0
    Last Post: 12-02-2009, 04:55 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
  •