On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd <kevin.g...@gmail.com> wrote: > 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).
Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. > -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> >> 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. If the typed array views are specified to be little-endian, the latter is what would need to be done in order to allow existing content to run. I agree that this would make WebGL unusably slow on big-endian architectures. -Ken >> 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 > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
