BLI_compute_context.hh File Reference

#include <optional>
#include "BLI_array.hh"
#include "BLI_linear_allocator.hh"
#include "BLI_stack.hh"
#include "BLI_string_ref.hh"
#include "BLI_struct_equality_utils.hh"

Go to the source code of this file.

Classes
struct	blender::ComputeContextHash
class	blender::ComputeContext
class	blender::ComputeContextBuilder

Namespaces
namespace	blender

Detailed Description

When logging computed values, we generally want to know where the value was computed. For example, geometry nodes logs socket values so that they can be displayed in the ui. For that we can combine the logged value with a ComputeContext, which identifies the place where the value was computed.

This is not a trivial problem because e.g. just storing a pointer to the socket a value belongs to is not enough. That's because the same socket may correspond to many different values when the socket is used in a node group that is used multiple times. In this case, not only does the socket have to be stored but also the entire nested node group path that led to the evaluation of the socket.

Storing the entire "context path" for every logged value is not feasible, because that path can become quite long. So that would need much more memory, more compute overhead and makes it complicated to compare if two contexts are the same. If the identifier for a compute context would have a variable size, it would also be much harder to create a map from context to values.

The solution implemented below uses the following key ideas:

• Every compute context can be hashed to a unique fixed size value (ComputeContextHash). While technically there could be hash collisions, the hashing algorithm has to be chosen to make that practically impossible. This way an entire context path, possibly consisting of many nested contexts, is represented by a single value that can be stored easily.
• A nested compute context is build as singly linked list, where every compute context has a pointer to the parent compute context. Note that a link in the other direction is not possible because the same parent compute context may be used by many different children which possibly run on different threads.

Definition in file BLI_compute_context.hh.