Linux下VA-API可实现JPEG硬解到Intel iGPU显存：需用vaCreateSurfaces分配YUV420 surface并设DECODER hint，走完整vaBegin/Render/End流程，再通过vaExportSurfaceHandle获取DMA-BUF fd，经EGL image绑定至OpenGL纹理，全程零拷贝。
Linux 下用 VA-API 调用 Intel iGPU 硬件 JPEG 解码器
目前没有标准 C++ 接口能“直接把 JPEG 解码到显存”，必须依赖平台特定的硬件抽象层。在 Linux + Intel 集成显卡（如 Tiger Lake 及以后）上，VA-API 是最可行路径：它允许你分配 VASurfaceID 显存表面，让解码器输出直接写入其中，避免 CPU 内存拷贝。
关键不是“C++ 语言能力”，而是能否绕过用户态像素拷贝。典型错误是调用 vaPutImage() 或手动映射 VASurfaceID 到 CPU 地址 —— 这会强制回写到系统内存，彻底失去显存直通意义。
- 必须用
vaCreateSurfaces()分配类型为VASurfaceAttribPixelFormat=VA_RT_FORMAT_YUV420的 surface，并确保VA_SURFACE_ATTRIB_USAGE_HINT_DECODER被设为 true - 解码流程必须走完整 pipeline：
vaBeginPicture()→vaRenderPicture()（传 JPEG bitstream buffer）→vaEndPicture()，不能跳过 render 阶段 - 解码后的 surface 不能用
vaDeriveImage()拿到 CPU 可读数据 —— 那就退化成软解；应直接传给 OpenGL/Vulkan 的 EGL/DRM interop 接口
如何把 VA-API surface 交给 OpenGL 使用（无 CPU 拷贝）
目标是让 OpenGL 的 glTexImage2D() 或纹理绑定不经过内存中转。这需要 DRM PRIME fd 或 EGL image 机制，而非传统 PBO。
常见误区是试图用 glBindTexture(GL_TEXTURE_2D, tex) 后再调用 glTexSubImage2D() —— 这必然触发 CPU memcpy。正确路径是让 VA-API surface 和 GL texture 共享同一个 DMA-BUF fd。
- 调用
vaExportSurfaceHandle()，handle_type设为VA_SURFACE_HANDLE_DRM_PRIME_2，mem_type设为VA_SURFACE_MEM_TYPE_KERNEL_DRM - 用返回的 fd 创建
glEGLImageOES（通过eglCreateImageKHR()），再用glBindTexture()+glEGLImageTargetTexture2DOES()绑定 - 注意：Intel 驱动要求 kernel >= 5.15、mesa >= 22.2，且 Xorg 必须禁用（Wayland 或 headless DRM render node）
Windows 上没有等效方案，别浪费时间尝试 DirectML / WIC
Windows 的 IMFTransform（Media Foundation）JPEG 解码器只支持输出到 ID3D11Texture2D，但该 texture 默认位于 GPU 可见内存（D3D11_USAGE_DEFAULT），**无法被 CUDA 或 OpenCL 直接访问**。NVIDIA/AMD 闭源驱动也不开放其底层显存句柄导出接口。
有人试过 ID3D11Device::OpenSharedResource() + CUDA 的 cuGraphicsD3D11RegisterResource()，但 JPEG 解码 output texture 往往带 D3D11_BIND_DECODER flag，CUDA 会拒绝注册，报错 CUDA_ERROR_INVALID_VALUE。
- Windows 下所谓“硬解到显存”实际仍是 driver internal copy，对 CUDA/OpenCL 不可见
-
WIC完全运行在 CPU，DirectML不支持 JPEG 解码算子 - 唯一可能路径是 Windows Subsystem for Linux（WSL2）+ VA-API，但需 GPU passthrough 支持（仅部分 Azure/NVidia Data Center 卡支持）
性能陷阱：即使路径走通，也要防隐式同步和 format mismatch
即便 surface 成功共享给 OpenGL，帧率仍可能暴跌 —— 常见原因是 driver 在每次 draw 时插入全 GPU barrier，因为 YUV 格式未被 shader 正确声明或采样器配置错误。
例如：VA-API 输出 VA_FOURCC_NV12，但 OpenGL shader 里用 sampler2D 而非 sampler2DRect 或 Vulkan 的 VK_FORMAT_G8B8G8R8_422_UNORM 对应 layout，会导致 driver 强制重排布内存布局。
- 务必检查
vaQuerySurfaceAttributes()返回的VAConfigAttribDecProcessing是否为VA_DEC_PROCESSING_NONE，否则后处理（如色彩空间转换）会在 CPU 发生 - OpenGL 中必须用
GL_SAMPLER_2D_RECT+texture2DRect()读 NV12 的两个 plane，或用 Vulkan 的VkSamplerYcbcrConversion显式声明 YUV 解码语义 - 调用
vaSyncSurface()前不要做任何 GL draw —— 否则会触发隐式等待，测出来 latency 比软解还高
真正“解码到显存”的核心不在 C++ 语法，而在是否全程避开 CPU 地址空间。一旦出现 memcpy、mmap、vaMapBuffer、glReadPixels 这类调用，链路就已断裂。硬件加速的收益全在 zero-copy pipeline 的完整性上，差一个环节，就是纯 CPU 解码的性能。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
