On Sun, Mar 13, 2016 at 2:23 AM, benson chepkwony <bchepk...@att.net> wrote:
> HI Costa,
> I have performed mid-level programming on concurrency, threading and
> parallelism. With pThreads, OpenMP and Java threading. However I am new to
> OpenCL.
>
> OpenCL requires similar threading techniques if I am not wrong.
>
Not really. I guess you did not read the article about SIMT I linked to.
> And I was going to ask you, if tuning the application or C/C++ code into a
> parallel code is important? by that, I mean conducting; optimization,
> eliminating dependency(i.e True, Anti, ..), Loops transformation, Data
> transformation, Aliasing issues, Anti-aliasing etc.
>
> Is there a specific Target area you should identify in your code? that
> needs to be implemented for OpenCL platform. Such as an Algorithm, Loops,
> functions, input/output readers etc. And how do you determine this
> particular Target area?
>
I am not going to teach you how to program in OpenCL. Or the differences
between C and OpenCL. It's expected that you learn that by yourself. I even
provided you with some links to resources on the topic which you seem to
have ignored...
> I have been familiarizing myself with OpenCL and I have a few questions.
> Are we targeting the GPU on this project?
>
The targets are GPUs and multi-core CPUs. So yes.
> Are we therefore conducting GPU programming with OpenCL?
>
> I was wondering if this is the OpenCL procedure, that we should follow on
> this project.
> - There a two kinds of OpenCL process:
> Kernel Code program
> Host Code program
>
> - OpenCL Host Program Procedure:
> Define platform and Queues
> Define Memory objects
> Create the program
> Build the program
> Create and setup kernel
> Execute the kernel
> Read results back to the host
>
> So here our biggest task is identifying routines, functions, algorithms
> and loops on Brl-cad Primitives i.e ETO that needs to be implemented and
> modified to performs its work/task under OpenCL Platform? Then identifying
> OpenCL Memory Objects, Work-Items, etc.
>
> How do you identify these primitives`s functions and algorithms?
>
That's supposed to be your job... i.e. read the BRL-CAD code and understand
it. I'm only here to provide you with pointers and guide you along the way.
> And for this project we are looking for Work-Items and Work-Groups in
> primitives c codes that can be computed concurrently under OpenCL GPU
> Platform.
>
> Thanks.
>
> From,
> Benson Chepkwony
>
>
>
>
>
> On 3/10/2016 12:10 PM, Vasco Alexandre da Silva Costa wrote:
>
> On Thu, Mar 10, 2016 at 3:51 AM, benson chepkwony < <bchepk...@att.net>
> 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>
>> 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>
>>> 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
>
>
>
--
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
