filter compiler instead of filter interpreter

Hi all,

not sure if it wasnt posted here already but I had the idea of creating a filter compiler instead of an interpreter (which i guess is used today for rendering) to speed up the render process up to 100 or 1000 times!

Am I right with my assumption, that during processing time the filter is interpreted instead of beeing compiled to fast machine code first?

This could be a revolution in speed!

cheers,
rilos

Quote
rilos Am I right with my assumption, that during processing time the filter is interpreted instead of beeing compiled to fast machine code first? This could be a revolution in speed!

As far as I know the filter forge render engine works only interpreting the filter and does not make any kind of conversion, just only follow the instructions given by the filter.

I do not know how is programmed filter forge and how it is done, and what language is using, but I think that this idea of converting the filter to machine code first could probably work and would be true maybe that would be much faster, but I do not that this is the only thing and would be just this, and to be done, (although I do not know) it would probably need to change also more things in the FF render engine to be able to do it.

Quote
Betis Could be a large change in architecture, probably not as bad as GPU rendering, but I think it's worth looking into!

YES! if this really could be possible and doable in some possible way, would be a good alternative to GPU if it works and the results would be faster, and also think that would be worth looking into and see if with FF could be faster, as it would really be a very good thing and something really great and would rise much the usability of FF.

We already know that the FF team is not going to make a GPU based FF, so perhaps this alternative could be a good idea if possible, although this must be confirmed by Vladimir or someone from the FF team.

Quote
rilos Would be interesting to hear what the officials say to that suggestion...?

Yes, I think it would be good if anyone from the filter forge team could say if this is a crazy or not possible idea, or could be something worth to look into and possible in some way and would help to make FF faster and better.

Quote
rilos it would be a very nice option for professional production on huge photos and textures - as it can take half and hour and much more to render.

YES! It would be very good for higher resolutions, as I have made some 5000 x 5000 images and have taken between 45 to 60 minutes to render and was nearly the same with 6 different filters.

Thanks for making that clear Vlad!

C++ can be compiled to very good and fast assembler code - so theres probably not much to optimize. It was just a guess - as I dont see any compilation time when editing a filter to render process. I recognized FF pauses a little before real rendering starts, so that could be the time the actual filter settings are compiled.

Maybe I am still wrong here and just the component-parts are precompiled but the actual node-construction is still interpreted at runtime - so that might be what you describe above when one component calls another it relies on...

I agree this cannot take too much time, but when it does this on each and every pixel this could sum up so some million procedure calls...
But probably there is no easy way to further optimize this...

Anyway FF got much faster now compared to version 1...