[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] TypedArrays and mapped memory regions

On Wed, Aug 4, 2010 at 8:46 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> Hi,
> TypedArrays and their underlying ArrayBuffer gives efficient native/direct
> access and interoperability with low-level languages to memory regions.
> Native memory regions do not always have read/write access like assumed
> right now by the spec though, some native APIs give back read-only or
> write-only memory regions.
> Currently these APIs (eg. such as mmap but also closer to WebGL glMapBuffer,
> or buffer locking APIs) are not usable from Javascript without defining
> custom 'illegal access' behavior to TypedArrays and/or, worse, writing new
> custom buffer types altogether to be able to safeguard such invalid access
> attempts.
> IMO being able to write Javascript wrappers for such native functions with a
> common, consistent, well-specified interface such as TypedArrays would be
> beneficial.
> Potential users for this are WebGL extensions, File API, Node.JS(?), etc...
> I propose a minimally intrusive addition to the spec to define behavior that
> makes TypedArrays usage compatible with any mapped memory region :
> [addition to ArrayBuffer type spec]
> readonly attribute boolean readable;
> Read-only property.
> True if the the ArrayBuffer contents can be read from, false otherwise.
> readonly attribute boolean writable;
> Read-only property.
> True if the the ArrayBuffer contents can be written to, false otherwise.
> [addition to ArrayBuffer constructor spec]
> The contents of the ArrayBuffer are initialized to 0 and both readable and
> writable attributes are true.
> [addition to TypedArray getter spec]
> If the underlying ArrayBuffer is not readable (readable attribute set to
> false) an INVALID_ACCESS_ERR is raised.
> [addition to TypedArray setter spec]
> If the underlying ArrayBuffer is not writable (writable attribute set to
> false) an INVALID_ACCESS_ERR is raised.
> It's the responsibility of Javascript native implementors to manage these
> attributes appropriately with the wrapped API and the Javascript engine
> internally (the access attributes being read-only from Javascript's user
> perspective).
> Benefits :
> - frontend APIs have consistent illegal access behavior and aren't required
> to implement/document custom types and behavior over existing TypedArray
> implementations.
> - for some APIs memory usage and GC churning can be greatly reduced as this
> allows zero-copy mechanisms.
> Prospective example with glMapBuffer : (NB: not the only potential user and
> I do not support its inclusion in WebGL 1.0 of course ;)
> array = gl.mapBuffer(GL_ARRAY_BUFFER, GL_WRITEONLY);
> //array is writable only
> //fill the array with, say, procedurally generated data from an audio
> waveform
> gl.unmapBuffer();
> //array is now neither readable or writable as backend storage is unmapped
> //any attempt to access its contents will raise an INVALID_ACCESS_ERR
> Proposed patch to support this spec addition in Mozilla :
> http://neonux.com/webgl/js_readable_writable.patch
> Proposed patch to add a helper for native JS code to create an ArrayBuffer
> from a mapped region :
> http://neonux.com/webgl/js_createarraybuffermapped.patch
> (patch not required to support the spec addition of course)
> Thoughts ?

I've had some experience with support for read-only buffers and
dynamically unmapping buffers in Java's New I/O API and
implementation. In that API, the read-only attribute was only one of a
few that could be toggled per buffer. Others were whether or not the
buffer was in big-endian mode, and whether the buffer was properly
aligned to support fast stores on CPU architectures that didn't
support unaligned stores.

In order to maintain high performance, it is essential to avoid
run-time checks for these attributes on each read and write. For this
reason, in the Java implementation of these concepts, many subclasses
of abstract base classes like FloatBuffer and IntBuffer were generated
behind the scenes. There were something like eight subclasses
generated per type. Unfortunately, the proliferation of these
subclasses was also a performance disaster; they defeated the
devirtualization techniques used at the time, so in many cases, every
read and write turned into a virtual call. This led to a factor of ten
performance hit in some common use cases.

I think we need to be very, very careful about adding functionality
like this to the TypedArray specification to avoid similar performance
disasters. Even though some good optimization work has already been
done for TypedArrays, the performance of the current spec in current
ECMAScript virtual machines is not near what is desired.

Until we have achieved acceptable baseline performance of the current
TypedArrays, and then can do good before-and-after performance
comparisons of feature additions such as this one, I am not in favor
of adding this functionality. APIs like this one can still be bound to
ECMAScript, just with an additional memory copy upon map / unmap.

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