blender
/
blender
137
411
Fork 594
Code Issues 6.3k Pull Requests 770 Projects 19 Wiki Activity

Hydra render engine #104712

Closed
Bogdan Nagirniak wants to merge 142 commits from BogdanNagirniak/blender:hydra-render into main
pull from: BogdanNagirniak/blender:hydra-render
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 31 Commits 142 Files Changed 65 +2 -2
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit c20f181fab - Show all commits

2
source/blender/render/hydra/final_engine.cc
View File

@ -67,7 +67,7 @@ void FinalEngine::update_render_result()
if (it_image == render_images_.end()) {
continue;
}
memcpy(pass->rect,
memcpy(pass->buffer.data,
it_image->second.data(),
sizeof(float) * pass->rectx * pass->recty * pass->channels);
}

2
source/blender/render/hydra/preview_engine.cc
View File

@ -39,7 +39,7 @@ void PreviewEngine::update_render_result(std::vector<float> &pixels)
RenderLayer *layer = (RenderLayer *)result->layers.first;
RenderPass *pass = (RenderPass *)layer->passes.first;
memcpy(pass->rect, pixels.data(), sizeof(float) * pass->rectx * pass->recty * pass->channels);
memcpy(pass->buffer.data, pixels.data(), sizeof(float) * pass->rectx * pass->recty * pass->channels);
RE_engine_end_result(bl_engine_, result, false, false, false);
}
BogdanNagirniak marked this conversation as resolved Outdated
Brecht Van Lommel commented 2023-05-25 18:29:07 +02:00
Outdated
Review
Copy Link

This is still using a timer, it should not be used at all. Other render engines don't need one either to free data.

This is still using a timer, it should not be used at all. Other render engines don't need one either to free data.
Bogdan Nagirniak commented 2023-05-27 07:06:18 +02:00
Outdated
Review
Copy Link

We use timer because it is not efficient to recreate Preview render engine each time when material is changes, including render of material thumbnail. Therefore we decided to free Preview engine after some time when it wasn't used. Can you propose another solution without timer or maybe it should be moved to python part?

We use timer because it is not efficient to recreate Preview render engine each time when material is changes, including render of material thumbnail. Therefore we decided to free Preview engine after some time when it wasn't used. Can you propose another solution without timer or maybe it should be moved to python part?
Brecht Van Lommel commented 2023-05-28 14:22:20 +02:00
Outdated
Review
Copy Link

Why is it inefficient, and how inefficient are we talking about? Is there anything that can be done to make it more efficient, maybe on the add-on side to reduce startup time or cache some slow library initialization? For Cycles and Eevee the startup time is not so much an issue.

Using a timer is and a single global instance is just not safe. There can be multiple previews at the same time, multiple threads can create a preview engine, the add-on may be disabled after which it's not longer safe to free the delegate, the instance is freed as part of static deinitialization which is too late, etc.

There are safer ways to do this, perhaps by Blender holding onto RenderEngine instances longer. But before we add that complexity, I'd like to understand why there is a performance issue in the first place.

Why is it inefficient, and how inefficient are we talking about? Is there anything that can be done to make it more efficient, maybe on the add-on side to reduce startup time or cache some slow library initialization? For Cycles and Eevee the startup time is not so much an issue. Using a timer is and a single global instance is just not safe. There can be multiple previews at the same time, multiple threads can create a preview engine, the add-on may be disabled after which it's not longer safe to free the delegate, the instance is freed as part of static deinitialization which is too late, etc. There are safer ways to do this, perhaps by Blender holding onto `RenderEngine` instances longer. But before we add that complexity, I'd like to understand why there is a performance issue in the first place.
Bogdan Nagirniak commented 2023-05-28 16:18:22 +02:00
Outdated
Review
Copy Link

Initializing of render delegate - it could be a complex task including GPU initializing and memory reservation etc and could take some time (till to several seconds). Therefore recreating render delegate each time when material is changed to render material preview and thumbnail takes some time, for example in RPR delegate.
Probably this optimization has to be moved to addon side, what do you think?

Initializing of render delegate - it could be a complex task including GPU initializing and memory reservation etc and could take some time (till to several seconds). Therefore recreating render delegate each time when material is changed to render material preview and thumbnail takes some time, for example in RPR delegate. Probably this optimization has to be moved to addon side, what do you think?
Brecht Van Lommel commented 2023-05-28 17:52:43 +02:00
Outdated
Review
Copy Link

Yes, this seems like it can be handled in the add-on. And then enabling viewport rendering or pressing F12 to render would likely be faster too. In Cycles this doesn't take several seconds though, not sure why it would be so slow in Hydra or RPR.

Yes, this seems like it can be handled in the add-on. And then enabling viewport rendering or pressing F12 to render would likely be faster too. In Cycles this doesn't take several seconds though, not sure why it would be so slow in Hydra or RPR.
Brian Savery (AMD) commented 2023-05-28 19:22:24 +02:00
Outdated
Review
Copy Link

Yes, this seems like it can be handled in the add-on. And then enabling viewport rendering or pressing F12 to render would likely be faster too. In Cycles this doesn't take several seconds though, not sure why it would be so slow in Hydra or RPR.

@BogdanNagirniak if this is an hydra RPR issue (not an issue in HDStorm), it should not be worked around here.

> Yes, this seems like it can be handled in the add-on. And then enabling viewport rendering or pressing F12 to render would likely be faster too. In Cycles this doesn't take several seconds though, not sure why it would be so slow in Hydra or RPR. @BogdanNagirniak if this is an hydra RPR issue (not an issue in HDStorm), it should not be worked around here.