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.
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 have been familiarizing myself with OpenCL and I have a few questions.
Are we targeting the GPU on this project?
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?
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
<mailto: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 <http://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 <mailto: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 <mailto: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
<mailto: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
