glCompileShader上的Mesa访问冲突(Mesa Access Violation on glCompileShader)

我一直试图为Windows编译mesa。我一直在大致关注本教程，但使用MSYS2而不是完整的Linux操作系统。除了一个方面，我已经成功编译了一个功能正常的opengl32.dll。

当它包含任意数量的标准内置函数之一时，我在编译着色器时遇到访问冲突。其中包括：

getType max(genType, getType); getType min(genType, getType); float dot(genType x, genType y); genType normalize(genType v);

这并非详尽无遗。大多数（可能是所有）内置函数都失败了。没有任何这些函数，着色器编译并运行正常。我无法获得编译日志或类似的东西，因为访问冲突意味着glCompileShader执行后没有代码。这是我的顶点着色器：

#version 130 in vec2 position; void main() { gl_Position = vec4(position, 0.0, 1.0); // Meaningless tests ... float a = 3.0, b = 4.0, c; c = max(a, b); // <-- COMPILES AND RUNS OK WITHOUT THIS LINE }

C ++代码是一个简单的本机Windows应用程序，它遵循本教程。如果人们认为它是相关的，我可以发布完整的代码，但大多数只是窗口设置和类似。实际的着色器编译位如下所示：

// Load the shader source code from a file std::string filePath("Shaders/vertex"); std::ifstream stream(filePath, std::ios::in); std::string code = "", line = ""; while(getline(stream, line)) code += "\n" + line; stream.close(); const char* code_c_str = code.c_str(); GLint code_length = code.size(); // Create a shader and compile the loaded source code GLuint vertexShaderID = glCreateShader(GL_VERTEX_SHADER); glShaderSource(vertexShaderID, 1, &code_c_str, &code_length); glCompileShader(vertexShaderID);

链接到硬件库时，程序运行正常（在我的例子中是NVIDIA）。该程序在链接到由我公司的前雇员完成的Mesa构建时也起作用。不幸的是，个人没有留下关于如何构建Mesa二进制文件的文档。我尝试使用和不使用LLVM构建Mesa，每次都有相同的结果。

有谁知道为什么我的Mesa构建可能无法编译简单的内置glsl函数如此壮观？

更新

我按照建议进行了调试构建，问题就消失了。这似乎是一个优化问题。我已经确定发布版本使用-O0或-O1优化，并且在-O2或-O3上失败。仍然有点痛苦，因为性能对于这个应用程序很重要，但至少我现在有一个工作的DLL和一个想法去哪里。

作为参考，我在msys2上使用默认的gcc / g ++交叉编译器，它似乎是4.9.2。我无法从调试器中获得太多，因为DLL是使用mingw构建的，但测试解决方案是在Visual Studio中。但是，我从gdb得到了这个：

#0 0x00000008 in ?? () #1 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #2 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #3 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #4 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #5 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #6 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #7 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #8 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #9 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #10 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #11 0x644395c0 in glsl_type::_struct_gl_DepthRangeParameters_type () from C:\Users\will\Documents\Visual Studio 2012\Projects\OpenGLMinimalTest\Debug\opengl32.dll #12 0x048c0964 in ?? () #13 0x00000002 in ?? () #14 0x01040000 in ?? () #15 0x00000000 in ?? ()

在Mesa代码之前或之后没有任何信息，因为这些位分别是Windows DLL和Visual Studio编译。错误在内置函数构建器中，这是有意义的，因为它的内置函数生成它。对我来说，这个错误的原因在于优化是不是很明显（至少对我来说）。

I have been attempting to cross compile mesa for windows. I've been following roughly this tutorial, but using MSYS2 rather than a full linux OS. I have successfully compiled a functioning opengl32.dll in all but one aspect.

I'm getting an access violation on compilation of a shader when it contains one of any number of standard built-in functions. These include the following:

getType max(genType, getType); getType min(genType, getType); float dot(genType x, genType y); genType normalize(genType v);

This isn't exhaustive. Most (possibly all) builtin functions fail. Without any of these functions, the shaders compile and run fine. I can't get a compilation log or anything like that as the access violation means no code after glCompileShader executes. Here is my vertex shader:

#version 130 in vec2 position; void main() { gl_Position = vec4(position, 0.0, 1.0); // Meaningless tests ... float a = 3.0, b = 4.0, c; c = max(a, b); // <-- COMPILES AND RUNS OK WITHOUT THIS LINE }

The C++ code is a simple native windows application which follows this tutorial. I can post the full code if people think it is relevant, but most of it is just window setup and similar. The actual shader compilation bit looks like this:

// Load the shader source code from a file std::string filePath("Shaders/vertex"); std::ifstream stream(filePath, std::ios::in); std::string code = "", line = ""; while(getline(stream, line)) code += "\n" + line; stream.close(); const char* code_c_str = code.c_str(); GLint code_length = code.size(); // Create a shader and compile the loaded source code GLuint vertexShaderID = glCreateShader(GL_VERTEX_SHADER); glShaderSource(vertexShaderID, 1, &code_c_str, &code_length); glCompileShader(vertexShaderID);

The program functions fine when linked to the hardware library (NVIDIA, in my case). The program also functions when linked to a Mesa build done by an ex-employee of my company. Unfortunately, the individual left no documentation on how that Mesa binary was built. I have tried building Mesa both with and without LLVM, with the same result each time.

Does anyone know why my build of Mesa might be failing to compile simple builtin glsl functions so spectacularly?

Update

I did a debug build, as suggested, and the problem went away. It seems to be an optimiser issue. I've since ascertained that the release build works with -O0 or -O1 optimisation, and fails on -O2 or -O3. Still a bit of a pain, as performance is important for this application, but at least I now have a working DLL and an idea of where to go.

For reference, I'm using the default gcc/g++ cross compiler on msys2, which appears to be 4.9.2. I haven't been able to get much out of the debugger, because the DLL is built with mingw, but the test solution is in Visual Studio. I did get this, however, from gdb:

#0 0x00000008 in ?? () #1 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #2 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #3 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #4 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #5 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #6 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #7 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #8 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #9 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #10 0x630e51a0 in (anonymous namespace)::builtin_builder::new_sig(glsl_type const*, bool (*)(_mesa_glsl_parse_state const*), int, ...) [clone .constprop.166] () at src/glsl/list.h:440 #11 0x644395c0 in glsl_type::_struct_gl_DepthRangeParameters_type () from C:\Users\will\Documents\Visual Studio 2012\Projects\OpenGLMinimalTest\Debug\opengl32.dll #12 0x048c0964 in ?? () #13 0x00000002 in ?? () #14 0x01040000 in ?? () #15 0x00000000 in ?? ()

There's no information before or after the Mesa code, as those bits are Windows DLLs and Visual Studio compiled respectively. The error is in the builtin function builder, which makes sense, given it's builtin functions that generate it. It's not immediately obvious (to me at least) what the reason for this error is under optimisation.

最满意答案

这不是一个完整的答案，但我认为这已经足够......

仅在更高级别的优化时，MinGW构建中发生了访问冲突问题。 O2及以上不起作用。问题在于着色器内置函数，但我们从未确切地知道它是什么或如何修复它。

最终，为了在Windows上生成Mesa的高效构建，我放弃了MinGW并使用visual studio构建。我使用以下python脚本作为起点。

https://github.com/florianlink/MesaOnWindows

希望这对于遇到相同问题的人来说是足够的信息。

It's not a complete answer, but I think it's enough...

The access violation problem was happening in MinGW builds only at higher levels of optimisation. O2 and above didn't work. The problem is in shader builtin functions, but we never worked out exactly what it was or how to fix it.

Eventually, in order to generate an efficient build of Mesa on windows, I abandoned MinGW and built using visual studio. I used the following python script as a starting point.

https://github.com/florianlink/MesaOnWindows

Hopefully that's sufficient information for anyone encountering the same problems.

更多推荐