Automatically calculate the best tile size for the fastest render #36785

New Issue

Greg Zaal · 2013-09-20T15:46:04+02:00

Greg Zaal commented

2013-09-20 15:46:04 +02:00

Project: Blender Extensions
Tracker: Py Scripts Upload
Blender: 2.66
Category: Render
Python: 3.2
Homepage: http://adaptivesamples.com/2013/09/11/auto-tile-size-addon/
Script name: Auto Tile Sizes
Wiki page: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Auto_Tile_Size
Author(s): Greg Zaal
Status: Open

%%%Info:
This addon gives you some quick controls to get the best possible tile sizes for the fastest possible Cycles render. Usually it's a good idea to stick to powers of 2 (16, 64, 256...) to get fast renders, however in the case of tile sizes it's even more important to keep the tiles fairly square and of consistent size. Having some tiles smaller than the rest due to the borders of the image makes for longer renders.

So this addon allows you to choose a target size and then automatically calculates the actual tile dimensions to ensure squareness and consistency.

As a rule of thumb, GPUs like bigger tiles (256 x 256 usually) and CPUs like smaller ones (often 32 square), thus the two target values are stored separately in case you switch between then often. Just remember to hit the Set button!

For a detailed explanation of this reasoning, see this blog post: http://adaptivesamples.com/2013/09/11/auto-tile-size-addon/

Usage:
At the bottom of the Performance Panel of the render settings are the target tile sizes.

Pick one and hit the Set button to calculate the closest pair of fairly-square dimensions (E.g. for 1080p it's 240x270, 8x4 tiles)

If for some reason you want to set the tile size to exactly the target, resulting in perfectly square tiles but probably not consistent ones, disable Factors Only%%%

**Project**: Blender Extensions **Tracker**: Py Scripts Upload **Blender**: 2.66 **Category**: Render **Python**: 3.2 **Homepage**: http://adaptivesamples.com/2013/09/11/auto-tile-size-addon/ **Script name**: Auto Tile Sizes **Wiki page**: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Auto_Tile_Size **Author(s)**: Greg Zaal **Status**: Open %%%Info: This addon gives you some quick controls to get the best possible tile sizes for the fastest possible Cycles render. Usually it's a good idea to stick to powers of 2 (16, 64, 256...) to get fast renders, however in the case of tile sizes it's even more important to keep the tiles fairly square and of consistent size. Having some tiles smaller than the rest due to the borders of the image makes for longer renders. So this addon allows you to choose a target size and then automatically calculates the actual tile dimensions to ensure squareness and consistency. As a rule of thumb, GPUs like bigger tiles (256 x 256 usually) and CPUs like smaller ones (often 32 square), thus the two target values are stored separately in case you switch between then often. Just remember to hit the Set button! For a detailed explanation of this reasoning, see this blog post: http://adaptivesamples.com/2013/09/11/auto-tile-size-addon/ Usage: At the bottom of the Performance Panel of the render settings are the target tile sizes. Pick one and hit the Set button to calculate the closest pair of fairly-square dimensions (E.g. for 1080p it's 240x270, 8x4 tiles) If for some reason you want to set the tile size to exactly the target, resulting in perfectly square tiles but probably not consistent ones, disable Factors Only%%%

Greg Zaal commented

2013-09-20 15:46:04 +02:00

Changed status to: 'Open'

Greg Zaal commented

2013-09-29 11:05:57 +02:00

%%%v2.0 changes:
Removed 'Set' button - tile size is automatically updated when changing target, render size or tile size (to manually change tile size, disable Auto Tile Size)
Improved accuracy for small tile sizes (result from 16 wasn't so different from 32)%%%

%%%v2.0 changes: Removed 'Set' button - tile size is automatically updated when changing target, render size or tile size (to manually change tile size, disable Auto Tile Size) Improved accuracy for small tile sizes (result from 16 wasn't so different from 32)%%%

Greg Zaal commented

2013-09-29 13:02:11 +02:00

%%%Fixed silly error after removing some debugging code, line 75 error.%%%

Greg Zaal commented

2013-11-05 18:45:14 +01:00

%%%Added support for Blender Render (BI) and made sure it wouldn't screw with any other renderers. Also tweaked UI.%%%

David Black commented

2014-10-04 14:21:51 +02:00

Added subscriber: @david_black

David Black commented

2014-10-04 14:21:51 +02:00

Hi Greg,

Is there a way to get your script to automatically load with recent Blender versions? Presently, auto_tile_size_release_03.py is always disabled in user prefs whenever Blender is started. Tried 2.69, 2,70a and 2.72.

Tried saving user prefs, start-up file, Auto Run Python Scripts (enabled/(default) disabled), saving a regular .blend file and lastly (as an inexperienced coder this should give you a smile if nothing else :) ) changing Blender version in script.

In case helpful, other scripts are loading okay at Blender start.

You've done a great job with the script, think it should be integrated into Blender, especially so with upcoming Cycles as default render engine.
Thank you for your time,

David

Hi Greg, Is there a way to get your script to automatically load with recent Blender versions? Presently, auto_tile_size_release_03.py is always disabled in user prefs whenever Blender is started. Tried 2.69, 2,70a and 2.72. Tried saving user prefs, start-up file, Auto Run Python Scripts (enabled/(default) disabled), saving a regular .blend file and lastly (as an inexperienced coder this should give you a smile if nothing else :) ) changing Blender version in script. In case helpful, other scripts are loading okay at Blender start. You've done a great job with the script, think it should be integrated into Blender, especially so with upcoming Cycles as default render engine. Thank you for your time, David

David Black commented

2014-10-04 14:24:44 +02:00

Just to clarify, meant 'me' as an inexperienced coder.

Greg Zaal commented

2014-10-04 14:44:22 +02:00

Hi David, glad it's helpful!

It loads just fine here if I save the user prefs. What OS are you on? I've tested on both Windows and Linux (both 64 bit)

I'll check with some folks about getting it included in blender, thanks :)

Hi David, glad it's helpful! It loads just fine here if I save the user prefs. What OS are you on? I've tested on both Windows and Linux (both 64 bit) I'll check with some folks about getting it included in blender, thanks :)

David Black commented

2014-10-04 15:18:54 +02:00

Thanks Greg for your quick reply,

Windows 7 x64

Maybe caused by the fact I do not use install versions, always zip download versions each with their own 'config' folder. Run several versions of Blender depending on needs. Although, as previously mentioned, other scripts (placed in scripts\addons) are starting?

Forgot to mention, even tried removing the script from scripts\addons and installing the script through user prefs Addons.

Thanks Greg for your quick reply, Windows 7 x64 Maybe caused by the fact I do not use install versions, always zip download versions each with their own 'config' folder. Run several versions of Blender depending on needs. Although, as previously mentioned, other scripts (placed in scripts\addons) are starting? Forgot to mention, even tried removing the script from scripts\addons and installing the script through user prefs Addons.

Greg Zaal commented

2014-10-04 15:34:28 +02:00

Try removing the addon, and put it in C:\Users<username>\AppData\Roaming\Blender Foundation\Blender\2.72\Scripts\Addons (or something like that...)

If that doesn't help, check if any errors are printed in the console (from the Window menu, Toggle System Console)

Try removing the addon, and put it in C:\Users\<username>\AppData\Roaming\Blender Foundation\Blender\2.72\Scripts\Addons (or something like that...) If that doesn't help, check if any errors are printed in the console (from the Window menu, Toggle System Console)

David Black commented

2014-10-04 15:55:34 +02:00

Tried with 2.70a

Removed local 'config' folder

Started Blender

From user prefs installed auto_tile_size_release_03.py, (installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons)

With addon enabled, saved fresh userpref.blend and startup.blend (in AppData\Roaming|Blender Foundation\Blender\2.70\config)

Same result

Tried with 2.70a Removed local 'config' folder Started Blender From user prefs installed auto_tile_size_release_03.py, (installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons) With addon enabled, saved fresh userpref.blend and startup.blend (in AppData\Roaming|Blender Foundation\Blender\2.70\config) Same result

Greg Zaal commented

2014-10-04 16:02:46 +02:00

Well if there's nothing printed to the console, then I've run out of ideas. Perhaps report a bug, but make sure to mention that it works just fine for me (win7 64 bit as well) and may not be a problem in the addon.

David Black commented

2014-10-04 16:16:51 +02:00

Oops! forgot to check the console. Several errors listed

Screen capture

Update:

Installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons it then works.

Any idea why this particular script will not not start locally?

Thank you again for your time

Oops! forgot to check the console. Several errors listed Screen capture ![System_Console_errors.png](https://archive.blender.org/developer/F114757/System_Console_errors.png) Update: Installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons it then works. Any idea why this particular script will not not start locally? Thank you again for your time

David Black commented

2014-10-04 16:23:45 +02:00

This comment was removed by @david_black

*This comment was removed by @david_black*

David Black commented

2014-10-04 16:27:15 +02:00

This comment was removed by @david_black

*This comment was removed by @david_black*

Greg Zaal commented

2014-10-04 16:34:00 +02:00

So it's loading on start-up fine now?

Looks like the problem might have just been because you had it installed in two different places. But might be something more obscure like it loaded the auto-tile-size add-on before it loaded the cycles add-on, thus the performance panel didn't exists yet and it failed to load.

So it's loading on start-up fine now? Looks like the problem might have just been because you had it installed in two different places. But might be something more obscure like it loaded the auto-tile-size add-on before it loaded the cycles add-on, thus the performance panel didn't exists yet and it failed to load.

David Black commented

2014-10-04 16:40:43 +02:00

After further tests

Script starts installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons

Script is disabled with previous console errors when installed in local Blender scripts\addons folder

Updated previous screen capture and posts to help improve readability

After further tests Script starts installed in AppData\Roaming|Blender Foundation\Blender\2.70\scripts\addons Script is disabled with previous console errors when installed in local Blender scripts\addons folder Updated previous screen capture and posts to help improve readability

Greg Zaal commented

2014-10-04 16:55:55 +02:00

Ok good. Probably caused by Cycles loading after this add-on then. I think the AppData... path is where installed scripts are supposed to go, and those in the local blender scripts folder are those that come bundled with blender by default. Thanks for checking!

David Black commented

2014-10-04 17:06:57 +02:00

Interesting, thank you for the information. Reason I keep the few extra scripts I use locally, so Blender can be used as a portable app on other computers without the need to update anything. Also easy to compare different Blender and script versions.

Other than using Appdata folder, is there a way I can delay script loading until after Cycles is loaded, or is it the core of how Blender is designed loading local scripts first and Appdata scripts later?

Interesting, thank you for the information. Reason I keep the few extra scripts I use locally, so Blender can be used as a portable app on other computers without the need to update anything. Also easy to compare different Blender and script versions. Other than using Appdata folder, is there a way I can delay script loading until after Cycles is loaded, or is it the core of how Blender is designed loading local scripts first and Appdata scripts later?

Greg Zaal commented

2014-10-04 17:13:32 +02:00

I'm not sure - you'd have to ask someone else, perhaps in the #blendercoders channel of freenode IRC.

David Black commented

2014-10-04 23:07:04 +02:00

As a brief follow up, able to confirm your Cycles loading later theory.

While of no practical use, changing

bpy.types.CyclesRender_PT_performance.append(menu_func_cycles)

to

bpy.types.RENDER_PT_performance.append(menu_func_cycles)

allows the script to start while stored locally.

Looked at various ideas, for example, trying to create a dummy CyclesRender_PT_performance interface for until Cycles had loaded, but presently my coding skills are not advanced enough. Not to worry! Once your code is included within Blender, this will no longer be an issue. :)

In closing, are there a few very minor modifications needed before submitting for Blender inclusion?
lines 226, 238 and 250

- description="Square dimentions of tiles",
+ description="Square dimensions of tiles",

Hope your weekend is going well, thanks again for your help and suggestions.

David

As a brief follow up, able to confirm your Cycles loading later theory. While of no practical use, changing ``` bpy.types.CyclesRender_PT_performance.append(menu_func_cycles) ``` to ``` bpy.types.RENDER_PT_performance.append(menu_func_cycles) ``` allows the script to start while stored locally. Looked at various ideas, for example, trying to create a dummy CyclesRender_PT_performance interface for until Cycles had loaded, but presently my coding skills are not advanced enough. Not to worry! Once your code is included within Blender, this will no longer be an issue. :) In closing, are there a few very minor modifications needed before submitting for Blender inclusion? lines 226, 238 and 250 ``` - description="Square dimentions of tiles", + description="Square dimensions of tiles", ``` Hope your weekend is going well, thanks again for your help and suggestions. David

Greg Zaal commented

2014-10-10 19:42:08 +02:00

Update:

Much more stable estimation - much simpler math and predictable results.
Also use border region in resolution calculations
Throw a warning when there are fewer tiles than render threads
Show warnings without the settings expanded

auto_tile_size_release_04.py

Update: - Much more stable estimation - much simpler math and predictable results. - Also use border region in resolution calculations - Throw a warning when there are fewer tiles than render threads - Show warnings without the settings expanded [auto_tile_size_release_04.py](https://archive.blender.org/developer/F115758/auto_tile_size_release_04.py)

Greg Zaal commented

2014-10-12 14:18:26 +02:00

Added subscriber: @mont29

Greg Zaal commented

2014-10-12 14:18:26 +02:00

I'd like to get this into contrib, and eventually master. I mentioned it on IRC and Bastien said he'd take a look, but I understand it's not a high priority and he has much more important things to do :)

Please ignore the original description at the top - Some of it is incorrect and I don't have permission to edit it.

Basically this add-on calculates the best[note] render tile size based on:

The render engine and device used (cpu/gpu)
The render resolution (including the percentage)
Whether you're rendering a border region (and how big it is)

It's all controlled in the background by handlers, updating the tile size each time one of the above changes. It also throws warnings when there are fewer tiles than available cpu threads, or if the calculated tile size is not very square (square tiles generally render quicker), although it is very uncommon for this to happen.

[note] I have done extensive testing on various kinds of scenes, and came to the conclusion that on average, around 64x64 is best for Blender Render, 32x32 for Cycles CPU and 256x256 for Cycles GPU. These are just generalisations though, the real advantage of this add-on is that it calculates the tile size to avoid having long narrow tiles on the borders of the image which often cause a small performance hit.

I'd like to get this into contrib, and eventually master. I mentioned it on IRC and Bastien said he'd take a look, but I understand it's not a high priority and he has much more important things to do :) Please ignore the original description at the top - Some of it is incorrect and I don't have permission to edit it. Basically this add-on calculates the best[note] render tile size based on: - The render engine and device used (cpu/gpu) - The render resolution (including the percentage) - Whether you're rendering a border region (and how big it is) It's all controlled in the background by handlers, updating the tile size each time one of the above changes. It also throws warnings when there are fewer tiles than available cpu threads, or if the calculated tile size is not very square (square tiles generally render quicker), although it is very uncommon for this to happen. [note] I have done extensive testing on various kinds of scenes, and came to the conclusion that on average, around 64x64 is best for Blender Render, 32x32 for Cycles CPU and 256x256 for Cycles GPU. These are just generalisations though, the real advantage of this add-on is that it calculates the tile size to avoid having long narrow tiles on the borders of the image which often cause a small performance hit.

Bastien Montagne commented

2014-10-12 14:40:33 +02:00

Addon seems to be working nice, and it is indeed a nice addition.

However, before I start a real code review, please address the following points:

Do not clutter the Scene class with a bunch of properties, please use a single PropertyGroup one to gather all your settings (see this page).
Do not use CamelCase for properties nor functions. Our code style requires CamelCase only for class names, functions, vars and class members should use that_style_of_naming.

Btw, do you have a commit access to addons repositories? If not, I can make the commit to addons_contrib on your behalf, will just need a valid mail address (so that you are correctly marked as author in git's logs).

Addon seems to be working nice, and it is indeed a nice addition. However, before I start a real code review, please address the following points: * Do not clutter the Scene class with a bunch of properties, please use a single PropertyGroup one to gather all your settings (see [this page](http://www.blender.org/documentation/blender_python_api_2_72_0/bpy.props.html#propertygroup-example)). * Do not use CamelCase for properties nor functions. Our code style requires CamelCase only for class names, functions, vars and class members should use that_style_of_naming. Btw, do you have a commit access to addons repositories? If not, I can make the commit to addons_contrib on your behalf, will just need a valid mail address (so that you are correctly marked as author in git's logs).

Bastien Montagne self-assigned this 2014-10-12 14:40:49 +02:00

David Black commented

2014-10-12 19:41:49 +02:00

Hi Greg,

After testing version 04, discovered people using a higher interface DPI setting only see part of the warning message, as seen below at 86 DPI.

A small error message modification in line 214, such as

- col.label (text="Warning: There are fewer tiles than render threads", icon='ERROR')
+ col.label (text="Warning: Fewer tiles than render threads", icon='ERROR')

allows the message to be viewed at DPI setting all the way up to 94 DPI, seen below at 86 DPI

After a small moment of lateral thinking, considered, do you need a warning message? Instead of displaying a warning, is it possible to just keep reducing tile sizes, so there are never fewer tiles than threads? It would be very rare for anyone to have a border size less then 8 or 12 pixels.

Is it possible to detect GPU render threads? If you only have access to one GPU, (having two GPU's solely for GPGPU) I can test a script for you if helpful?

In closing, encountered some unusual behavior while using border render, .blend file below (very high sample setting so tile area remains visible for longer).

GPU_tile_calculation_unusual_behavior.blend

Keep up the great work, looking forward to seeing your script included in Blender.

David

Hi Greg, After testing version 04, discovered people using a higher interface DPI setting only see part of the warning message, as seen below at 86 DPI. ![86_DPI_error_message_(original).png](https://archive.blender.org/developer/F116137/86_DPI_error_message__original_.png) A small error message modification in line 214, such as ``` - col.label (text="Warning: There are fewer tiles than render threads", icon='ERROR') + col.label (text="Warning: Fewer tiles than render threads", icon='ERROR') ``` allows the message to be viewed at DPI setting all the way up to 94 DPI, seen below at 86 DPI ![86_DPI_error_message_(reword).png](https://archive.blender.org/developer/F116140/86_DPI_error_message__reword_.png) After a small moment of lateral thinking, considered, do you need a warning message? Instead of displaying a warning, is it possible to just keep reducing tile sizes, so there are never fewer tiles than threads? It would be very rare for anyone to have a border size less then 8 or 12 pixels. Is it possible to detect GPU render threads? If you only have access to one GPU, (having two GPU's solely for GPGPU) I can test a script for you if helpful? In closing, encountered some unusual behavior while using border render, .blend file below (very high sample setting so tile area remains visible for longer). ![GPU_tile_calculation_unusual_behavior.png](https://archive.blender.org/developer/F116150/GPU_tile_calculation_unusual_behavior.png) [GPU_tile_calculation_unusual_behavior.blend](https://archive.blender.org/developer/F116152/GPU_tile_calculation_unusual_behavior.blend) Keep up the great work, looking forward to seeing your script included in Blender. David

Greg Zaal commented

2014-10-26 14:05:52 +01:00

Addressed those two issues - now uses a PropertyGroup, and functions+vars are not CamelCase.

My email is gregzzmail@gmail.com - though I'd prefer not to have to rely on someone else to commit on my behalf. I have commit access to Addons, but I don't think I have access for Addons-Contrib. Can check again once this is ready.

auto_tile_size_release_05.py

btw @david_black - those 1-pixel-wide tiles on the edge are fixed now too, was just a rounding error.

Addressed those two issues - now uses a PropertyGroup, and functions+vars are not CamelCase. My email is gregzzmail@gmail.com - though I'd prefer not to have to rely on someone else to commit on my behalf. I have commit access to Addons, but I don't think I have access for Addons-Contrib. Can check again once this is ready. [auto_tile_size_release_05.py](https://archive.blender.org/developer/F119754/auto_tile_size_release_05.py) btw @david_black - those 1-pixel-wide tiles on the edge are fixed now too, was just a rounding error.

Riccardo Giovanetti commented

2014-10-26 16:51:06 +01:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2014-10-26 16:51:06 +01:00

Hi Greg, I've used your great addon version 03 until I read your today's post, so I downloaded and replaced the previous version with the current 05 one, putting it inside the \addons_extern folder as it was the previous 03 version (which worked fine). Ouch! Little problem: it doesn't activate anymore returning the following error message in the console:

Traceback (most recent call last):

 File "D:\Blender\blender-2.72b-windows64\2.72\scripts\modules\addon_utils.py", line 299, in enable
  mod = __import__(module_name)
File "D:\Blender\blender-2.72b-windows64\2.72\scripts\addons_extern\auto_tile_size_release_05.py", line 37, in <module>
  class AutoTileSizeSettings(bpy.types.PropertyGroup):
File "D:\Blender\blender-2.72b-windows64\2.72\scripts\addons_extern\auto_tile_size_release_05.py", line 49, in AutoTileSizeSettings
  update=_update_tile_size)

NameError: name '_update_tile_size' is not defined

I've also tried to move it to \addons as well as \addons_contrib (which anyway I think shouldn't be done from a formal point of view) but I get always the exact same error and the addon does not activate from the Preferences|Addons. I thought it needed to have the render engine set to Cycles as the default one but even that didn't help.

FYI, I'm running the latest official 2.72b release in its own controlled environment (to exclude local AppData user settings from being taken into account) on a Win7 Pro 64bit SP1 OS and I don't use CUDA, only CPU computing.

Thanks

Hi Greg, I've used your great addon version 03 until I read your today's post, so I downloaded and replaced the previous version with the current 05 one, putting it inside the **\addons_extern** folder as it was the previous 03 version (which worked fine). Ouch! Little problem: it doesn't activate anymore returning the following error message in the console: Traceback (most recent call last): ``` File "D:\Blender\blender-2.72b-windows64\2.72\scripts\modules\addon_utils.py", line 299, in enable mod = __import__(module_name) File "D:\Blender\blender-2.72b-windows64\2.72\scripts\addons_extern\auto_tile_size_release_05.py", line 37, in <module> class AutoTileSizeSettings(bpy.types.PropertyGroup): File "D:\Blender\blender-2.72b-windows64\2.72\scripts\addons_extern\auto_tile_size_release_05.py", line 49, in AutoTileSizeSettings update=_update_tile_size) ``` NameError: name '_update_tile_size' is not defined I've also tried to move it to \addons as well as \addons_contrib (which anyway I think shouldn't be done from a formal point of view) but I get always the exact same error and the addon does not activate from the Preferences|Addons. I thought it needed to have the render engine set to Cycles as the default one but even that didn't help. FYI, I'm running the latest official 2.72b release in its own controlled environment (to exclude local AppData user settings from being taken into account) on a Win7 Pro 64bit SP1 OS and I don't use CUDA, only CPU computing. Thanks

Greg Zaal commented

2014-10-26 17:56:43 +01:00

Thanks - didn't catch that somehow. Moving the function above the AutoTileSizeSettings class seems to have fixed it though:

auto_tile_size_release_06.py

(Edit: uploaded wrong version, if you still have the issue, try download it again)

Thanks - didn't catch that somehow. Moving the function above the AutoTileSizeSettings class seems to have fixed it though: [auto_tile_size_release_06.py](https://archive.blender.org/developer/F119806/auto_tile_size_release_06.py) (Edit: uploaded wrong version, if you still have the issue, try download it again)

Riccardo Giovanetti commented

2014-10-26 21:14:32 +01:00

Thank you very much Greg for your lightning fast reply and fix. Now it works perfectly! Have a pleasant evening.

David Black commented

2014-10-26 22:58:38 +01:00

Thanks harvester for the \addons_extern folder information, this fixes previously reported script-starting issues while running Blender locally. Knew there had to be a solution after testing the PortableApps version of Blender, which allows a previous version of the script to start without errors.

Thanks Greg for your updated version containing improvements and fixes for reported issues. :)

Thanks harvester for the \addons_extern folder information, this fixes previously reported script-starting issues while running Blender locally. Knew there had to be a solution after testing the PortableApps version of Blender, which allows a previous version of the script to start without errors. Thanks Greg for your updated version containing improvements and fixes for reported issues. :)

Riccardo Giovanetti commented

2014-10-27 12:56:40 +01:00

You're wellcome David.

In principle, the \addons folder shouldn't be touched since it contains the officially supported add-ons, as well as the \addons_contrib because I sync it via GIT with the online repository. All the other unofficial or thirdparty addons (eg. Luxrender, Mitsuba, YafaRay, Greg's addon etc.) should be placed inside the \addons_extern folder. At least this is my understanding of how add-ons should be properly managed.

Please, note that I use ONLY the Blender's zipped packages which allow me to set up different specific "controlled" environments (production and/or testing) that don't interact or conflict with eachother giving me the freedom to use whatever version I like or need to work with.

You're wellcome David. In principle, the \addons folder shouldn't be touched since it contains the officially supported add-ons, as well as the \addons_contrib because I sync it via GIT with the online repository. All the other unofficial or thirdparty addons (eg. Luxrender, Mitsuba, YafaRay, Greg's addon etc.) should be placed inside the \addons_extern folder. At least this is my understanding of how add-ons should be properly managed. Please, note that I use ONLY the Blender's zipped packages which allow me to set up different specific "controlled" environments (production and/or testing) that don't interact or conflict with eachother giving me the freedom to use whatever version I like or need to work with.

Bastien Montagne commented

2014-10-31 15:54:33 +01:00

Hi Greg,

Code is globally OK now. Still did a cleanup pass, there were some things to improve yet (mostly: style, needless complexity like using an enum for the 'optimal tiles' option, and general simplifications like deduplicating some logic, etc.).

Proposed changes are in auto_tile_size_release_07.py

Should be no behavior changes from user PoV, would be good to double-check I did not break anything though, ended up making quite big changes in some areas. If you are OK with it, please commit it (if you need access to contrib, poke Campbell on IRC).

Hi Greg, Code is globally OK now. Still did a cleanup pass, there were some things to improve yet (mostly: style, needless complexity like using an enum for the 'optimal tiles' option, and general simplifications like deduplicating some logic, etc.). Proposed changes are in [auto_tile_size_release_07.py](https://archive.blender.org/developer/F120731/auto_tile_size_release_07.py) Should be no behavior changes from user PoV, would be good to double-check I did not break anything though, ended up making quite big changes in some areas. If you are OK with it, please commit it (if you need access to contrib, poke Campbell on IRC).

David Black commented

2014-11-01 03:40:07 +01:00

@ mont29,

Just tried your modified version in 2.72b and found an issue.

Normally, clicking Auto Tile Size (grey bar) toggles on/off auto tile size function, in your version it causes the grey bar to vanish with seemingly no way to reactive the auto tile function until Blender is closed and re-opened.

@ Greg,

For next version, don't forget email mentioned slight regression, reach a whole new dimension ;)

@ mont29, Just tried your modified version in 2.72b and found an issue. Normally, clicking *Auto Tile Size* (grey bar) toggles on/off auto tile size function, in your version it causes the grey bar to vanish with seemingly no way to reactive the auto tile function until Blender is closed and re-opened. @ Greg, For next version, don't forget email mentioned slight regression, reach a whole new dimension ;)

Greg Zaal commented

2014-11-01 08:42:43 +01:00

Wow, thanks Bastien, this is great :)

Made a few minor changes (diff ) - fixed David's issue (no need to do ats_poll when adding the UI, the buttons should always be visible); some minor alignment stuff and use_optimal UI text.

auto_tile_size_release_08.py

Will commit this sometime soon.

Wow, thanks Bastien, this is great :) Made a few minor changes ([diff ](http://www.pasteall.org/54905/diff)) - fixed David's issue (no need to do ats_poll when adding the UI, the buttons should always be visible); some minor alignment stuff and use_optimal UI text. [auto_tile_size_release_08.py](https://archive.blender.org/developer/F120999/auto_tile_size_release_08.py) Will commit this sometime soon.

Bastien Montagne commented

2014-11-01 09:12:34 +01:00

Yep, looks OK now, sorry about that. ;)

Bastien Montagne commented

2014-11-01 15:38:39 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2014-11-01 15:38:39 +01:00

Bastien Montagne commented

2014-11-01 15:38:39 +01:00

In contrib now. :)

Greg Zaal commented

2015-01-13 16:00:02 +01:00

Has been in contrib for over 2 months, haven't got any complaints - can we we move it to addons? :)

Bastien Montagne commented

2015-01-13 21:46:32 +01:00

Done :)

Greg Zaal commented

2015-01-14 19:11:18 +01:00

Woo :D thanks Bastien

Chris Offner commented

2016-04-04 21:54:43 +02:00

Added subscriber: @chrisoffner3d

Chris Offner commented

2016-04-04 21:54:43 +02:00

I use an NVIDIA GTX 980 Ti. After reading blender/blender#45093 and noticing that setting the tile size from64x64to*160x120// reduced my render time from 2:16min to just 57sec, I searched for a data-driven addon for determining optimal tile sizes.
Just tried this add-on here out and it falls short of the seemingly optimal 160x120. Rendering the same scene with Auto Tile Size on takes 1:23min.
So I was wondering:

Could someone write an add-on that comes with a few sample scenes that everyone could render at different tile sizes (and other hardware-specific render settings, if there are any like that), preferably automated, and send the render times for each setting combination together with the hardware (and OS) setup info to a database?

Then that add-on could source the settings via a single "Find the optimal settings for my machine." click for everyone.

Seems grossly inefficient that stuff like this is still sorted out via forum posts and guessing games if it could be easily solved via a data-driven crowdsourcing approach.

I use an NVIDIA GTX 980 Ti. After reading [blender/blender#45093 ](https:*developer.blender.org/T45093) and noticing that setting the tile size from*64x64*to*160x120// reduced my render time from **2:16min** to just **57sec**, I searched for a data-driven addon for determining optimal tile sizes. Just tried this add-on here out and it falls short of the seemingly optimal *160x120*. Rendering the same scene with *Auto Tile Size* on takes **1:23min**. So I was wondering: Could someone write an add-on that comes with a few sample scenes that everyone could render at different tile sizes (and other hardware-specific render settings, if there are any like that), preferably automated, and send the render times for each setting combination together with the hardware (and OS) setup info to a database? Then that add-on could source the settings via a single "Find the optimal settings for my machine." click for everyone. Seems grossly inefficient that stuff like this is still sorted out via forum posts and guessing games if it could be easily solved via a data-driven crowdsourcing approach.

Levin Nelio Omurca commented

2020-04-14 16:10:46 +02:00

Added subscriber: @levinnelio

Sign in to join this conversation.