I know there's a long standing policy against it, but is it possible to
create read-only repositories for POVRAY and MORAY?

There might be some truly great contributions that could have been made in
the last 2 years while 3.7 has been in beta.

If it's a matter of computer or network resources, I'd be willing to donate
both.

Post a reply to this message

Calvin wrote:
> I know there's a long standing policy against it, but is it possible to
> create read-only repositories for POVRAY and MORAY?
> 
> There might be some truly great contributions that could have been made in
> the last 2 years while 3.7 has been in beta.

Hi Calvin,

As mentioned in http://www.povray.org/news/moray-announcement.php, we will
be making the beta codebase available in due course. We haven't decided
exactly how we will do this, but it is possible we could create a branch in
our revision control system (perforce) and provide access to that via HTTP
and/or perforce itself. If we go this route we will also consider providing
write access to some individuals.

regards,

-- Chris

Post a reply to this message

Chris Cason <""Chris Cason <deletethis-newsadmin2\"@deletethistoo.povray.org>
wrote:
> Calvin wrote:
> > I know there's a long standing policy against it, but is it possible to
> > create read-only repositories for POVRAY and MORAY?
> >
> > There might be some truly great contributions that could have been made in
> > the last 2 years while 3.7 has been in beta.
>
> Hi Calvin,
>
> As mentioned in http://www.povray.org/news/moray-announcement.php, we will
> be making the beta codebase available in due course. We haven't decided
> exactly how we will do this, but it is possible we could create a branch in
> our revision control system (perforce) and provide access to that via HTTP
> and/or perforce itself. If we go this route we will also consider providing
> write access to some individuals.
>
> regards,
>
> -- Chris

I don't want to be too pushy, but any hope of this happening any time soon?

I'm very interested in porting the parallelizing code to Cell, and possibly also
to CUDA. Right now the only option seems to be to wait for 3.7 or reinvent the
wheels from a 3.6 base.

I know the real issue is policy, but again I'll offer the resources to help make
it available. If Perforce access is a limiter, there's always the Perforce to
SVN repository converter to simplify getting it out to us masses.

Post a reply to this message

Calvin wrote:
> I'm very interested in porting the parallelizing code to Cell, and possibly also
> to CUDA.

Neither of that is feasible with either the 3.6 or 3.7 codebase. Or, putting
a "positive" spin on it: The work required would be exactly the same.

	Thorsten, POV-Team

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Calvin wrote:
> > I'm very interested in porting the parallelizing code to Cell, and possibly also
> > to CUDA.
>
> Neither of that is feasible with either the 3.6 or 3.7 codebase. Or, putting
> a "positive" spin on it: The work required would be exactly the same.
>
>  Thorsten, POV-Team

To argue that that which has not been done before cannot be done is to argue
disbelief in the dignity of the human spirit :-)

Are you saying it's unfeasible because of the lack of double floating point
support, or is there some architectural reason? [Cell/SPU has doubles and the
soon-to-be-released G92/9800 have doubles]

(I obviously haven't seen the 3.7 source, but I don't see what would be
unfeasible from the 3.6 source. Please let me know what I've missed!)

Post a reply to this message

Calvin wrote:
> Are you saying it's unfeasible because of the lack of double floating point
> support, or is there some architectural reason?

The architecture of POV-Ray does not allow you to treat some objects as
different as you would need to treat them without implementation all the
ray-tracing in special purpose hardware.

	Thorsten

Post a reply to this message

Calvin <nomail@nomail> wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
> > Calvin wrote:
> > > I'm very interested in porting the parallelizing code to Cell, and possibly also
> > > to CUDA.

> Are you saying it's unfeasible because of the lack of double floating point
> support, or is there some architectural reason? [Cell/SPU has doubles and the
> soon-to-be-released G92/9800 have doubles]

  Don't know about Cell, but in CUDA it's probably just impossible. For one,
CUDA doesn't support recursive function calls, which is more or less a must
in raytracing. (POV-Ray uses recursion not only for tracing rays but other
things as well.) Also single-precision floating point (with division and
square root of even lower quality compared to single-precision math done
with the FPU) is also a rather big wall. Not to talk about the CPU/GPU
bottleneck. As for multithreading, threads must run in groups of at least
32 threads that execute identical instructions simultaneously. Not very
likely in raytracing (again, because of all those pesky random recursions...)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Don't know about Cell, but in CUDA it's probably just impossible. For one,
> CUDA doesn't support recursive function calls, which is more or less a must
> in raytracing. (POV-Ray uses recursion not only for tracing rays but other
> things as well.) Also single-precision floating point (with division and
> square root of even lower quality compared to single-precision math done
> with the FPU) is also a rather big wall. Not to talk about the CPU/GPU
> bottleneck. As for multithreading, threads must run in groups of at least
> 32 threads that execute identical instructions simultaneously. Not very
> likely in raytracing (again, because of all those pesky random recursions...)

It can be done.

It's not what you'd call "easy". Would require an absurd amount of work 
to do it.

(You can build a ray queue. The GPU picks up a bundle of rays, sees 
whether or not each one intesects object X, and stores that somewhere. 
You then move the rays that hit it into another render queue ready to go 
through a different pass of the process. Long, complicated, and quite 
possibly not actually very fast...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message