kalle.last@[EMAIL PROTECTED]
wrote:
> Dr Jon D Harrop kirjutas:
> > That's for 10x fewer triangles though?
>
> Want to bet that adding 10x triangles won't bring performance down
> nearly as much as with rasterizing? I would expect around 1.5-3x
> performance decrease with adding 10x more triangles to a scene.
It isn't very compelling for you to claim that real time ray tracers
can handle 1M triangle scenes with ease, then point to a 100k tri
benchmark and then speculate that the ray tracer would only be
"1.5-3x" slower. We need code and measurements! :-)
I can render the 200k tri dragon full screen with 4xFSAA at 15fps now,
still on an 800MHz laptop...
> > You want to cripple OpenGL to make the comparison fair? You'll be
> > comparing TBP's C++ with an OCaml newbie's code next... ;-)
>
> As I asked, are we debating over SW/HW implementation speeds or
> algorithmic efficiency?
I want to know if real time ray tracing can compete with rasterising
on modern consumer hardware, e.g. if we were to write a game now,
would be it worth considering ray tracing?
> Currently you are trying to compare HW accelerated rasterizing vs
software ray tracing. Is it fair?
The vast majority of current computers have hardware rasterisation but
little in the way of hardware ray tracing.
> If you want to compare HW then perhaps you should compare dRPU8 vs any
> GPU you like:
> http://graphics.cs.uni-sb.de/SaarCOR/
-> Publications -> "SaarCOR - A
> Hardware-Architecture for Realtime Ray Tracing "
The same arguments apply to DEC Alpha vs x86. I'm really interested in
learning about the practical trade-offs. Of course, if nVidia
announced serious hardware accelerated ray tracing in a future GPU,
that would change everything.
> > I just implemented completely naive geometric shadows in ~90LOC and
> > I'm getting 10fps on my laptop at 1600x900. My current algorithm is
> > using dynamic data structures (mainly lists) that get completely
> > regenerated every frame. I'll optimise it by changing to static data
> > structures and incremental updates.
>
> Please upload your code somewhere so I could test it on my PC too.
I'll put it on the web page when I get back home.
> > Gallium Arsenide is the semiconductor of the future. It always has
> > been and it always will be.
>
> Say what?
Ray tracing has been the future of rendering since I can remember.
>From my point of view, it looks like ray tracing (like GaAs, fusion
reactors, ...) will always be a thing of the future.
> Also please read that dynRPU thingie and compare the transistor counts
> and especially needed memory bandwidth to current GPU's.
I don't doubt it. But I have a GF7900GT, not a dynRPU.
> > > Even better would be some speed
> > > comparisons with shadows turned on and off.
> >
> > Currently 1600fps without shadows and 10fps with. :-)
>
> I can run glxgears at 10k FPS too. FPS that high only shows you don't
> really benchmark anything ;)
Absolutely.
> > Because they can't afford to trace much more than 1 primary and 1
> > shadow per pixel.
>
> Who sais you have to trace packets per pixel? Just read this paper:
> http://www.sci.utah.edu/~wald/Publications/2007///BVH/download//
> togbvh.pdf
> They say tracing 16x16 ray packets is rather efficient, even for
> secondary and shadow rays.
Sounds like a step towards rasterising for primaries to me. They're
exploiting exactly the same coherence.
> > > > The screenshot on that page is about as compelling as Jacco's
grainy bunny.
> > >
> > > You didn't run the latest demo, did you?
> >
> > Not yet (no Windows here).
>
> It wors quite nicely through Wine. I don't have Windows installed
> either. It shouldn't loose too much performance. Only thing is that
> SSE2 is required. Without it, it won't work.
I don't have Wine on here (does it work from 64-bit?).
> > The OCaml code was written by a newbie!
>
> Somehow I doubt you can create much better code but feel free to prove
> me wrong.
I already did. My original OCaml ray tracer was much faster (60%
slower than C++) and I posted several major rewrites of his code, e.g.
to completely avoid OOP.
> Also don't forget to post it to ompf, it would make an
> interesting discussion subject.
I thought I already had. I certainly posted to the caml-list (fa.caml
newsgroup).
Cheers,
Jon.


|