 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-1-2010 22:51, nemesis wrote:
> Sabrina Kilian escreveu:
>> I have stated my intention to look into this...
>
> ...and then proceeded to precisely put up with all those excuses about
> non-triangle surfaces and all other povray features that have no such
> use for a GPU. I thought you changed your mind.
>
> I'm not ranting, nor whining, nor demanding anything. I just thought
> most would here would be glad to know GPU's are finally there for
> raytracing speedup. I was wrong, as always.
Ok, this is going to be my last try: everybody here would love POV to be
faster. Only based on the information we have got, GPU programming won't
work at the moment. As soon as it is feasible somebody will implement
things.
You seem to be surprised again and again that even if we look at the
same sources, we don't reach the same conclusions. You attribute that to
malice and silly conservatism. The fact of the matter is that the people
who reach that other conclusion do so based on the fact that they know
more than you, not less. We know how to program at a low level, we know
how a CPU works internally, we also know how a GPU works, and we know
how POV works. Based on all that we have concluded that ATM no general
GPU library can support POV.
You might be right in that a ray-tracer that has almost the POV syntax
but does not support the entire set of primitives and textures could be
implemented now on a GPU. But even if that were the case it would cost a
lot of manpower that we don't have and the result would almost certainly
be unusable in a few years time. So we think that it would be a waste of
our precious time and that we would not like the limitations anyway.
There will come a time when POV will use GPUs, but that time is not now.
Also remember that the time it takes for a render is seldom the limiting
factor. If POV gets faster we see opportunities to add just that little
bit extra to our scenes. Just like starting up a computer takes the same
order of magnitude of time now as it did 30 years ago. Scrolling a page
in Word also takes about as much time as it did on a C64. It is all
about how much time you are willing to spend on it. The reason that I am
saying that is that apart from just speeding up with Moore's law you can
increase the performance of POV by introducing a new algorithm or trick.
There is a surprising number of entries in p.b.i. that are about how to
achieve an effect.
Another observation: Margareth Thatcher has played a big role in
achieving that the EU is much less democratic than it should be. Just by
being stubbornly aggressive on anything that was going on in the EU.
Nobody wanted to be associated with that sort of single mindedness and
nobody wanted to let her hold up every discussion forever. The result is
that there was a lot that could not be discussed openly.
We had a similar thing in this group. I don't know if JPG2000 is an
improvement over standard JPG, but I know that I never looked seriously
into that. Nor did I ever try irfanview. And I know why.
My advice: if you want to increase the possibility that one day soon POV
will be able to use GPUs, just shut up about it. You may point us
towards new developments, that is what p.o-t is for, but never try to
tell anybody what he should do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Warp wrote:
> > You have POV-Ray, open source,
> > and you have a library to calculate ray-triangle intersections with the
> > GPU, open source. What stops you from integrating the latter in the
> > former?
> GPL incompatibility with POV-Ray license?
POV-Ray 3.7 will probably have a GPL license.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> The only explanation so far being thrown has been: "we don't want to speed up
> povray's ray-triangle intersections because it would make it much more useful to
> people outside our small geek niche and those people wouldn't be interested in
> using other povray features thus making us feel unloved".
GPU acceleration will be useful when the following conditions are met:
1) Support for sophisticated branching
2) Full double-precision accuracy
3) Large memory sets (other than textures)
4) Independent shaders running on distinct units.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> I'm not whining nor demanding povray to evolve, just thought people
> around here would enjoy the idea that GPU's are finally getting ready to
> boost raytracing
They're getting close. Have you read the specs for the current version
of OpenCL, and verified that it supports the features needed for POV-Ray?
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> I'm not ranting, nor whining, nor demanding anything. I just thought
> most would here would be glad to know GPU's are finally there for
> raytracing speedup. I was wrong, as always.
Are you ever happy to see a dead horse?
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> around here would enjoy the idea that GPU's are finally getting ready to
> boost raytracing, despite many years of such trumpeting here and
Here's a hint for you. When this is the message you want to communicate,
you post a link and say "Cool, GPUs are getting to where they can do
ray-tracing." You don't say "You're all losers for not doing this, and the
software you love to work on is going to DIE DIE DIE if you don't
immediately work to integrate this feature."
Dick.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian wrote:
> actual contribution has been negligible.
actual contribution has been negative.
FTFY.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> GPU acceleration will be useful when the following conditions are met:
Actually, just curious here... would it help in any way with speeding up
shadow calculations? If you have a large hard-to-bound-well object with
dozens of lights, is there anything you could do in parallel (such as on a
GPU) that might be able to tell you which lights are known not to be visible
at a particular 3D point?
That would seem an easier problem to apply GPU to than the full
ray-intersection and texture and color and such, because you could fall back
to a CPU-based test in the event you came back with "I don't know"?
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/19/2010 2:23 PM, Jim Henderson wrote:
> On Tue, 19 Jan 2010 13:35:47 -0500, nemesis wrote:
>
>> The only explanation so far being thrown has been: "we don't want to
>> speed up povray's ray-triangle intersections because it would make it
>> much more useful to people outside our small geek niche and those people
>> wouldn't be interested in using other povray features thus making us
>> feel unloved".
>
> Huh, you and I are reading different messages, then.
>
>> Really, they can't stop talking how isosurfaces,
>> textures and whatsoever would not be well-supported on GPU even though I
>> agreed with that from the start and only hinted at triangles speed up.
>
> And given the relatively small niche in the userbase who has hardware
> that could do so, it doesn't seem reasonable to you to say "this is not a
> good use of our developer's time"?
>
> In any development project, there are good ideas that get put off or not
> implemented due to resource constraints. This is one of those times.
> Maybe the right kind of GPU hardware will become more pervasive and
> someone will take this on, but until then, you'll just have to be
> satisfied with the answer that's been given, which I'm quite *sure* isn't
> "we want to keep the software slow", as you seem to think it is.
>
> Jim
You know.. There is one bit of irony in this whole mess. If you look at
something that "attempts" to do building in a virtual environment you
get the god awful mess of Second Life/Opensim, and there idea of
"prims". While the purpose of POVRay hasn't been to create a game engine
at all, its tiresome to see such total junk produced to do what POVRay
does well, which is let you build stuff, without making it in a $500
application that handles nothing but meshes.
I would love nothing else than to see POVRay like design features, and
real primitives, integrated into a GPU supported system, that worked
better than the stuff on the market. Both have handicaps. POVRay due to,
until now, there being no feasible way to use a GPU to help it, and
everything else by the fact that the *best* real time generation of a
scene, based on anything close to a data set that defines what you are
looking at, its a bloody disaster, because its trying to use stuff that
works mathematically with predefined meshes, and various cheats, to
*fake* CSG effects, which it can't actually manage at all.
You could use half as many "prims", end up with better results, and use
the half you end up left over to add detail, if SL/Opensim used real
primitives, even *with* the idiocy of having to tessellate them into a
mesh first. Its absurd, and annoying, and I dream of the day someone
manages to fix the problem. But, based on my understanding, that
**isn't** going to happen any time soon, especially not unless POVRay
picked up some heavy hitters, who knew the other code well, and actually
thought it would be a good idea to produce something that used the best
of both. The team doesn't have such a person, and even if it did, it
would still need to get 3.7 working, without such added functionality,
and that, for now, is the reason its not going to happen now, or
necessarily even "soon".
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> GPU acceleration will be useful when the following conditions are met:
> 1) Support for sophisticated branching
> 2) Full double-precision accuracy
> 3) Large memory sets (other than textures)
> 4) Independent shaders running on distinct units.
I think all those conditions are already met. For me the only barrier to
not implementing POV on the GPU is the developer effort needed, and the risk
that it might be wasted if the overall technology changes of programming
GPUs in the next 5-10 years.
Maybe there are some small problems that have to be worked around, but IMO
GPUs are powerful enough today to run something like POV. I already made
demo applications that do raytraced spheres and isosurfaces on the GPU (and
my GPU is not even a modern one, it still has certain limitations), so I'm
pretty sure something *could* written in OpenCL or CUDA on a new GPU and
would handle POV fine, including all primitives and texturing. It's just
the effort needed, and whether it will all be wasted in 5 years when
something new appears.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
