blender/intern/cycles/render/session.h

185 lines
4.1 KiB
C
Raw Normal View History

/*
* Copyright 2011, Blender Foundation.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
#ifndef __SESSION_H__
#define __SESSION_H__
#include "buffers.h"
#include "device.h"
#include "tile.h"
#include "util_progress.h"
#include "util_thread.h"
CCL_NAMESPACE_BEGIN
class BufferParams;
class Device;
class DeviceScene;
class DisplayBuffer;
class Progress;
class RenderBuffers;
class Scene;
/* Session Parameters */
class SessionParams {
public:
DeviceInfo device;
bool background;
string output_path;
bool progressive;
bool experimental;
int samples;
int2 tile_size;
int resolution;
int threads;
double cancel_timeout;
double reset_timeout;
double text_timeout;
SessionParams()
{
background = false;
output_path = "";
progressive = false;
experimental = false;
samples = INT_MAX;
tile_size = make_int2(64, 64);
resolution = 4;
threads = 0;
cancel_timeout = 0.1;
reset_timeout = 0.1;
text_timeout = 1.0;
}
bool modified(const SessionParams& params)
{ return !(device.type == params.device.type
&& device.id == params.device.id
&& background == params.background
&& output_path == params.output_path
/* && samples == params.samples */
&& progressive == params.progressive
&& experimental == params.experimental
&& tile_size == params.tile_size
&& resolution == params.resolution
&& threads == params.threads
&& cancel_timeout == params.cancel_timeout
&& reset_timeout == params.reset_timeout
&& text_timeout == params.text_timeout); }
};
/* Session
*
* This is the class that contains the session thread, running the render
* control loop and dispatching tasks. */
class Session {
public:
Device *device;
Scene *scene;
RenderBuffers *buffers;
DisplayBuffer *display;
Progress progress;
SessionParams params;
TileManager tile_manager;
boost::function<void(RenderTile&)> write_render_tile_cb;
boost::function<void(RenderTile&)> update_render_tile_cb;
Session(const SessionParams& params);
~Session();
void start();
bool draw(BufferParams& params);
void wait();
bool ready_to_reset();
void reset(BufferParams& params, int samples);
Performance fix for Cycles: Don't wait in the main UI thread when resetting devices. When the scene is updated Cycles resets the renderer device, cancelling all existing tasks. The main thread would wait for all running tasks to finish before continuing. This is ok when tasks can actually cancel in a timely fashion. For OSL however, this does not work, since the OSL shader group optimization takes quite a bit of time and can not be easily be cancelled once running (on my crappy machine in full debug mode: ~0.12 seconds for simple node trees). This would lead to very laggy UI behavior and make it difficult to accurately control elements such as sliders. This patch removes the wait condition from the device->task_cancel method. Instead it just sets the do_cancel flag and returns. To avoid backlog in the task pool of the device it will return early from the BlenderSession::sync function while the reset is going on (tested in Session::resetting). Once all existing tasks have finished the do_cancel flag is finally cleared again (checked in TaskPool::num_decrease). Care has to be taken to avoid race conditions on the do_cancel flag, since it can now be modified outside the TaskPool::cancel function itself. For this purpose the scope of the TaskPool::num_mutex locks has been extended, in most cases the mutex is now locked by the TaskPool itself before calling TaskScheduler methods, instead of only locking inside the num_increase/num_decrease functions themselves. The only occurrence of a lock outside of the TaskPool methods is in TaskScheduler::thread_run. This patch is most useful in combination with the OSL renderer mode, so it can probably wait until after the 2.64 release. SVM tasks tend to be cancelled quickly, so the effect is less noticeable.
2012-09-11 11:41:51 +00:00
bool resetting() const;
void set_samples(int samples);
void set_pause(bool pause);
protected:
struct DelayedReset {
thread_mutex mutex;
bool do_reset;
BufferParams params;
int samples;
} delayed_reset;
void run();
void update_scene();
void update_status_time(bool show_pause = false, bool show_done = false);
void tonemap();
void path_trace();
void reset_(BufferParams& params, int samples);
void run_cpu();
bool draw_cpu(BufferParams& params);
void reset_cpu(BufferParams& params, int samples);
Performance fix for Cycles: Don't wait in the main UI thread when resetting devices. When the scene is updated Cycles resets the renderer device, cancelling all existing tasks. The main thread would wait for all running tasks to finish before continuing. This is ok when tasks can actually cancel in a timely fashion. For OSL however, this does not work, since the OSL shader group optimization takes quite a bit of time and can not be easily be cancelled once running (on my crappy machine in full debug mode: ~0.12 seconds for simple node trees). This would lead to very laggy UI behavior and make it difficult to accurately control elements such as sliders. This patch removes the wait condition from the device->task_cancel method. Instead it just sets the do_cancel flag and returns. To avoid backlog in the task pool of the device it will return early from the BlenderSession::sync function while the reset is going on (tested in Session::resetting). Once all existing tasks have finished the do_cancel flag is finally cleared again (checked in TaskPool::num_decrease). Care has to be taken to avoid race conditions on the do_cancel flag, since it can now be modified outside the TaskPool::cancel function itself. For this purpose the scope of the TaskPool::num_mutex locks has been extended, in most cases the mutex is now locked by the TaskPool itself before calling TaskScheduler methods, instead of only locking inside the num_increase/num_decrease functions themselves. The only occurrence of a lock outside of the TaskPool methods is in TaskScheduler::thread_run. This patch is most useful in combination with the OSL renderer mode, so it can probably wait until after the 2.64 release. SVM tasks tend to be cancelled quickly, so the effect is less noticeable.
2012-09-11 11:41:51 +00:00
bool resetting_cpu() const;
void run_gpu();
bool draw_gpu(BufferParams& params);
void reset_gpu(BufferParams& params, int samples);
Performance fix for Cycles: Don't wait in the main UI thread when resetting devices. When the scene is updated Cycles resets the renderer device, cancelling all existing tasks. The main thread would wait for all running tasks to finish before continuing. This is ok when tasks can actually cancel in a timely fashion. For OSL however, this does not work, since the OSL shader group optimization takes quite a bit of time and can not be easily be cancelled once running (on my crappy machine in full debug mode: ~0.12 seconds for simple node trees). This would lead to very laggy UI behavior and make it difficult to accurately control elements such as sliders. This patch removes the wait condition from the device->task_cancel method. Instead it just sets the do_cancel flag and returns. To avoid backlog in the task pool of the device it will return early from the BlenderSession::sync function while the reset is going on (tested in Session::resetting). Once all existing tasks have finished the do_cancel flag is finally cleared again (checked in TaskPool::num_decrease). Care has to be taken to avoid race conditions on the do_cancel flag, since it can now be modified outside the TaskPool::cancel function itself. For this purpose the scope of the TaskPool::num_mutex locks has been extended, in most cases the mutex is now locked by the TaskPool itself before calling TaskScheduler methods, instead of only locking inside the num_increase/num_decrease functions themselves. The only occurrence of a lock outside of the TaskPool methods is in TaskScheduler::thread_run. This patch is most useful in combination with the OSL renderer mode, so it can probably wait until after the 2.64 release. SVM tasks tend to be cancelled quickly, so the effect is less noticeable.
2012-09-11 11:41:51 +00:00
bool resetting_gpu() const;
bool acquire_tile(Device *tile_device, RenderTile& tile);
void update_tile_sample(RenderTile& tile);
void release_tile(RenderTile& tile);
void update_progress_sample();
bool device_use_gl;
thread *session_thread;
volatile bool display_outdated;
volatile bool gpu_draw_ready;
volatile bool gpu_need_tonemap;
thread_condition_variable gpu_need_tonemap_cond;
bool pause;
thread_condition_variable pause_cond;
thread_mutex pause_mutex;
thread_mutex tile_mutex;
thread_mutex buffers_mutex;
thread_mutex display_mutex;
bool kernels_loaded;
double start_time;
double reset_time;
double preview_time;
double paused_time;
};
CCL_NAMESPACE_END
#endif /* __SESSION_H__ */