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

Re: [Public WebGL] A different approach to interleaved typed arrays



I was thinking an alternative approach to the array of structures approach (which looks to be extraordinarily complicated if it's at all achievable) would be a structure of arrays, eg. you define your type as in the last structure concept, but instead of 

array[i].x

you would do

array.x[i]

etc

This would have the benefit of being achievable now, having all the perf benefits of typed arrays, and would solve the issues of byte endianess, etc.

Additionally in the current ES proposal for an array of structures it looks like (effectively) implementations would have to do a significant amount of optimisation to prevent reification of GC objects whenever you do myArrayOfStructures[i].

--Oliver

On Jun 11, 2010, at 10:38 AM, Chris Marrin wrote:

> 
> On Jun 4, 2010, at 12:47 PM, Vladimir Vukicevic wrote:
> 
>> 
>> ...
>> I'm in general agreement with Ken here -- I just don't see the aliasing/endianness issues as a significant showstopper problem.  I'm interested in the TC-39 struct proposal purely from a developer convenience point of view, because being able to access interleaved array data in a more natural form (like foo[i].vertex.x, foo[i].normal.y, foo[i].color.r, etc.) would be nice, though only if the implementations can get that indexing to be close to typed array speed.  Having it fix the endianness exposure issues is, to me, only a nice side benefit.
>> 
>> Current typed array indexing is:
>> 
>> base_ptr + index<<elemsize_shift
>> 
>> The struct proposal could be, with enough parser work:
>> 
>> (base_ptr + structsize*index) + member_offset
>> 
>> (Though base_ptr+offset will be constant for each element, so maybe there's something useful that can be done there.)
>> 
>> The interleaved proposal above would be, I believe:
>> 
>> stride = elementsPerGroup*elemsize + bytesToNextGroup
>> (ptr + stride*(index/elementsPerGroup)) + (index % elementsPerGroup)
> 
> Your indexing scheme does look better, but think about where that 'index' value is coming from. In the current scheme filling an interleaved array requires index arithmetic in JavaScript. You essentially have to do this:
> 
> 	var index = 0;
> 	for (var i = 0; i < values.length; i += 3) {	
> 		floats.set(index++, values[i]);
> 		floats.set(index++, values[i+1]);
> 		floats.set(index++, values[i+2]);
> 		index++;
> 	}
> 
> In my scheme, all that is done in native code. From a standpoint of optimizing JavaScript to more efficiently access the structure of the views I don't think the difference is significant. The more extensive math you show for accessing my structure can be optimized out because elementsPerGroup, elemsize and bytesToNextGroup are all constant for a given view.
> 
> So I don't think the "less efficient" argument holds. 
> 
> The reason I get concerned about the endianness issue is because I think we've done a great job of hiding all the gritty, crash-prone issues of OpenGL ES. And while it wouldn't cause browser crashes, the ease with which an author can expose the endianness of the machine is troubling. If we can button that up (and I think we can) then we will have a better API
> 
> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
> 
> 
> -----------------------------------------------------------
> 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:
> 


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