Optimizations & contributions

22 views
Skip to first unread message

Kevin Schmidt

unread,
Apr 12, 2013, 10:28:56 AM4/12/13
to webgl-load...@googlegroups.com
Hi there,
  I'm working on some optimizations for the web-gl loader code, and I was wondering the best process to contribute?  I've come up with one speed optimization that seems to help the happy buddha example (~8.5s > ~6.7s on my laptop) from the trunk.  Any way I can help?  

Kevin

Won

unread,
Apr 12, 2013, 10:57:31 AM4/12/13
to webgl-load...@googlegroups.com
Awesome! Could you post the diff with a quick description of what it's doing and I'll merge it myself.

Obviously, this is a pretty bad strategy moving forward. I will be moving the code to GitHub so that it can be included as a submodule to the glTF project, which will likely use some variant of this compression code as an encoding format.


My current timeline for this is a bit murky, but the transition will likely happen in the next month or so. Unfortunately, I have some work deadlines that I'm already late on, so I need to take care of all that, first. But it will happen.

-Won



Kevin

--
You received this message because you are subscribed to the Google Groups "webgl-loader-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-loader-dis...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Kevin Schmidt

unread,
Apr 12, 2013, 11:15:52 AM4/12/13
to webgl-load...@googlegroups.com
Hi Won,
   Here's the diff.  I saw from your comments you were thinking of this anyway :) 

A couple of other (untested) ideas I had that *might* really help this.
1.  I think if the active flag for triangles is moved into a large bitset, it will make scanning for true bits much faster as you can check 32 at a time.  Though it will add verbosity.  Trying to figure a way to encapsulate something like this (not tested, bugs ahead..):

std::vector<int> activeBits;  // numtris/32
...

for (int i = 0 ; i < activeBits.size() ; ++i)
{
  const int theseBits = activeBits[i];
  if (theseBits)
  {
     unsigned int bit=0x1;
     unsigned int base = i*sizeof(int);
     for (int j = 0; i < sizeof(int) ; ++j)
     {
        if (bit & theseBits)
        {
           unsigned int tri = base + j;
           // active.
        }
        bit = bit << 1;
     }
  }

}

2.  A smaller help might be to cache the values of powf.  At least for the cache contribution, the possible # values are very limited (to the size of the cache).  Not sure if there is a space efficient way to store the valence contribution.  


Kevin


optimize.h.diff

Kevin Schmidt

unread,
Apr 12, 2013, 2:08:54 PM4/12/13
to webgl-load...@googlegroups.com
Here's yet another (more significant) diff.  Most of my efforts are on the optimizer.  On my machine, the total time for buddha was 8.5 originally, with about 2.5 from the wavefrontobj loader. 

This diff took me from 8.5s down to under 6s (5.8 or 5.9) by implementing the bit-vector for marking active and caching powf.  Given the fixed (as far as I'm concerned) cost of the loader @ 2.5s, this is taking the timings for the rest of the program from 6s down to about 3.5s.

I realize I'm only optimizing the implementation rather than the algorithm, and certainly hurting readability, so I know this is of debatable use.  I'm mostly doing it to see if this strategy would be useful for some of my own code.  Testing the limits, if you will.

Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-loader-discuss+unsub...@googlegroups.com.
optimizer_speedup.diff

Won

unread,
Apr 12, 2013, 3:22:18 PM4/12/13
to webgl-load...@googlegroups.com
Kevin,

That's great!

Yeah, the vertex cache optimizer is itself generally useful, so optimizations there are certainly welcome. Do you know which made more difference? Pow-caching or the bit-vector?

-Won


To unsubscribe from this group and stop receiving emails from it, send an email to webgl-loader-dis...@googlegroups.com.

Kevin Schmidt

unread,
Apr 12, 2013, 3:36:42 PM4/12/13
to webgl-load...@googlegroups.com
Unfortunately I don't recall off hand.  I think the bit-vector.  




You received this message because you are subscribed to a topic in the Google Groups "webgl-loader-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/webgl-loader-discuss/8mYhfY4xZeE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to webgl-loader-dis...@googlegroups.com.

Kevin Schmidt

unread,
Apr 12, 2013, 4:00:36 PM4/12/13
to webgl-load...@googlegroups.com
Hi Won,
   So I have to laugh.  I just tried actually loading the model in the viewer and it didn't work.  Of course I didn't check before either, so I'm not sure that it is all correct!  

I'll keep digging.

Kevin

Kevin Schmidt

unread,
Apr 15, 2013, 8:02:01 AM4/15/13
to webgl-load...@googlegroups.com
Hi Won,
    So I ran the code w/o any modifications & got the same result, so either I'm I'd doing something wrong, or using something incorrectly.  I run objcompress, which generates a utf8 file prefixed w/ a hash (?) and outputs json.  I ran this against the happy.obj, and get nothing in the web page.  Not sure what the issue is.



Won

unread,
Apr 15, 2013, 2:34:05 PM4/15/13
to webgl-load...@googlegroups.com
What happens if you try obj2utf8 or obj2utf8x?


On Mon, Apr 15, 2013 at 8:02 AM, Kevin Schmidt <kevine...@gmail.com> wrote:
Hi Won,
    So I ran the code w/o any modifications & got the same result, so either I'm I'd doing something wrong, or using something incorrectly.  I run objcompress, which generates a utf8 file prefixed w/ a hash (?) and outputs json.  I ran this against the happy.obj, and get nothing in the web page.  Not sure what the issue is.
Reply all
Reply to author
Forward
0 new messages