问题标签 [compute-shader]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
hlsl - DirectX 11 计算着色器 5 循环
我有以下用于计算景深的计算着色器代码。但是,非常不寻常的是,即使 g_rayCount 为 10,循环也只执行一次。请查看 for 循环所在的主函数 raycastercs。
c - How to bind shader buffer blocks using glShaderStorageBinding?
Using OpenGL 4.3, I want to know how to bind shader buffer blocks using glShaderStorageBinding
.
'binding' qualifiers works fine, but I don't want to use them.
I have written the following code:
Compute Shader:
Expecting result as 1, but returning value as 0 in Obuffer.
directx - DirectCompute 最优线程数设置
我最近一直在玩计算着色器,我正在尝试确定设置我的 [numthreads(x,y,z)] 和调度调用的最佳方式。我的演示窗口是 800x600,我每像素启动 1 个线程。我正在执行 2D 纹理修改 - 没有太重。
我的第一次尝试是指定
我的 Dispatch() 电话总是
所以首先是
这以 25-26 fps 的速度运行。然后我减少到以 16 fps 运行的 [numthreads(4,4,1)]。将其增加到 [numthreads(16,16,1)] 开始产生大约 30 fps 的不错结果。玩弄 Y 线程组编号 [numthreads(16,8,1)] 设法将其推到 32 fps。
我的问题是是否有确定线程数的最佳方法,以便我可以最有效地利用 GPU,还是只是好的试错法?
directx - 具有 numthreads (1,1,1) 的计算着色器运行速度极慢
我刚刚开始学习 DirectX 编程,使用 F# 和 SharpDX 作为 .NET 包装器。作为一个测试用例,我渲染了 Mandelbrot 集。计算是使用 2 个计算着色器完成的。
第一个着色器计算每个像素的深度(函数“CalcMandel”),结果存储在 RWStructuredBuffer 中。这种计算需要大量的单乘或双乘,但它在我的 GPU (AMD 7790) 上速度非常快。“CalcMandel”具有属性
并通过
这里没有问题——“核心”Mandelbrot 集的 1000 x 800 像素图像以超过 1000 fps 的速度运行(在 GPU 上使用单精度)。
第二个着色器几乎什么都不做:它计算先前计算的最小值、最大值和平均值(函数“CalcMinMax”)。“CalcMinMax”具有属性
并通过调用
对于给定的图像大小,单个 GPU 线程必须遍历缓冲区超过 800.000 个整数来计算最小值、最大值和平均值。我使用单线程,因为我不知道如何以并行方式实现此计算。
问题:“CalcMinMax”非常慢:帧速率从 1000 多帧下降到 5 帧!
我的问题:这里有什么问题?我是否使用了错误的设置/参数(numthreads)?如何加快 min-max 计算?
我的想法:我的第一个假设是访问 RWBuffer 可能很慢——事实并非如此。当我用常量替换缓冲区访问时,帧速率没有增加。
我的 GPU 有 appr。900 个着色器核心并使用数千个线程来计算 Mandelbrot 集,而“CalcMinMax”仅使用一个线程。然而,我仍然不明白为什么事情变得如此缓慢。
我将不胜感激任何建议!
=================================================
// HLSL CONTENT (Mandelbrot 集计算省略):
// * ** * ** * ** * ** * ** * ** * F# 程序(最小-最大部分) * ** * ** * ** * ** *
着色器设置:
着色器用法:
阅读统计:
hlsl - 如何使用顶点缓冲区将计算着色器结果输入顶点着色器?
在详细介绍之前,我想概述一下问题:
我使用 RWStructuredBuffers 来存储我的计算着色器 (CS) 的输出。由于顶点和像素着色器无法从 RWStructuredBuffers 中读取,我将一个 StructuredBuffer 映射到同一插槽 (u0/t0) 和 (u4/t4) 上:
我使用 ShaderRecourceView 授予像素和/或顶点着色器访问缓冲区的权限。这个概念适用于我的像素着色器,但顶点着色器似乎只读取 0 值(我使用 SV_VertexID 作为缓冲区的索引):
没有来自 hlsl 编译器的错误消息或警告,renderloop 以 60 fps(使用 vsync)运行,但屏幕仍然是黑色的。由于我在调用 Draw(..) 之前使用 Color.White 将屏幕空白,因此渲染管道似乎处于活动状态。
当我通过 UAView 从 GPU 读取三角形数据内容到“vertArray”并将其反馈到顶点缓冲区时,一切正常:
程序:
HLSL:
这里定义了 2D - Vertex / Pixelshaders。请注意,PS_2D 访问插槽 t0 中的缓冲区“output2” - 这正是我想要为 3D 顶点着色器“VS_3DA”复制的“技巧”:
三天来,我一直在寻找和尝试,但无济于事。我收集的所有信息似乎都证实了我使用 SV_VertexID 的方法应该有效。
有人可以给建议吗?感谢您阅读我的帖子!
==================================================== ====================
细节:
我非常喜欢 DirectX 11 计算着色器的概念,我想将它用于代数计算。作为一个测试用例,我在 3D 中渲染分形(Mandelbrot 集)。一切都按预期工作——除了墙上的最后一块砖不见了。
计算采取以下步骤:
使用 CS 计算 2D 纹理(输出为“counterTable”和“colorOutbutTable”(有效)
可选择将此纹理渲染到屏幕(作品)
使用另一个 CS 生成网格(三角形列表)。此 CS 从步骤 1 中获取 x、y 和颜色值,计算 z 坐标,最后为每个像素创建一个四边形。结果存储在“vertexTable”中。(作品)
将三角形列表提供给顶点着色器(问题!!!)
渲染到屏幕(工作 - 使用顶点缓冲区)。
对于编程,我使用 F# 3.0 和 SharpDX 作为 .NET 包装器。两个着色器(像素和顶点)的 ShaderRessourceView 设置了相同的参数(大小参数除外):
这里没什么特别的。创建 2D 缓冲区(绑定到插槽 t0 中的缓冲区“output2”):
创建 3D 缓冲区(绑定到插槽 t4 中的“vertexTable2”):
为 2D 设置资源:
渲染 2D:
为 3D 设置资源:
渲染 3D(不起作用 - 输出结果为黑屏)
最后是插槽号:
directx - 像素着色器可以访问结构化缓冲区,而顶点着色器不能——这是 DirectX 规范吗?
===================== 编辑:解决方案=====================
我终于找到了问题所在,因为答案对于正在学习 DirectX 的初学者可能很重要,所以我将其发布在这里。(我使用 F# 和 SharpDX 作为 DirectX 的 .NET 包装器)
在我的程序中,资源(缓冲区、视图等)仅在调整交换链大小时发生变化。所以我把所有的资源分配(IA、OM、VS、PS)放到一个函数switchTo2DLayout
中。如果交换链没有switchTo2DLayout
调整大小,则立即返回(不做任何事情)。这是由一个标志控制的。
后来我发现这个标志从未被重置,因此资源分配是在每次绘制调用之前完成的。我纠正了这个错误,但现在图像仅在第一次调用renderPixels
. 事实证明,我必须在绘制调用之前设置ShaderresourceView
每次。
这完全出乎我的意料。我使用的有关 DirectX 的书籍从未明确说明哪些资源可以分配一次(只要不更改设置),哪些资源必须在每次绘制调用时分配。
对于网格渲染,我使用了类似的设置(这里没有我提到的错误),同样缺少等效的行:
这解释了为什么 2D 渲染因为这个错误(像素着色器从缓冲区读取)而工作,而 3D 没有(顶点着色器从缓冲区读取)。
======================= 我的原帖:=================
几天前,我发布了一个问题 [链接:]如何使用顶点缓冲区将计算着色器结果输入到顶点着色器中?这可能太复杂而无法回答。同时,我将设置简化为一个更简单的情况:
案例 A:像素着色器设置颜色(有效)
案例 B:顶点着色器设置颜色(不起作用)
显然,像素着色器可以访问“output2”缓冲区,而顶点着色器不能(读取始终为零)。
在互联网上搜索我找不到这种行为的任何解释。在我的“真实”应用程序中,计算着色器计算一个三角形列表并将其存储在 RWStructuredBuffer 中,因此我需要从顶点着色器(通过映射槽)访问该表。
我想许多使用计算着色器的人可能会偶然发现这个问题。知道如何解决这个问题吗?(我目前用不了Level 11.1或者11.2,得找个基于11.0的解决方案)
vertex-shader - 为什么这个计算着色器比顶点着色器慢得多?
我正在探索使用计算着色器将骨骼变形应用于网格顶点,而不是使用流输出的顶点着色器。我发现计算着色器的执行速度比顶点着色器慢得多,但在我把它写下来之前,我想确定我没有做错什么。
使用我的 100,000 个顶点的测试数据和 300 个骨骼的 1,000 帧动画数据,顶点着色器的运行时间约为 0.22 毫秒,而计算着色器的运行时间是 0.85 毫秒的 4 倍。计时是通过 D3D API 计时器查询(而不是 cpu 计时器)完成的。
变形结构体.hlsl
bone_deform_cs.hlsl
bone_deform_vs.hlsl
缓冲区运行后比较它们的内容,它们是相同的并且包含预期值。
我怀疑我可能错误地执行了计算着色器,产生了太多线程?我传递给Dispatch
错误的号码吗?由于它是一维数据行,因此对我来说使用[numthreads(64,1,1)]
. 我尝试了 32-1024 的各种值。64 似乎是最佳选择,因为它是高效使用 AMD GPU 所需的最低要求。反正。当我调用时Dispatch
,我要求它执行(vertex_count / 64) + (vertex_count % 64 != 0) ? 1 : 0
。对于 100,000 个顶点,调用最终为Dispatch(1563,1,1)
.
这就是顶点着色器的执行方式:
或者答案仅仅是从着色器资源视图读取并写入无序访问视图比从顶点缓冲区读取并写入流输出缓冲区要慢得多?
directx - DirectX 11 计算是否能够将超过 10k 的顶点写入 RWStructuredBuffer?
我有一个带有无序访问视图的顶点缓冲区,我使用计算着色器填充顶点,计算着色器将 UAV 视为 RWStructuredBuffer,使用与顶点定义等效的结构。有216000个顶点(即60 x 60 x 60)。但是我的计算机着色器似乎只填充了大约 8000 个,其余的则保留了它们的初始值。结构化缓冲区中可以以这种方式写入的元素数量是否有限制?
directx-11 - 是否有用于在绘图调用之间绑定和取消绑定资源的 DirectX 指南?
所有 DirectX 书籍和教程都强烈建议将绘制调用之间的资源分配减少到最低限度——但我找不到任何更详细的指南。回顾了在网上找到的大量示例代码,我得出结论,程序员对这个主题有完全不同的编码原则。有些甚至设置和取消设置
在每次绘制调用之前和之后(尽管设置保持不变),而其他人则不然。
估计是有点过分了……
从我自己的实验中,我发现我必须在每个绘图调用上绑定的唯一资源是ShaderResourceViews
(在我的情况下)VS
。PS
此要求可能是由使用计算着色器引起的,因为我绑定/取消绑定UAVs
到绑定到VS
/PS
稍后绑定的缓冲区。
在我发现这种重新绑定是必要的之前,我已经失去了很多小时的工作。而且我猜许多编码人员也不确定,他们更愿意解除绑定和重新绑定“有点太多”,而不是陷入类似的陷阱。
问题 1:关于这个问题至少有一些经验法则吗?
问题 2:我的ShaderResourceViews
绑定是否可能不受VS/PS
驱动程序/DirectX 核心的绑定,因为我UAVs
在 CS 调度调用之前绑定到相同的缓冲区(我自己没有取消绑定SRVs
)?
问题 3:VS/PS
在使用计算着色器之前,我什至没有设置为 null。工作没有问题,但我一直不确定我是否正在使用这种“懒惰”的方法来挖掘我的下一个陷阱。
opengl - OpenGL 计算着色器原子操作
我正在尝试编写一个与用于 BF3 的 DICE 一致的延迟平铺渲染器,但我要么不明白我在做什么,要么 GLSL 正在对我进行快速渲染。
内核的第一部分是计算每个图块的最大和最小深度,我正在使用这段代码。
如果我为每个片段绘制深度,场景看起来像这样。
尝试绘制 minDepth 会导致纯白屏,而绘制 maxDepth 会导致黑屏。我的内存管理/原子功能是错误的还是我的驱动程序/GPU/Unicorn 有问题?
作为说明,我已经尝试过
这也产生了一个完全白色的图像,这让我非常怀疑到底发生了什么。