[sldev] Rendering engine bottlenecks, and future rendering directions

[Douglas Soo]

I'm not going to address specifics of the current and future direction of 
the rendering engine, because I frankly haven't been directly involved in 
the direction of our rendering engine or touched its code since around 2004 
or so.  That being said, I think there are some things to keep in mind when 
talking about rendering engine performance and future directions - and I'm 
sure Dave will correct me if I'm wrong on any of this. :)

There are at least 4 major bottlenecks that every rendering engine will 
bump into, which are vastly different depending on the particular 
hardware/os/driver configuration that you're using:
- GPU fill rate and shader execution speed (if there ARE shaders).
- CPU performance.
- Memory bandwidth from system memory to the video card.
- Memory bandwidth and cache miss latency from system memory to the CPU.

Depending on the particular hardware configuration that you're running, 
which one of these bottlenecks that you hit first will limit your 
performance.  And unfortunately, even on hardware from different eras, 
there will be vastly different bottlenecks.  A great example of this was 
when nVidia released their 5200 cards a few years ago - these cards had 
substantially LOWER fill rate than most cards from the previous generation 
- which caused no end of grief at the time.

When reworking a rendering engine, invariably we will make tradeoffs 
between these bottlenecks - especially when you are adding new 
functionality.  If we had infinite resources, it would make sense to create 
different renderers that target different bottlenecks and hardware 
configurations, but, alas, we don't.  I do think, however, that we are 
moving towards an architecture that will at least make it possible.


Second, another thing that's important to remember is that it's not just 
average frame rate that's important, but minimum frame rates that are 
important as well.  We would much rather have a solid frame rate of 30fps 
than a frame rate of 60 fps, with occasional stalls down to 10 fps.  So a 
lot of work is done to improve performance in worse-case scenarios, 
possibly at the expense of best-case scenarios.


Third, there's not nearly as much benefit from improving someone's frame 
rate from 30 to 60 fps as there is in improving someone's frame rate from 8 
to 16 fps - the improvement in experience for the first is nice, but not 
big - but for the second person, it can make the difference between an 
unusable and usable experience.  So, in many cases, there may be choices 
made to


Essentially, the point I'm trying to get at here is that absolute numbers 
shouldn't be the only way to evaluate performance of a rendering engine - 
and yes, there ARE cases where we will consciously choose to reduce the 
performance in a particular hardware configuration or situation - in order 
to hopefully improve the overall experience.  I do happen to know that for 
Windlight, we spent a lot of time poring over performance statistics 
reported to us based on hardware configurations - but there are literally 
tens (or hundreds) of thousands of different permutations of OS, driver, 
CPU, GPU, AGP/PCIe bus type/speed, display resolution out there.  Some of 
them (and a fair number, even) will almost definitely perform more poorly, 
and it may have been a deliberate tradeoff that we made.


The thing that I'm more interested in is not necessarily the specifics of 
where we're going with a particular rendering engine from a feature 
perspective, but the refactoring and rearchitecture that will eventually 
allow the viewer to "easily" support multiple different rendering 
architectures - so that it is easy to write plug-in renderers that target 
specialized OS/hardware combinations.  That way, this debate hopefully 
becomes moot.  I'm also waiting for someone to plug in support for some of 
the hardware ray-tracing stuff that's just now starting to become viable - 
or to hook SL up to a vector display - like maybe a laser show laser. :)

- Doug

--
Douglas Soo
Engineering Director
Linden Lab