[Bf-cycles] problems with function callbacks from Cycles standalone exporter
Mohamed Sakr
3dsakr at gmail.com
Tue May 19 12:58:41 CEST 2015
@Jasper , the constructor is sizing it , std::vector<float>
pixels(params.width*params.height * 4);
and BTW it crashes even if I didn't call this function "just by entering
the function pointer part"
@Sergey, please confirm!!
so it crashes with this:
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); //no call at all
delete rtile.buffers;// this is why it crashes!! , it deletes the buffers
}
}
update_status_time();
}
AND
if(!(params.background && params.output_path.empty())) {//enters here
tile_manager.state.buffer.get_offset_stride(rtile.offset, rtile.stride);
rtile.buffer = buffers->buffer.device_pointer;
rtile.rng_state = buffers->rng_state.device_pointer;
rtile.buffers = buffers;// these buffers are already deleted, bam!!
device->map_tile(tile_device, rtile);
return true;
}
On Tue, May 19, 2015 at 12:42 PM, Jasper Kindt <jasper.kindt at gmail.com>
wrote:
> Not an STL expert but shouldn't you reserve space in the pixels vector
> first before you pass it?
> On 19 May 2015 12:25, "Mohamed Sakr" <3dsakr at gmail.com> wrote:
>
>> but I'm sure it doesn't crash from the function content, even if the
>> function is empty "just return; " , it crashes
>>
>> On Tue, May 19, 2015 at 12:17 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
> _______________________________________________
> 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/47c0b2ea/attachment.htm
More information about the Bf-cycles
mailing list