Re: [Public WebCL] WebCL syntax style?

[Chris Marrin <cmarrin@apple.com>]

On May 24, 2011, at 1:46 PM, Ian Johnson wrote:

> While in principal it is nice to have similar APIs, OpenGL and OpenCL are fundamentally different. The OpenCL runtime API lends itself very well to an object-oriented approach, it is nice to have context and queue objects to interact with and share among routines. Furthermore you can have multiple platforms, contexts and queues which can process different things and send results to different targets, whereas in OpenGL each GPU handles its own display or framebuffers.
> 
> While people have been using OpenGL to do computing (with shaders) I think its fair to encourage using OpenCL for compute and not promote the abuse of a rendering API for general purpose computing.

I don't think that's what we're talking about. If OpenCL is generating data to be used as input for WebGL, then that data is passed through a WebGLBuffer. The creation of that buffer and its lifetime management should be the same as WebGL. Therefore all buffer management should follow the same conceptual model. 

I also don't agree that the API's are fundamentally different. WebGL takes input data and uses programs (shaders) to produce output from that data (a framebuffer). The only real difference is that the intent of WebCL output is to be used as input (e.g., WebGL vertex data) or used in some other way (e.g, a filtered image). 

When we began WebGL we discussed how close to the OpenGL API we wanted to stay. We could have gone nuts with putting state functions on the Framebuffer object or texture manipulation and parameterization on the Texture object. We could even have made meta-objects which encapsulated all the uniforms, vertex data and shaders needed for a given rendering function. We didn't do any of that for a few reasons:

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.

-----
~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
-----------------------------------------------------------