[Bf-cycles] problems with function callbacks from Cycles standalone exporter

Mohamed Sakr 3dsakr at gmail.com
Tue May 19 12:17:20 CEST 2015


Hi Sergey,

it didn't solve the issue "although I guess it is a part of the crash, so
there is another part that crashes it here too" , it crashes in both CPU
and CUDA, when I tested with CUDA it throws this message:
ILLEGAL_ADDRESS in cuCtxSynchronize()

here is the code that I'm using for the function callback:

void rContextHandler::r_C4D_write_tile(RenderTile& rtile)
{
BufferParams& params = rtile.buffers->params;
int x = params.full_x - options.session->tile_manager.params.full_x;
int y = params.full_y - options.session->tile_manager.params.full_y;
int w = params.width;
int h = params.height;

RenderBuffers *buffers = rtile.buffers;

/* copy data from device */
if (!buffers->copy_from_device())
return;

float exposure = scene->film->exposure;
std::vector<float> pixels(params.width*params.height * 4);

if (buffers->get_pass_rect(PASS_COMBINED, exposure, rtile.sample, 4,
&pixels[0]))
write_c4d(&pixels[0], x, y, w, h);

return;
}

On Tue, May 19, 2015 at 9:40 AM, Sergey Sharybin <sergey.vfx at gmail.com>
wrote:

> I can't reproduce issue with missing update/write callbacks call here,
> this all works just fine here by the looks of it. Also not sure why would
> commenting buffers deletion make things work to you. Either you're
> referencing buffers in the callback or maybe it is related to the next
> issue.
>
> Bet you've got default start resolution of 64 in the settings. This makes
> it so frame first renders with lower resolution and then goes to a final
> resolutions. This for sure causes number of tiles to be changed, which is
> not supported by progressive refine in the background mode.
>
> Surely we can add some checks in the session constructor to verify the
> settings, but for until then just manually control the settings on your
> side.
>
> On Tue, May 19, 2015 at 3:21 AM, Mohamed Sakr <3dsakr at gmail.com> wrote:
>
>> Hi,
>>
>>     I'm creating a render engine based on Cycles, right now everything is
>> fine except that the function callbacks "write_render_tile_cb,
>> update_render_tile_cb" and variables "progressive, progressive_refine" are
>> making a problem!!
>>
>> the problem is:
>> case (1):
>> options.session_params.progressive = true;
>> options.session_params.progressive_refine = true;
>> options.session_params.progressive_update_timeout = 0.1;
>> options.session_params.background = true;
>>
>> no feedback is given "from both functions, so they are not called" , at
>> the end of the render it saves the image on destructor.
>>
>> case (2):
>> options.session_params.progressive = false;
>> options.session_params.progressive_refine = false;
>> options.session_params.progressive_update_timeout = 0.1;
>> options.session_params.background = true;
>>
>> crash!! after first tile, shows 12/192 in tiles and crashes.
>>
>> case (3):
>> options.session_params.progressive = false;
>> options.session_params.progressive_refine = false;
>> options.session_params.progressive_update_timeout = 0.1;
>> options.session_params.background = true;
>>
>> and in session.cpp:
>>
>> void Session::release_tile(RenderTile& rtile)
>> {
>> thread_scoped_lock tile_lock(tile_mutex);
>>
>> if(write_render_tile_cb) {
>> if(params.progressive_refine == false) {
>> /* todo: optimize this by making it thread safe and removing lock */
>> write_render_tile_cb(rtile);
>>
>> //delete rtile.buffers;  // I commented this line!!
>> }
>> }
>>
>> update_status_time();
>> }
>>
>> with commenting delete rtile.buffers; , it doesn't crash, and updates
>> fine!! "although with some problems in gamma in updating, but at the end
>> the written image is gamma correct"
>>
>> I'm not sure where is the problem.
>>
>> cheers,
>> Mohamed Sakr
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
>
> --
> With best regards, Sergey Sharybin
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150519/92029dc4/attachment.htm 


More information about the Bf-cycles mailing list