GPU中工作项负载的限制？ CUDA / OpenCL [英] Limitations of work-item load in GPU? CUDA/OpenCL

问题描述

我有一个计算密集型图像算法，对于每个像素，需要读取许多远距离的像素。距离取决于在编译时定义的常量。我的OpenCL算法执行良好，但在一定的最大距离 - 导致更重的循环 - 驱动程序似乎解脱。屏幕变黑了几秒钟，然后命令队列不会完成。气球消息显示驱动程序不正常：

I have a compute-intensive image algorithm that, for each pixel, needs to read many distant pixels. The distance is dependent on a constant defined at compile-time. My OpenCL algorithm performs well, but at a certain maximum distance - resulting in more heavy for loops - the driver seems to bail out. The screen goes black for a couple of seconds and then the command queue never finishes. A balloon message reveals that the driver is unhappy:

显示驱动程序AMD驱动程序已停止响应，并已成功恢复。

"Display driver AMD driver stopped responding and has successfully recovered."

（在OpenCL 1.1上使用 AMD FirePro V4900（FireGL V）图形适配器运行）

(Running this on OpenCL 1.1 with an AMD FirePro V4900 (FireGL V) Graphics Adapter.)

1. 为什么会发生这种情况？


2. 是否可以事先告诉司机一切正常？

推荐答案

这是Windows下的一个已知的功能（不知道Linux） - 如果视频驱动程序停止响应，操作系统将重置它。除此之外，由于OpenCL（和CUDA）是由驱动程序实现的，一个需要太长时间的内核将看起来像一个冻结的驱动程序。

This is a known "feature" under Windows (not sure about Linux) - if the video driver stops responding, the OS will reset it. Except that, since OpenCL (and CUDA) is implemented by the driver, a kernel that takes too long will look like a frozen driver. There is a watchdog timer that keeps track of this (5 seconds, I believe).

您的选择是：

1. 您需要确保您的内核不会太耗时（最好）。


2. 您可以关闭看门狗定时器：超时检测和恢复GPU 。


3. 您可以运行

我建议你使用1。

这篇关于GPU中工作项负载的限制？ CUDA / OpenCL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！