 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>>> If you converted POV to run on the GPU then it would take a huge
>>> amount of work and would no longer be as portable as it is today.
>>
>> But would be much faster! Take a look here:
>
> Sure, but there simply aren't the people willing to do the work for
> free. Look how long it's taken from 3.6 to 3.7 beta, what hope is there
> of a complete rewrite for the GPU before 2020?
>
I finally got some free time. CUDA and OpenCL are both on my 'to learn'
list. POV-Ray seems like a good code base to start from, once I get my
brain back around parallel processing. So, that is at least one more
person available to work for free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escreveu:
> On 13-1-2010 21:52, nemesis wrote:
>> andrel escreveu:
>>>>> What I think is that ATM GPU's are useful for trangulations and
>>>>> that the result is near real life. As far as I have heard the
>>>>> rendering is less physical correct and more is faked. I though they
>>>>> were a bit lacking in multiple reflection and refraction, in media
>>>>> and possibly also in versatility of procedural textures. I am not a
>>>>> gamer, so I don't actually know for sure.
>>>>
>>>> I show you a link for a video of a physically-based path tracer
>>>> running on GPU and yet you talk about limited game tech...
>>>>
>>> No I didn't.
>>
>> Those words are yours.
>>
> Which?
I think is that ATM GPU's are useful for trangulations and
that the result is near real life. As far as I have heard the
rendering is less physical correct and more is faked. I though they
were a bit lacking in multiple reflection and refraction, in media
and possibly also in versatility of procedural textures. I am not a
gamer, so I don't actually know for sure.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Amazing the amount of self-denial one has to go in order to cope with excuses
> for why his favorite rendering engine should not evolve.
>
That isn't an arguement; it borders on insult. I offered you reasons.
Not vague reasons, but reasons why there is no man-power to divert to
this path you, who admit you do not have the skills to contribute, think
will bring a dramatic speed increase.
> Sabrina Kilian <ski### [at] vt edu> wrote:
>>> Can you imagine what povray could do comparatively without getting
>>> boiled down by unbiased techniques?!
>>>
>> Those unbiased techniques are what allows them to appear so fast. The
>> video appears to be getting 10fps tops, and between 2 and 4 the rest of
>> the time. Yes, unbiased rendering is slower to achieve the same image as
>> a biased renderer, however you can stop it much sooner and get a full
>> resolution picture. That picture just has more noise.
>>
>> Your question comes out as if you were asking "Could you imagine what
>> povray could do by using unbiased techniques for single sample speed
>> increases without being unbiased?" I think the quickest answer would be
>> "Not really, but set the max depth to 1 and lets see what the pictures
>> look like."
>
> No, my question is merely like: "hey, I can render scenes in povray in seconds
> rather than dozens of minutes. And truly complex ones in a few hours rather
> than days."
>
Right, and as I said, the bandwidth of the PCI-E bus may or may not
allow for those truly complex scenes. Look at these demos, check out the
rather simplistic geometry being used. Now pick a scene from the POV HOF.
My suspicion right now, is that those complex scenes would choke the bus
in one setup, or choke the GPU in another. This is based on knowledge of
the principle and some skill at parallel programing and low level code
design, but little in either the POV-Ray code base or GPGPU. If one of
the experts would like to chime in before I get some tests written,
please do.
> I'm not impressed with that demo's noisy 4fps display. I'm impressed to see
> scenes with full light transport phenomena set that usually take 1 hour to
> denoise being noise-free in a couple of minutes.
>
> This is the future: tapping all that hidden power that was being ignored so far
> because we insist on using a lame-O chip geared at word processing to do math
> operations.
Yes, it is. But that is not what you are asking for. You are asking for
it to be the immediate future of POV-Ray.
At this point in time, both OpenCL and CUDA have no enforced double
precision float variables. They are optional in OpenCL, and only
available on certain cards in CUDA. In a raytracer that does not care
about this, or that is rewritten to not care, this would not be a
problem. However, since POV-Ray uses them for a lot of things
internally, there is a major problem in off-loading just part to the
GPU. The parts on the GPU will only be using standard floats, while the
CPU is using doubles, which will result in noticeable precision loss. If
you think the solar system scale issue is bad, right now, then wait
until you lose a portion of that and are stuck dealing with it on a much
smaller scale. And you might as well go back to running the older 16 bit
versions if you just change the CPU to only use single precision floats.
Or, if you insist on forcing the GPU to do the extra math to fake double
precision values, then you have lost all of the speed increase.
Will POV-Ray move to GPU? Of course, once there is a good assurance that
the code will not have to be rewritten for 8 different APIs, and will
not lose the precision that it is known for now. And all of the multiple
other problems that you seem to think are just fan-boys' "self-denial" .
. . "in order to cope with excuses for why his favorite rendering engine
should not evolve."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-1-2010 22:29, nemesis wrote:
> andrel escreveu:
>> On 13-1-2010 21:52, nemesis wrote:
>>> andrel escreveu:
>>>>>> What I think is that ATM GPU's are useful for trangulations and
>>>>>> that the result is near real life. As far as I have heard the
>>>>>> rendering is less physical correct and more is faked. I though
>>>>>> they were a bit lacking in multiple reflection and refraction, in
>>>>>> media and possibly also in versatility of procedural textures. I
>>>>>> am not a gamer, so I don't actually know for sure.
>>>>>
>>>>> I show you a link for a video of a physically-based path tracer
>>>>> running on GPU and yet you talk about limited game tech...
>>>>>
>>>> No I didn't.
>>>
>>> Those words are yours.
>>>
>> Which?
>
> I think is that ATM GPU's are useful for trangulations and
> that the result is near real life. As far as I have heard the
> rendering is less physical correct and more is faked. I though they
> were a bit lacking in multiple reflection and refraction, in media
> and possibly also in versatility of procedural textures. I am not a
> gamer, so I don't actually know for sure.
>
So, point me to where I talked exclusively about game tech.
But let me try to explain again: what you pointed at and other things I
have seen so far is that GPUs are used for a limited set of primitives
only, modelling a subset of physical behaviour. Even if they claim to be
physically accurate in practice they aren't, nor is POV for that matter.
Again what I have seen and understood is that up till now POV is more
physical complete (disclaimer: I have not seen everything that is out
there.). Hence POV still has a place.
In order to get more 'realistic' games the GPUs have been optimized to
render textures and fake reflections and shadows. They can be used as
FPU replacement for certain tasks, but they are not perfect for general
processing (yet). That is as far as I know. There may have been
significant advances that I have missed because I am not a gamer and
hence do not follow the developments closely. OTOH with every new
development in GPUs there is bound to be a POVer somewhere to draw
attention to the fact that POV is still not using GPUs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-1-2010 22:17, Sabrina Kilian wrote:
> scott wrote:
>>>> If you converted POV to run on the GPU then it would take a huge
>>>> amount of work and would no longer be as portable as it is today.
>>> But would be much faster! Take a look here:
>> Sure, but there simply aren't the people willing to do the work for
>> free. Look how long it's taken from 3.6 to 3.7 beta, what hope is there
>> of a complete rewrite for the GPU before 2020?
>>
>
> I finally got some free time.
Sounds good.
> CUDA and OpenCL are both on my 'to learn' list.
They are on my list of things to do when I get a less demanding job.
> POV-Ray seems like a good code base to start from, once I get my
> brain back around parallel processing. So, that is at least one more
> person available to work for free.
Not really for free. You get nice pictures as reward. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
>> I think is that ATM GPU's are useful for trangulations and
>> that the result is near real life. As far as I have heard the
>> rendering is less physical correct and more is faked. I though they
>> were a bit lacking in multiple reflection and refraction, in media
>> and possibly also in versatility of procedural textures. I am not a
>> gamer, so I don't actually know for sure.
>>
> So, point me to where I talked exclusively about game tech.
"less physical correct", "lacking reflection and refraction", "lacking
media" and "lacking procedural textures" are all indeed game tech
limitations (for now) that don't show up at all in the "physically
correct" path tracer running on GPU I linked to.
> But let me try to explain again: what you pointed at and other things I
> have seen so far is that GPUs are used for a limited set of primitives
> only, modelling a subset of physical behaviour. Even if they claim to be
> physically accurate in practice they aren't
GPU's don't claim anything. General purpose algorithms making use of
their sheer math processing power do.
I thought by physically correct you were talking about materials or
light propagation behavior, not every model being made of from polygons.
> Again what I have seen and understood is that up till now POV is more
> physical complete (disclaimer: I have not seen everything that is out
> there.). Hence POV still has a place.
and I hope that place is a GPU.
> In order to get more 'realistic' games the GPUs have been optimized to
> render textures and fake reflections and shadows. They can be used as
> FPU replacement for certain tasks, but they are not perfect for general
> processing (yet). That is as far as I know. There may have been
> significant advances that I have missed because I am not a gamer and
> hence do not follow the developments closely.
I'm not talking about games at all. I only hinted at the fact that
several other raytracers are beginning to use the GPU for their
calculations, including full raytraced reflections, refractions,
mesh-based lighting etc. They are not using the GPU as a mere game
scanline engine, they are just general purpose programs (actually,
parts of it) running on GPU.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian wrote:
> nemesis wrote:
>> Amazing the amount of self-denial one has to go in order to cope with excuses
>> for why his favorite rendering engine should not evolve.
>>
>
> That isn't an arguement; it borders on insult.
yes, I apologise for that. It was a general over-the-top statement not
addressed directly at you, but at all GPU deniers. I'm not an attention
whore, but I think it's an important subject and by going a bit trollish
I think I helped to bring discussion about it and, hopefully, change.
You already commit to the idea, so I think I did a good job. But sorry
for the rudeness anyway. Military tactics, dear. ;)
> I offered you reasons.
> Not vague reasons, but reasons why there is no man-power to divert to
> this path you, who admit you do not have the skills to contribute, think
> will bring a dramatic speed increase.
I don't "think", I've been following it elsewhere. There are measured
data, at least for triangle meshes. May not be helpful at all for
people who want perfect spheres or extremely slow isosurface terrains,
but should make povray a lot more viable to general 3D artists.
>> Sabrina Kilian <ski### [at] vtedu> wrote:
> Right, and as I said, the bandwidth of the PCI-E bus may or may not
> allow for those truly complex scenes. Look at these demos, check out the
> rather simplistic geometry being used. Now pick a scene from the POV HOF.
You have a point. I prefer to be optimistic though and think the main
reason to be that they were targetting a "real-time" (puny 4fps) display
to draw attention and that wouldn't be possible with far too much
geometry on screen.
Have you seen the whole video? There are some considerably more
detailed scenes to the end, including some well-known 3D benchmark scenes.
> My suspicion right now, is that those complex scenes would choke the bus
> in one setup, or choke the GPU in another. This is based on knowledge of
> the principle and some skill at parallel programing and low level code
> design, but little in either the POV-Ray code base or GPGPU. If one of
> the experts would like to chime in before I get some tests written,
> please do.
Might be of help to see how they are doing there, complete with benchmarks:
http://www.luxrender.net/forum/viewtopic.php?f=21&t=2947
very long thread full of juicy stuff.
>> This is the future: tapping all that hidden power that was being ignored so far
>> because we insist on using a lame-O chip geared at word processing to do math
>> operations.
>
> Yes, it is. But that is not what you are asking for. You are asking for
> it to be the immediate future of POV-Ray.
No, but it's good to be prepared. POV-Ray develops slowly and without a
push, it just might wait another 5 years just to become aware of GPGPU,
let alone try to implement.
> At this point in time, both OpenCL and CUDA have no enforced double
> precision float variables. They are optional in OpenCL, and only
> available on certain cards in CUDA. In a raytracer that does not care
> about this, or that is rewritten to not care, this would not be a
> problem. However, since POV-Ray uses them for a lot of things
> internally, there is a major problem in off-loading just part to the
> GPU. The parts on the GPU will only be using standard floats, while the
> CPU is using doubles, which will result in noticeable precision loss. If
> you think the solar system scale issue is bad, right now, then wait
> until you lose a portion of that and are stuck dealing with it on a much
> smaller scale. And you might as well go back to running the older 16 bit
> versions if you just change the CPU to only use single precision floats.
> Or, if you insist on forcing the GPU to do the extra math to fake double
> precision values, then you have lost all of the speed increase.
David, the author of the demo, says in that thread:
"Yup, it is so easy and so fast to zoom in that you end the 32bit
floating point resolution very soon. The only solution would be to use
64bit floating points instead of 32bit but there are very few boards
supporting them at the moment (I think the new ATI HD5xxx series has the
hardware support for double).
The other option would be the use software implemented floating point
numbers with user defined resolution ... this stuff is so fast that it
could handle it quite well even in software."
In any case, no need to worry about doubles as the hardware will just be
there once any implementation whatsoever is complete: don't forget 3.7
beta has been around for ages ever since multicore started to become
feasible.
Cards supporting doubles are already there, just not so cheap as to be
in every PC.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel wrote:
>>> I think is that ATM GPU's are useful for trangulations and
>>> that the result is near real life. As far as I have heard the
>>> rendering is less physical correct and more is faked. I though they
>>> were a bit lacking in multiple reflection and refraction, in media
>>> and possibly also in versatility of procedural textures. I am not a
>>> gamer, so I don't actually know for sure.
>>>
>> So, point me to where I talked exclusively about game tech.
>
> "less physical correct", "lacking reflection and refraction", "lacking
> media" and "lacking procedural textures" are all indeed game tech
> limitations (for now) that don't show up at all in the "physically
> correct" path tracer running on GPU I linked to.
>
>> But let me try to explain again: what you pointed at and other things
>> I have seen so far is that GPUs are used for a limited set of
>> primitives only, modelling a subset of physical behaviour. Even if
>> they claim to be physically accurate in practice they aren't
>
> GPU's don't claim anything. General purpose algorithms making use of
> their sheer math processing power do.
>
> I thought by physically correct you were talking about materials or
> light propagation behavior, not every model being made of from polygons.
>
>> Again what I have seen and understood is that up till now POV is more
>> physical complete (disclaimer: I have not seen everything that is out
>> there.). Hence POV still has a place.
>
> and I hope that place is a GPU.
>
>> In order to get more 'realistic' games the GPUs have been optimized to
>> render textures and fake reflections and shadows. They can be used as
>> FPU replacement for certain tasks, but they are not perfect for
>> general processing (yet). That is as far as I know. There may have
>> been significant advances that I have missed because I am not a gamer
>> and hence do not follow the developments closely.
>
> I'm not talking about games at all. I only hinted at the fact that
> several other raytracers are beginning to use the GPU for their
> calculations, including full raytraced reflections, refractions,
> mesh-based lighting etc. They are not using the GPU as a mere game
> scanline engine, they are just general purpose programs (actually,
> parts of it) running on GPU.
Lets just say that.. It may be feasible to do in an hour what takes days
now, using a GPU, for POVRay, when it was using prior CPUs, that didn't
have the bit depth for floats that modern ones do. But I agree with
Andrel's general assessment, based on what I have seen and read, that,
*in general* too many things are still done using cheats, because the
GPU can't handle them, and you *may* find yourself running into
precision issues, when trying to use some GPUs.
Now, that said, you *could* allow for a "minimum" requirement in that
respect, and get stuff as good or better than we see on a cheap machine
now, possibly. Though, that is a pure guess. You could then "allow for"
some sort of computable scaling of settings, where if the GPU allowed
larger floats, you could adjust to get a *better* final. Problem is,
most of that parameters are stuff that is bloody hard to get right when
you *know* the machine you are using, never mind if you had to have the
parser "update" them to match a better GPU.
All of which become irrelevant, if AMD's idea takes wing and the GPU
becomes part of the CPU, making the difference between the "internal"
floats, and the "external" GPU floats completely bloody meaningless. We
may see GPUs become a sort of "enhanced process" loaded with stuff the
inbuilt doesn't handle, instead of the main focus of this whole thing.
The end result is likely that the difference between an AMD compliant
POVRay and one for GPU will be zip, zilch, and nada.
--
void main () {
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Sabrina Kilian wrote:
>> nemesis wrote:
>>> Amazing the amount of self-denial one has to go in order to cope with
>>> excuses
>>> for why his favorite rendering engine should not evolve.
>>>
>>
>> That isn't an arguement; it borders on insult.
>
> yes, I apologise for that. It was a general over-the-top statement not
> addressed directly at you, but at all GPU deniers. I'm not an attention
> whore, but I think it's an important subject and by going a bit trollish
> I think I helped to bring discussion about it and, hopefully, change.
>
> You already commit to the idea, so I think I did a good job. But sorry
> for the rudeness anyway. Military tactics, dear. ;)
>
My commitment to this started well before this conversation. Some time
about 2 years ago when I started reading about the abilities of CUDA and
the multicore setup on the PS3. Problem was, the PS3's double precision
was handled in hardware, but at something close to 2GFLOPs for the whole
system. Not a substantial increase. Under CUDA, the option was 32bit or
forget about it.
Military tactics only work if you can step up and lead. Otherwise . . .
>> I offered you reasons.
>> Not vague reasons, but reasons why there is no man-power to divert to
>> this path you, who admit you do not have the skills to contribute, think
>> will bring a dramatic speed increase.
>
> I don't "think", I've been following it elsewhere. There are measured
> data, at least for triangle meshes. May not be helpful at all for
> people who want perfect spheres or extremely slow isosurface terrains,
> but should make povray a lot more viable to general 3D artists.
>
Right, they bring a dramatic speed increase to other systems and
programs, so you THINK they will here as well. Prove it, or wait.
> Have you seen the whole video? There are some considerably more
> detailed scenes to the end, including some well-known 3D benchmark scenes.
>
Various GPUs is going to be one of the places this all falls apart. My
laptop has a GeForce 9600M GT, with 2.5gigs of available ram, because it
can share system resources. But for all that available space, it only
has 32 cores.
If I start testing, and find an 8 fold decrease in speed, does this
indicate a problem with my set up, or with the code, or with the API?
Unlike when we deal with CPUs, where we may have a range of single to 4
core, with only a few people using more, and a relative similar range of
ram, and clock speeds only varying by maybe 25%. For GPUs, the clock
speed may be similar, but ram varies from 512 to several gigs, cores
from 8 to 112 just on the 9xxx mobile lines.
If someone wants to donate a 2xx GPU that can actually handle 64bit
floats, I will be glad to put it to use.
>> My suspicion right now, is that those complex scenes would choke the bus
>> in one setup, or choke the GPU in another. This is based on knowledge of
>> the principle and some skill at parallel programing and low level code
>> design, but little in either the POV-Ray code base or GPGPU. If one of
>> the experts would like to chime in before I get some tests written,
>> please do.
>
> Might be of help to see how they are doing there, complete with benchmarks:
>
> http://www.luxrender.net/forum/viewtopic.php?f=21&t=2947
>
> very long thread full of juicy stuff.
>
30 odd pages, if you have a specific part that you think would be
helpful, a direct link would be better. I will keep trawling it.
> David, the author of the demo, says in that thread:
>
> "Yup, it is so easy and so fast to zoom in that you end the 32bit
> floating point resolution very soon. The only solution would be to use
> 64bit floating points instead of 32bit but there are very few boards
> supporting them at the moment (I think the new ATI HD5xxx series has the
> hardware support for double).
>
> The other option would be the use software implemented floating point
> numbers with user defined resolution ... this stuff is so fast that it
> could handle it quite well even in software."
Depends on the card, again. If the card is only offering double or
triple the FLOPs of the FPU/CPU, then the speed loss by faking it in
software will not be better. Wide range of hardware, remember?
Anyone have a good double precision faking library for CUDA? I guess I
could write that as a first program, but why start from scratch?
> In any case, no need to worry about doubles as the hardware will just be
> there once any implementation whatsoever is complete: don't forget 3.7
> beta has been around for ages ever since multicore started to become
> feasible.
Right, it will be there eventually. But testing it on 32bit hardware is
tough. Bugs may crop up, performance will be vastly different. And then
there is the number of developers available. Convince some new people to
offer code to POV-Ray, and you might convince the dev team otherwise.
>
> Cards supporting doubles are already there, just not so cheap as to be
> in every PC.
I know, I bought a new laptop at the beginning of this summer and had
been waiting for 2 years to get a graphics card that would support
hardware 64-bit floats. But, because of timing of my main desktop dying,
and funds available, I just couldn't manage it. The university undergrad
lab doesn't stock a room full of gaming computers for development, the
grad student one may but I am not privy to that.
If you happen to have a computer with a high end GPU that I can run
comparison benchmarks on, great. Otherwise, my development time will be
limited to how often I can ship code off to friends and get benchmarks
and profiles.
Or I could find an AGP GeForce 2xx, and drop it into a really old tower.
I wonder if those even exist.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel wrote:
>>> I think is that ATM GPU's are useful for trangulations and
>>> that the result is near real life. As far as I have heard the
>>> rendering is less physical correct and more is faked. I though they
>>> were a bit lacking in multiple reflection and refraction, in media
>>> and possibly also in versatility of procedural textures. I am not a
>>> gamer, so I don't actually know for sure.
>>>
>> So, point me to where I talked exclusively about game tech.
>
> "less physical correct", "lacking reflection and refraction", "lacking
> media" and "lacking procedural textures" are all indeed game tech
> limitations (for now) that don't show up at all in the "physically
> correct" path tracer running on GPU I linked to.
>
They are also short cuts that people have used to implement ray-tracing
on the GPU.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
