On Fri, Jul 21, 2017 at 6:41 PM, Marco Domingues <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' to get this to work.
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?
> 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/
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
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,
--
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
