[opensource-dev] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Hi,

I understand your leading question.

It leads me to the conclusion that we should allow public Second Life 
Groups to automatically allow or disallow features within the client 
viewer architecture.

That probably doesn't make sense unless you read the source, yet there 
are so many people that don't read the source.

I started to think about a "Doctor" group, as in Science-of-the-Arts 
Doctor. I think universities may need such funding^B^B^B^B, especially 
if they own the group as a piece of content they create. It's not 
obvious, yet between Second Life land and a Second Life group the 
features already exist to create a certain desired flow.

It's like... i have a set of minimal features needed...  here is a 
larger set that provides them. It doesn't make sense to you unless you 
understand the minimal features needed.

Chat in those groups are optional, yet I think SL may want to consider 
group-chat-rates for real institutions and commercial businesses that 
reach a certain threshold.

Note that the significant feature here is the group acts as "flags" 
internally and externally to the source code... if you strip out what 
you know about chat and some other features. Start with that idea and 
catch-up... because we didn't have to change it.


Nexii Malthus wrote:
> ..What?
>
> - Nexii
>
> On Tue, Aug 3, 2010 at 4:44 PM, Dzonatas Sol <dzonatas at gmail.com 
> <mailto:dzonatas at gmail.com>> wrote:
>
>     Was just thinking of a secondary proof to this. This should be helpful
>     to traditional physicist: Dark Liquid Crystal.
>
>     The significant thing to note is how light "slows" or "refracts" as
>     noted by dark matter... when taken to a substate.
>
>     On that note... it's not for me to "doctor" the Rx, and I know someone
>     that wants...
>
>
>
>     heh... "BURN"... �love it!
>
>     Oh let's "share" this one... LMAO!!!!
>
>
>
>     P.S. Working On It 2.0...
>
>
>
>     Dzonatas Sol wrote:
>     > Hi,
>     >
>     > I believe I found another solution.
>     >
>     > In my research as I optimized graphics routines in the viewer, I
>     > achieved between 100% to 150% increase in rendering performance.
>     To be
>     > fair, I reported as "up to 100%".
>     >
>     > There overall frame loop has many tasks, so keep that in mind that
>     > overall performance increase noted are of tasks that directly
>     related
>     > to rendering itself.
>     >
>     > I was blackboxed from the results when deployed. I admit, it
>     pissed me
>     > off how that was done, even if I had a right to be pissed, ... meh.
>     >
>     > However, I found out that "shown" results were actually not even my
>     > fault. I even realize they aren't of the of fault of those who
>     > immediately �worked around with me on it. Of what little I had
>     to work
>     > with, it didn't make sense, and the obvious thing was to "fix"
>     it as a
>     > bug.
>     >
>     > I think some of us realize it was no software bug. I can understand
>     > while the market plays to GPUs, that such any performance increase
>     > that would generally help everybody would be held back because
>     of....
>     > "overclockers".
>     >
>     > I don't think it matters anymore, and no need to keep something that
>     > isn't a secret as a secret anymore.
>     >
>     > Let's just say that I was visualizing how the "streaming media
>     > extensions" work through the hardware. Then I realized that the
>     > obvious answer was that "overclockers" were reporting problems yet
>     > they weren't telling they overclocked. The visualization I had
>     led me
>     > to decide that is the logical explanation.
>     >
>     > "Overclocking"... don't do that! �We have proven that the overall
>     > performance in rendering "sucks" for the larger general audience due
>     > to the "few" that report "knowledge" of their "crashes" from
>     > "overclocking" yet.... �those details aren't even being recorded
>     even
>     > when fully not blackboxed.
>     >
>     > Even where there is no crashes... �it is only a demostrations of
>     where
>     > the GPU actuall fails... and not the CPU... �of course there is no
>     > crash. The GPU is preventing itself... it only overheats... hides
>     > itself and "BURN".
>     >
>     > Enjoy!
>     >
>     >
>
>
>     --
>     --- https://twitter.com/Dzonatas_Sol ---
>     Web Development, Software Engineering, Virtual Reality, Consultant
>
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/OpenSource-Dev
>     Please read the policies before posting to keep unmoderated
>     posting privileges
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant