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