ASC_CPU_LOG

Supported Products

Product	Supported
Atlas A3 training products / Atlas A3 inference products	√
Atlas A2 training products / Atlas A2 inference products	√
Atlas 200I/500 A2 inference products	√
Atlas inference product 's AI Core	√
Atlas inference product 's Vector Core	x
Atlas training products	√

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. In general, 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 where the log is located are printed.
In the tiling offload scenario, logs are not output to the plog. Instead, they need to be flushed to disks and parsed. Before running the operator, you need to 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 set dump parameters such as enable_dump, dump_path, and dump_mode. For details, see section "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

      
           #include "utils/log/asc_cpu_log.h"

Prototype

      
           #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

**Table 1** Parameters
Parameter	Input/Output	Description
format	Input	Format control string, which contains two types: common characters and conversion specifications. Common characters are directly output. Conversion specifications are used to control the formatted output of parameters. Each conversion specification begins with a percent sign (%) and is followed by a type specifier that specifies the type of the output data. The supported data types are the same as those in C/C++.
...	Input	Variable argument list, which contains a variable number of arguments with variable types. The number and types of the arguments must match the number and types of the % tags in the format control string. Each argument will replace the corresponding % tag in the format string to achieve the expected output effect.

Returns

None

Restrictions

In the tiling offload scenario, if the custom operator project generated by the CANN package of an earlier version (which does not support the ASC_CPU_LOG API) is used, pay attention to the compatibility. In this case, calling this API cannot output logs. 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 in the custom operator project. If the field does not exist, you need to generate the custom operator project again.

Example

      
           #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

In the non-tiling offload scenario, the printed information is output to the xxxxxxx_2025xxxxxxxxxxxxx.log file. The following is an example:

       
            [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

Parent topic: log