On Fri, 14 Jun 2002, Daniel Heckenberg wrote:
That's good news: those pix_es could definitely be optimized and MMX and Altivec are great for image processing. How far are you through this process?
Thats a good questions, I have only started. So far I have done the simple things like pix_add, pix_sub which got a tremendous speedup.
I have been working with pix_convolve a bit, no asm yet, but by specializing to fixed convolution kernels and avoiding allocation/deallocation of memory as well as floating point calculations I got a 2-3 fold improvement in speed. The asm code is a bit more complex there and I am not a specialist in doing this.
Finally we have to check the pix_ objects step by step,and of course non asm version have to be supplied to .... maybe investigate on libraries for doing that.
There are problems in the release code when an dualpix object is deleted or its stoprender method is called.
.. ok, now I got it. I think that if you create the left render chain first it may work out, thats why the problem only showed up sometimes, really great that you were able to figure this out !
I am just looking at the chaining setup (I did this the last time some years ago, forgot completely how it worked).
Doing that I am trying to figure out how to reconstruct render chains every time the patch is changed, ... would be great if there was immediate feedback if the patch is edited.
Looking through the per-input code above, the obvious question is "how to make this easily extend to n-input objects?". The motivation for n-input objects seems pretty clear: e.g doing n layer compositing would be much neater and faster that way.
wait, ... I think that the fastest way of doing layers in Gem is still with alpha blending on several objects. Well, I see the usefulness of providing both possiblities though, and I think that in several situations the OpenGL way is not possible.
Another topic with pixes it feedback loops. I experimented with that some time ago, and it is possible with pix_buf, but this concept isn't really thought out yet.
I have already asked Johannes about setting up a CVS for GEM, this would make shared development a lot easier.
Yes, that would be good. I note that there's already a CVS archive for the GEM OSX project so it would be good to get a central repository up to keep things consistent and organised.
yep .. I am localy working with CVS too ...
Can you send a diff against gem-0.87 of the changes you did ?
thanks a lot .. just about to try it out ...
Guenter