[Bf-committers] How about adding boost uBLAS library toblender/extern?

[joe]

On Mon, Jan 26, 2009 at 6:15 AM, Yves Poissant <ypoissant2 at videotron.ca> wrote:
> From: "joe" <joeedh at gmail.com>
> Sent: Monday, January 26, 2009 5:18 AM
>
>
>> Ugh, porting the render code to c++ would be a really bad idea.  It's
>> highly optimized for C.
>
> I wonder what this "optimizition for C" really means. The renderer is very
> far from fast and thus certainly far from optimized in one way or another.
> It might be optimized for C but I think the rendering pipeline itself needs
> some fundamental conceptual revision. Just optimizing C statements does not
> cut it and some old C optimization tricks are actually detrimental to modern
> CPU architectures. And given that C++ is a superset of C, any C optimization
> trick that are actually efficient could be ported to C++ as well.

The renderer is an optimized scanline renderer.  It's not optimized
for raytracing, no, which was essentially tacked on.  The slowest part
is actually the shading pipeline, not the rasterization.  There are
some effective scanline optimizations.  For example, multiple
oversamples with the same object and face index share shading; while
this isn't completely correct, it does look fine in many situations
and gives a fairly large speedup (and if it looks too bad, the user
can disable it with the "full osa" option, or turn on ray tracing).
The strand renderer is also fairly fast, and caches shading
information at strand verts.

These don't really work in the context of the ray tracer, though,
which is the problem.

>
> I suggest that porting the renderer to C++ might be beneficial even if not
> totally "optimized for C" if some other aspects can be optimized such as the
> vector/matrix and color calculations. At least, that might be the first step
> to a gradual refactoring of the renderer. That just said, I believe that a
> more profound refactoring than simply porting or improving is needed.
>
Blender's core math stuff basically stores vectors and matrices as
float arrays.  Converting the renderer to use specific datatypes would
likely be a huge pain, and would need a lot of forethought.

What sort of profound refactoring are you talking about, btw?  It's
obvious that the shading system needs a fairly complete overhaul;
ton's been fishing for proposals for this for years.  The code could
probably be more cache-friendly too, and structured in a way to play
nice with ray tracing.  Though I'm not sure how a cache-friendly
shader/ray tracing pipeline would work (are there any papers  that
address a cache friendly shader and ray tracing pipeline, as opposed
to just a ray tracing pipeline?).

> Just for my own education, I would like to be pointed to some of those C
> optimization tricks in Blender renderer that could not be ported to C++.

The math stuff all assumes float arrays.  That's what I meant, I
guess, is all the stuff that goes on there.  I admit the render code's
optimization scares me, I keep fearing there's more nasty, subtle ones
I've missed there.  I suspect there would be optimizations that
wouldn't port easily to a c++ math library, just because of how much
like an interlocking puzzle the render code's optmizations can be.  It
probably wouldn't matter though, now I think about it, since it'd
probably be a fairly low-level and likely useless thing.

Anyway, if someone wrote a nice proposal outlining ideas for a new
pipeline design (rasterization, ray tracing and shading), which math
library to use, etc that'd really help.

Joe