[sldev] Running First Look in Debug

[Laurent Laborde]

On 3/19/07, Dave Parks <davep at lindenlab.com> wrote:
> It's high priority.  The fix is switching almost all of the updates to
> TCP instead of UDP.  I believe that work is in progress, as it helps
> scalability, too.

Wonderfull ! :)

> As for that idle loop, I'd like to take renderGeom and put it in its own
> thread, which would basically be the same thing as giving idle its own
> thread.

I noticed :)
and more than 50% of the gpu time is spent in GLDrawRangeElement.

> BTW, all these profiler values vary wildly from one scene to the next,
> so try to keep the "general case" in mind.  Particularly, 40 blingtards
> with flexi prim everything dancing to a 256k audio stream, watching a
> 512k video stream, and playing lots of sound gestures on a worm-infested
> computer that was bought on a budget 4 years ago.

100% agree.
I'm sure i'm not the 1st one trying to do some profiling :)

The fact are :
- MacOS X have incredible (and free) tools for profiling
- I love to do that (i was used to do that when i was Unix Sysadmin)
- I'm not a great code writer. The best way i can help  is to read,
track and hunt.
- i may eventually submit some patch on stuff not important enough to
get attention from great coders.

> No disrespect, but that's what we gotta make work.

No offense taken, thank you very much for the info.

on all the tests in differents situations i noticed :
- drawing the UI and 2D use  around 5 to 10% of cpu time.
- the idle loop use 30 to 50% of cpu time
- GLDrawRangeElement use 50-60% of GPU Time
- 5 to 10% of application time is spent in openGL operation (according
to the GL Profiler)
- From time to time the CPU is waiting for the GPU, but it's just some
tiny peak. (according to the GL profiler)
- Sometime (maybe because of packet loss), the viewer spend an
incredible amount of time in loop that normaly don't use more than 1%
of CPU time.
- A lot of tiny improvment could be done (but it's better to work on
the big one for now)
- Multithreading improved BY FAR the speed of the client. (mostly, of
course, the jpeg decoding stuff)
- The main bottleneck is the main secondlife thread. It use 100% of my
1st core while the other one is idling (unless there is a lot of jpeg
to decode, but even when there is a lot of jpeg to decode my 2nd core
have some idling time)
- i need an additional mac (mac Pro ?) to do remote profiling and
distribute compilation. ;)
- multi-multi-multi-threading is the only way to win ;)

---
kerunix Flan.

> Laurent Laborde wrote:
> > Couldn't be some kind of "SUPER HIGH CRITICAL PRIORITY" of viewer
> > improvment ?
> > Because, let me guess, packet loss may also lead to high image time on
> > the server and then : sim crash ? (i'm used to have that on my sims)
> >
> > Any way to have some stuff done in the idle() loop in another thread ?
> > (this "idle" thingy is 30-50% of the cpu load)