[squeak-dev] Possible approaches for rendering in Morphic 3

Juan Vuletich juan at jvuletich.org
Sun Sep 7 03:04:39 UTC 2008


Hi Joshua,

Joshua Gargus wrote:
> ...
>> May be you're right, but as I'm only rendering 2d objects, the
>> computational cost should be much lower than for ray tracing. 
>>     
>
> It depends on what kind of non-affine transforms you want to render
> with, since this will determine the cost of each intersection-test.  For
> arbitrary transforms, these interesection-tests can become arbitrarily
> expensive.
>
>   
Not sure what you mean. In my implementation there are no intersection 
tests. At each pixel, every morph is asked for its value there 
(actually, the coordinates are transformed to the morph's space before 
asking). The morph might answer transparent, if the point falls outside 
it. The transformation of coordinates is done before asking the morph, 
so the only code that can get more expensive is the transformation 
itself. The code for the morph, something like #colorAt: is the same 
regardless of the transformations involved.

If this doesn't make sense to you, please elaborate, so I can follow you 
better.
>> Besides, if Morphic 3 turns to be usable only with help from OpenCL or
>> CUDA or some other special hardware, it is not too bad.
>>     
>
> My first thought when I read your original post was "how is he planning
> to take advantage of graphics hardware?".  In order to use OpenCL or
> CUDA effectively, you need to set up a parallelized workload for the GPU
> to munch through.  The implementation you describe ("for each pixel,
> iterate over the morphs, starting at the one at the top, and going
> through morphs behind it, etc...") requires a traversal of the Morphic
> scene-graph for each pixel.  A CUDA program running on the GPU can't ask
> Squeak for information about which morph is where... all of the GPU
> processors will pile up behind this sequential bottleneck.  Do you have
> some idea of how you would approach this?  It seems like you'd need to
> generate (and perhaps cache) a CUDA-friendly data structure.
>   

Hehehe. You're right! Today I'm experimenting with an idea. I'd like to 
traverse the morphs graph (actually a tree) and for each morph iterate 
over the pixels. This would require an enormous amount of memory, to 
compute all pixels in parallel. What I'm trying to do, is to iterate 
blocks of, let's say, 32x32 pixels. For each block, traverse the morph 
graph. At each morph (actually at each "shape"), compute the effect of 
it over each pixel in the 32x32 block. To do this, instead of building 
just one "color stack" I need to build 1024 of them (32x32). This is a 
reasonable amount of memory. The work inside each shape, with 1024 
pixels can be parallelized and be made CUDA friendly. The data 
structures involved at this step are some float arrays and float stacks.

Besides making it CUDA friendly, it will divide the cost of fetching the 
Smalltalk objects and traversing the tree by a factor of 1024. This 
should have a big effect on performance!
> Stepping back, one of the main difficulties I have when thinking about
> how rendering should work in Morphic 3 is that I don't really understand
> what the end-user APIs will look like.  For example, suppose that I
> program a graph that plots data against linear axes (each data point is
> rendered as a circle).  If I want to instead plot data against
> logarithmic axes, I can't simply render the whole graph with a different
> transform, because the circles will no longer look like circles.  How
> could this be avoided?  I can't see how.
>   

You're right again. This is one of the problems I had open without 
finding a solution for several years now. So far, circles won't look 
like circles anymore. I believe that should be the default behavior. If 
the graph is logarithmic, everything gets logarithmic!

However I understand that an application might want those circles to 
look like circles, or to add text labels that look like regular text, 
etc. I still haven't worked it out completely. But I envision some 
morphs (the circles and the labels), that live inside an owner with 
logarithmic coordinates, and they can say something like "instead of 
transforming pixel coordinates all the way down to my parent for me to 
render, stop at my grandparent, and translate my parameters (circle 
center and radius, etc) to its space, and render there". It can be done. 
I'm still not sure on how the programmer should specify this. I don't 
want to drive programmers crazy!
> I think that the idea of rendering entire scenes with arbitrary,
> non-linear transforms is very cool.  However, I don't see how it would
> be very useful in practice (for reasons like the example above). 
> Hopefully, I'm just missing something, and you'll be able to explain it
> to me.
>
> Cheers,
> Josh
>   

I hope what I said above makes sense to you. However, this is 
experimental stuff. I hope it will turn out to be very useful. Only time 
will tell.
Thanks for your interest!

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list