ASC_CPU_LOG

Product Support

Function

Provides the function of printing logs on the host. You can use the ASC_CPU_LOG_XXX API in the TilingFunc code of the operator to output related content. Generally, you can also use common printing methods on the host, such as printf, for debugging. However, in the tiling offload scenario, the tiling function runs on the AI CPU, and this API must be used for printing.

• In non-tiling offload scenarios, logs are output to the plog. For example, debug logs are output to the /root/ascend/log/debug/plog directory. The log level is controlled by the environment variable ASCEND_GLOBAL_LOG_LEVEL. The log level, timestamp, code line where the log is located, and function name are printed.
• In tiling offload scenarios, logs are not output to the plog. Instead, they need to be flushed to the disk and parsed. Before running the operator, enable the dump function to make the log dump function take effect. Dump function enabling depends on the network run mode. Take the TorchAir graph mode as an example. You need to configure dump parameters such as enable_dump, dump_path, and dump_mode. For details, see "max-autotune Mode" > "Dumping Operator Inputs and Outputs (Graph Mode)" in PyTorch Graph Mode User Guide (TorchAir). The following is an example:

  import torch_npu, torchair
  config = torchair.CompilerConfig()
  # Data dump switch [required].
  config.dump_config.enable_dump = True
  # dump type: [optional] all indicates that all data is dumped.
  config.dump_config.dump_mode = "all"
  # Dump path: [optional] The current directory is the default path.
  config.dump_config.dump_path = '/home/dump'
  ...

  After the operator is executed, a log dump file is generated in the dump data storage path. The file name format is {op_type}.{op_name}.{taskid}.{stream_id}.{timestamp}, where {op_type} indicates the operator type, {op_name} indicates the operator name, and {taskid} indicates the ID of the task that calls the operator Compute API, {stream_id} indicates the ID of the stream executed by the operator, and {timestamp} indicates the timestamp.

Header File to Be Included

1

#include "utils/log/asc_cpu_log.h"

Prototype

1
2
3
4

#define ASC_CPU_LOG_ERROR(format, ...)
#define ASC_CPU_LOG_INFO(format, ...)
#define ASC_CPU_LOG_WARNING(format, ...)
#define ASC_CPU_LOG_DEBUG(format, ...)

Parameters

Returns

None

Restrictions

In the tiling offload scenario, if the custom operator project is generated using the CANN package of an earlier version (which does not support the ASC_CPU_LOG API), pay special attention to compatibility issues. In this case, logs cannot be output when this API is called. You can check whether the current project supports the log dump function by checking whether the DEVICE_OP_LOG_BY_DUMP field exists in the cmake/device_task.cmake file of the custom operator project. If the field is not found, you need to regenerate the custom operator project.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#include "utils/log/asc_cpu_log.h"

namespace optiling {
static ge::graphStatus TilingFunc(gert::TilingContext *context)
{
    TilingData tiling;
    uint32_t totalLength = context->GetInputShape(0)->GetOriginShape().GetShapeSize();
    ...
    ASC_CPU_LOG_ERROR("I am ERROR log: %d\n", 0x123);
    ASC_CPU_LOG_INFO("I am INFO log: %d\n", 0x123);
    ASC_CPU_LOG_WARNING("I am WARNING log: %d\n", 0x123);
    ASC_CPU_LOG_DEBUG("I am DEBUG log: %d\n", 0x123);
    ...
}
} // namespace optiling

1
2
3
4

[ERROR] ASCENDCKERNEL(xxx,execute_add_op):2025-xx-xx-xx:xx:xx.xxx.xxx [/xxx/xxx.cpp:xx][TilingFunc] I am ERROR log: 291
[INFO] ASCENDCKERNEL(xxx,execute_add_op):2025-xx-xx-xx:xx:xx.xxx.xxx [/xxx/xxx.cpp:xx][TilingFunc] I am INFO log: 291
[WARNING] ASCENDCKERNEL(xxx,execute_add_op):2025-xx-xx-xx:xx:xx.xxx.xxx [/xxx/xxx.cpp:xx][TilingFunc] I am WARNING log: 291
[DEBUG] ASCENDCKERNEL(xxx,execute_add_op):2025-xx-xx-xx:xx:xx.xxx.xxx [/xxx/xxx.cpp:xx][TilingFunc] I am DEBUG log: 291