On Thu, Mar 10, 2016 at 3:51 AM, benson chepkwony <bchepk...@att.net> wrote:

> Hi Costa,
> Are we suppose to be "Porting" these primitives the(RHC, ARB4, DSP,
> EXTRUDE etc) from its current rendering structure to OpenCL?
> Is there any compatible issues with moving these primitives to OpenCL?
> In order to "Port" these pimitives are we going to just "read in" their
> extensions to OpenCL?
>

I think I already gave you enough info so you can work on a patch. Rome
wasn't built on a day. You need to focus on an achievable task. Focus on
one primitive for now. I suggested one.

OpenCL is not C compatible so yes there will be issues porting the code
over. The syntax is C like but OpenCL is a language designed for parallel
programming in a SIMT fashion. I you want to know more about OpenCL you can
go to www.khronos.org. They have online an overview reference card of the
language so people already familiar with C and graphics programming can get
a quick start:
https://www.khronos.org/files/opencl-1-2-quick-reference-card.pdf.


> I was also looking at your "Milestone" on your logs and you wanted to
> implement HLBVH acceleration structure with the Bounding Volume Hierarchy
> to traverse the ray packets. Did you actually implemented this acceleration
> structure?
>

The HLBVH is in BRL-CAD SVN trunk. It is currently built on the CPU as a
pre-processing step, sent to the GPU, then the GPU traverses it during the
rendering passes.


> I wrote a Proposal too last year for GSoC that specifically targeted the
> Ray Packets coherency traversal as acceleration structures for performance
> improvement.
>

Ray packets is a technique which is commonly used with fixed width SIMD
architectures like x86-64 SSE or AVX. In a SIMT model the lane size can
vary. In practice this is what also happens with x86 hence the multiple
instruction standards to increase the lane size. 128-bit, 256-bit,
eventually 512-bit, etc. This article explains the concept differences
nicely:
http://yosefk.com/blog/simd-simt-smt-parallelism-in-nvidia-gpus.html


> I was also going to ask you about the OpenMP multithreading compiler
> support. How does this work?
>

It doesn't. It was a throw away prototype used in the process of producing
an OpenCL final prototype.


> which part of performance improvement were you targeting with the OpenMP
> multithreading?
> How does OpenCL platform working i.e do you have to install the OpenCL in
> your computer in order to run the current Ray Tracing? and is OpenCL going
> to be shipped with Brl-cad software?
>

This is a rather basic question to ask... The BRL-CAD OpenCL rendering mode
is optional and is to be activated only if people have OpenCL on their
computers. Rather like OpenGL it is either installed by the user or comes
with the OS install. The implementation may be in a GPU driver (AMD,
NVIDIA) or can be downloaded from one of the multi-core x86 CPU vendors
(AMD, Intel).

If you do not have prior OpenCL or CUDA programming experience you are
probably better off choosing some other project to work on right now. The
OpenCL language syntax itself is not that hard to learn for someone who
knows ANSI C well, but the parallel programming concepts can be challenging
to master and the development environment tools are still in their infancy.


> Thanks.
>
> From,
> Benson Chepkwony
>
>
>
> On 3/9/2016 4:05 PM, Vasco Alexandre da Silva Costa wrote:
>
> On Wed, Mar 9, 2016 at 4:52 AM, benson chepkwony < <bchepk...@att.net>
> bchepk...@att.net> wrote:
>
>> Hi Costa,
>> I just went through your logs. And its seems on your patch, you modified
>> Three files; EHY, ELL and ARB8. And in specific you worked on Elliptical
>> Hyperboloid, Ellipsoid and Polyhedron Algorithms.
>>
>
> Actually I worked on ARB8, ARS, BOT, EHY, ELL, SPH, REC, TOR, TGC.
>
>
>> Is there any work left to do on these Algorithms? or should we continued
>> optimizing these 'librt/primitives' files that you worked on?
>>
>
> Each of the primitives has a .cl and a .c file with the primitive
> implementation in OpenCL/C. IIRC the only primitive, of those I worked on,
> which is not feature complete is BOT (Bag Of Triangles). e.g. BOT in
> OpenCL/C does not have plate mode support yet. You could work on that or on
> implementing some other relevant primitive like ETO. ETO is a quartic kinda
> like TOR and the quartic solver has been ported to OpenCL already.
>
> You take a look at the BRL-CAD primitives here (I mentioned this before in
> this list):
> http://brlcad.org/w/images/5/52/MGED_Quick_Reference_Card.pdf
>
> You can submit your work as a patch in unified diff format (e.g. 'diff
> -Nurd').
>
> Did you just modified the Algorithms on this specific files or is this
>> more than just Algorithm modification?
>>
>> I am sure you did the profiling in the initial stages. And this should be
>> our starting point but since you have done it, do we have to profile again?
>> I am sure you had so many files to work with under 'librt/primitives'.
>>
>
> You should do accuracy tests for each primitive you implement similar to
> what I did in Week 10:
>
> http://brlcad.org/wiki/User:Vasco.costa/GSoC15/logs#Weeks_9-10_:_20_Jul-26_Jul.2C_27_Jul-2_Aug
> i.e. a pixdiff between the existing ANSI C primitive implementation and
> the OpenCL implementation.
>
> At this point performance profiling (e.g. timing tests) should be done
> with more complex models than a single primitive. When I started out I had
> to reimplement the whole rendering pipeline so some of those tests are more
> to test buffer writing performance than actual ray tracing algorithm
> performance.
>
> Regards,
> -Vasco Costa
>
>
>> From,
>> Benson Chepkwony
>>
>>
>>
>> On 3/8/2016 8:55 PM, Vasco Alexandre da Silva Costa wrote:
>>
>> On Tue, Mar 8, 2016 at 10:35 PM, benson chepkwony <bchepk...@att.net>
>> wrote:
>>
>>> Hay Costa,
>>> I am interested with this project titled "Ray tracing performance,
>>> coherent boolean evaluation". I understand you worked on this project last
>>> year, that is good. However, I was wondering if you could further elaborate
>>> what you did with the coherency and which area did your research reside in?
>>>
>>> I am not sure about this but since it is a continuation of your work, I
>>> am not sure if we have to apply and use the coherency Techniques that you
>>> applied?
>>>
>>> How is the Ray Tracing working out at this point? and what area need to
>>> be further research? Do we need to understand your code fully to work on
>>> this project?
>>>
>>> What files in the binary is this project located?
>>>
>>
>> Welcome aboard.
>> You can see the Blog of my activities last year if you are interested in
>> what I actually did.
>> http://brlcad.org/wiki/User:Vasco.costa/GSoC15/logs
>>
>> Basically what I did was a port of the basic ray tracing pipeline to an
>> OpenCL GPU environment. This includes numerous supported primitives. What
>> it doesn't support is boolean evaluation i.e. CSG (Constructive Solid
>> Geometry) operations. Anyone interested in working on the OpenCL ray tracer
>> should get familiar with the BRL-CAD code e.g. by making a patch to add
>> OpenCL acceleration to an existing primitive like 'eto'.
>>
>> Afterwards we can look at how the standard BRL-CAD rt pipeline does CSG
>> ops and how to achieve this in a GPU amenable fashion. For this I will you
>> give you pointers for where to start reading the code. But be prepared for
>> some rough sailing. I have a rough outline of how this can be done but you
>> guys need to get a feel for it and I want your own opinion on how to do it.
>> I already have mine. :-)
>>
>> Read all the e-mail correspondence I have had with Param Hanji <
>> <param.catchch...@gmail.com>param.catchch...@gmail.com> in this list.
>> Since both of you guys seem to be interested in the same subject:
>> https://sourceforge.net/p/brlcad/mailman/brlcad-devel/
>>
>> There is enough work here for two people but we need to figure out what
>> your strengths are, get you guys to understand the problems, so you can
>> figure out which approach or which part you want to work on. What I do not
>> know is how is the workshare allocation for GSoC this year.
>>
>> All the best,
>> -Vasco Costa
>>
>>
>>
>>> Thank you.
>>>
>>> From,
>>> Benson Chepkwony
>>>
>>
>>
>>
>> --
>> Vasco Alexandre da Silva Costa
>> PhD in Computer Engineering (Computer Graphics)
>> Instituto Superior Técnico/University of Lisbon, Portugal
>>
>>
>>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>
>
>


-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to