﻿<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="ja">
	<id>https://wiki.blender.jp/index.php?action=history&amp;feed=atom&amp;title=%E5%88%A9%E7%94%A8%E8%80%85%3ALukasstockner97%2FGSoC_2016%2FWeekly_Reports%2FWeek_5</id>
	<title>利用者:Lukasstockner97/GSoC 2016/Weekly Reports/Week 5 - 版の履歴</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.blender.jp/index.php?action=history&amp;feed=atom&amp;title=%E5%88%A9%E7%94%A8%E8%80%85%3ALukasstockner97%2FGSoC_2016%2FWeekly_Reports%2FWeek_5"/>
	<link rel="alternate" type="text/html" href="https://wiki.blender.jp/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Lukasstockner97/GSoC_2016/Weekly_Reports/Week_5&amp;action=history"/>
	<updated>2026-10-26T01:39:29Z</updated>
	<subtitle>このウィキのこのページに関する変更履歴</subtitle>
	<generator>MediaWiki 1.31.0</generator>
	<entry>
		<id>https://wiki.blender.jp/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Lukasstockner97/GSoC_2016/Weekly_Reports/Week_5&amp;diff=152025&amp;oldid=prev</id>
		<title>Yamyam: 1版 をインポートしました</title>
		<link rel="alternate" type="text/html" href="https://wiki.blender.jp/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Lukasstockner97/GSoC_2016/Weekly_Reports/Week_5&amp;diff=152025&amp;oldid=prev"/>
		<updated>2018-06-28T21:20:52Z</updated>

		<summary type="html">&lt;p&gt;1版 をインポートしました&lt;/p&gt;
&lt;table class=&quot;diff diff-contentalign-left&quot; data-mw=&quot;interface&quot;&gt;
				&lt;tr class=&quot;diff-title&quot; lang=&quot;ja&quot;&gt;
				&lt;td colspan=&quot;1&quot; style=&quot;background-color: #fff; color: #222; text-align: center;&quot;&gt;← 古い版&lt;/td&gt;
				&lt;td colspan=&quot;1&quot; style=&quot;background-color: #fff; color: #222; text-align: center;&quot;&gt;2018年6月28日 (木) 21:20時点における版&lt;/td&gt;
				&lt;/tr&gt;&lt;tr&gt;&lt;td colspan=&quot;2&quot; class=&quot;diff-notice&quot; lang=&quot;ja&quot;&gt;&lt;div class=&quot;mw-diff-empty&quot;&gt;(相違点なし)&lt;/div&gt;
&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;</summary>
		<author><name>Yamyam</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.blender.jp/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Lukasstockner97/GSoC_2016/Weekly_Reports/Week_5&amp;diff=152024&amp;oldid=prev</id>
		<title>wiki&gt;Lukasstockner97: Created page with &quot;Hi!  This week, I finished the GPU denoising kernels - it turned out to be bit more work than I expected since I planned to use a different strategy for the seamless filtering th...&quot;</title>
		<link rel="alternate" type="text/html" href="https://wiki.blender.jp/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Lukasstockner97/GSoC_2016/Weekly_Reports/Week_5&amp;diff=152024&amp;oldid=prev"/>
		<updated>2016-08-01T14:01:40Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;Hi!  This week, I finished the GPU denoising kernels - it turned out to be bit more work than I expected since I planned to use a different strategy for the seamless filtering th...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;新規ページ&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Hi!&lt;br /&gt;
&lt;br /&gt;
This week, I finished the GPU denoising kernels - it turned out to be bit more work than I expected since I planned to use a different strategy for the seamless filtering there: On the CPU, tiles are denoised when their neighbors have been rendered. However, on GPUs, that approach has multiple problems: Tiles tend to be much larger and memory usage tends to be a major problem, so having 10 or more 256x256 tiles with 30 or more channels in memory isn&amp;#039;t exactly great. Also, that would cause problems on Multi-GPU systems where neighbor tiles might be on different cards.&lt;br /&gt;
Therefore, on GPUs a different approach is used: Instead of getting the pixels around the border from other tiles, each tile is internally rendered a bit bigger and only the pixels that will be visible in the end are filtered. Since the tiles are pretty large, the performance impact isn&amp;#039;t that big: For 256x256 tiles at default settings, Cycles will render internally with 272x272 tiles, a 13% increase in pixels - not great, but the best option available as far as I can see.&lt;br /&gt;
Therefore, I modified the RenderBuffer and RenderResult sync code to deal with &amp;quot;overscan&amp;quot;, as I called it for now. With that in place, the CUDA kernels were fairly easy to add.&lt;br /&gt;
&lt;br /&gt;
Next, I started working on the option to re-denoise after rendering is completed. Since I wanted a clean and flexible solution, I added a general &amp;quot;postprocess&amp;quot; option to the External Render API that comes with a poll function that checks whether a particular RenderResult can be post-processed, and a function that actually does the post-processing. These are then used by a operator that&amp;#039;s called by a button in the image editor.&lt;br /&gt;
From the Cycles side, the polling function already works, but the actual processing isn&amp;#039;t implemented yet. Therefore, the button doesn&amp;#039;t do anything yet. The reason for that is that I&amp;#039;m not sure how to implement it in the Session handling in Cycles: It could be added in as a third option, similar to how baking exists next to rendering. However, that isn&amp;#039;t really great: Rendering and baking share most of the syncing code, only the final details (which device tasks are executed) are really different. For denoising, however, the situation is a lot different: All that&amp;#039;s needed is 1. create a RenderBuffer from the existing result, 2. get tiles from the tile manager, 3. call the device to denoise them (no two-stage processing or overscan needed since the image is fully rendered to begin with), 4. write the result back. Therefore, the second option would be to add a simpler DenoisingSession, but that&amp;#039;s not really nice either from a code design point of view...&lt;br /&gt;
&lt;br /&gt;
So, from a user perspective, not too much changed in the branch: I added a currently useless button, but at least GPU denoising works now - or at least should.&lt;br /&gt;
&lt;br /&gt;
Next to the denoiser work, I also did some work on other Cycles topics:&lt;br /&gt;
* Bug fixing: I fixed T48691, T48698 and a few unreported bugs:&lt;br /&gt;
** Building the Cycles CUDA kernels at runtime failed due to a new file missing from CMake (dfa7ddd)&lt;br /&gt;
** Cycles crashed when using an environment texture with OSL (73cfbb0)&lt;br /&gt;
** The anisotropic BSDF failed with OSL because the automatically inserted Convert node was connected wrongly due to a missing entry in the Socket Type -&amp;gt; Name mapping (9bce807)&lt;br /&gt;
* Multi-Scattering GGX closures (D2002): Finally in master (23c2768)! I implemented the OSL bindings, fixed a few remaining numerical issues etc. Thanks to Brecht and Thomas for the review and suggestions! Next up is the Metallic BSDF based on the same paper (D2003) &lt;br /&gt;
&lt;br /&gt;
Oh, and sorry for not providing any more test renders yet - I somehow overlooked the mail until now, and previously I didn&amp;#039;t think that it makes too much sense yet because the filter is still buggy. Also, over the weekends I&amp;#039;m usually on my laptop, which means that every larger render takes a few hours... I&amp;#039;ll render a few as soon as I&amp;#039;m back on the decent PC, though.&lt;br /&gt;
&lt;br /&gt;
Lukas&lt;/div&gt;</summary>
		<author><name>wiki&gt;Lukasstockner97</name></author>
		
	</entry>
</feed>