 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> 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.
>
This is one thing that will drastically change everything. If that idea
takes flight, and any compiler offers a nice API and syntax for writing
the equivalent of CUDA kernels, then the data bus problems vanish (to
the coder, they are still there in reality), the bit accuracy problem
goes away, and very little needs to be rewritten. Recursion may be a
problem for the GPU on chip, but that will be a problem for any current
GPU implementation.
But, chances are, we would still be stuck with AMD/ATI implementing
their Stream SDK instead of OpenCL. But, we can hold out hope.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
>
> What hope is there for an old-fashioned, dog-slow, CPU-only raytracer to
> still be alive by 2020?
Because nothing else will come along with a nice SDL like POV has. Almost
all other raytracers *require* you to use an external mesh modeller to
generate your scene - POV doesn't which IMO is its strongest point.
> The guys there ported the ray intersection code and the space
> partitioning.
Sure, that's relatively simple for triangles, but that is only a tiny part
of POV. The interesting parts are all the other primitives and the material
options. I suspect to convert those would be order of magnitudes more work
than just the ray-triangle intersection test.
> And are working now on refining load balance. Good starting points
> without much pain if you ask me... I'd leave troubles with non-triangle
> surfaces out.
If you only want to render triangle meshes then I would suggest that POV
isn't the best tool for the job.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian escreveu:
> nemesis wrote:
>> You already commit to the idea, so I think I did a good job. But sorry
>> for the rudeness anyway. Military tactics, dear. ;)
>
> Military tactics only work if you can step up and lead. Otherwise . . .
you're right. I'm only Private Joker playing of Sergeant Hartman.
> Right, they bring a dramatic speed increase to other systems and
> programs, so you THINK they will here as well. Prove it, or wait.
I would think pov-ray's triangle handling to be similar to that of other
raytracers but if that's not the case, I'll just wait for your word on
it, sweetie.
> 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?
In that thread, they run into all of them. oh teh fun! might be of
much help to not duplicate the same errors.
notice also that OpenCL drivers are still alfa/beta quality.
>> 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.
No, I didn't read it all either, much less the later pages. The talk
about float4 vectors might interest you.
> 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?
Wide range of hardware has never prevented povray running on low-end
hardware or super-duper minicomputers. Users never complained of the
vastly different speeds.
Shoot for the best, darling.
> 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?
So you'll be targetting CUDA? It's not cross-platform as OpenCL,
although much more mature for now.
> 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.
sadly, I'm already an old wig with a Q6600 and a cheap nvidia card (9400
GT if I remember correctly).
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott escreveu:
>> What hope is there for an old-fashioned, dog-slow, CPU-only raytracer
>> to still be alive by 2020?
>
> Because nothing else will come along with a nice SDL like POV has.
> Almost all other raytracers *require* you to use an external mesh
> modeller to generate your scene - POV doesn't which IMO is its strongest
> point.
well, you have a point. FORTRAN is still around too and just as much
niche as pov SDL, but it's also more useful.
>> The guys there ported the ray intersection code and the space
>> partitioning.
>
> Sure, that's relatively simple for triangles, but that is only a tiny
> part of POV.
which is why I'm suggesting looking only at this tiny part for the
change. Tiny or not, it's 90% more useful for general 3D artists than
all perfect spheres or math surfaces.
Would you not enjoy povray to go wildly popular? Do you prefer it to be
this geek niche? Popularity would also bring more contributing
developers, I guess...
> If you only want to render triangle meshes then I would suggest that POV
> isn't the best tool for the job.
That is kind of obvious as it is now.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian escreveu:
> nemesis wrote:
>> andrel wrote:
>>> 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.
I don't see those limitations in the demo. Indeed there is a cornell
box in there with reflections and refraction.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Because nothing else will come along with a nice SDL like POV has.
> Almost all other raytracers *require* you to use an external mesh
> modeller to generate your scene - POV doesn't which IMO is its strongest
> point.
That, and excellent procedural textures, is why I'm interested in it. :-)
--
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 14-1-2010 2:16, 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)
Probably, yet going from that to the converse is a logical fallacy.
> that don't show up at all in the "physically
> correct" path tracer running on GPU I linked to.
How do you know?
>> 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.
To be even more pedantic: it is the people that write software who claim
things.
> I thought by physically correct you were talking about materials or
> light propagation behavior, not every model being made of from polygons.
No I made both statements: they are less physical correct and don't
support all primitives of POV. Until both problems are solved it is not
sensible to try to port POV to a GPU.
>> 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.
Why? I mean why a GPU especially? There is a lot going on and I don't
see a reason to single out GPUs. I want my ray tracer to run as facst as
possible, I don't really care on what hardware it is implemented, as
long as it is affordable.
>> 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.
Good, me neither.
> 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.
I fail to see why it is necessary to repeat what I already indicated to
know. Has the fact that I don't share your conclusion something to do
with it? If that is the main reason, my estimate is that if you just
repeat yourself, I am not going to change my opinion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14-1-2010 16:54, nemesis wrote:
>>> dear. ;)
>>
> sweetie.
>
> darling.
It is a good practice on the internet to assume that anyone that has a
female sounding name is in fact an overweight 70 YO male.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escreveu:
> On 14-1-2010 16:54, nemesis wrote:
>>>> dear. ;)
>>>
>> sweetie.
>>
>> darling.
>
> It is a good practice on the internet to assume that anyone that has a
> female sounding name is in fact an overweight 70 YO male.
Yes, caught off guard! :P
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escreveu:
> On 14-1-2010 2:16, 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)
>
> Probably, yet going from that to the converse is a logical fallacy.
>
>> that don't show up at all in the "physically correct" path tracer
>> running on GPU I linked to.
>
> How do you know?
I know because the code is available and it implements a
general-purpose, though limited, version of a physically-based path
tracer on the GPU. No scanline trickery, just general-purpose
raytracing tapping that awesome hidden power sitting idle on your PC
right now.
> To be even more pedantic: it is the people that write software who claim
> things.
You can look at the code if you have any such understanding. If you
don't understand, you can also simply look at the video and marvel at
the physically correct reflections, caustics, soft shadows, diffuse
interreflections etc.
>> I thought by physically correct you were talking about materials or
>> light propagation behavior, not every model being made of from polygons.
>
> No I made both statements: they are less physical correct and don't
> support all primitives of POV. Until both problems are solved it is not
> sensible to try to port POV to a GPU.
A path tracer sports physically correct rendering, with full light
transport phenomena and material settings according to physics equation.
If that can run on GPU, a simple raytracer with artistic parameters
can too.
> Why? I mean why a GPU especially? There is a lot going on and I don't
> see a reason to single out GPUs. I want my ray tracer to run as facst as
> possible, I don't really care on what hardware it is implemented, as
> long as it is affordable.
Because a GPU is damned fast for math calculations and if you're not a
gamer (only such application for it now) you don't use all that awesome
power at all despite being available in every PC.
>> I'm not talking about games at all.
>
> Good, me neither.
Then I think you just don't understand the matter.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
