> Hmm okay, I was using the elapsed time… I will update the tables considering
> this new information!
> So this was the timing block output from the command ‘rt -z1 -l5 -s1024’ for
> the havoc scene:
>
> <Screen Shot 2017-07-30 at 19.52.52.png>
That screenshot's timings clearly have some issue(s) that give pause. At a
glance, I’m not sure what those numbers are saying other than there’s a huge
chunk of time introduced somewhere outside the ray intersection testing.
If the 0.55s RTFM number can be trusted and the rays/sec on that line is 0
simply because it’s not yet tracking the number of rays from the OpenCL side,
then that SHOULD represent time spent in ray traversal, intersection testing,
boolean evaluation, and shading. That is, it’s the most important number for
your project.
What is really curious is the "SHOT:" line that says it spent 2.18s of cpu time
and 2.54s elapsed. The elapsed time SHOULD be nearly identical to the RTFM
number, at least for sunk data. This discrepancy could be OpenGL inefficiency.
Add -o /dev/null to sink the image, so we’re not timing how long it takes to
draw pixels in the window. If the wallclock elapsed time is still hight, that
would indicate a problem somewhere. If it drops to 0.55, that’ll be good.
> If the RTFM line is the important line, I think the time displayed is quite
> good actually, compared with the elapsed time I was using before. But I am
> curious about the meaning of the 3rd and 4th line, since they seem to be the
> reason for the long times when rendering the scenes.
The third line is cpu time (man time), i.e., the number of clock ticks across
all CPUs. Generally, cputime is wallclock times your number of threads. At
least, it would be if you had perfect scaling efficiency, which is rare. The
wallclock line is everything including application startup cost, prep,
releasing memory, etc.
Cheers!
Sean
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
