> On 11 Aug 2017, at 00:20, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com> wrote:
>
> On Thu, Aug 10, 2017 at 11:36 PM, Marco Domingues <marcodomingue...@gmail.com
> <mailto:marcodomingue...@gmail.com>> wrote:
> Hi,
>
> Thanks for reviewing my code and making the adjustments, Vasco! I’ve
> integrated the changes in my patch.
>
> I’ve finished the port of the new bool_eval() function to OpenCL, and
> although the improved performance, it wasn’t enough to outperform the ANSI C
> code with the Release build.
>
> For the havoc scene, I got 1.56sec now vs 2.10sec before, when running the
> OpenCL code on my GPU. (command ‘rt -z1 -l5 -s1024’). For reference, the same
> scene renders in 0.63sec with the ANSI C code currently in the trunk.
>
> Despite that, when I ran the OpenCL code in my CPU, I got 0.64sec now vs
> 2.79sec before. (command ‘rt -z1 -l5 -s1024’).
>
> So let me get this straight. The OpenCL backend is slower in your GPU than
> the CPU based trunk/ ANSI C backend. That's not totally unexpected. You have
> a consumer GPU with nerfed DP FP.
Yes that is right.
>
> What I want you to do tomorrow is to compare the trunk/ ANSI C backend with
> the OpenCL backend over your CPU with the AMD and Intel OpenCL
> implementations. I also want you to time the results with the single-hit mode
> if you have the time for that.
>
> Why are the 'rt -s1024' times in your July 27 post different from the times
> in your August 7 post?
At the time I was running the ‘rt -s1024’ over a Debug build, and also running
it with the ANSI C code from the OpenCL branch, that used the rpn tree
representation, which is considerable slower than running the code with a
Release build and with the bool_eval() function currently in the trunk.
>
> I am a little intrigued with this, because smaller scenes like the
> operators.g are clearly faster when using the GPU, (0.06 sec gpu vs 0.16sec
> cpu). Any explanation?
>
> Those scenes are fillrate limited with little depth or scene complexity.
>
> Other thing that caught my attention was how close the lines RTFM and
> wallclock from the ‘rt’ output are when running the OpenCL code in the CPU,
> compared with the same lines from running the OpenCL code in the GPU. (i.e
> 0.60 and 0.65 sec - cpu vs 0.32 and 1.65 sec - gpu).
> Couldn’t the big difference on the GPU side be caused from transfers between
> CPU-GPU and not by performing ray-intersections, boolean evaluation and
> shading operations? Is there a way to investigate this?
>
> The best way is to use a profiler like the ones I mentioned before.
> Alternatively one can time the transfers vs the computations by timing the
> appropriate CL calls making sure to clFinish() the queue before you measure
> the time.
>
> Tomorrow I will update the previous tables that I shared before on my
> document, now using Release builds. And will also include side by side image
> comparisons between the ANCI C and OpenCL results, for each scene.
>
> Ok. Make sure to try with both the AMD and Intel OpenCL SDKs over the CPU.
> I'm not interested in your GPU results right now as it would only complicate
> the comparison.
Okay, from now on I will run the OpenCL code on my CPU! Most of the previous
times in my tables were using the GPU. Sorry about that.
Cheers!
Marco
>
> Regards,
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
