> On 21 Jul 2017, at 21:20, Vasco Alexandre da Silva Costa
> <vasco.co...@gmail.com> wrote:
>
> On Fri, Jul 21, 2017 at 6:41 PM, Marco Domingues <marcodomingue...@gmail.com
> <mailto:marcodomingue...@gmail.com>> wrote:
> Hi,
>
> There is still the issue with the materials, that I can look into next.
>
> Right. I made a simple port of the Phong shader from
> 'liboptical/sh_plastic.c' and added basic material support to opencl librt.
> However this was done near the end of the code period and it was never 100%
> tested. It has issues with regions and getting the correct materials. Since
> this was dependent on the CSG regions code I left finishing this for later.
>
> Are you sure it is computing the surface normals correctly? Try to compare
> the output with CSG enabled while rendering 'operators.g' in "Diffuse
> Normals" mode vs the ANSI C code. You might have to change shade_segs() in
> 'rt.cl <http://rt.cl/>' to get this to work.
Hm I will try to replicate that lighting model and see what it looks like!
>
> Complex scenes like the havoc.g and the goliath.g, are still taking too much
> time to render, which I believe comes from the operation of building the
> regiontable (commenting the
>
> Ok but how long is "too much time"? Also how long does the ANSI C code take
> to render the same scene?
Well, the ‘rt -z1 -l5’ command takes 8,103 seconds for the havoc.g scene when
rendering with the GPU, and this same scene renders in 0,558 seconds when using
the ANSI C code. Despite that, when I comment the call to the
‘build_regiontable’ function, the OpenCl code only takes 0,14 seconds. So the
process of building the regiontable, evaluating partitions and resolving
overlaps is causing a major bottleneck for this scene.
The operators.g scene takes 0,027 seconds when using the ‘rt -z1 -l5’ command,
and 0,054 when using the ‘rt’ command.
>
> function call results in huge differences in execution times), so I think we
> should look into an alternative to build the regiontable. Right now, to build
> the regiontable I iterate over all the segments in the partition, and then
> over the regions to test if the segment bits are in the boolean tree of the
> region. Perhaps this process could be optimised if the segments had the
> ‘soltab’ structure, and the respective information on the regions involved
> for that segment.
>
> I'll try to read the OpenCL CSG implementation source code this weekend to
> compare it in terms of complexity to the ANSI C source code to see if I can
> spot major differences.
>
> But I will gather some statistics for these scenes like execution times,
> total memory allocated, max segments per partition, max regions involved per
> partition and maybe we will have some other clues of possible optimisations
> to make on the code!
>
> Yes, we also need to measure the time it spends on each of the kernels for a
> given scene at the very least. This would be a good time for you to learn how
> to use a profiler:
> http://gpuopen.com/compute-product/codexl/
> <http://gpuopen.com/compute-product/codexl/>
>
> AMD's CodeXL should be able to profile both CPU and GPU binaries and tell you
> much time is spent on each function/kernel and the number of cache misses,
> etc.
>
> There is also the NVIDIA Visual Profiler:
> https://stackoverflow.com/questions/29068229/is-there-a-way-to-profile-an-opencl-or-a-pyopencl-program
>
> <https://stackoverflow.com/questions/29068229/is-there-a-way-to-profile-an-opencl-or-a-pyopencl-program>
>
> But it is like they purposefully nerfed it for OpenCL code. So you are
> probably better off with AMD's CodeXL.
>
> I think you are using a CPU based OpenCL implementation in Linux right? You
> should also be able to use the OProfile and KCacheGrind tools in case you
> have issues with CodeXL.
>
> Regards,
Thanks for sharing, I will take a look into these tools and will create a
document with some more detailed measurements for the scenes in the ‘share/db’
directory!
Cheers!
>
> --
> 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
