C#渲染OpenCL生成的图像 [英] C# Rendering OpenCL-generated image

查看:427
本文介绍了C#渲染OpenCL生成的图像的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

问题:我试图实时呈现动态的Julia分形。由于分形不断变化,我需要能够呈现每秒至少20帧,最好是更多。你需要知道的有关Julia分形的知识是每个像素都可以独立计算,因此任务很容易并行化。第一种方法:第一种方法:因为我已经习惯了C#中的Monogame,所以我尝试在HLSL中编写着色器来完成这项工作,但编译器不停地抱怨,因为我使用了超过允许的64个算术插槽(我需要至少一千个)。



第二种方法:使用CPU,如预期的那样,花费大约两分钟时间来生成一帧。
$ b

第三种方法:我开始使用名为Cloo的包装器学习OpenCL的基础知识。通过使用OpenCL计算图像数据,然后从GPU获取数据,将数据存储在Texture2D中并将纹理绘制到屏幕上,我确实得到了一个快速,好的结果。对于1000x1000的图像,我可以获得每秒13帧。这还不是我所希望的,因为图像应该是1920x1080来填满我的屏幕,并且帧率非常明显。我意识到我实际上是在GPU上生成图像,将数据发送给CPU,然后将其发送回GPU,所以这看起来像是一个不必要的步骤,如果可以删除,可能会解决我的问题。我在一些论坛上看到OpenGL能够做到这一点,但我一直无法找到具体的信息。



问题:首先,有没有一种简单的方法来直接绘制由OpenCL生成的数据,而不涉及CPU(最好与Monogame兼容)?如果情况并非如此,是否可以使用OpenGL来实现它,然后将它与Monogame结合起来?其次,为什么使用简单的HLSL着色器不可能呢?由于HLSL和OpenCL都使用GPU,因此当进行许多算术运算时,为什么HLSL会受到更多限制?

编辑



我找到了这个网站,它大致上是我想要的,但是使用GLSL着色器。这再一次质疑我在HLSL中的失败。不幸的是,由于monogame不支持GLSL(尚未),我的问题仍未得到解答。 解决方案

OpenCL可以绘画,但是Monogame显然不会封装在CL的顶部,所以对于问题1不是问题。问题2是正确的问题:也许,请参阅下面的建议。问题3:HLSL本质上是PS 1.1,因此为什么不可能是因为PS演变为2.x以通过更广泛的数据管道来管理并行化......所以您需要Dx12支持或GLSL / OpenGL。



由于使用CLoo接近您的性能预期,为什么不尝试使用OpenCL.Net和/或OpenTK将Julia计算更紧密地绑定到Monogame API? - 如果你必须使用GPU-CPU-GPU,至少应该尽可能地扩大管道。



或者,对于并行化和帧率问题可能会将诸如Quanta的Alea之类的GP-GPU包装器与您的Monogame解决方案集成在一起。我建议看看Cudafy,但Alea更强大且支持跨供应商的GPU。

构建过程将决定Julia代码的哪一部分将通过Alea在GPU上计算,并且Monogame部分将接收用于渲染的像素字段。最重要的是,如果你得到它的工作,它将成为图书馆玩 - 很好的兼容性,并最终达到帧速率。底线:通过选择,在HLSL(阅读:微软Dx9)和Monogame不支持GLSL / Dx12 ....所以你将不得不创造性地操纵以获得未卡住。


Problem: I'm trying to render a dynamic Julia fractal in real time. Because the fractal is constantly changing, I need to be able to render at least 20 frames per second, preferably more. What you need to know about a Julia fractal is that every pixel can be calculated independently, so the task is easy parallelizable.

First approach: Because I'm already used to Monogame in C#, I tried writing a shader in HLSL that would do the job, but the compiler kept complaining because I used up more than the allowable 64 arithmetic slots (I need at least a thousand).

Second approach: Using the CPU, it took, as could be expected, about two minutes to generate one frame.

Third approach: I started learning the basics of OpenCL using a wrapper called Cloo. I actually got a quick, nice result by calculating the image data using OpenCL, then getting the data from the GPU, storing the data in a Texture2D and drawing the texture to the screen. For a 1000x1000 image I get about 13 frames a second. This is still not quite what I had hoped for, as the image should be 1920x1080 to fill up my screen, and the frame rate is pretty noticeable. I realised that I'm actually generating the image on the GPU, sending the data to the CPU and then sending it back to the GPU, so this seems like an unnecessary step that, if could be removed, will probably solve my problem. I read on some fora that OpenGL is able to do this, but I haven't been able to find specific information.

Questions: Firstly, is there a simple way to draw the data generated by OpenCL directly without involving CPU (preferably compatible with Monogame)? If this isn't the case, is it possible to implement it using OpenGL and afterwards combine it with Monogame? Secondly, why isn't this possible with a simple HLSL shader? As HLSL and OpenCL both use the GPU, why is HLSL so much more limited when it comes to doing many arithmetic operations?

Edit

I found this site that does roughly what I want, but using a GLSL shader. This again questions my fait in HLSL. Unfortunately, as monogame doesn't support GLSL (yet), my questions remain unanswered.

解决方案

To cover the questions: Yes, OpenCL can paint, but Monogame apparently doesn't encapsulate over the top of CL, so No to Question 1. Question 2 is the right question: maybe, see suggestions below. Question 3: HLSL is essentially PS 1.1 so "why isn't it possible" is because PS evolved to 2.x to manage parallelization through wider data pipes...so you want Dx12 support or GLSL/OpenGL.

Since you are close to your performance expectations using CLoo, why not try OpenCL.Net and/or OpenTK to bind the Julia calculations more closely to the Monogame API? --If you have to go GPU-CPU-GPU at least make that as wide a pipeline as possible.

Alternately, a slightly sideways solution to your parallelization and framerate problem might be integrating GP-GPU wrappers such as Quanta's Alea with your Monogame solution. I'd suggest looking at Cudafy, but Alea is more robust and cross-vendor GPU supported.

The build process will decide which portion of the Julia code will calculate on GPU via Alea, and the Monogame portions will receive the pixel-field for rendering. The sticking points will be library "play-nice" compatibility, and ultimately, frame-rate if you get it working.

Bottom line: you're stuck, by choice, in HLSL (read: Microsoft Dx9) and Monogame doesn't support GLSL/Dx12....so you will have to maneuver creatively to get un-stuck.

这篇关于C#渲染OpenCL生成的图像的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆