Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Predefined Macros: device type

  1. #1
    Senior Member
    Join Date
    Mar 2011
    Location
    Seoul
    Posts
    118

    Predefined Macros: device type

    Khronos should add the following (or an equivalent) predefined macros to the official OpenCL specification: __CPU__, __GPU__, __ACCELERATOR__, __X86__, and __X86_64__. This allows one kernel source to be maintained for all devices and the two most common ISAs, independent of the build options. Currently the AMD APP SDK supports all the requested predefined macros except __ACCELERATOR__.

  2. #2
    Junior Member
    Join Date
    Aug 2011
    Posts
    8

    Re: Predefined Macros: device type

    As already mentioned in another forum post, I would be happy if this would be included in the next standard too.

    Herbert

  3. #3
    Junior Member
    Join Date
    Mar 2011
    Posts
    1

    Re: Predefined Macros: device type

    All for it. Would be a really useful feature.

  4. #4
    Senior Member
    Join Date
    Mar 2011
    Location
    Seoul
    Posts
    118

    Re: Predefined Macros: device type

    Unfortunately I didn't see this suggestion adopted in the OpenCL 1.2 specifications. However, please consider it for the next version (although 18 months is an extremely long time to wait for something seemingly so simple).

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

    Re: Predefined Macros: device type

    Can you elaborate a little on how these work? For each device that the code is being built for, the OpenCL implementation would look at the device type and enable each of the corresponding macros?

    Considering that a device can be simultaneously a GPU, CPU, and accelerator (notice that cl_device_type is a bitfield), then multiple of these macros may be enabled at once?

    As for __X86__ and __X86_64__ that sounds more thorny. Why stop with x86? Most CPUs in the planet today are probably ARM and there are different variants of the ARM instruction set as well. Then the good folks at IBM will demand Cell to be included as well. Etc.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  6. #6
    Senior Member
    Join Date
    Mar 2011
    Location
    Seoul
    Posts
    118

    Re: Predefined Macros: device type

    I see, I didn't put much consideration into cl_device_type being a bitfield as you described. Actually that confuses me some. In your example of a device being simultaneously a GPU, CPU, and accelerator, how do you control exactly where the kernel is run? For some reason I was under the impression that you would get back three distinct devices (each with only one bit turned on in their respective cl_device_type bitfields).

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

    Re: Predefined Macros: device type

    In your example of a device being simultaneously a GPU, CPU, and accelerator, how do you control exactly where the kernel is run?
    It's a single device. The kernel runs in it. It's not a GPU and a CPU working separately anymore. It may sound confusing because such devices are not common yet.
    Disclaimer: Employee of Qualcomm Canada. Any opinions expressed here are personal and do not necessarily reflect the views of my employer. LinkedIn profile.

  8. #8
    Senior Member
    Join Date
    Sep 2002
    Location
    Santa Clara
    Posts
    105

    Re: Predefined Macros: device type

    Can't you do this by defining your own macro which is passed in the options argument to clBuildProgram? It does mean that you now need to call clBuildProgram separately for devices of different types in your CL context which makes it not very elegant.

  9. #9
    Senior Member
    Join Date
    Mar 2011
    Location
    Seoul
    Posts
    118

    Re: Predefined Macros: device type

    Quote Originally Posted by david.garcia
    It's a single device. The kernel runs in it. It's not a GPU and a CPU working separately anymore.
    How do you optimize for a device if you don't really know which particular hardware the software will be run? I guess you just program a simple scalar version and the hardware or runtime/driver will manage it all for you?

    Do you happen to know how current AMD APUs appear to developers: two distinct devices or one device with two cl_device_type bit-fields turned on? Are there any devices available to buy now that you described? BTW, I have an AMD Radeon HD 5970 (two identical GPU dies on one board) and it appears as two distinct GPU devices, which was contrary to my hopes and expectations. I'm starting to feel like there isn't much I can assume about CPU and GPU devices anymore.

    Quote Originally Posted by affie
    Can't you do this by defining your own macro which is passed in the options argument to clBuildProgram? It does mean that you now need to call clBuildProgram separately for devices of different types in your CL context which makes it not very elegant.
    Calling clBuildProgram separately as you mentioned was my main motivating factor to suggest adding this feature. I naively assumed it wouldn't be too difficult to implement since it's already available in the AMD OpenCL SDK.

  10. #10

    Re: Predefined Macros: device type

    I also think that this is a useful feature to add.
    It just means that these macros would be added automatically, instead of passing them manually.

Page 1 of 2 12 LastLast

Similar Threads

  1. OpenCL system, device type
    By giridhart in forum OpenCL
    Replies: 2
    Last Post: 07-30-2010, 03:24 AM
  2. Discrepancy between XAAudioInputDescriptor elements & macros
    By rajv in forum OpenMAX AL - feedback
    Replies: 1
    Last Post: 03-27-2009, 01:43 PM

Posting Permissions

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