[Tig] St. Diig

[Bob Friesenhahn]

On Thu, 18 Oct 2007, Martin Tlaskal wrote:
>
> It'll be interesting to see how things pan out - there seems to be a major 
> misconception that writing a colour corrector / compositor is all about the 
> pixel bashing engine and everything else is just a thin veneer on top. There 
> is *far* more code in Baselight dealing with keyframing, plugin 
> ui/management, deck/Spirit control, AAF/MXF/CMX conform, A/C mode sorting, 
> control desk management, undo/redo, colour management, disk i/o performance, 
> etc etc than there is dealing with the rendering. I'm sure all our 
> competitors would say the same.. We're as excited about the growth of 
> massively-multicore CPUs/GPUs as everyone else is.. :-)

Sorry for blowing the announcement of the formerly secret unannounced 
product (oops!) but I just had to mention the Baselight 64 since the 
Baselight architecture is already obviously designed as a parallel 
application.  Some of the other vendors use special ASICs and FPGAs in 
order to obtain the performance.  The cost effectiveness of this 
approach tends to wane as general purpose processors gain in 
performance.  And of course most of the product development has 
nothing to do with the high speed rendering loops.

Regardless of rapidly-growing CPU performance, I/O is the true 
throughput bottleneck and the vendor who most effectively distributes 
and balances the I/O (while preserving convenience) is the one who 
will deliver the most performance per seat.

Bob
======================================
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/