<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
regarding the overall layout, there is a Wiki article
(<a class="moz-txt-link-freetext" href="https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout">https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/SourceLayout</a>)
but it doesn't really say much, so here's my attempt on an overview:<br>
<br>
Overall, Cycles can be divided into four layers:<br>
- Kernel code - the computations that are executed on the chosen
device, doing the actual rendering<br>
- Device code - handles memory management and is able to execute
tasks on the different compute devices by calling the kernel<br>
- "Host" code - handles data synchronization to the device and
control flow during rendering, exposes an API<br>
- Blender code - Glue logic between Blender and Cycles, synchronizes
data from Blender into the Cycles-specific formats<br>
Of those four, the first three are independent of Blender and also
used in e.g. the standalone renderer.<br>
<br>
When you hit F12, Blender internally starts a rendering job (not
going into details here). Effectively, it ends up calling functions
in the Cycles addon (blender/addon/, all paths relative to
intern/cycles/). These in turn call the Cycles Python API (as
defined in blender/blender_python.cpp), which wraps the
BlenderSession (in blender/blender_session.cpp).<br>
<br>
This Blender session allocates a Cycles Session (render/session.cpp)
and Scene (render/scene.cpp) and then fills the Cycles-internal
scene representation (consisting of Shaders, Meshes, Lights etc.,
all defined in render/ and part of the Scene class) from
Blender-internal data through the code in BlenderSync
(blender/blender_sync.cpp).<br>
<br>
Then, it calls the Session to start the rendering. The Session in
turn calls the internal Scene synchronization, which then loops over
all the components of a Scene and calls their device_update
functions, which are responsible for converting the internal host
representation into the format that the kernel expects. Once that is
done, it divides the image into tiles (render/tile.cpp) and then
starts a DeviceTask (device/device_task.cpp) for rendering.<br>
<br>
The device (device/device_{cpu, cuda, opencl, multi}.cpp) then calls
the acquire_tile callback of the task, which makes the Session
return tiles to render. Then, it calls the rendering kernel for that
particular device until the tile is finished, and goes back to
acquiring another tile until they're all rendered.<br>
<br>
In the kernel, most of the code is shared between devices, which
means that we can only use the common subset of C++, CUDA and OpenCL
(which is generally the limiting factor). To archieve this, whenever
any language needs a particular keyword, a ccl_ keyword is defined.
Then, for each of the three languages, these ccl_keywords are
#defined to the proper keywords in
kernel/kernel_compat_<device>.h. For example, CUDA requires
each function that's supposed to be executed on the GPU to be
prefixed by __device__. Therefore, we have the ccl_device keyword,
which gets #defined to __device__ for CUDA and to nothing for CPU
and OpenCL. This is all there is to the "cycles compute language" -
it's essentially just a bunch of defines that allows to write code
that compiles in all three languages.<br>
<br>
As a result, for many changes you can completely ignore the fact
that your code will also be compiled on GPUs. The main downside is
that it completely screws up code completion in most IDEs.<br>
Also, here's the wiki article on the kernel language (a bit outdated
unfortunately):
<a class="moz-txt-link-freetext" href="https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel">https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Kernel</a><br>
<br>
Generally, to get an overview of the control flow, I'd recommend
looking at:<br>
- BlenderSession::create_session, BlenderSession::reset_session,
BlenderSession::render<br>
- BlenderSync in general<br>
- Session::run_cpu<br>
- Scene::device_update<br>
- CPUDevice::thread_render<br>
- Session::acquire_tile<br>
- kernel_path_trace<br>
<br>
And ultimately, the best approach for figuring out control flow of
course always is searching and a debugger.<br>
<br>
Hope this helps :)<br>
<br>
- Lukas<br>
<br>
<div class="moz-cite-prefix">On 11.02.2018 13:09, Bob Geller wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAQqdsctAbrXwopxuHTGe3tgj3E9+Yj4x5L1wCXb4dHLeugvWg@mail.gmail.com">
<div dir="ltr">Hi,
<div><br>
</div>
<div>My name is Bob and I'm trying to get into cycles
development to hopefully contribute in the future. Is there
any documentation to understand the system better and
especially understand the flow of control in the renderer?
Also, I'm struggling to find enough info about cycles kernel
development and the cycles compute language. I would
appreciate if someone can point me in the right direction to
help understand this better. Thank you for your time and sorry
for mailing the whole group, I wasn't sure who to contact. </div>
<div><br>
</div>
<div>Regards,</div>
<div>Bob</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</body>
</html>