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

Re: [Public WebGL] Matrix objects in JavaScript



Some operations proposed in this API are much cheaper than 4x4 inversion. For example translate() is just a few cycles.

Even 4x4 matrix inversion is just 200 cycles with SSE1 on a Pentium III, certainly less on a modern CPU:
http://download.intel.com/design/PentiumIII/sml/24504301.pdf

So the overhead of DOM API calls will be at least significant for matrix inversion and definitely dominant for the cheaper operations.

Benoit

On 13-03-21 12:35 PM, Florian Bösch wrote:
I think there might be an underestimation of how expensive matrix operations like inverse and multiply are.

A 4x4 matrix multiplication involves:

32x fetching of the value from a buffer (likely float32) and converting to native JS doubles.
64x double multiplications
60x double additions
16x converting a double to the target buffer (likely float32)

So 48x double conversions and 124 double mathops.

A 4x4 inversion by gaussian elimination involves:

16x fetching of the value from a buffer, converting to native JS doubles
32x double multiplication, 14x double subtraction and 2x double addition to compute the determinant
64x double multiplication, 32x double addition and 32x double subtraction
16x store to buffer conversion

So 32x double conversion and 176 double mathops.

Those are not insignificant amounts of math in JS, it's not even insiginificant if somehow magically the compiler would convert it all to straightforward native code.


On Thu, Mar 21, 2013 at 5:12 PM, Benoit Jacob <bjacob@mozilla.com> wrote:

There are two competing technologies in development to do this sort of
thing: WebCL and RiverTrail. We'll see how it shakes out. That's not a
use case that the proposal on public-fx is concerned with.

Benoit

On 13-03-21 12:10 PM, Steve Baker wrote:
> I agree that for all of the specialist math functions (inverse and such),
> we're better off letting _javascript_ handle it.  There are plenty of good
> libraries out there - and if there is browser-engineer time available, I'd
> rather it was spent on making JS faster than on writing and maintaining a
> library like this.
>
> HOWEVER:
>
> The place where having some API support would be useful is in bulk
> operations.
>
> If I have 1,000 matrices that all need to be transformed in some way - or
> if I have a bunch of vertices that need to be multiplied by matrices -
> then there are massive gains to be had with machine-code that uses
> specialised CPU instruction sets and GPU OpenCL stuff that the JS
> optimizer is unlikely to be able to spot and take advantage of.  WebCL may
> be able to handle that - but I doubt we'll get comprehensive support for
> it on every platform as soon as we could get a set of simple operations
> for bulk matrix/vector work.
>
> So I think there would be value in defining a very minimal matrix library
> to handle a minimal set of operations (multiply, translate, rotate maybe)
> on large arrays of vertices and matrices.
>
>   -- Steve
>
>
> Benoit Jacob wrote:
>> I have been arguing on public-fx that we are better off without a
>> browser-supported matrix library because this is best done in JS both
>> from the perspective of performance (giving it a bit of time for JS
>> toolchains to solve roadblocks) and from the perspective of flexibility
>> and not blessing an arbitrary choice of matrix library over other ones
>> (and a poor one at that).
>>
>> Benoit
>>
>> On 13-03-21 07:04 AM, Si Robertson wrote:
>>> I have to say I can not think of any reason for native matrix objects
>>> to be implemented by browser vendors unless those objects (a) provide
>>> a significant performance gain over custom code, and (b) are
>>> compatible with WebGL.
>>>
>>> Matrix operations that work on typed arrays are very fast already if
>>> the code is optimised, and it is relatively easily to avoid creating
>>> new type arrays when needed.
>>>
>>>
>>>
>>> On 21 March 2013 10:24, Florian Bösch <pyalot@gmail.com
>>> <mailto:pyalot@gmail.com>> wrote:
>>>
>>>     On Thu, Mar 21, 2013 at 11:19 AM, Kirill Prazdnikov
>>>     <kirill.prazdnikov@jetbrains.com
>>>     <mailto:kirill.prazdnikov@jetbrains.com>> wrote:
>>>
>>>         Will it be a helper library or part of WebGL API ?
>>>
>>>     Neither. It would be implemented in the browser, not related to
>>>     WebGL, and in  my opinion, unusable for it.
>>>
>>>
>>>
>>
>
>  -- Steve
>


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