I thought I'd try to get a Lisp-specific answer to this question.
This is an excellent opportunity for people to demonstrate my lack of
understanding of Functional Programming.
I need to shove a "scene graph" of 3D data, essentially a big recursive
tree of arbitrary stuff, into hardware buffers. As the scene graph is
traversed, some parts of the scene are culled and never sent to the HW.
Other parts of the scene are reduced to 3D vertices and indices.
Vertices are shoved into a hardware VertexBuffer, and vertices are
always the same size. Indices are shoved into a hardware IndexBuffer,
and indices are always the same size. The VertexBuffer and IndexBuffer
are write-only, and elements must be written to them in strictly
sequential fashion. When the buffers runs out, they must be flushed and
new buffers rotated in for the write-only output to continue.
Additionally, the "scene graph" is not composed of homogenous
geometrical types. Many vertex formats will be utilized. Multiple HW
buffers will exist, each buffer handling only 1 type. So there's a
bunch of context switching going on. This shouldn't complicate the
buffer writing part of the problem, but it may complicate the scene
graph traversal, as far as breaking up the problem into distinct chunks
in advance. You'll probably have to recurse to some depth before you
know what you're dealing with. You'll have to recurse to some depth
anyways to do the culling, it's just not possible to break up these
problems in advance. Also the buffers may need to be ordered as context
is switched, or it may be acceptable to flush them in any old order.
The 3D scene likely has a partial ordering, such as for transparency
effects that must be rendered in-order.
Imperative programming is the straightforward way to approach this class
of problem.
My question is, Functional Programming purports many
benefits, such as potential parallelism for sticking with the pure FP
paradigm. What are reasonable FP approaches to the problem I pose
above? Bear in mind that we are talking tens of millions of vertices
per second. Excessive overheads in the absence of demonstrable
performance benefit, merely to preserve the FP paradigm for its own
sake, are not acceptable.
For instance, it is not desireable to simply create some great big list,
copy that into a software buffer, then copy that into a hardware buffer.
I'd like to get the results into the HW buffers "in the 1st shot." In
part I'm asking what FP can characterize. Can FP offer all the
purported parallelism benefits and yet write to HW buffers sequentially?
Can it do so elegantly, or are the results going to be bloated and
crazy?
Real parallelism can take many forms. One architectural target might be
the IBM Cell architecture, the upcoming core of the Sony Playstation 3.
http://arstechnica.com/articles/paedia/cpu/cell-1.ars
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
"Brandon J. Van Every" <·····················@mycompanyname.com> schrieb im
Newsbeitrag ·········································@207.69.189.191...
>
> I thought I'd try to get a Lisp-specific answer to this question.
> This is an excellent opportunity for people to demonstrate my lack of
> understanding of Functional Programming.
...
Sorry, I cannot really answer your question. The reason, you did not get an
answer from the group yet, might be we're talking about common lisp. Lisp is
multi-paradigm. You can do functional as well as procedural (imparative) or
even logic programming (s. On Lisp by Paul Graham). The functional only
approach is Scheme (AFAIK). For me functional sometimes is helpful but much
of my code produces side effects and thus isn't functional.
Andreas
"Andreas Thiele" <······@nospam.com> writes:
> Sorry, I cannot really answer your question. The reason, you did not get an
> answer from the group yet, might be we're talking about common lisp. Lisp is
> multi-paradigm. You can do functional as well as procedural (imparative) or
> even logic programming (s. On Lisp by Paul Graham). The functional only
> approach is Scheme (AFAIK).
Not even, there's a lot of ! (destructive) procedures in scheme.
Try Haskel.
> For me functional sometimes is helpful but much
> of my code produces side effects and thus isn't functional.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/