One could also argue that people using typed arrays to alias and munge individual values should be using DataView instead. If it performs poorly, that can hopefully be addressed in the JS runtimes (the way it's specified doesn't seem to prevent it from being efficient).
-kg On Sun, Mar 31, 2013 at 1:37 PM, Vladimir Vukicevic <vladi...@mozilla.com>wrote: > (Apologies for breaking threading -- subscribed too late to have original > message to reply to.) > > David Herman wrote: > > On Mar 27, 2013, at 6:51 AM, Andreas Rossberg <rossberg at google.com > <https://mail.mozilla.org/listinfo/es-discuss>> wrote: > > >* There actually are (third-party) projects*>* with ports of V8 and/or > >Chromium to big endian architectures.* > It would be helpful to have more information about what these platforms and > projects are. > > > The Wii-U is probably the highest profile example of this; PowerPC base, > and they're doing a bunch of HTML5 apps stuff like what they announced at > GDC. > > > >* WebGL*>* code should not break or become prohibitively expensive on them > all of*>* a sudden.* > But WebGL code doesn't break either way. It's if we *don't* mandate > little-endian that > code breaks. As for the expense, it has to be weighed against content > breaking. Not to > mention the burden it places on developers to write portable code without > even having > big-endian user agents to test on. (I suppose they could use DI and shim the > typed array > constructors with simulated big-endian versions. Ugh...) > > > The problem, as I see it at least, is that if little-endian is mandated, > then effectively we *have* broken WebGL, or the possibility o ever having > performant WebGL on those platforms. The underlying OpenGL API will always > be native-endian. While big-endian processors often do have ways of > efficiently doing byte-swapped loads and stores, that doesn't apply to > passing bulk data down. For example, vertex skinning is the base method of > doing skeletal animation. It's often done on the CPU, and it involves > transforming a bunch of floating point data. The result is then uploaded > to the GPU for rendering. > > If typed arrays are fixed to be little endian, that means that on big > endian platforms one of two things will need to happen: > > - the application will need to manually byte swap (in JS) by aliasing the > Float32Array as a UInt8Array and twiddling bytes. > - the WebGL implementation will need to make a copy of every incoming > 1 > byte element size buffer and do the byte swapping before passing it down to > GL -- it can either allocate a second buffer, swap into it, and then throw > it away, or it can swap before the GL call and unswap after the GL call > in-place. > > Both of these are essentially murder for performance; so by attempting to > prevent code from breaking you're basically guaranteeing that all code will > effectively break due to performance -- except that developers have no > option to write portable and performant code. > > The other thing is, I suspect that a large chunk of code using typed > arrays today will work just fine on big endian platforms, provided that the > arrays are defined to be native-endian. Very few code actually aliases and > does munging; the only issues might come up with are loading data from the > network, but those are present regardless. > > - Vlad > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- -kg
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
