Khronos Public Bugzilla
Bug 808 - Spec is not clear about what should happen if Double is not supported by the platform
Spec is not clear about what should happen if Double is not supported by the ...
Status: RESOLVED FIXED
Product: WebCL
Classification: Unclassified
Component: Specification
1.0
PC Mac OS
: P3 normal
: ---
Assigned To: WebCL Mailing List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-19 14:15 PST by Igor Oliveira
Modified: 2013-06-06 09:11 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Oliveira 2013-02-19 14:15:26 PST
Spec section 2.12:

  CLtype HALF   = 9;    // not supported in all implementations
  CLtype DOUBLE = 10;   // not supported in all implementations

half and double values are not supported values in the core OpenCL 1.1 spec, they are extensions. The spec is not clear about the behavior when the user tries to use those types and it is not supported.

note: Probably it is the same case of the webgl webcl interop, the browser can black list cl_khr_fp64 extension, so we can have problems creating the conformance tests.
Comment 1 steven eliuk 2013-03-14 15:26:06 PDT
From the 03/11/13 discussion, this is missing in the spec. The WG agreed that this support is through extensions and not supported, at this time, in the core API. 

Conformance tests based on extensions will have to be added as required.
Comment 2 Tomi Aarnio 2013-03-21 08:59:18 PDT
Fixed by adding the extensions "khr_fp64" and "khr_fp16".
Comment 3 steven eliuk 2013-05-01 09:33:04 PDT
Hi Tomi,

I see the two extensions were added to the core spec but there is still 'double' and 'half' types in the core spec. Shouldnt these be removed, then in the extension discussion one illustrates the availability of 'half' and 'double' types?
Comment 4 Mikael Bourges-Sevenier 2013-05-14 15:02:26 PDT
(In reply to comment #3)
> Hi Tomi,
> 
> I see the two extensions were added to the core spec but there is still
> 'double' and 'half' types in the core spec. Shouldnt these be removed, then
> in the extension discussion one illustrates the availability of 'half' and
> 'double' types?

That's a bug, it should have been removed when we transitioned to extensions.
Comment 5 Tomi Aarnio 2013-05-15 01:11:16 PDT
(In reply to comment #0)

>   CLtype HALF   = 9;    // not supported in all implementations
>   CLtype DOUBLE = 10;   // not supported in all implementations

We could move these two from WebCLKernelArgumentTypes to separate derived classes, like so:

  interface WebCLKernelArgumentTypesFP16 : WebCLKernelArgumentTypes {
    CLtype HALF = 9;
  }

  interface WebCLKernelArgumentTypesFP64 : WebCLKernelArgumentTypes {
    CLtype DOUBLE = 10;
  }

But then what do we do about other enums that are specific to fp16/64? There are several of those, including PREFERRED_VECTOR_WIDTH_{HALF,DOUBLE}. We can't put them into a class that's derived from WebCLKernelArgumentTypes, so we have to scrap that idea. This leaves us with an extension object that's not derived from any core WebCL class:

  interface WebCLFP16 {
    CLtype HALF = 9;
    CLenum PREFERRED_VECTOR_WIDTH_HALF = 0xDEADBEEF;
    ...
  }

That makes it even more awkward to set kernel args, though. Consider a half4 vector:

  var FP16 = device.getExtension("KHR_FP16");
  kernel.setArg(0, myArray, FP16.HALF | WebCLKernelArgumentTypes.VEC4);

On the other hand, you can make that less ugly by taking local copies of the values that you actually need:

  var HALF4 = FP16.HALF | WebCLKernelArgumentTypes.VEC4;
  kernel.setArg(0, [1.0, 2.0, 3.0, 4.0], HALF4);

Not ideal, but I guess the best we can get. I'll make these changes if there are no objections.
Comment 6 Tomi Aarnio 2013-06-06 09:11:57 PDT
Fixed as proposed in comment #5:

   interface WebCLFP16 {
     CLtype HALF = 9;
     CLenum PREFERRED_VECTOR_WIDTH_HALF = ...;
   }

...and similarly for WebCLFP64.