我有一个WPF应用程序，它从相机获取图像，处理这些图像并显示它们。处理部分已经成为CPU的负担，所以我考虑将这个处理移动到GPU并针对它们运行定制的CUDA内核。基本过程如下：在WPF中显示CUDA处理图像
1）从相机 2）负载的图像获取图像到GPU 3）调用CUDA内核来处理图像 4）显示经处理的图像
甲WPF到CUDA-显示控制策略是我试图弄清楚的。 一旦图像加载到GPU上，它就不必卸载以显示，这似乎很自然。我读过这可以用OpenGL完成，但是我真的需要学习OpenGL并将其包含在我的项目中，以便快速显示CUDA处理的图像吗？
我明白（我认为）从C＃调用CUDA内核的问题。我的计划是围绕我的CUDA调用构建一个非托管库，然后我为C＃包装 - 或 - 尝试确定哪个托管包装（managedCUDA，Cudafy等）要尝试。我担心使用预构建的包装器之一，因为它们似乎都得到了轻微的支持......但也许我的印象是错误的。
无论如何，经过几天的研究可能的选择，我感觉有点不知所措。任何建议将不胜感激。
将CUDA计算结果直接用于图形活动的设备称为“interop”。有OpenGL“互操作”，并有DirectX“互操作”。有很多CUDA sample codes演示如何与计算图像进行交互。
要直接从设备上的计算数据直接显示出来，而不需要访问主机，则需要使用这两个API之一（OpenGL或DirectX）。
你提到了我听说过的两个管理界面，所以你似乎知道那里的选项。
如果处理时间与将图像从主机传输到设备所花费的时间相比（远大于）所需的时间显着，那么您可以考虑从图像从主机传输到设备，处理它，然后传输它回来了，你可以在那里使用你用来显示它的相同管道。然后，您可以决定是否为Interop额外付出努力是值得的。
如果您可以分析您的代码以确定图像处理在主机上运行了多长时间，然后在设备上对原型进行原型设计以确定其速度，那么这将具有启发性。
您可能会发现处理时间太长，您甚至可以从双份复制安排中受益。或者您可能会发现主机上的处理时间很短（与仅传输到设备的成本相比），CUDA加速功能无用。
WPF有一个名为D3DImage的控件，可以直接在屏幕上显示DirectX内容，并且在managedCuda示例包中，您可以使用它（与SlimDX一起）从Cuda Toolkit中找到原始流体示例的一个版本。您不必使用managedCuda在C＃中实现Cuda，但您可以通过它来了解如何实现：managedCuda samples
来自你和Robert Crovella的好建议。我开始研究DirectX（认为与OpenGL相比，它可以更好地与Windows集成），并且发现关于如何让WPF和DirectX一起工作还有另一个决定。你提到SlimDX。我还发现SharpDX（从SlimDX分拆）。两者似乎都有中度至低度的活动。试图做出一个明智的发展决定非常令人沮丧...在哪里投入我的时间和精力。啊！！！！ –
由于managedCuda是我的项目，我可以告诉你一个包装库不能有更多的活动，然后包装的API本身。一旦编写代码，如果你想简单起见，就没有太多的工作要做。 Cuda核心库非常小，您可以使用现有代码轻松构建自己的包装。尽管DirectX是一个巨大的API，但它也很安静：DirectX 9已经超过10年了，并且包装代码被写入。 SlimDX/SharpDX没有什么可以添加的，为什么我不担心这些项目的活动：它们都很成熟，并在很多项目中使用。 – kunzmi
我很欣赏你评论的智慧，我希望你在我的天真中没有冒犯。事实上，我已经开始跟进有关D3DImage控件的建议。对我来说，当我需要的只是显示CUDA操作图像时，采用Direct3D似乎有点矫枉过正。从你的建议，我已经能够放弃一个WPF形式的D3DImage控件（尽管我还没有做任何事情）。如果事实证明这足以显示我的图像，并为我作为互操作“接收器”，那么managedCUDA可能会让我完成剩下的任务吗？ –
谢谢！你已经教给我有关互操作的知识。现在只需要决定从WPF转到DirectX的方式。看起来像另一个开源工具集的决定。这些东西让我感到紧张。候选人似乎是SlimDX和SharpDX。 –