我的问题是在尝试一系列不同的技术时提出的，我对这些技术都没有太多经验。可悲的是，我什至不知道我是否犯了一个愚蠢的逻辑错误，我是否使用了glium crate 错误，我是否在GLSL中搞砸了等等。无论如何，我设法开始了从头开始创建新的 Rust 项目，致力于展示我的问题的最小示例，并且该问题至少在我的计算机上重现。
然而，这个最小的例子最终很难解释，所以我首先做了一个更简单的例子，它可以做我想要它做的事情，尽管通过破解位和被限制为 128 个元素(4 乘以 32 位，在一个GLSLuvec4)。由此，升级到出现我的问题的版本相当简单。
一个工作版本，带有简单的uniform和位移位
程序在屏幕上创建一个矩形，纹理坐标从0.0水平到128.0。该程序包含一个用于矩形的顶点着色器，以及一个使用纹理坐标在矩形上绘制垂直条纹的片段着色器:如果纹理坐标(固定为uint)为奇数，则绘制一种颜色，当纹理坐标是偶数，它绘制另一种颜色。
// GLIUM, the crate I'll use to do "everything OpenGL"
#[macro_use]
extern crate glium;
// A simple struct to hold the vertices with their texture-coordinates.
// Nothing deviating much from the tutorials/crate-documentation.
#[derive(Copy, Clone)]
struct Vertex {
position: [f32; 2],
tex_coords: [f32; 2],
}
implement_vertex!(Vertex, position, tex_coords);
// The vertex shader's source. Does nothing special, except passing the
// texture coordinates along to the fragment shader.
const VERTEX_SHADER_SOURCE: &'static str = r#"
#version 140
in vec2 position;
in vec2 tex_coords;
out vec2 preserved_tex_coords;
void main() {
preserved_tex_coords = tex_coords;
gl_Position = vec4(position, 0.0, 1.0);
}
"#;
// The fragment shader. uses the texture coordinates to figure out which color to draw.
const FRAGMENT_SHADER_SOURCE: &'static str = r#"
#version 140
in vec2 preserved_tex_coords;
// FIXME: Hard-coded max number of elements. Replace by uniform buffer object
uniform uvec4 uniform_data;
out vec4 color;
void main() {
uint tex_x = uint(preserved_tex_coords.x);
uint offset_in_vec = tex_x / 32u;
uint uint_to_sample_from = uniform_data[offset_in_vec];
bool the_bit = bool((uint_to_sample_from >> tex_x) & 1u);
color = vec4(the_bit ? 1.0 : 0.5, 0.0, 0.0, 1.0);
}
"#;
// Logic deciding whether a certain index corresponds with a 'set' bit on an 'unset' one.
// In this case, for the alternating stripes, a trivial odd/even test.
fn bit_should_be_set_at(idx: usize) -> bool {
idx % 2 == 0
}
fn main() {
use glium::DisplayBuild;
let display = glium::glutin::WindowBuilder::new().build_glium().unwrap();
// Sets up the vertices for a rectangle from -0.9 till 0.9 in both dimensions.
// Texture coordinates go from 0.0 till 128.0 horizontally, and from 0.0 till
// 1.0 vertically.
let vertices_buffer = glium::VertexBuffer::new(
&display,
&vec![Vertex { position: [ 0.9, -0.9], tex_coords: [ 0.0, 0.0] },
Vertex { position: [ 0.9, 0.9], tex_coords: [ 0.0, 1.0] },
Vertex { position: [-0.9, -0.9], tex_coords: [128.0, 0.0] },
Vertex { position: [-0.9, 0.9], tex_coords: [128.0, 1.0] }]).unwrap();
// The rectangle will be drawn as a simple triangle strip using the vertices above.
let indices_buffer = glium::IndexBuffer::new(&display,
glium::index::PrimitiveType::TriangleStrip,
&vec![0u8, 1u8, 2u8, 3u8]).unwrap();
// Compiling the shaders defined statically above.
let shader_program = glium::Program::from_source(&display,
VERTEX_SHADER_SOURCE,
FRAGMENT_SHADER_SOURCE,
None).unwrap();
// Some hackyy bit-shifting to get the 128 alternating bits set up, in four u32's,
// which glium manages to send across as an uvec4.
let mut uniform_data = [0u32; 4];
for idx in 0..128 {
let single_u32 = &mut uniform_data[idx / 32];
*single_u32 = *single_u32 >> 1;
if bit_should_be_set_at(idx) {
*single_u32 = *single_u32 | (1 << 31);
}
}
// Trivial main loop repeatedly clearing, drawing rectangle, listening for close event.
loop {
use glium::Surface;
let mut frame = display.draw();
frame.clear_color(0.0, 0.0, 0.0, 1.0);
frame.draw(&vertices_buffer, &indices_buffer, &shader_program,
&uniform! { uniform_data: uniform_data },
&Default::default()).unwrap();
frame.finish().unwrap();
for e in display.poll_events() { if let glium::glutin::Event::Closed = e { return; } }
}
}
但这还不够好...
该程序有效，并显示具有交替条纹的矩形，但有明显限制，限制为 128 个条纹(或 64 个条纹，我猜。其他 64 个是“矩形的背景”)。为了允许任意多的 strip (或者，通常，将任意多的数据传递给片段着色器)，可以使用uniform buffer objects，which glium exposes。遗憾的是，most relevant example in the glium repo无法在我的机器上编译:
GLSL版本不受支持，buffer关键字是支持版本中的语法错误，一般不支持计算着色器(在我的机器上使用 glium) ，并且都不是 headless 渲染上下文。一个不太实用的版本，带有缓冲区
uniform因此，由于无法从该示例开始，我不得不使用文档从头开始。对于上面的例子，我想出了以下内容:
// Nothing changed here...
#[macro_use]
extern crate glium;
#[derive(Copy, Clone)]
struct Vertex {
position: [f32; 2],
tex_coords: [f32; 2],
}
implement_vertex!(Vertex, position, tex_coords);
const VERTEX_SHADER_SOURCE: &'static str = r#"
#version 140
in vec2 position;
in vec2 tex_coords;
out vec2 preserved_tex_coords;
void main() {
preserved_tex_coords = tex_coords;
gl_Position = vec4(position, 0.0, 1.0);
}
"#;
// ... up to here.
// The updated fragment shader. This one uses an entire uint per stripe, even though only one
// boolean value is stored in each.
const FRAGMENT_SHADER_SOURCE: &'static str = r#"
#version 140
// examples/gpgpu.rs uses
// #version 430
// buffer layout(std140);
// but that shader version is not supported by my machine, and the second line is
// a syntax error in `#version 140`
in vec2 preserved_tex_coords;
// Judging from the GLSL standard, this is what I have to write:
layout(std140) uniform;
uniform uniform_data {
// TODO: Still hard-coded max number of elements, but now arbitrary at compile-time.
uint values[128];
};
out vec4 color;
// This one now becomes much simpler: get the coordinate, clamp to uint, index into
// uniform using tex_x, cast to bool, choose color.
void main() {
uint tex_x = uint(preserved_tex_coords.x);
bool the_bit = bool(values[tex_x]);
color = vec4(the_bit ? 1.0 : 0.5, 0.0, 0.0, 1.0);
}
"#;
// Mostly copy-paste from glium documentation: define a Data type, which stores u32s,
// make it implement the right traits
struct Data {
values: [u32],
}
implement_buffer_content!(Data);
implement_uniform_block!(Data, values);
// Same as before
fn bit_should_be_set_at(idx: usize) -> bool {
idx % 2 == 0
}
// Mostly the same as before
fn main() {
use glium::DisplayBuild;
let display = glium::glutin::WindowBuilder::new().build_glium().unwrap();
let vertices_buffer = glium::VertexBuffer::new(
&display,
&vec![Vertex { position: [ 0.9, -0.9], tex_coords: [ 0.0, 0.0] },
Vertex { position: [ 0.9, 0.9], tex_coords: [ 0.0, 1.0] },
Vertex { position: [-0.9, -0.9], tex_coords: [128.0, 0.0] },
Vertex { position: [-0.9, 0.9], tex_coords: [128.0, 1.0] }]).unwrap();
let indices_buffer = glium::IndexBuffer::new(&display,
glium::index::PrimitiveType::TriangleStrip,
&vec![0u8, 1u8, 2u8, 3u8]).unwrap();
let shader_program = glium::Program::from_source(&display,
VERTEX_SHADER_SOURCE,
FRAGMENT_SHADER_SOURCE,
None).unwrap();
// Making the UniformBuffer, with room for 128 4-byte objects (which u32s are).
let mut buffer: glium::uniforms::UniformBuffer<Data> =
glium::uniforms::UniformBuffer::empty_unsized(&display, 4 * 128).unwrap();
{
// Loop over all elements in the buffer, setting the 'bit'
let mut mapping = buffer.map();
for (idx, val) in mapping.values.iter_mut().enumerate() {
*val = bit_should_be_set_at(idx) as u32;
// This _is_ actually executed 128 times, as expected.
}
}
// Iterating again, reading the buffer, reveals the alternating 'bits' are really
// written to the buffer.
// This loop is similar to the original one, except that it passes the buffer
// instead of a [u32; 4].
loop {
use glium::Surface;
let mut frame = display.draw();
frame.clear_color(0.0, 0.0, 0.0, 1.0);
frame.draw(&vertices_buffer, &indices_buffer, &shader_program,
&uniform! { uniform_data: &buffer },
&Default::default()).unwrap();
frame.finish().unwrap();
for e in display.poll_events() { if let glium::glutin::Event::Closed = e { return; } }
}
}
我希望这会产生相同的条纹矩形(或者给出一些错误，或者如果我做错了什么就会崩溃)。相反，它显示了矩形，最右边的四分之一是纯红色的(即，“当片段着色器读取它时，该位似乎已设置”)，而其余四分之三则为深红色(即，“该位在片段着色器读取它”)。
自原始发布后更新
我真的在这里暗中刺伤，所以认为这可能是内存排序、字节序、缓冲区溢出/不足等的低级错误。 (例如，每三组中一位，每四组中一位，两组后跟两个未设置，等等)。这并没有改变输出。
使内存“靠近”
uint values[128]的一种明显方法是将其放入Data结构中，就在values之前(不允许在values后面，因为Data的values: [u32]是动态调整大小的)。如上所述，这不会改变输出。但是，将正确填充的uvec4放入uniform_data缓冲区中，并使用类似于第一个示例的的main函数，会产生原始结果。这表明中的glium::uniforms::UniformBuffer<Data>做了的工作。因此，我更新了标题以反射(reflect)问题似乎出在其他地方。
在以利的回答之后
@Eli Friedman 的回答帮助我朝着解决方案迈进，但我还没有到那里。
分配和填充四倍大的缓冲区确实改变了输出，从四分之一填充的矩形变为完全填充的矩形。哎呀，这不是我想要的。不过，我的着色器现在正在读取正确的内存词。所有这些字都应该用正确的位模式填充。尽管如此，矩形的任何部分都没有变成条纹。由于
bit_should_be_set_at应该每隔一位设置一次，我提出了以下假设:Bits: 1010101010101010101010101010101010101
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: all bits set
为了验证这个假设，我将
bit_should_be_set_at更改为在 3、4、5、6、7 和 8 的倍数上返回true。结果与我的假设一致:Bits: 1001001001001001001001001001001001001
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: first bit set, then repeating two unset, one set.
Bits: 1000100010001000100010001000100010001
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: all bits set
Bits: 1000010000100001000010000100001000010
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: first bit set, then repeating four unset, one set.
Bits: 1000001000001000001000001000001000001
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: first bit set, then repeating two unset, one set.
Bits: 1000000100000010000001000000100000010
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: first bit set, then repeating six unset, one set.
Bits: 1000000010000000100000001000000010000
Seen: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
What it looks like: first bit set, then every other bit set.
这个假设有意义吗？无论如何:看起来问题是设置数据(在 Rust 端)还是读取它(在 GLSL 端)？
最佳答案
您遇到的问题与制服的分配方式有关。 uint values[128];没有您认为的内存布局；它实际上具有与 uint4 values[128] 相同的内存布局.见 https://www.opengl.org/registry/specs/ARB/uniform_buffer_object.txt 2.15.3.1.2 小节。
关于glsl - 使用 Glium 中的 UniformBuffer 将任意大小的对象传递给片段着色器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32938673/