小编Mic*_*ell的帖子

我一直在尝试使用OpenGL和GLSL编写Marching Cubes算法的两遍GPU实现,类似于GPU Gems 3第一章中详述的算法.但是,glDrawArrays在我的第一次传球中的呼叫始终失败了GL_INVALID_OPERATION.

我查找了所有可以找到的文档,并发现这些条件glDrawArrays可以抛出该错误:

1. GL_INVALID_OPERATION如果非零缓冲区对象名称绑定到已启用的数组或GL_DRAW_INDIRECT_BUFFER绑定,并且缓冲区对象的数据存储当前已映射,则会生成.
2. GL_INVALID_OPERATION如果glDrawArrays在执行glBegin和相应的执行之间执行,则生成glEnd.
3. GL_INVALID_OPERATION将由glDrawArrays或glDrawElements当前程序对象中的任何两个活动采样器具有不同类型,但引用相同的纹理图像单元.
4. GL_INVALID_OPERATION 如果几何着色器处于活动状态且模式与当前安装的程序对象中几何着色器的输入基元类型不兼容,则会生成.
5. GL_INVALID_OPERATION如果模式是GL_PATCHES并且没有曲面细分控制着色器处于活动状态,则生成.
6. GL_INVALID_OPERATION如果将基元的顶点记录到用于变换反馈目的的缓冲区对象,则会生成超出任何缓冲区对象大小的限制,或者超出结束位置偏移+大小-1,如下所示glBindBufferRange.
7. GL_INVALID_OPERATIONglDrawArrays()如果不存在几何着色器,则生成变换反馈,并且模式不是允许的模式之一.
8. GL_INVALID_OPERATIONglDrawArrays()如果存在几何着色器,则生成变换反馈,并且几何着色器的输出基元类型与变换反馈primitiveMode不匹配.
9. GL_INVALID_OPERATION 如果绑定着色器程序无效,则生成.
10. GL_INVALID_OPERATION如果正在使用变换反馈,则生成编辑10/10/12:绑定到变换反馈绑定点的缓冲区也绑定到数组缓冲区绑定点.这是我遇到的问题,因为我绑定了缓冲区的拼写错误.虽然规范确实声明这是非法的,但在我发现的任何文档中,它都没有列在glDrawArrays下作为它可以抛出错误的原因之一.

不幸的是,我找不到任何一份官方文档,其中包括超过3篇.我不得不从众多来源收集这份清单.第7点和第8点实际上来自文档glBeginTransformFeedback,第9点似乎根本没有记录.我发现它在某个论坛帖子中提到过.但是,我仍然不认为这个列表是完整的,因为这些似乎都没有解释我得到的错误.

1. 我在任何地方的程序中都没有映射任何缓冲区.
2. 我使用的是核心配置文件,所以glBegin并glEnd没有提供连.
3. 我有两个采样器,它们有不同的类型,但它们肯定映射到不同的纹理.
4. 几何着色器处于活动状态,但它的输入布局是layout (points) in,并且glDrawArrays正在调用GL_POINTS.
5. 我没有使用GL_PATCHES任何类型的镶嵌着色器.
6. 我已经确定我正在分配我的几何着色器可能输出的最大空间量.然后我尝试了四倍.没有帮助.
7. 有一个几何着色器.看下一点.
8. 正在使用变换反馈,并且有一个几何着色器,但输出布局是layout (points) out …

我在我的机器上下载并安装了Rust和Cargo nightlies,并使用Cargo生成了一个新的二进制项目:

Cifram@Valyria ~
$ cargo new test --bin

然后我尝试运行这个处女项目,再次使用Rust和Cargo的新装置,并且得到这个:

Cifram@Valyria ~/test
$ cargo run --verbose
   Compiling test v0.0.1 (file:///C:/cygwin64/home/Cifram/test)
     Running `rustc C:\cygwin64\home\Cifram\test\src\main.rs --crate-name test --crate-type bin -g --out-dir C:\cygwin64\home\Cifram\test\target --dep-info C:\cygwin64\home\Cifram\test\target\.fingerprint\test-51757ad0485ed143\dep-bin-test -L C:\cygwin64\home\Cifram\test\target -L C:\cygwin64\home\Cifram\test\target\deps`
error: linking with `gcc` failed: exit code: 1
note: gcc '-m64' '-L' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib' '-o' 'C:\cygwin64\home\Cifram\test\target\test.exe' 'C:\cygwin64\home\Cifram\test\target\test.o' '-Wl,--whole-archive' '-lmorestack' '-Wl,--no-whole-archive' '-fno-lto' '-fno-use-linker-plugin' '-Wl,--gc-sections' '-static-libgcc' '-Wl,--enable-long-section-names' '-Wl,--nxcompat' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib\libnative-4e7c5e5c.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib\libstd-4e7c5e5c.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib\libsync-4e7c5e5c.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib\librustrt-4e7c5e5c.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\x86_64-w64-mingw32\lib\libcollections-4e7c5e5c.rlib' 'C:\Program Files …

这段代码:

#![feature(macro_rules)]

macro_rules! new(
    ($my_type:ty) => ( $my_type::new() );
)

struct Foo {
    blah: int
}

impl Foo {
    fn new() -> Foo {
        return Foo { blah: 0 }
    }
}

fn main() {
    let my_foo = new!(Foo);
    println!("Foo's value: {}", my_foo.blah);
}

看起来不错,但它失败并出现此错误:

test.rs:4:25: 4:32 error: unexpected token: `Foo`
test.rs:4     ($my_type:ty) => ( $my_type::new() );
                                  ^~~~~~~

如果我进入宏并$my_type用Foo它替换编译并运行得很好,那么Foo在那个位置显然是有效的.除非Foo来自宏观替代,显然.

如果我运行rustc test.rs --pretty expanded,它不会显示扩展的宏.它只是给了我相同的错误信息.我怀疑这意味着它在扩展宏之前生成了消息,但它可能只是因为除非编译成功,否则它不会显示任何内容.虽然这会严重限制其有用性--pretty expanded.

基于其他实验,我可以在基本上每个其他地方使用宏类型参数,期望一个类型工作.你不能在它们上面调用静态函数.这似乎是一个相当随意的限制,错误信息肯定没有用.

为什么存在这种限制？它有办法吗？

如果我有 C# 8 代码：

class Foo {}

然后：

#nullable enable
var bar = new Foo();

那么 的类型bar是Foo?。这显然不正确，因为new表达式不能返回null。为什么会bar是一个可为空的引用？我什至查阅了Nullable Reference Type Specification，发现了以下内容：

永远不为空的表达式

以下表达式形式的空状态始终为“非空”：

• ...
• new 表达式（对象、委托、匿名对象和数组创建表达式）
• ...

并且：

var 的类型推断

为用 var 声明的局部变量推断的类型由初始化表达式的空状态通知。

var x = E;

Run Code Online (Sandbox Code Playgroud)

如果类型E是可空的引用类型C?和空状态E是“不空”，则推断该类型x是C。否则，推断的类型是 的类型E。

推断的类型的可空性x如上所述确定，基于 的注释上下文var，就像在该位置明确给出类型一样。

因此，根据我在规范中可以找到的所有内容，bar在我非常简单的示例中，应该是 type Foo，而不是 type Foo?。我错过了什么？