-
-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MOJOSHADER_glCompileEffect returns 0x0, and MOJOSHADER_glGetError returns "" when trying to compile shader. #124
Comments
Does ARB_debug_output say anything? I would expect an error to show up in a DEBUG build. The effect appears to parse without any trouble so you're definitely looking at a compiler error. On an unrelated note, the preshaders for some of these effects are HUGE. Take ShaderFunction47 for example:
And I'm not even sure if that's the largest preshader in the pile! You might be able to fix this issue just by doing more work on the CPU instead of in the Effects. |
This may be a duplicate of #69, be sure not to stack TEXCOORD attribs and use stuff like NORMAL and others where appropriate. |
Okay, so I should be using things like How do I access |
If you use a Debug FNA.dll and run on a recent graphics card it should automatically throw an Exception when a GL error occurs: https://github.com/FNA-XNA/FNA/blob/master/src/FNAPlatform/OpenGLDevice_GL.cs#L838 |
Sorry, no exception gets thrown. Geforce GTX 860 M. Is this a recent change? |
Nah, I've had that in there for a few years now. Do you have a minimal sample I can try? Doesn't need to be crazy, just something that loads the Effect and draws a box is enough to go on. I wonder if it's actually using the Intel chipset though. Can you check and make sure it's using the dedicated GPU for sure? We print the active device info to stdout. |
Took a quick look, this appears to be a problem with the shaders' use of clip(). The problem gets introduced when clip() is done directly on an input value, such as the TEXCOORD5 value in the very first pixel shader, which produces something like this:
The problem is that texkill against an input register is forbidden according to Microsoft's own documentation on the texkill instruction. In fact, if I change the shader model to 2.0 instead of 3.0, I get this...
This is what we're actually expecting! So either the documentation we're looking at is outdated and only references SM2 or the SM3 compiler has a problem with this shader. The immediate fix is to change this line to use I'll see if I can't figure out why input registers might suddenly be allowed here, but know that the glsl output is exactly the same as it would be if I were to remove the sanity check for the texkill register type. |
Wow, that's crazy. Thank you so much for helping with this! |
Closing this issue in favor of icculus/mojoshader#4 since it's not strictly FNA doing this. We do have a working fix though! |
Hey, I have a huge, ugly shader here. When I try to compile it, I get an invalid operation exception caused by
MOJOSHADER_glCompileEffect
returning 0x0. There is no error message associated.For reference, the file used to compile, but this commit broke it. That consisted of switching everything over to
ps_3_0
and converting many of my branches into interpolations of boolean values. Still not sure what caused it, but without any kind of error message its hard to know.I have thought about stepping through
MOJOSHADER_glCompileEffect
, but since its an external c library I can't figure out how to do that.The text was updated successfully, but these errors were encountered: