[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
|