POV-Ray : Newsgroups : povray.programming : POV-Ray modification question : Re: POV-Ray modification question Server Time
29 Jul 2024 04:21:31 EDT (-0400)
  Re: POV-Ray modification question  
From: Nathan Kopp
Date: 7 Apr 1999 17:26:44
Message: <370BBEC7.7EA854A9@Kopp.com>
Ray Gardener wrote:
> 
> If a JIT is truly fast enough (does anyone have benchmarks
> from that JavaRays program?) then that would be great. But
> if not... and let's face it, for all of fuss over JITs,
> they haven't had any real impact on day-to-day computing.
> When I see JITs used for commercial video games, then
> I'll be impressed. And how much RAM did Sun say their JIT
> needed? Tons and tons? Insane.

Current Java JIT, as you indicate, is too slow and too much of a
resource hog.  I agree.

> With raytracing, there's never a point where the
> system is 'fast enough'. Even if gigahertz machines
> were common, we'd still need every last bit of performance.
> If the pics we're doing today render quickly, we'll
> start doing more complex scenes. And then there's movies,
> which need tons of frames, etc. It's not like accounting,
> were there's only so much math a transaction can involve.

I agree.  However, as you say in your other post, the plug-in issue
must be dealt with at some point.  So the question becomes, "what
format do the plug-ins take and how are they distributed?"

Binary plugins:
* very fast
* system-dependent
* must be recompiled for each system, which requires a the user to have
  access to development tools
* probably different program<->plugin interfaces on each system
  For example, a DLL-type system exists on some UNIX systems, but it
  works in a totally different way.  Now the core of POV is no longer
  system-independent.

Source/bytecode plugins (I consider these to be very similar):
* interpreted, very slow
* platform independent, provided interpreter is platform independent
* could be JIT compiled
* JIT compilers are still slow
* interpreter/JIT compiler would bloat the POV-Ray executable

> So Ron's saying gcc's code can't be used to improve POV.
> Well, that sure strikes a blow for the open source
> movement. What a collosally wasted opportunity.

The reason it can't be used is that if you use GPL source in your program,
your code must also be put under GPL.  And POV is not under GPL.

Somebody should design the following:  the "POV Plugin Dynamic Library",
or PPDL for short.  The development kit would consist of a modified GCC
which compiles POV shaders (or other plugins) to a PPDL format.  This
PPDL could include binary code for a variety of systems in the same
file.  The PPDL interface (meaning how POV talks to the plugin) would be
the same for all systems, keeping the core of POV system independent and
the part of this system embedded in POV would be developed independently
of GPL stuff and would therefore not be part of GPL.  A pov plugin
compiler could be made available for all systems that are supported by
GCC.  And maybe the PPDL specification would include the plugin source
in the PPDL file (all-in-one-package design) so that people could easily
add/remove binary sections.  (a PPDL file would have multiple sections:
one for the source and others for the binary parts)

Of course, binary plugins like this would be susceptible to trojans and
viruses.  :-(

Ambitious, huh?  Has anyone done anything like this before?

-Nathan


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.