【问题标题】:OpenGL-OpenCL interop transfer times + texturing from bitmapOpenGL-OpenCL 互操作传输时间 + 位图纹理
【发布时间】:2012-11-22 21:39:28
【问题描述】:

两部分问题:

我正在开展一个学校项目,使用生命游戏作为试验 gpgpu 的工具。我正在使用 OpenCL 和 OpenGL 进行实时可视化,目标是让这个东西尽可能大和快。分析后,我发现帧时间主要由 CL 获取和释放 GL 缓冲区控制,时间成本与缓冲区的实际大小成正比。

1) 这正常吗?为什么会这样?据我所知,缓冲区永远不会离开设备内存,而 CL Acquire/Release 就像互斥锁一样。 OpenCL 是否单独锁定/解锁每个字节?

为了解决这个问题,我已从 24 位 RGBA 颜色模式(据我了解是 OpenGL 的首选颜色模式?)缩小为 8 位 RGB 颜色。这导致了显着的加速,但是在调整我的内核之后,传输时间再次占主导地位。

在没有关于如何完全消除传输时间的任何想法(没有将我的内核从 OpenCL 移植到 GLSL,这将超出项目的原始范围),我现在认为我最好的选择是写信给一个位图(与我目前使用的 8 位像素图相反),然后使用该位图和一个颜色索引来纹理一个四边形。

2) 我可以直接使用位图对四边形进行纹理处理吗?我曾考虑使用 glBitmap 绘制到辅助缓冲区,然后使用此缓冲区对我的四边形进行纹理处理,但如果可用的话,我更愿意使用更直接的路线。

【问题讨论】:

    标签: opengl opencl


    【解决方案1】:

    CL/GL 互操作获取和释放调用背后的设计意图是让它们成为简单的所有权转移。然而,在许多早期的实现中,这些都是将图像从 CL 复制到 GL 并返回。

    除非您使用 OpenCL 1.1 中的同步对象扩展,否则您需要在发布之前执行 clFinish,在获取之前执行 glFinish;您看到这里花费了大量时间,因为所有排队的工作都必须在这些调用继续之前完成。有些平台可以使用 clFlush 代替 clFinish;检查供应商提供的 OpenCL 文档。

    借助或多或少最新硬件上的最新 NVIDIA 和 AMD 驱动程序,我看到高清视频大小的图像的获取和发布调用非常迅速。

    【讨论】:

    • 优秀。我使用的是 1.0(硬件限制),很高兴知道这些问题已经解决。我想我真正需要的是一张新的视频卡。
    猜你喜欢
    • 1970-01-01
    • 2016-08-18
    • 2016-10-31
    • 1970-01-01
    • 1970-01-01
    • 2013-07-27
    • 2019-11-05
    • 1970-01-01
    • 2013-10-15
    相关资源
    最近更新 更多