Unity Tracy

[nzcv]

查找图像压缩算法的实现细节：

[3 tools called]

查看客户端如何处理图像压缩：

[3 tools called]

查看 DXT1 压缩的具体实现：

[3 tools called]

Tracy 使用两阶段压缩来处理图像数据：

图像压缩算法详解

一、第一阶段：DXT1 纹理压缩（客户端）

1. 压缩位置

在客户端，由专门的压缩线程处理：

                const auto csz = size_t( w * h / 2 );
                auto etc1buf = (char*)tracy_malloc( csz );
                CompressImageDxt1( (const char*)fi->image, etc1buf, w, h );

2. DXT1 压缩特性

• 算法：S3 纹理压缩（DXT1/BC1）
• 压缩比：8:1（每像素从 32 位压缩到 4 位）
• 格式：从 RGBA8888（4 字节/像素）→ DXT1（0.5 字节/像素）
• 类型：有损压缩，质量损失较小
• 块大小：4×4 像素块 = 8 字节

3. 性能优化

支持 SIMD 加速，性能数据（320×180 图像）：

实现	所需定义	压缩时间
x86 参考实现	---	198.2 μs
x86 SSE4.1	__SSE4_1__	25.4 μs
x86 AVX2	__AVX2__	17.4 μs
ARM 参考实现	---	1.04 ms
ARM32 NEON	__ARM_NEON	529 μs
ARM64 NEON	__ARM_NEON	438 μs

4. 处理流程

1. 用户调用 FrameImage() 传入 RGBA 数据
2. 数据存入 m_fiQueue 队列
3. 压缩线程从队列取出图像
4. 调用 CompressImageDxt1() 进行 DXT1 压缩
5. 压缩后的数据通过网络发送到服务器

---

二、第二阶段：ZSTD 压缩（服务器端）

1. 压缩位置

在服务器端接收数据后进行进一步压缩：

    m_texcomp.FixOrder( (char*)dst, sz/8 );
    m_texcomp.Rdo( (char*)dst, sz/8 );
    m_pendingFrameImageData.image = m_texcomp.Pack( m_frameImageBuffer, sz, m_pendingFrameImageData.csz, m_slab );

2. ZSTD 压缩参数

uint32_t TextureCompression::Pack( struct ZSTD_CCtx_s* ctx, char*& buf, size_t& bufsz, const char* image, uint32_t inBytes )
{
    const auto maxout = ZSTD_COMPRESSBOUND( inBytes );
    if( bufsz < maxout )
    {
        bufsz = maxout;
        delete[] buf;
        buf = new char[maxout];
    }
    assert( ctx );
    auto ret = (uint32_t)ZSTD_compressCCtx( ctx, buf, maxout, image, inBytes, 3 );

• 算法：ZSTD（Zstandard）
• 压缩级别：3（平衡压缩比与速度）
• 类型：无损压缩
• 对象：对 DXT1 压缩后的数据再次压缩

3. 服务器端优化处理

在 ZSTD 压缩前，还进行了两项优化：

1. FixOrder()：调整 DXT1 块的数据顺序，提高压缩效率
2. Rdo()：基于视觉的 RDO（Rate Distortion Optimization），在保持视觉质量的前提下进一步优化压缩

---

三、完整压缩流程

用户提供RGBA图像
    ↓
[客户端] FrameImage() - 存储到队列
    ↓
[客户端] 压缩线程 - DXT1压缩 (8:1)
    ├─ 32位/像素 → 4位/像素
    ├─ 支持SIMD加速
    └─ 质量轻微下降
    ↓
[网络传输] DXT1压缩数据
    ↓
[服务器] 接收数据
    ↓
[服务器] FixOrder() - 优化数据排列
    ↓
[服务器] Rdo() - 视觉优化压缩
    ↓
[服务器] ZSTD压缩 (级别3) - 进一步压缩
    └─ 无损压缩
    ↓
[服务器] 存储压缩后的数据

---

四、压缩效果

1. 理论压缩比

• DXT1：8:1（32 位 → 4 位）
• ZSTD：通常 2-4:1（取决于图像内容）

综合压缩比通常为 16-32:1

2. 实际示例

对于 320×180 的图像：

• 原始 RGBA：320 × 180 × 4 = 230,400 字节（约 225 KB）
• DXT1 压缩后：320 × 180 / 2 = 28,800 字节（约 28 KB）
• ZSTD 进一步压缩后：通常 < 10 KB

3. 限制

• 单帧图像压缩后不能超过 256 KB（网络缓冲限制）
• 960×540 的图像可以满足此限制

---

五、关键代码位置

1. 客户端 DXT1 压缩：

   • public/client/TracyDxt1.cpp - DXT1 压缩实现
   • public/client/TracyProfiler.cpp:2288 - 调用压缩函数

2. 服务器端 ZSTD 压缩：

   • server/TracyTextureCompression.cpp - ZSTD 压缩实现
   • server/TracyWorker.cpp:3887 - 调用压缩函数

3. 服务器端解压：

   • server/TracyTextureCompression.cpp:62-80 - 解压函数

---

六、总结

Tracy 使用两阶段压缩：

1. DXT1 纹理压缩（客户端，有损）

   • 8:1 压缩比
   • 支持 SIMD 加速
   • 质量损失小

2. ZSTD 压缩（服务器端，无损）

   • 对 DXT1 数据再次压缩
   • 压缩级别 3
   • 进一步减小存储空间

该方案在保持视觉质量的同时，显著减少内存和网络传输开销。

[nzcv]

搜索与移动端截屏相关的代码。

[3 tools called]

继续搜索移动端图形API相关的实现：

[3 tools called]

查看客户端发送帧图像的具体实现：

[4 tools called]

查看是否有移动平台特定实现或示例：

[3 tools called]

以下是 Tracy 在移动端截屏的说明：

Tracy 移动端截屏实现详解

一、核心概念

Tracy 提供了 FrameImage 宏用于将截屏数据发送到分析器，但需要开发者自行从 GPU 获取帧缓冲数据。Tracy 负责数据压缩、传输和显示。

二、API 接口

1. FrameImage 宏定义

FrameImage(image, width, height, offset, flip)

参数：

• image: RGBA 像素数据指针（8 位/通道）
• width, height: 宽高，必须能被 4 整除
• offset: 帧延迟（当前图像对应之前多少帧）
• flip: 是否需要垂直翻转（OpenGL 通常为 true，Vulkan 通常为 false）

2. 实现位置

查看 public/client/TracyProfiler.hpp 中的 SendFrameImage：

    static tracy_force_inline void SendFrameImage( const void* image, uint16_t w, uint16_t h, uint8_t offset, bool flip )
    {
#ifndef TRACY_NO_FRAME_IMAGE
        auto& profiler = GetProfiler();
        assert( profiler.m_frameCount.load( std::memory_order_relaxed ) < (std::numeric_limits<uint32_t>::max)() );
#  ifdef TRACY_ON_DEMAND
        if( !profiler.IsConnected() ) return;
#  endif
        const auto sz = size_t( w ) * size_t( h ) * 4;
        auto ptr = (char*)tracy_malloc( sz );
        memcpy( ptr, image, sz );

        profiler.m_fiLock.lock();
        auto fi = profiler.m_fiQueue.prepare_next();
        fi->image = ptr;
        fi->frame = uint32_t( profiler.m_frameCount.load( std::memory_order_relaxed ) - offset );
        fi->w = w;
        fi->h = h;
        fi->flip = flip;
        profiler.m_fiQueue.commit_next();
        profiler.m_fiLock.unlock();
#else
        static_cast<void>(image); // unused
        static_cast<void>(w); // unused
        static_cast<void>(h); // unused
        static_cast<void>(offset); // unused
        static_cast<void>(flip); // unused
#endif
    }

三、移动端实现方案

方案 1：OpenGL ES（Android/iOS）

流程与 OpenGL 类似，但需注意 OpenGL ES 的限制。

1. 初始化资源（文档示例）：

GLuint m_fiTexture[4];      // 存储缩略图的纹理
GLuint m_fiFramebuffer[4];  // FBO用于写入纹理
GLuint m_fiPbo[4];          // PBO用于CPU访问
GLsync m_fiFence[4];        // 同步对象
int m_fiIdx = 0;            // 当前使用的缓冲区索引
std::vector<int> m_fiQueue; // 等待完成的队列

// 初始化（每个缓冲区320x180，RGBA格式）
glGenTextures(4, m_fiTexture);
glGenFramebuffers(4, m_fiFramebuffer);
glGenBuffers(4, m_fiPbo);
for(int i=0; i<4; i++)
{
    glBindTexture(GL_TEXTURE_2D, m_fiTexture[i]);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 320, 180, 0, GL_RGBA, GL_UNSIGNED_BYTE, nullptr);

    glBindFramebuffer(GL_FRAMEBUFFER, m_fiFramebuffer[i]);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
        m_fiTexture[i], 0);

    glBindBuffer(GL_PIXEL_PACK_BUFFER, m_fiPbo[i]);
    glBufferData(GL_PIXEL_PACK_BUFFER, 320*180*4, nullptr, GL_STREAM_READ);
}

2. 在 Present 前发起截屏：

// 在swap buffers或present之前调用
assert(m_fiQueue.empty() || m_fiQueue.front() != m_fiIdx);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, m_fiFramebuffer[m_fiIdx]);
glBlitFramebuffer(0, 0, screenWidth, screenHeight, 0, 0, 320, 180, 
                  GL_COLOR_BUFFER_BIT, GL_LINEAR);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBindFramebuffer(GL_READ_FRAMEBUFFER, m_fiFramebuffer[m_fiIdx]);
glBindBuffer(GL_PIXEL_PACK_BUFFER, m_fiPbo[m_fiIdx]);
glReadPixels(0, 0, 320, 180, GL_RGBA, GL_UNSIGNED_BYTE, nullptr);
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
m_fiFence[m_fiIdx] = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
m_fiQueue.emplace_back(m_fiIdx);
m_fiIdx = (m_fiIdx + 1) % 4;

3. 在下一帧检查并获取数据：

// 在下一帧开始时（或在实际渲染之前）检查
while(!m_fiQueue.empty())
{
    const auto fiIdx = m_fiQueue.front();
    if(glClientWaitSync(m_fiFence[fiIdx], 0, 0) == GL_TIMEOUT_EXPIRED) 
        break;  // 还没准备好，下一帧再试
    
    glDeleteSync(m_fiFence[fiIdx]);
    glBindBuffer(GL_PIXEL_PACK_BUFFER, m_fiPbo[fiIdx]);
    auto ptr = glMapBufferRange(GL_PIXEL_PACK_BUFFER, 0, 320*180*4, GL_MAP_READ_BIT);
    
    // 发送到Tracy
    FrameImage(ptr, 320, 180, m_fiQueue.size(), true);  // OpenGL需要flip=true
    
    glUnmapBuffer(GL_PIXEL_PACK_BUFFER);
    m_fiQueue.erase(m_fiQueue.begin());
}

注意：

• 使用 4 个缓冲区处理 GPU/CPU 异步
• 使用 Fence 同步，避免阻塞
• 使用硬件缩放（glBlitFramebuffer），而非 CPU 缩放

方案 2：Vulkan（Android）

思路类似，但使用 Vulkan API：

1. 创建资源：

   • 创建 4 个图像（320x180，RGBA8）
   • 创建对应的 ImageView 和 Framebuffer
   • 创建 CommandBuffer、Fence 用于同步

2. 截屏流程：

   • 在 render pass 结束时，使用 vkCmdBlitImage 缩放
   • 使用 vkCmdCopyImageToBuffer 复制到 staging buffer
   • 提交命令并等待 Fence

3. 获取并发送：

vkWaitForFences(device, 1, &fence, VK_TRUE, UINT64_MAX);
void* data;
vkMapMemory(device, stagingMemory, 0, 320*180*4, 0, &data);
FrameImage(data, 320, 180, offset, false);  // Vulkan不需要flip
vkUnmapMemory(device, stagingMemory);

方案 3：Metal（iOS）

使用 Metal 时需从 render target 获取数据：

1. 创建资源：

// 创建纹理和buffer
id<MTLTexture> captureTexture = [device newTextureWithDescriptor:textureDesc];
id<MTLBuffer> captureBuffer = [device newBufferWithLength:320*180*4 
                                                  options:MTLResourceStorageModeShared];

2. 在渲染完成后：

id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];
[blitEncoder copyFromTexture:renderTarget 
                  sourceSlice:0 
                  sourceLevel:0 
                 sourceOrigin:MTLOriginMake(0, 0, 0)
                   sourceSize:MTLSizeMake(screenWidth, screenHeight, 1)
                     toTexture:captureTexture
              destinationSlice:0
              destinationLevel:0
             destinationOrigin:MTLOriginMake(0, 0, 0)];
[blitEncoder copyFromTexture:captureTexture
                     toBuffer:captureBuffer
              destinationOffset:0
         destinationBytesPerRow:320*4
       destinationBytesPerImage:320*180*4
                        options:MTLBlitOptionNone];
[blitEncoder endEncoding];
[commandBuffer commit];
[commandBuffer waitUntilCompleted];

3. 获取数据并发送：

uint8_t* data = (uint8_t*)[captureBuffer contents];
FrameImage(data, 320, 180, offset, false);  // Metal通常不需要flip

四、重要注意事项

1. 性能

• 图像会被压缩（DXT1），但原始数据仍较大
• 建议分辨率：320x180 或更小
• 使用硬件缩放和异步传输，避免阻塞渲染

2. 内存与带宽

• 单帧 1080p 未压缩约 8MB
• 压缩后单帧不超过 256KB（网络缓冲限制）
• 960×540 可在限制内

3. 尺寸限制

• 宽高必须能被 4 整除
• 压缩后大小不能超过 256KB

4. 禁用帧图像功能

如果不需要，可定义宏禁用：

#define TRACY_NO_FRAME_IMAGE

这样可以避免启动压缩线程，降低开销。

5. 平台差异

• OpenGL/OpenGL ES: flip = true
• Vulkan: flip = false
• Metal: 通常 flip = false（取决于坐标系统）

五、完整示例结构

class FrameCapture {
    // OpenGL ES 示例
    GLuint textures[4];
    GLuint framebuffers[4];
    GLuint pbos[4];
    GLsync fences[4];
    int currentIdx = 0;
    std::vector<int> pendingQueue;
    
    void Init() {
        // 初始化资源...
    }
    
    void CaptureFrame() {
        // 在present前调用
        // 1. Blit到小纹理
        // 2. 读取到PBO
        // 3. 创建Fence
        // 4. 加入队列
    }
    
    void RetrieveFrames() {
        // 在下一帧开始时调用
        // 1. 检查Fence状态
        // 2. 映射PBO
        // 3. 调用FrameImage
        // 4. 清理
    }
};

// 使用
FrameCapture capture;
capture.Init();

while(running) {
    capture.RetrieveFrames();  // 处理上一帧的截屏
    
    // 正常渲染...
    
    capture.CaptureFrame();     // 发起新的截屏
    SwapBuffers();
}

六、总结

移动端截屏要点：

1. Tracy 提供 FrameImage API，开发者负责从 GPU 获取数据
2. 使用硬件缩放和异步传输以提升性能
3. 使用环形缓冲区和同步对象处理 GPU/CPU 异步
4. 控制图像尺寸以符合内存和带宽限制
5. 按平台（OpenGL ES/Vulkan/Metal）选择正确的 API 和参数

该机制是通用的，关键在正确实现各平台的 GPU 数据读取部分。

[nzcv]

搜索代码库中与 Android 堆栈回溯相关的实现。

[3 tools called]

查看 Android 平台堆栈回溯的具体实现：

[3 tools called]

查看符号解析部分的实现：

[2 tools called]

Android 平台上的堆栈回溯实现如下：

Android 平台堆栈回溯实现

1. 平台检测与配置

在 TracyCallstack.h 中，Android 平台的配置如下：

#  elif defined __ANDROID__
#    if !defined __arm__ || __ANDROID_API__ >= 21
#      define TRACY_HAS_CALLSTACK 2
#    else
#      define TRACY_HAS_CALLSTACK 5
#    endif

• 非 ARM 架构，或 ARM 且 API >= 21：使用 TRACY_HAS_CALLSTACK 2（使用 libbacktrace）
• ARM 且 API < 21：使用 TRACY_HAS_CALLSTACK 5（仅使用 dlfcn）

2. 堆栈回溯实现

Android 使用 _Unwind_Backtrace（来自 <unwind.h>）进行堆栈回溯：

#elif TRACY_HAS_CALLSTACK == 2 || TRACY_HAS_CALLSTACK == 5

struct BacktraceState
{
    void** current;
    void** end;
};

static _Unwind_Reason_Code tracy_unwind_callback( struct _Unwind_Context* ctx, void* arg )
{
    auto state = (BacktraceState*)arg;
    uintptr_t pc = _Unwind_GetIP( ctx );
    if( pc )
    {
        if( state->current == state->end ) return _URC_END_OF_STACK;
        *state->current++ = (void*)pc;
    }
    return _URC_NO_REASON;
}

static tracy_force_inline void* Callstack( int32_t depth )
{
    assert( depth >= 1 && depth < 63 );

    auto trace = (uintptr_t*)tracy_malloc( ( 1 + depth ) * sizeof( uintptr_t ) );
    BacktraceState state = { (void**)(trace+1), (void**)(trace+1+depth) };
    _Unwind_Backtrace( tracy_unwind_callback, &state );

    *trace = (uintptr_t*)state.current - trace + 1;

    return trace;
}

3. 实现要点

• 使用 _Unwind_Backtrace 遍历堆栈帧
• 回调函数 tracy_unwind_callback 通过 _Unwind_GetIP 获取每个帧的程序计数器（PC）
• 将 PC 地址保存到缓冲区
• 符号解析：
  • TRACY_HAS_CALLSTACK == 2：使用 libbacktrace 解析符号
  • TRACY_HAS_CALLSTACK == 5：使用 dlfcn.h 和 cxxabi.h 进行基本解析

4. 关键 API

• _Unwind_Backtrace()：遍历堆栈
• _Unwind_GetIP()：获取当前帧的 PC
• _Unwind_Context：表示堆栈帧上下文

5. 注意事项

• 需要包含 <unwind.h>
• 编译时建议使用 -fno-omit-frame-pointer 以提高回溯质量
• 需要调试信息（-g）才能解析符号名称
• Android 8.0+ 对 /proc 文件系统的访问受限，可能影响某些系统信息获取

这是基于 C++ 异常处理机制（Itanium ABI）的标准堆栈展开方式，在 Android 上广泛使用。

[nzcv]

查看符号解析的实现：

[2 tools called]

查看符号解析的完整实现：

[3 tools called]

查看初始化部分：

[2 tools called]

符号解析流程如下：

符号解析流程

1. 初始化阶段 (InitCallstack)

在 InitCallstack() 中创建 backtrace_state：

void InitCallstack()
{
    InitRpmalloc();

#ifdef TRACY_HAS_DL_ITERATE_PHDR_TO_REFRESH_IMAGE_CACHE
    CreateImageCaches();
#endif //#ifdef TRACY_HAS_DL_ITERATE_PHDR_TO_REFRESH_IMAGE_CACHE

#ifndef TRACY_SYMBOL_OFFLINE_RESOLVE
    s_shouldResolveSymbolsOffline = ShouldResolveSymbolsOffline();
#endif //#ifndef TRACY_SYMBOL_OFFLINE_RESOLVE
    if( s_shouldResolveSymbolsOffline )
    {
        cb_bts = nullptr; // disable use of libbacktrace calls
        TracyDebug("TRACY: enabling offline symbol resolving!\n");
    }
    else
    {
        cb_bts = backtrace_create_state( nullptr, 0, nullptr, nullptr );
    }

• 创建 backtrace_state（用于符号解析）
• 创建图像缓存（用于地址到模块的映射）
• 初始化名称还原缓冲区

2. 符号解析实现（Android 平台）

Android 有两种实现：

方式 A: TRACY_HAS_CALLSTACK == 2（使用 libbacktrace）

使用 libbacktrace 进行解析：

CallstackEntryData DecodeCallstackPtr( uint64_t ptr )
{
    InitRpmalloc();
    if ( !IsKernelAddress( ptr ) )
    {
        const char* imageName = nullptr;
        uint64_t imageBaseAddress = 0x0;

#ifdef TRACY_HAS_DL_ITERATE_PHDR_TO_REFRESH_IMAGE_CACHE
        const auto* image = s_imageCache->GetImageForAddress( ptr );
        if( image )
        {
            imageName = image->m_name;
            imageBaseAddress = uint64_t( image->m_startAddress );
        }
#else
        Dl_info dlinfo;
        if( dladdr( (void*)ptr, &dlinfo ) )
        {
            imageName = dlinfo.dli_fname;
            imageBaseAddress = uint64_t( dlinfo.dli_fbase );
        }
#endif

        if( s_shouldResolveSymbolsOffline )
        {
            cb_num = 1;
            GetSymbolForOfflineResolve( (void*)ptr, imageBaseAddress, cb_data[0] );
        }
        else
        {
            cb_num = 0;
            backtrace_pcinfo( cb_bts, ptr, CallstackDataCb, CallstackErrorCb, nullptr );
            assert( cb_num > 0 );

            backtrace_syminfo( cb_bts, ptr, SymInfoCallback, SymInfoError, nullptr );
        }

        return { cb_data, uint8_t( cb_num ), imageName ? imageName : "[unknown]" };
    }

步骤：

1. 确定模块：通过图像缓存或 dladdr 找到地址所属的模块
2. 解析文件/行号：调用 backtrace_pcinfo()，从 DWARF 调试信息获取文件名和行号
3. 解析符号信息：调用 backtrace_syminfo()，从符号表获取符号名称和大小

回调函数处理解析结果：

static int CallstackDataCb( void* /*data*/, uintptr_t pc, uintptr_t lowaddr, const char* fn, int lineno, const char* function )
{
    cb_data[cb_num].symLen = 0;
    cb_data[cb_num].symAddr = (uint64_t)lowaddr;

    if( !fn && !function )
    {
        const char* symname = nullptr;
        auto vptr = (void*)pc;
        ptrdiff_t symoff = 0;

        Dl_info dlinfo;
        if( dladdr( vptr, &dlinfo ) )
        {
            symname = dlinfo.dli_sname;
            symoff = (char*)pc - (char*)dlinfo.dli_saddr;
            const char* demangled = ___tracy_demangle( symname );
            if( demangled ) symname = demangled;
        }

        if( !symname ) symname = "[unknown]";

        if( symoff == 0 )
        {
            const auto len = std::min<size_t>( strlen( symname ), std::numeric_limits<uint16_t>::max() );
            cb_data[cb_num].name = CopyStringFast( symname, len );
        }
        else
        {
            char buf[32];
            const auto offlen = sprintf( buf, " + %td", symoff );
            const auto namelen = std::min<size_t>( strlen( symname ), std::numeric_limits<uint16_t>::max() - offlen );
            auto name = (char*)tracy_malloc_fast( namelen + offlen + 1 );
            memcpy( name, symname, namelen );
            memcpy( name + namelen, buf, offlen );
            name[namelen + offlen] = '\0';
            cb_data[cb_num].name = name;
        }

        cb_data[cb_num].file = CopyStringFast( "[unknown]" );
        cb_data[cb_num].line = 0;
    }
    else
    {
        if( !fn ) fn = "[unknown]";
        if( !function )
        {
            function = "[unknown]";
        }
        else
        {
            const char* demangled = ___tracy_demangle( function );
            if( demangled ) function = demangled;
        }

        const auto len = std::min<size_t>( strlen( function ), std::numeric_limits<uint16_t>::max() );
        cb_data[cb_num].name = CopyStringFast( function, len );
        cb_data[cb_num].file = NormalizePath( fn );
        if( !cb_data[cb_num].file ) cb_data[cb_num].file = CopyStringFast( fn );
        cb_data[cb_num].line = lineno;
    }

    if( ++cb_num >= MaxCbTrace )
    {
        return 1;
    }
    else
    {
        return 0;
    }
}

方式 B: TRACY_HAS_CALLSTACK == 5（仅使用 dladdr）

旧版 ARM Android 仅使用 dladdr：

CallstackEntryData DecodeCallstackPtr( uint64_t ptr )
{
    static CallstackEntry cb;
    cb.line = 0;

    const char* symname = nullptr;
    const char* symloc = nullptr;
    auto vptr = (void*)ptr;
    ptrdiff_t symoff = 0;
    void* symaddr = nullptr;

    Dl_info dlinfo;
    if( dladdr( vptr, &dlinfo ) )
    {
        symloc = dlinfo.dli_fname;
        symname = dlinfo.dli_sname;
        symoff = (char*)ptr - (char*)dlinfo.dli_saddr;
        symaddr = dlinfo.dli_saddr;
        const char* demangled = ___tracy_demangle( symname );
        if( demangled ) symname = demangled;
    }

    if( !symname ) symname = "[unknown]";
    if( !symloc ) symloc = "[unknown]";

    if( symoff == 0 )
    {
        const auto len = std::min<size_t>( strlen( symname ), std::numeric_limits<uint16_t>::max() );
        cb.name = CopyString( symname, len );
    }
    else
    {
        char buf[32];
        const auto offlen = sprintf( buf, " + %td", symoff );
        const auto namelen = std::min<size_t>( strlen( symname ), std::numeric_limits<uint16_t>::max() - offlen );
        auto name = (char*)tracy_malloc( namelen + offlen + 1 );
        memcpy( name, symname, namelen );
        memcpy( name + namelen, buf, offlen );
        name[namelen + offlen] = '\0';
        cb.name = name;
    }

    cb.file = CopyString( "[unknown]" );
    cb.symLen = 0;
    cb.symAddr = (uint64_t)symaddr;

    return { &cb, 1, symloc };
}

3. 符号名称还原（Demangling）

C++ 符号名称需要还原：

extern "C" const char* ___tracy_demangle( const char* mangled )
{
    if( !mangled || mangled[0] != '_' ) return nullptr;
    if( strlen( mangled ) > ___tracy_demangle_buffer_len ) return nullptr;
    int status;
    size_t len = ___tracy_demangle_buffer_len;
    return abi::__cxa_demangle( mangled, ___tracy_demangle_buffer, &len, &status );
}

使用 abi::__cxa_demangle() 将 C++ 修饰名还原为可读名称。

4. 符号解析的数据源

• DWARF 调试信息：用于文件/行号（需要 -g 编译）
• ELF 符号表：用于符号名称和地址
• 动态链接信息：通过 dladdr 获取模块信息

5. 离线符号解析

设置 TRACY_SYMBOL_OFFLINE_RESOLVE=1 时，仅保存地址偏移和模块名，后续离线解析：

void GetSymbolForOfflineResolve(void* address, uint64_t imageBaseAddress, CallstackEntry& cbEntry)
{
    // tagged with a string that we can identify as an unresolved symbol
    cbEntry.name = CopyStringFast( "[unresolved]" );
    // set .so relative offset so it can be resolved offline
    cbEntry.symAddr = (uint64_t)address - imageBaseAddress;
    cbEntry.symLen = 0x0;
    cbEntry.file = CopyStringFast( "[unknown]" );
    cbEntry.line = 0;
}

总结

Android 平台的符号解析流程：

1. 初始化：创建 backtrace_state 和图像缓存
2. 地址到模块映射：通过图像缓存或 dladdr 确定模块
3. 符号解析：
   • 方式 A（libbacktrace）：从 DWARF 获取文件/行号，从符号表获取符号名
   • 方式 B（dladdr）：仅获取符号名，无文件/行号
4. 名称还原：使用 __cxa_demangle 还原 C++ 符号
5. 结果组装：返回函数名、文件名、行号等信息

这种方式可提供完整的调用栈信息，前提是编译时包含调试信息。

[nzcv]

查看 Tracy 如何保存堆栈数据，特别是相同堆栈的去重机制：

[3 tools called]

查看数据结构和哈希机制：

[4 tools called]

查看 VarArray 的哈希和比较实现，以及内存分配相关的存储：

[3 tools called]

查看内存分配事件的结构：

[2 tools called]

Tracy 的堆栈数据存储与去重机制如下：

堆栈数据存储与去重机制

1. 数据结构

堆栈存储结构

        unordered_flat_map<VarArray<CallstackFrameId>*, uint32_t, VarArrayHasher<CallstackFrameId>, VarArrayComparator<CallstackFrameId>> callstackMap;
        Vector<short_ptr<VarArray<CallstackFrameId>>> callstackPayload;

• callstackMap: 哈希表，键为 VarArray<CallstackFrameId>*，值为索引（uint32_t）
• callstackPayload: 向量，存储所有唯一的堆栈数组

VarArray 的哈希计算

template<typename T>
inline void VarArray<T>::CalcHash()
{
    m_hash = uint32_t( XXH3_64bits( m_ptr.get(), m_size * sizeof( T ) ) );
}

使用 XXH3 计算哈希值。

哈希和比较函数

template<typename T>
struct VarArrayHasher
{
    size_t operator()( const VarArray<T>* arr ) const
    {
        return arr->get_hash();
    }
};

template<typename T>
struct VarArrayComparator
{
    bool operator()( const VarArray<T>* lhs, const VarArray<T>* rhs ) const
    {
        return Compare( *lhs, *rhs );
    }
};

2. 去重流程

当收到新的堆栈数据时：

void Worker::AddCallstackPayload( const char* _data, size_t _sz )
{
    assert( m_pendingCallstackId == 0 );

    const auto sz = _sz / sizeof( uint64_t );
    const auto memsize = sizeof( VarArray<CallstackFrameId> ) + sz * sizeof( CallstackFrameId );
    auto mem = (char*)m_slab.AllocRaw( memsize );

    auto data = (CallstackFrameId*)mem;
    auto dst = data;
    auto src = (uint64_t*)_data;
    for( size_t i=0; i<sz; i++ )
    {
        *dst++ = PackPointer( *src++ );
    }

    auto arr = (VarArray<CallstackFrameId>*)( mem + sz * sizeof( CallstackFrameId ) );
    new(arr) VarArray<CallstackFrameId>( sz, data );

    uint32_t idx;
    auto it = m_data.callstackMap.find( arr );
    if( it == m_data.callstackMap.end() )
    {
        idx = m_data.callstackPayload.size();
        m_data.callstackMap.emplace( arr, idx );
        m_data.callstackPayload.push_back( arr );

        for( auto& frame : *arr )
        {
            QueryCallstackFrame( GetCanonicalPointer( frame ) );
        }
    }
    else
    {
        idx = it->second;
        m_slab.Unalloc( memsize );
    }

    m_pendingCallstackId = idx;
}

步骤：

1. 分配内存并构建 VarArray<CallstackFrameId>
2. 计算哈希（构造时自动计算）
3. 在 callstackMap 中查找
4. 如果不存在：
   • 分配新索引
   • 插入 callstackMap 和 callstackPayload
   • 查询堆栈帧信息
5. 如果已存在：
   • 使用已有索引
   • 释放刚分配的内存（去重）

3. 内存分配与堆栈关联

内存分配事件通过索引引用堆栈：

struct MemEvent
{
    tracy_force_inline uint64_t Ptr() const { return uint64_t( int64_t( _ptr_csalloc1 ) >> 8 ); }
    tracy_force_inline void SetPtr( uint64_t ptr ) { memcpy( ((char*)&_ptr_csalloc1)+1, &ptr, 4 ); memcpy( ((char*)&_ptr_csalloc1)+5, ((char*)&ptr)+4, 2 ); memcpy( ((char*)&_ptr_csalloc1)+7, ((char*)&ptr)+6, 1 ); }
    tracy_force_inline uint64_t Size() const { return _size_csalloc2 >> 16; }
    tracy_force_inline void SetSize( uint64_t size ) { assert( size < ( 1ull << 47 ) ); memcpy( ((char*)&_size_csalloc2)+2, &size, 4 ); memcpy( ((char*)&_size_csalloc2)+6, ((char*)&size)+4, 2 ); }
    tracy_force_inline uint32_t CsAlloc() const { return uint8_t( _ptr_csalloc1 ) | ( uint16_t( _size_csalloc2 ) << 8 ); }
    tracy_force_inline void SetCsAlloc( uint32_t csAlloc ) { memcpy( &_ptr_csalloc1, &csAlloc, 1 ); memcpy( &_size_csalloc2, ((char*)&csAlloc)+1, 2 ); }
    // ...
    uint64_t _ptr_csalloc1;
    uint64_t _size_csalloc2;
    Int24 csFree;

• CsAlloc(): 分配时的堆栈索引（24 位）
• csFree: 释放时的堆栈索引（24 位）

处理内存分配时：

void Worker::ProcessMemAllocCallstack( const QueueMemAlloc& ev )
{
    auto mem = ProcessMemAlloc( ev );
    assert( m_serialNextCallstack != 0 );
    if( mem ) mem->SetCsAlloc( m_serialNextCallstack );
    m_serialNextCallstack = 0;
}

4. 优化效果

• 相同堆栈只存储一次：多个分配共享同一堆栈时，只保存一份
• 使用索引引用：每个 MemEvent 仅存储 24 位索引，而非完整堆栈
• 哈希快速查找：XXH3 哈希 + 哈希表，查找接近 O(1)
• 内存节省：相同堆栈复用，避免重复存储

5. 示例

假设有 1000 次内存分配，都来自同一个调用栈：

• 传统方式：存储 1000 份完整堆栈数据
• Tracy 方式：
  • 堆栈数据：存储 1 份
  • 索引：1000 个 MemEvent 各存储 1 个 24 位索引（3 字节）
  • 节省：约 99% 的堆栈存储空间

总结

Tracy 通过以下方式实现去重：

1. 使用 VarArray 存储堆栈帧数组
2. 使用 XXH3 计算哈希值
3. 使用哈希表 callstackMap 进行去重查找
4. 相同堆栈只存储一次，其他位置使用索引引用
5. 内存分配事件通过 24 位索引关联堆栈

这样在大量相同堆栈的场景下，可显著减少内存占用。

[nzcv]

查看并发场景下相同堆栈的处理机制：

[3 tools called]

查看客户端如何发送堆栈数据，以及服务端的处理流程：

[4 tools called]

查看 Worker 线程如何单线程处理所有数据：

[3 tools called]

Tracy 通过单线程处理 + 无锁队列解决并发分配堆栈相同的问题：

并发分配堆栈相同的解决方案

1. 架构设计：MPSC（多生产者单消费者）

• 客户端（多线程）：多个线程并发写入 lock-free 队列
• 服务端（单线程）：Worker 线程串行处理所有数据

2. 客户端：Lock-Free 队列写入

多个线程并发分配内存时，各自将堆栈数据写入 lock-free 队列：

void Profiler::SendCallstack( int32_t depth, const char* skipBefore )
{
#ifdef TRACY_HAS_CALLSTACK
    auto ptr = Callstack( depth );
    CutCallstack( ptr, skipBefore );

    TracyQueuePrepare( QueueType::Callstack );
    MemWrite( &item->callstackFat.ptr, (uint64_t)ptr );
    TracyQueueCommit( callstackFatThread );
#endif
}

• 使用 TracyQueuePrepare 和 TracyQueueCommit 宏写入队列
• 基于 moodycamel::ConcurrentQueue 的 lock-free 实现
• 多线程可并发写入，无需互斥锁

3. 服务端：单线程串行处理

Worker 线程的 Exec() 函数单线程处理所有数据：

    for(;;)
    {
        if( m_shutdown.load( std::memory_order_relaxed ) || ( m_memoryLimit > 0 && memUsage.load( std::memory_order_relaxed ) > m_memoryLimit ) )
        {
            QueryTerminate();
            goto close;
        }

        NetBuffer netbuf;
        {
            std::unique_lock<std::mutex> lock( m_netReadLock );
            m_netReadCv.wait( lock, [this] { return !m_netRead.empty(); } );
            netbuf = m_netRead.front();
            m_netRead.erase( m_netRead.begin() );
        }
        if( netbuf.bufferOffset < 0 ) goto close;

        const char* ptr = m_buffer + netbuf.bufferOffset;
        const char* end = ptr + netbuf.size;

        {
            std::unique_lock<std::mutex> lk( m_data.lock );
            if( m_data.mainThreadWantsLock )
            {
                // Hand over the lock to the main thread to avoid starving it.
                // Wait for a millisecond maximum to avoid the opposite 
                // problem where main thread would never let us execute
                m_data.lockCv.wait_for( lk, std::chrono::milliseconds( 1 ) );
            }

            while( ptr < end )
            {
                auto ev = (const QueueItem*)ptr;
                if( !DispatchProcess( *ev, ptr ) )
                {
                    if( m_failure != Failure::None ) HandleFailure( ptr, end );
                    QueryTerminate();
                    goto close;
                }
            }

• 单线程处理，保证串行化
• 堆栈去重操作在单线程中执行，无需额外同步

4. 堆栈去重：单线程安全

在单线程环境中进行去重：

void Worker::AddCallstackPayload( const char* _data, size_t _sz )
{
    assert( m_pendingCallstackId == 0 );

    const auto sz = _sz / sizeof( uint64_t );
    const auto memsize = sizeof( VarArray<CallstackFrameId> ) + sz * sizeof( CallstackFrameId );
    auto mem = (char*)m_slab.AllocRaw( memsize );

    auto data = (CallstackFrameId*)mem;
    auto dst = data;
    auto src = (uint64_t*)_data;
    for( size_t i=0; i<sz; i++ )
    {
        *dst++ = PackPointer( *src++ );
    }

    auto arr = (VarArray<CallstackFrameId>*)( mem + sz * sizeof( CallstackFrameId ) );
    new(arr) VarArray<CallstackFrameId>( sz, data );

    uint32_t idx;
    auto it = m_data.callstackMap.find( arr );
    if( it == m_data.callstackMap.end() )
    {
        idx = m_data.callstackPayload.size();
        m_data.callstackMap.emplace( arr, idx );
        m_data.callstackPayload.push_back( arr );

        for( auto& frame : *arr )
        {
            QueryCallstackFrame( GetCanonicalPointer( frame ) );
        }
    }
    else
    {
        idx = it->second;
        m_slab.Unalloc( memsize );
    }

    m_pendingCallstackId = idx;
}

• 在单线程中执行，无需锁
• 哈希表查找和插入是线程安全的（单线程访问）

5. 数据流

线程1 (分配内存) ──┐
线程2 (分配内存) ──┼──> Lock-Free Queue (MPSC) ──> Worker Thread (单线程)
线程3 (分配内存) ──┘                                    │
                                                         ├──> AddCallstackPayload()
                                                         │    (单线程去重)
                                                         └──> callstackMap (无需锁)

6. 优势

• 无锁设计：客户端使用 lock-free 队列，服务端单线程处理
• 性能：避免锁竞争，多线程写入无阻塞
• 正确性：单线程去重保证一致性
• 内存效率：相同堆栈只存储一次

7. 关键点

1. 客户端并发写入：多个线程可同时写入 lock-free 队列
2. 服务端串行处理：Worker 线程按顺序处理所有事件
3. 去重在服务端：在单线程环境中进行，无需同步
4. 状态管理：使用 m_pendingCallstackId 在事件间传递堆栈索引

总结

Tracy 通过 MPSC 架构解决并发分配堆栈相同的问题：

• 客户端：多线程并发写入 lock-free 队列（无锁）
• 服务端：单线程串行处理（无需锁保护去重操作）

这样既保证了线程安全，又避免了锁带来的性能开销。

[nzcv]

分析 short_ptr 的设计目的。先查看实现代码。

[2 tools called]

查看 short_ptr 的具体使用场景：

[2 tools called]

查看 TracyVector.hpp 中 short_ptr 的使用：

[2 tools called]

short_ptr 的设计目的分析

1. 内存优化（主要目的）

在 64 位系统上：

• 标准指针：8 字节
• short_ptr：6 字节
• 节省：25% 内存

2. 利用 48 位地址空间限制

现代 64 位系统（x64、ARM64）实际只使用 48 位地址空间：

• 有效地址范围：0x0000000000000000 到 0x00007FFFFFFFFFFF（用户空间）
• 高 16 位必须进行符号扩展（全 0 或全 1）
• short_ptr 只存储低 48 位（6 字节），通过断言确保高 16 位为 0

        assert( ( uint64_t( ptr ) & 0xFFFF000000000000 ) == 0 );

3. 使用场景

short_ptr 被广泛用于存储大量指针的场景：

• Vector<T>：存储数据指针
• VarArray<T>：存储数组指针
• 事件数据结构：ZoneEvent、GpuEvent、MessageData 等
• Worker 类：存储大量事件指针的容器

4. 性能影响

• 提高缓存局部性：相同内存可容纳更多指针
• 减少内存占用：处理大量事件时更明显
• 降低内存带宽压力：适合性能分析工具的高吞吐场景

5. 实现细节

• 64 位系统：使用 6 字节存储（低 32 位 + 高 16 位）
• 32 位系统：直接使用标准指针（无优化）
• 通过 memcpy 进行字节级操作，避免对齐问题

总结

short_ptr 是一个内存优化技巧，利用 64 位系统的 48 位地址空间限制，将指针从 8 字节压缩到 6 字节。在 Tracy 这种需要处理大量事件数据的性能分析工具中，这种优化可以显著减少内存占用并提升性能。

[yhnu]

#define TracyAllocS( ptr, size, depth ) tracy::Profiler::MemAllocCallstack( ptr, size, depth, false )
#define TracyFreeS( ptr, depth ) tracy::Profiler::MemFreeCallstack( ptr, depth, false )
#define TracySecureAllocS( ptr, size, depth ) tracy::Profiler::MemAllocCallstack( ptr, size, depth, true )
#define TracySecureFreeS( ptr, depth ) tracy::Profiler::MemFreeCallstack( ptr, depth, true )