Cycles Memory statistics in Blenders UI
Closed, ArchivedPublicDESIGN
Actions

Description

Hi,
as part of my GSoC, I like to add Cycles (memory) statistics to Blenders interface.
I will continue to refine this document this week, and give more information about what and how exactly the displayed information should look like, but I'd like to get feedback from the UI and Cycles Team about what the best place would be for such infos. Thanks!

What we have

When running Blender with --debug-cycles, we get various information about the memory requirements. Here an excerpt of that:

I0816 22:33:13.158812 12180 device_cpu.cpp:158] Texture allocate: __tri_patch, 1,016 bytes. (1016)
I0816 22:33:13.158818 12180 device_cpu.cpp:158] Texture allocate: __tri_patch_uv, 1,328 bytes. (1.30K)
I0816 22:33:13.158833 12180 device_cpu.cpp:158] Texture allocate: __object_flag, 24 bytes. (24)
I0816 22:33:13.185516 12176 device_cpu.cpp:158] Texture allocate: __tex_image_byte4_1024, 2,073,600 bytes. (1.98M)
I0816 22:33:13.196496 12179 device_cpu.cpp:158] Texture allocate: __tex_image_byte4_1027, 1,536,000 bytes. (1.46M)
I0816 22:33:13.196631 12177 device_cpu.cpp:158] Texture allocate: __tex_image_byte4_1025, 2,073,600 bytes. (1.98M)

While that is quite useful for developers, it's hidden from the user, and even if every user would have an open terminal all the time, it's still pretty technical.

In case of a memory failure (not enough memory available e.g. on a GPU, we get an error message in the Info Header and the Image Editor, but these are pretty technical as well.

CUDA error: Out of memory in cuMemAlloc(&device_pointer, size)

What we need

We need a place inside of Blenders UI, that is easily accessible for users and that shows detailed statistics about memory usage and error messages. Now, the main question is where to put that.

We want to display several things there, e.g.

Detailed infos about how much memory is used by different areas of the scene (Geometry, Attributes, Textures, BVH...) in a human readable format and nicely formatted.
In case of memory failures, give suggestions about possible simplifications or allow conversion to e.g. half float format (in case of too large image textures), which might make the scene fit into memory at the cost of some precision loss etc.

Possible places for that

Properties Editor

It could be a "Statistics" panel inside the Render Tab, that contains all these infos.

Outliner

Have a new submode there, called Render Statistics. This could be used by other render engines as well (should be python accessible of course).

Info Editor, Main Area

We print operators and errors to the main area of the info editor atm (pull down the info header). This could be extended with a statistics view as well.

Alternatives

Generate a XML/HTML report instead of putting that info inside of Blenders UI. See comments below for details.

Event Timeline

Thomas Dinges (dingto) created this task.Aug 16 2016, 10:46 PM

Personly I think it should be a submode in the info editor.

As I've mentioned before, I think an XML/HTML report would be better than showing this data in the Blender UI:

Easier to search and browse, particularly if there is a lot of data.
Easier to create a nice layout, perhaps with charts etc.
Report can be written on the render farm for later analysis.
Blender UI can have a button / link to open such a report.

I agree with Brecht on this. It has many benefits over a implementation inside of Blenders UI. I wrote a bit about such an approach in my Week 11 report already.

Thomas Dinges (dingto) updated the task description. (Show Details)Aug 16 2016, 11:08 PM

Francesco Siddi (fsiddi) added a subscriber: Francesco Siddi (fsiddi).Aug 17 2016, 9:09 AM

Using XML/HTML is a lazy man approach to achieve something with questionable outcome for artists, which just does not solve or achieve requirements we need. This particular project is about giving an artist a tool to investigate their scene, to make it simpler to tweak parameters to make scene renderable on either their hardware or on a farm's hardware.

@Brecht Van Lommel (brecht), from a quick thought your approach does not work because:

It makes it much more difficult for artists to re-iterate over various settings, to see how they affect final memory usage (or give indication that something is not really a bottleneck from a memory point of view).
It would not work if the scene does not fit into memory already, simply because somewhere along the line memory allocation will fail and Cycles will stop further exporting, making statistics incomplete.
It doesn't give any preliminary information about the scene, forcing you to render first.

Points about being able to create nicer layout i simply don't buy. It is possible to create decent layout for this in Blender. Not saying it'll be fewliner patch, but that's what development is all about really: solve and improve weak points in a software, move it to the next level.

The only point i agree here is that having such statistics files saved by renderfarms will make TDs life easier, but that is another project. Would be nice to have it tackled as well, but it is out of the scope of this particular GSoC.

I can not understand why people here are only grasping one particular statistics which needs visualization. There _is_ world outside of Cycles apparently: another example of crucial statistics data to be visualized are the dependency graph, motion tracking. Likely node-based things will also require some statistics/troubleshooting tools in the future.

So please stop cutting the corners, get a bigger picture and give a decent proposal which solves all the requirements we need.

That all being said, such things deserves own space, for full control over visualization and possible tools to operate on visualization. Space Info fits perfectly (especially from it's name). The only issue here would be that it is used as a main menu header, but that is solvable.

@Thomas Dinges (dingto), why aren't you discussing details with your mentor and not even CCing him to the discussion here?

@Sergey Sharybin (sergey) Ton is part of the UI team project, so I thought an extra CC is not needed. :)

I would favor the Info Editor or adding our own (Statistics Editor) if we want to use that for other areas of Blender as well, just because this gives us more space and is more flexible imho.

Here's an example of such XML stats (open in a web browser).

In T49101#386643, @Sergey Sharybin (sergey) wrote:

@Brecht Van Lommel (brecht), from a quick thought your approach does not work because:

It makes it much more difficult for artists to re-iterate over various settings, to see how they affect final memory usage (or give indication that something is not really a bottleneck from a memory point of view).

Not sure how the info being in a separate browser page makes much of a difference, or are you suggesting that such stats could be updated interactively? I don't think we can reliably predict memory usage.

It would not work if the scene does not fit into memory already, simply because somewhere along the line memory allocation will fail and Cycles will stop further exporting, making statistics incomplete.

To me it seems like this is a case you need to deal with regardless where you display the stats.

It doesn't give any preliminary information about the scene, forcing you to render first.

The only point i agree here is that having such statistics files saved by renderfarms will make TDs life easier, but that is another project. Would be nice to have it tackled as well, but it is out of the scope of this particular GSoC.

I can not understand why people here are only grasping one particular statistics which needs visualization. There _is_ world outside of Cycles apparently: another example of crucial statistics data to be visualized are the dependency graph, motion tracking. Likely node-based things will also require some statistics/troubleshooting tools in the future.

So please stop cutting the corners, get a bigger picture and give a decent proposal which solves all the requirements we need.

Ok, you are suggesting a generic Blender statistics tool, not a Cycles render statistics tool. I was thinking about how to make this work as well as possible for a renderer, and for that working on a render farm is important.

If you want to prioritize it being usable by other parts of Blender that's fine, displaying it in the UI and logging to disk are not mutually exclusive if we want to support both in the future. Getting stats about depsgraph evaluation and physics simulation on the farm might be useful too eventually.

Not sure how the info being in a separate browser page makes much of a difference, or are you suggesting that such stats could be updated interactively?

If it's a separate web page you have no chance to add any tools for artists to reduce memory usage. For example, you might offer tools like image scaling, settings half vs. full float, use less speed-optimized BVH or whatever.

Having such tool closely integrated with real statistics is a nice workflow improvement.

And perhaps in the future Cycles might also automatically decide to fall back to memory-optimized settings rather than speed-optimized just to make rendering possible.

I don't think we can reliably predict memory usage.

We can give quite good ball-park figures. They wouldn't be 100% the same as real-life rendering, but should be possible to predict those good enough.

It would not work if the scene does not fit into memory already, simply because somewhere along the line memory allocation will fail and Cycles will stop further exporting, making statistics incomplete.

To me it seems like this is a case you need to deal with regardless where you display the stats.

Don't see why you need to deal with anything. If rendering gets aborted due to memory starvation so be it. You just wouldn't get full picture of real rendering process, but it is a separate thing i'd say.

Ok, you are suggesting a generic Blender statistics tool, not a Cycles render statistics tool. I was thinking about how to make this work as well as possible for a renderer, and for that working on a render farm is important.

We need generic tool for Blender, that's for sure. There are various reasons for that, details of which we can discuss in IRC.

So for artists ease of control i don't see any reason not to make all the visualization of Cycles things and some shortcuts for scene optimization in Blender itself.

It doesn't mean i'm against stand-alone file generated by render farms, but that's just separate thing which we kind of already have for technical users (by just enabled --debug-cycles). For now it works good enough, so improving this particular usecase is not a priority for now.

If you want to prioritize it being usable by other parts of Blender that's fine, displaying it in the UI and logging to disk are not mutually exclusive if we want to support both in the future. Getting stats about depsgraph evaluation and physics simulation on the farm might be useful too eventually.

Exactly.

Also, i'm not saying i want to have full design doc about all the details of how physics/depsgraph will work here in details. I just want to have a design which would allow such extra logging/statistics added easily without huge refactor and without spreading such info all over the interface.

I agree on the need for a general statistics and debugging solution integrated into the UI. It would be a big enough interface to justify its own editor. However, I also agree that the Info Editor would be the optimal place for this, but its purpose should be re-evaluated completely then. My idea was to deprecate the Info Editor as it currently is anyway, replacing it with this design. The Info Editor could then be re-purposed and include the memory statistics as discussed here.

I also agree that the option to export the statistics as XML/HTML would be useful, additionally to the integrated Blender UI solution. Such files could also be super handy for bug tracker work. Ultimately, the XML/HTML pages would have a button to automatically store the page on dev.b.org so they can be easily attached to reports. Note that this could be a proper solution for the System Info thingy too.

Another idea that could be considered (in general - not only as a possible solution for this task), would be having an own "Render Properties Editor". It would contain all scene level render settings, namely what's currently in the Render and Render Layer context of the Properties Editor.
The amount of render engine options is growing and it will keep doing so in the future. We probably can't avoid such a step on the long run, if we want to keep things well structured.

Tools to actually fix the performance issues could be quite powerful, as would be showing per object stats based on selection. But I guess that's out of scope for GSOC.

So the initial stuff to support would be something like this?

New Statistics / Log editor (copied from Info editor which loses the operator history).
Contains a list of logs: Operator History, System Info, Render Log 1, Render Log 2, ...
Each log is a multiline text
List of logs stored in WM?
Python API to add a log
Select / Delete / Clear All logs functionality

But how to extend that to "rich text" logs?

You could figure out some syntax to pass tree structured text you can collapse/expand, titles, tables, graphs, markup to render warnings with red text, some way to insert buttons for fixing tools, .. . But we're not in the business of re-implementing HTML.

So instead, when adding a log you would pass a draw() callback that lets you draw arbitrary UIs with Python, is that the idea?

My GSoC proposal only contains the Memory Statistics shown inside of Blenders UI. So basically what we have when running --debug-cycles, just inside of Blenders UI.
Pre-render statistics and tools for fixing performance / memory issues is nice, but that needs more time and careful implementation. I am happy to work on these too, but thats for after GSoC then.

So we seem to agree on a new editor, I can implement the raw basics and then add some basic operators for drawing logs in there. Then I will check on how to pass the memory infos from Cycles to the UI.

This sounds like a good idea to me.
I hope that external renderers will also be able to use this new editor, to display statistics as well as warning/error messages that happened during the export process (e.g. missing imagemaps).

@Thomas Dinges (dingto) would it be possible to "merge" it with your spreadsheet editor idea? Make the new editor able to have several lines and rows. With an option to export those to .csv will allow to quickly generate charts and web pages in js. Then extending the table with a last row containing some click-able operators to solve the problems will be easy as a first draft.

Hi guys! This looks like a really really good thing to have in blender. I was searching for such tools right now because I have a huge scene that I would like to optimize to use less ram as possible, but the amount of texture is so big that it would take a looooong time to do it "by hand". This tool would allow to have an overview of memory usage really quick!

Can I ask what's the status of the project?

Thank you! :)

Aaron Carlisle (Blendify) moved this task from Backlog to Blender 2.8 Design on the User Interface board.Apr 16 2017, 6:39 AM

Just stumbling over this again... In the meanwhile we've decided to re-purpose the Info Editor completely. It's planned to make it the place for various statistics and logs, so it would also be the place where Cycles stats should go.

That said, is there anything else that needs to be discussed here? I think we can close the task?

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.Oct 31 2018, 2:08 PM

Brecht Van Lommel (brecht) claimed this task.

Cycles Memory statistics in Blenders UIClosed, ArchivedPublicDESIGNActions