Blender Git Loki
February 11, 2017, 06:45 (GMT) |
Fix uninitialized values |
January 14, 2017, 08:36 (GMT) |
Cycles: Fix building of CUDA kernels after last commit |
January 14, 2017, 07:02 (GMT) |
Cycles: Deduplicate sample range setting and getting |
January 14, 2017, 04:09 (GMT) |
Cycles: Add generic work item functions for OpenCL |
January 14, 2017, 04:08 (GMT) |
Cycles: Add generic work item functions for CUDA |
January 13, 2017, 01:49 (GMT) |
Cycles: Rendering multiple tiles at once for OpenCL mega kernel Basically the same as for CUDA. No major performance difference, but in some cases this is a little faster than single tile rendering. |
January 13, 2017, 01:41 (GMT) |
Add get_ideal_tile_size function to RenderEngine This allows render engines to specify an ideal tile size to use while rendering. The function is optional, if provided the returned tile size will override the scene settings, if not provided the original behavior will be used. |
January 13, 2017, 01:41 (GMT) |
Cycles: Implement the get_ideal_tile_size function Since devices will be rendering many tiles at once the tile size chosen is on the smaller side. A limited selection of tiles sizes is provided as an option. This may be removed later, for now its mostly useful for debugging. |
January 13, 2017, 01:41 (GMT) |
Cycles: Rendering multiple tiles at once for CUDA There's no major performance difference from rendering a single large tile. However if there are too many tiles (such as if the tiles are 16x16) the overhead of updating tile display can become a bit noticeable. This should be easy to fix by restructuring the tile update code a little. |
January 13, 2017, 01:41 (GMT) |
Cycles: Overload DeviceTask::update_progress to take multiple tiles `update_progress` will only update the tile sample once every second, which is a problem when there are multiple tiles and calls to this function. The overload allows for multiple tiles to be updated at once by getting around the rate limit with a single call. |
January 13, 2017, 01:40 (GMT) |
Cycles: Have CPU devices use new the acquire_tiles function This is mostly for testing at the moment, as the default work request sizes should result in only one tile being acquired at once. May need to tweak the request sizes later, but for now this should do. |
January 13, 2017, 01:40 (GMT) |
Cycles: Add SampleRange struct This struct will be used to describe the ranges of tile samples passed to the kernel when rendering multiple tiles samples at once. |
January 13, 2017, 01:40 (GMT) |
Cycles: Add functions to acquire multiple tiles at once Devices will render multiple smallish tiles (and eventually multiple samples) at once to keep busy. Using smaller tiles has a few benefits: there's less of an issue of tiles being cropped at image edges, multiple devices can share work better, and we may even be able to increase coherency from rendering multiple samples. |