[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Public WebCL] WebCL syntax style?
For web application developers, it might not be so intuitive to select a
correct object for a particular API without OpenCL UML diagram. With
enqueueMapImage() example, the JavaScript code would look like:
var ctx = WebCL.createContext(...);
var queue = ctx.createCommandQueue(devices[0], 0);
var image = ctx.createImage2D(...);
var w = image.width;
var h = image.height;
var event_wait_list = [];
var pitchSliceInfo = WebCL.createDataObject();
queue.enqueueMapImage(image, true, CL_MAP_READ, [0, 0, 0], [w, h, 0],
event_wait_list, pitchSliceInfo);
var image_row_pitch = pitchSliceInfo.get(...);
var image_row_slice = pitchSlinceInfo.get(...);
Then, the question would be, Why createImage2D() is defined as a member
function of ctx? Why enqueueMapImage() is defined as a member function of
queue? ...
On the other hand, if we have a near 1:1 mapping between WebCL and OpenCL
APIs, then the JS snippet for the example would look like:
var ctx = cl.createContext(...);
var queue = cl.createCommandQueue(ctx, ...);
var image = cl.createImage2D(...);
var event_wait_list = [];
var w = image.width;
var h = image.height;
var pitchSliceInfo = new Object();
var anEvent = cl.enqueueMapImage(queue, image, true, cl.MAP_READ,
[0, 0, 0], [w, h, 0], pitchSliceInfo, event_wait_list);
var image_row_pitch = pitchSliceInfo.image_row_pitch;
var image_row_slice = pitchSliceInfo.image_row_slice;
As a result, it would be simpler and easier for WebCL to stay in sync with
the progress made by OpenCL, which would ensure easier adaption by the
community at large.
Regards,
Won
-----Original Message-----
From: owner-public_webcl@khronos.org [mailto:owner-public_webcl@khronos.org]
On Behalf Of tomi.aarnio@nokia.com
Sent: Thursday, May 26, 2011 7:41 AM
To: cmarrin@apple.com; public_webcl@khronos.org
Subject: RE: [Public WebCL] WebCL syntax style?
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/interfaceIWebCLCommandQu
eue.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
-----------------------------------------------------------
-----------------------------------------------------------
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
-----------------------------------------------------------