RE: [Public WebCL] WebCL syntax style?

[<tomi.aarnio@nokia.com>]

Chris, all,

There is no interaction with WebGL, but that's only because Firefox extensions don't have access to WebGL resources (or their corresponding native OpenGL resources). That could be fixed by either Mozilla exposing the necessary APIs, or by someone integrating WebCL into the browser.

Regarding the WebCL API syntax, let's take a concrete example as a basis for discussion -- the native function clEnqueueMapImage:

http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueMapImage.html

void * clEnqueueMapImage (cl_command_queue command_queue,
  	cl_mem image,
  	cl_bool blocking_map,
  	cl_map_flags map_flags,
  	const size_t origin[3],
  	const size_t region[3],
  	size_t *image_row_pitch,
  	size_t *image_slice_pitch,
  	cl_uint num_events_in_wait_list,
  	const cl_event *event_wait_list,
  	cl_event *event,
  	cl_int *errcode_ret)

This function exhibits pretty much all the different parameter passing mechanisms that are used in OpenCL. It has a return value, four output parameters, and a bunch of inputs, including objects, enums and arrays. Here's how we've mapped it to JavaScript:

http://projects.forum.nokia.com/dav/webcl/docs/html/interfaceIWebCLCommandQueue.html#ae9808bcfedb9db457d2644ee53d55477

IWebCLEvent IWebCLCommandQueue::enqueueMapImage( 	
		in IWebCLMemoryObject  	aImage,
		in boolean  	aBlockingMap,
		in T_WebCLMapFlags  	aMapFlags,
		in nsIVariant  	aOrigin,
		in nsIVariant  	aRegion,
		in nsIVariant  	aEventWaitList,
		in IWebCLDataObject  	aDataObject) 	

Some points of interest:
1) cl_command_queue is mapped to a class WebCLCommandQueue.
2) clEnqueueMapImage becomes a member function of WebCLCommandQueue.
3) The void * return value is replaced by a WebCLDataObject.
4) The WebCLDataObject also incorporates the row_pitch and slice_pitch output parameters.
5) The "origin" and "region" inputs are mapped to regular JavaScript arrays.
6) The "event" output parameter becomes the function return value.

WebCLDataObject is something that we'd like to get rid of. Its main reason for existence is/was to isolate all interfacing with TypedArrays into one module, because the TypedArray spec and its implementation in Firefox were constantly changing. Now that things are becoming more stable, we should be able to switch to TypedArrays across the API. However, there are a few other things that the DataObject is also doing, such as writing pixels to/from Canvas, and storing metadata (such as the row_pitch and slice_pitch in the above example), so we need to figure out alternative means to get those done.

Best regards,
  Tomi

-----Original Message-----
From: ext Chris Marrin [mailto:cmarrin@apple.com] 
Sent: 26. toukokuuta 2011 1:48
To: Simon Gibbs - SISA
Cc: Ian Johnson; steve@sjbaker.org; Aarnio Tomi (Nokia-NRC/Tampere); demidov@ipm.sci-nnov.ru; public_webcl@khronos.org; Gordon Erlebacher
Subject: Re: [Public WebCL] WebCL syntax style?


On May 25, 2011, at 8:49 AM, Simon Gibbs - SISA wrote:

> 
> On May 24, 2011, at 4:40 PM, Chris Marrin wrote:
> 
> ============================<cut>
> 
> 1) Keeping it like OpenGL allows us to leverage the learning of 
> existing OpenGL developers.
> 
> 2) OpenGL ES is a very lightweight API which is very powerful. Moving 
> away from its native API means you either make it more heavyweight or 
> lose some of its power.
> 
> 3) Adding structure to the library would necessarily bias it toward a 
> certain solution space, making it less appropriate for other uses.
> 
> 4) Coming up with a higher level API that would satisfy everyone would 
> have either been impossible or would have taken much too long.
> 
> We learned from the success of OpenGL vs the difficulties of higher 
> level representations like X3D. Keeping it simple makes it fit a wide 
> variety of use cases, and higher level abstractions that suit a 
> particular need can be layered on top.
> 
> ============================<cut>
> 
> 
> It seems the above arguments also apply to OpenCL/WebCL. In addition I 
> think there's another reason WebCL APIs should be similar to OpenCL:
> 
> 5) OpenCL and WebCL will evolve. It will be easier to keep the two in 
> sync if WebCL APIs closely resemble those in OpenCL.

Ok, after comparing the API's more closely, OpenCL does follow an object model much more closely than OpenGL. Even though it's a C API, every call that is not "static" contains the object being operated on. So that makes the WebCL API a good reflection of OpenCL.

The only question is how WebCL and WebGL interact. OpenCL has an API for this purpose, but I don't see that represented in WebCL. Is that API coming, or did I miss seeing it in the current API? 

-----
~Chris
cmarrin@apple.com





-----------------------------------------------------------
You are currently subscribed to public_webcl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webcl
-----------------------------------------------------------