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

[Mohamed Sakr]

Hi Sergey,

when I removed the output_path name "to force it outside of the
if(!(params.background
&& params.output_path.empty())) , it worked fine, so I guess it needs more
checks.
so now it works fine with buckets updating, checking progressive refine "it
should work fine also!!"

thanks for help so far.

cheers,
Mohamed Sakr

On Tue, May 19, 2015 at 1:17 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:

> Hi Sergey,
>
> I can confirm that the above part is the problem, I added those 2 lines to
> see if it is the cause of the issue:
>
> 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
>                         rtile.buffers = nullptr; //here!!
> }
> }
>
> update_status_time();
> }
>
> if(!(params.background && params.output_path.empty())) {//enters here
>                 if(!rtile.buffers)
>                      std::cout << "nullptr buffer!!" << std::endl; // it
> enters here, as they are pointers so the buffers is also empty, and it is
> re assigned so it crashes, it needs recreation or another logic, you know
> better than me at this point.
>
> 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:58 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:
>
>> @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/20150521/02122345/attachment.htm