问题标签 [buffer-objects]

我对 OpenCL 还很陌生，虽然到目前为止我已经理解了所有内容，但是我无法理解缓冲区对象的工作原理。

我不明白缓冲区对象的存储位置。在这个StackOverflow 问题中指出：

如果您只有一台设备，可能 (99.99%) 将在设备中。（在极少数情况下，如果设备暂时没有足够的内存，它可能在主机中）

对我来说，这意味着缓冲区对象存储在设备内存中。但是，正如StackOverflow 问题中所述，如果在 中使用该标志，则CL_MEM_ALLOC_HOST_PTR使用clCreateBuffer的内存很可能是固定内存。我的理解是，当内存被固定时，它不会被换出。这意味着固定内存必须位于 RAM 中，而不是设备内存中。

那么实际发生了什么？

我想知道标志是什么：

• CL_MEM_USE_HOST_PTR
• CL_MEM_COPY_HOST_PTR
• CL_MEM_ALLOC_HOST_PTR

暗示缓冲区的位置。

谢谢

我想从存储缓冲区对象中检索数据。一开始，我想利用glGetBufferSubData. 但是在opengl中似乎没有这个功能，虽然在opengl中确实存在。然后我又靠上了glMapBufferRange。
如果我能在从缓冲区检索数据后解释信息，那就完美了。但我认为要做到这一点，我必须提供确切的布局，甚至更多信息。目前，我不需要做那么多。我要做的是，在两种不同的情况下，我想检索缓冲区内容，并比较两种情况下的内容是否相同。
问题是，glMapBufferRange返回一个void *类型。我将其转换为char *并比较十六进制值中的每个字符：

我感到很困惑，因为我只能看到不到 20 个打印出来的字符。为什么？问题是什么？我确定缓冲区大小与其他信息相比很大。

我正在研究 OpenGL 统一缓冲区对象和着色器存储缓冲区。我认为这个问题适用于他们两个，但让我们只关注 UBO。

教程似乎在说“块索引”和“绑定点索引”是不同的东西，如果我在着色器中有多个UBO，我需要指定绑定索引

我得到的印象是块索引由链接器确定并且可以从 读取，但是绑定点索引必须在布局中glGetUniformBlockIndex以任意不同的方式进行硬编码，并且对应的，这让我觉得脆弱和令人讨厌。binding=NglBindBufferBase(GL_UNIFORM_BUFFER, N, ubo_handle)

块索引和绑定点有什么区别？

我可以binding=N在布局中省略吗？那么会发生什么glBindBufferBase？

这对 SSBO 来说都一样吗？

假设我有一个动态数量的“球”，我想在我的 OpenGL 着色器中访问它们。在 C++ 中，数据可能是这样的：

如果我想在我的片段着色器中进行迭代all_balls，我相信我需要一个着色器存储缓冲区对象。

该文档涉及数组，但明显不完整。

我假设我可以像这样将数据发送到缓冲区

在 GLSL 中，我如何指定缓冲区是一个数组，以及我的着色器如何知道这个数组的大小？

我的着色器存储缓冲区中似乎有不确定的数据。

我曾经apitrace检查状态机并注意到跟踪中的以下函数调用序列：

根据更高级别的应用程序代码，这似乎是正确的，它与设置此匹配

到一个以长度为前缀的数组glm::vec4[2]。

但是，apitrace显示GL_BUFFER_DATA_SIZE在上述跟踪中的每个阶段都是 32，而不是 36。

此外，这是对 SSBO 的检查：

Components.colour[0]有GL_ARRAY_SIZE=0（这不应该是非零吗？）和GL_OFFSET=16（这不应该是 4 吗？）

该程序非常简单，所以为了更好地衡量，这是完整的跟踪（这是针对第 1 帧的，glBufferData(...,36,...)在第 0 帧中并且没有重复）：

1. GL_BUFFER_DATA_SIZE鉴于我的呼吁，SSBO 不应该有=36glBufferData吗？如果是这样，这是驱动程序错误吗？如果它规定的 32 大小是正确的，你能解释一下这是怎么回事吗？

2. GL_ARRAY_SIZE和GL_OFFSET正确吗？

3. 鉴于检查glBufferSubData调用，我的数组glm::vec4[2]描述了正确的确定性数据，此跟踪中是否有任何内容可以解释为什么当我b_components.colour[i]在其中读取时for (int i = 0; i < b_components.count; ++i)得到不确定的结果？

我一直在尝试初始化 SSBO 并将其传递给计算着色器。

在着色器中我有：

当我运行它时，sph 充满了 0-s。我试图从缓冲区中读取数据：

这让我收到错误 1281，也就是 0 + a.size() > ssbo 的大小。然后我检查了 SSBO 的实际大小：

这给了我 0。我用过这篇文章。我对 OpenGL 很陌生，所以我的代码中可能有一个非常明显的错误，这就是为什么我在这里包含了这么多。

谢谢指教！

编辑：LWJGL 版本是 3.2.1 build 12

我试图让 ffmpeg 解码并将像素转换为 rgb8 格式并写入映射的像素缓冲区并使用流来更新 opengl 纹理，然后将其渲染到 sdl 窗口。

解码和上传发生在一个专用线程中（使 sws_scale 写入映射的缓冲区），并且渲染在另一个上下文中的渲染线程中完成，并具有共享。（PBO实际上有几个帧，纹理是一个二维数组纹理，用来解耦位置。）

如果我在解码线程中刷新映射范围，并在渲染线程中使用 glTextureSubImage3D 来更新所需索引处的纹理，则一切正常。在这种情况下，集成的英特尔 gpu 工作得非常快（应该），但 NV 驱动程序抱怨Pixel-path performance warning: Pixel transfer is synchronized with 3D rendering.

我认为这可能是实际上只有 glTextureSubImage3D 才进行上传，所以我在刷新操作后立即移动了 glTextureSubImage3D。这次 NV gpu 工作正常，警告消失了，而 intel gpu 给出了一个黑色窗口，并且只在关闭时显示解码的内容。

代码是这样的：

我对客户端内存的想法以及驱动程序如何异步上传纹理、上传的确切位置以及绑定 GL_PIXEL_UNPACK_BUFFER 时 glTextureSubImage3D 实际做了什么感到困惑？

编辑：

在每次上传后添加 glFlush() 命令刷新上传上下文的命令队列后，intel 版本可以正常工作，不会出现黑屏。

更新：

添加 glFlush() 似乎使 NV gpu 发出警告“像素路径性能警告：像素传输与 3D 渲染同步。” 再次，同一视频样本的 GPU 利用率从 8% 增长到 10%。似乎 glFlush() 触发了一些内部同步，这可能会使事情处于忙碌等待状态？由于 Intel GPU 在没有 glFlush 的情况下无法工作，即使 clientwaitsync 版本设置了刷新命令位，并且在渲染端显式调用刷新也不起作用。那么应该怎么做才能让两个司机都开心（并降低利用率）？

在我的具体情况下，我试图将一个顶点缓冲区对象绑定到一个统一的缓冲区对象中。

有关更多详细信息，在延迟着色的不透明对象渲染管道中，我创建了一个 G 缓冲区，然后使用光 vbo 一次渲染一个点光。

然后，我需要所有这些灯作为可用于在半透明对象的前向渲染中进行迭代的 ubo。

我有一个用三角形条制成的立方体，我正在尝试找到它的 UV 坐标。

有谁知道他们会是什么？

我使用统一缓冲区对象来包含用于不同绘制调用的统一数据“块”。我设置了缓冲区的哪个部分应该被视为绘制调用将使用的“块”的开始glBindBufferRange()。

但是，在我的机器上存在一个相当大的对齐限制，即 256 字节，因此我上传到 GPU 的源缓冲区在没有平均约 50% 填充的情况下很少会与其对齐（我的着色器倾向于使用很少的制服），并且我通常每帧大约 500 个块 (125kb) 流到 GPU，具体取决于我正在渲染的场景。

我应该在使用 上传之前继续填充我的内存glBufferData()，还是从我紧凑的内存中上传每个“块”，分别使用多个glBufferSubData()调用？

或者有没有办法在一次调用中将我的客户端数据上传到 GPU 缓冲区，它将用不同的块步长填充？