 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote in message <370bb83f.25447192@news.povray.org>...
>
>There's nothing wrong with using POV for production work. The thing
>they're trying to prevent is someone taking the POV renderer and using
>it as the core of a commercial program.
Granted. But sooner or later, we have to face up
to this plug-in issue. I'd rather have the
POV-Team proactively taking the lead instead
of lots of people going around making patches
and other competing hacks to make it work.
If we sit around, POV will start fraying
at the edges.
That slope stuff is really neat, btw. I
whipped up this image while trying it out:
http://www.daylongraphics.com/products/leveller/tut/forest/final4.jpg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote in message <370AE1F3.3DC4D6A3@Kopp.com>...
>Ray Gardener wrote:
>>
>> Agreed, supporting all those CPUs is bothersome. But
>> gcc does it, the templates are mature, and we can tweak
>
>Does gcc support EVERY cpu? The core of POV is supposted to be completely
>platform independent ...
>
>Therefore any bytecode interpreter that is part of the core must also be
>platform independent... JIT compilers could be extra for each system...
>but the functionality would still exist for EVERY system.
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.
The irony is, that if a new instruction set appears, one
still needs to ultimately port something. For the same amount
of work, you may as well just port a native-code compiler.
The bytecode interpreter might be available, but I don't think anyone
would seriously use it. I'd sooner buy hardware supported
by a JIT instead of run bytecode (because hardware is now
so cheap these days). But if I'm doing that, I'll opt
for the hardware that's natively supported, and get even
more speed.
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.
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.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 7 Apr 1999 12:48:47 -0700, Ray Gardener <ray### [at] daylongraphics com> wrote:
>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.
No it doesn't. It strikes a blow for the non-open-source (i.e. POVLEGAL)
movement.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey now...
Quake3arena will be based on a JIT compiler..
it will be using one binary for the server part, and one for client part
computing(not gfx).
It will be written in ansi C, pre-compiled into a binary form, then compiled at
runtime for each system, using the internal C processor in quake 3...
it will all be based on LCC.
Well, JIT in games, of course :-)
Ray Gardener wrote:
>
> Nathan Kopp wrote in message <370AE1F3.3DC4D6A3@Kopp.com>...
> >Ray Gardener wrote:
> >>
> >> Agreed, supporting all those CPUs is bothersome. But
> >> gcc does it, the templates are mature, and we can tweak
> >
> >Does gcc support EVERY cpu? The core of POV is supposted to be completely
> >platform independent ...
> >
> >Therefore any bytecode interpreter that is part of the core must also be
> >platform independent... JIT compilers could be extra for each system...
> >but the functionality would still exist for EVERY system.
>
> 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.
>
> The irony is, that if a new instruction set appears, one
> still needs to ultimately port something. For the same amount
> of work, you may as well just port a native-code compiler.
> The bytecode interpreter might be available, but I don't think anyone
> would seriously use it. I'd sooner buy hardware supported
> by a JIT instead of run bytecode (because hardware is now
> so cheap these days). But if I'm doing that, I'll opt
> for the hardware that's natively supported, and get even
> more speed.
>
> 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.
>
> 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.
>
> Ray
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 07 Apr 1999 16:23:35 -0400, Nathan Kopp <Nat### [at] Koppcom> wrote:
>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.
Not much modification to GCC required, just a bunch of cross-compilers
and something that can read .o files and make ppdl files (a linker of
sorts).
Who decides which systems will be supported? Will we have binaries
for M68K? (assuming for the moment that no system calls will be made,
so a Linux M68K binary is just like a Mac one is just like an
Amiga one. Of course, that ignores the problem of calling conventions
and reserved registers.) How about Alpha? Sparc? MIPS? What about
all those other weird architectures Linux and GCC (and presumably
POV-Ray) run on? Who's going to test this thing?
Okay, so if I'm running a port of POV on my custom foo42 processor, I
probably have GCC ported to it and can compile my own binary chunk for
any plugins that come my way, but what if I give my foo42 build to my
buddy next door who has the same processor but zero technical expertise?
Where does he get a binary chunk for the nifty new plugin he just got?
>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.
Okay, so I have this binary file with lots of different formats in it.
I've just allocated a block of memory and read the appropriate code
into it, relocated addresses where necessary, and i'm ready to run it.
Now where did I put that library routine that lets me mark a data page
(or pages) as executable? I mean, I know how to do it under WinNT, but
that's a Win32 API call. I'm looking for something cross-platform.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ray Gardener wrote:
> That slope stuff is really neat, btw. I
> whipped up this image while trying it out:
>
> http://www.daylongraphics.com/products/leveller/tut/forest/final4.jpg
I'm impressed.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Nathan Kopp:
>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... [snip]
Sounds good to me. As least you're being
proactive and trying for a solution.
I suspect that most developers will opt to
build 'partial' plug-ins that only support
the two or three favorite platforms, but
that pretty much mirrors POV -- WinPOV
has the nicest GUI and latest builds, etc.
>Of course, binary plugins like this would be susceptible to trojans and
>viruses. :-(
True, but that's always the case with
any binary, even builds of POV. We just
have to download from trusted sources
like we always do. If we mandate that
the source has to be provided, then
security freaks can always build their
own local binary of a plug-in.
>Ambitious, huh? Has anyone done anything like this before?
Ambitious, yes. Original? I don't know.
But if the end goal is reached, you'll
get my vote for the Nobel Prize for
POV programming. Or the 'Most Judicious
Use of Plug-ins in a POV-Ray Script'
category at the Oscars. :)
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <370c283f.1@news.povray.org> , "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:
> I suspect that most developers will opt to
> build 'partial' plug-ins that only support
> the two or three favorite platforms, but
> that pretty much mirrors POV -- WinPOV
> has the nicest GUI and latest builds, etc.
"WinPOV has the nicest GUI and latest builds", aha (???)...
"only support the two or three [...] platforms", great idea (irony!)...
Thorsten
PS: Did I miss the last ten years or so and it is 2009??? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider wrote in message <370BC0F6.55C32441@bahnhof.se>...
>Hey now...
>Quake3arena will be based on a JIT compiler..
>it will be using one binary for the server part, and one for client part
>computing(not gfx).
Ooo... Quake on a JIT. Now I'll be able to
make detailed observations on the gameplay
to others.
"See that rocket? In ten seconds it will
hit that wall. But before it does, notice
the subtle use of rust and dirt used
to texture the fuselage..." :)
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
