Program Crashes When Opening Gds_DKPass.bcmdl On Linux

[CuriousTommy]

Hello,

So I tried to open the Gds_DKPass.bcmdl file from my Fedora 27 machine. But as the title suggested, the program crashes whenever I try to open the file. The program itself open just fine. I downloaded the prebuilt Windows executable (from the readme) and ran it with the mono command.

Below is the error I get when I try to open the file:

SPICA.Rendering.Shaders.ShaderException: Error compiling Shader!
0:42(20): error: sampler arrays indexed with non-constant expressions are forbidden in GLSL 1.30 and later

  at SPICA.Rendering.Shaders.Shader.CheckCompilation (System.Int32 Handle) [0x0002c] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.Rendering.Shaders.Shader.CompileAndCheck (System.Int32 Handle, System.String Code) [0x0000d] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.Rendering.Model.UpdateShaders () [0x000b3] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.Rendering.Model..ctor (SPICA.Rendering.Renderer Renderer, SPICA.Formats.CtrH3D.Model.H3DModel BaseModel) [0x000a4] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.Rendering.Renderer.Merge (SPICA.Formats.CtrH3D.H3DDict`1[T] Models) [0x00010] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.Rendering.Renderer.Merge (SPICA.Formats.CtrH3D.H3D Scene) [0x00000] in <c0b2010ee3ad4017a282f7a89612c3ba>:0 
  at SPICA.WinForms.Formats.FileIO.Merge (System.String[] FileNames, SPICA.Rendering.Renderer Renderer, SPICA.Formats.CtrH3D.H3D Scene) [0x0004b] in <8651b74666a644edb6ddba6144e261e6>:0 
  at SPICA.WinForms.FrmMain.FileOpen (System.String[] Files, System.Boolean MergeMode) [0x000b6] in <8651b74666a644edb6ddba6144e261e6>:0 
  at SPICA.WinForms.FrmMain.Open (System.Boolean MergeMode) [0x00038] in <8651b74666a644edb6ddba6144e261e6>:0 
  at SPICA.WinForms.FrmMain.TBtnOpen_Click (System.Object sender, System.EventArgs e) [0x00000] in <8651b74666a644edb6ddba6144e261e6>:0 
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) [0x00019] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.ToolStripButton.OnClick (System.EventArgs e) [0x00017] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.ToolStripItem.HandleClick (System.Int32 mouse_clicks, System.EventArgs e) [0x00029] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs e, System.Windows.Forms.ToolStripItemEventType met) [0x00054] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem.FireEvent(System.EventArgs,System.Windows.Forms.ToolStripItemEventType)
  at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) [0x00048] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00078] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x001b4] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message& m) [0x00000] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x0000b] in <562ff57d5f0647a7b8cd6b9991443574>:0 
  at System.Windows.Forms.NativeWindow.WndProc (System.IntPtr hWnd, System.Windows.Forms.Msg msg, System.IntPtr wParam, System.IntPtr lParam) [0x00085] in <562ff57d5f0647a7b8cd6b9991443574>:0

[CuriousTommy]

Strange... I tested the program on my desktop and it works fine for both Windows and Linux. The only difference is that my desktop uses the Nvidia GPU while my Laptop (the one with the bug) uses the Intel Graphics Driver.

I am going to do a little more testing to see if I can reproduce the bug on my Desktop by using the integrated GPU instead of the Nvidia card.

Edit: Yeah, this error is caused by the Intel Graphic Drivers. I do wonder if AMD cards are effected from this since they also use mesa.

[iskunk]

Hi @CuriousTommy,

In testing a Mono-based build of SPICA (see PR #51), I encountered the same error you reported. I'm trying to nail down exactly what the problem is, beyond the type of GPU. I do not currently have access to a real GPU, and thus am looking to get this working with a software GLSL compiler (llvmpipe) so that the thing at least runs.

Could I request output from glxinfo for the known-good and known-bad Linux OpenGL environments that you tested on previously?

As an aside: It would be great if you could test-build SPICA using Mono on Fedora, so that any significant differences from the Ubuntu build could be documented.

(It so happens that this bug report was what led to my PR, as I figured that if Mono could run the unmodified Windows binary, then it should be able to compile it too :-)

[CuriousTommy]

Could I request output from glxinfo for the known-good and known-bad Linux OpenGL environments that you tested on previously?

Sure, For my desktop: nvidia_gtx1060_good_gl_enviroment intel_4600_bad_gl_enviroment

For my laptop: intel_530_bad_gl_enviroment

As an aside: It would be great if you could test-build SPICA using Mono on Fedora, so that any significant differences from the Ubuntu build could be documented.

I am probably not the best person to ask since it has been a very long time since I compiled a .net application. With that being said, I did test script and it says that msbuild is not found.

I thought mono used xbuild instead of msbuild.

[iskunk]

Thank you @CuriousTommy for the comprehensive information! I'll be reviewing it soon (bit late for tonight).

I'm even more a stranger to the .NET environment, which is why I put together the makefile. I'd like to save others the trouble of digging for the necessary info as I had to do. After all, the main impediment to building this on Linux is informational, not technical.

As of Mono 5.0.0, xbuild has been superceded by msbuild. (Mono is practically a Microsoft project at this point.) What's probably going on is that your distro ships Mono 4.x.x, as Debian/Ubuntu do (4.6.2 as of this writing), which cannot compile SPICA anyway.

Thanks for trying it, in any event. If you like, you could install the current version of Mono from the project's yum repo and try with that. However, if you're not really keen on installing Mono to begin with, then it is no big deal.

[iskunk]

Okay, this has been a bit confusing. I have a couple of findings to report.

First, Mesa's software rendering support seems to top out at OpenGL 3.3 with GLSL 3.30. This should, in theory, be enough to run SPICA. However, the specific feature of dynamic indexing of samplers is addressed by the GL_ARB_gpu_shader5 extension, and glxinfo does not report this extension on a system with the current released version of Mesa (18.1.1). As far as I can tell, Mesa's implementation of this extension is a work in progress.

So running software-only with Mesa is out. However, @CuriousTommy, your laptop does appear to support that extension, per its glxinfo output. And the OpenGL core profile version, at 4.5, is pretty high. So I think it may be possible to get SPICA working on that system, Intel GPU and all. It may be just a matter of enabling this extension in the shader source.

[iskunk]

Well I'll be a monkey's uncle... I've managed to make this work.

I borrowed a laptop with an Intel GPU, described as "Intel(R) HD Graphics 5500 (Broadwell GT2) (0x1616)". Full glxinfo output is here. Initially, I got the same shader-compilation error as originally reported above.

Much to my surprise, the problem turned out to be exactly what I thought it was going in: The ARB_gpu_shader5 extension needs to be explicitly enabled in one particular shader in order for compilation to succeed. This one-liner gets SPICA working for me:

--- a/SPICA.Rendering/Resources/FragmentShaderBase.txt
+++ b/SPICA.Rendering/Resources/FragmentShaderBase.txt
@@ -1,4 +1,5 @@
 #version 150
+#extension GL_ARB_gpu_shader5 : require

 uniform sampler2D LUTs[6];

There may be an alternate approach; I saw some commentary about how you shouldn't normally have to enable extensions explicitly like this. However, I did confirm that merely specifying #version 330 core, as in some of the other shaders, was not enough.

[CuriousTommy]

Did the shader tweak from #47 work for you? That should allow SPICA to run using the Intel GPU on both your laptop and desktop systems.

I tested this on my laptop, I can confirm that it works great (able to load the models) when I load a Mario Kart 7 battle stage.

[iskunk]

Thanks for trying this out @CuriousTommy, I'm glad to hear it addresses the issue for you as well!

(I don't suppose you ever had this problem running SPICA on Windows with an Intel GPU?)

All that remains now is for @gdkchan to review...

[CuriousTommy]

@iskunk I was thinking... maybe we should do a pull request instead so that gdkchan can merge it instead.

[iskunk]

Is a one-line PR really worth the trouble?

This kind of needs some feedback, too, as I'm not terribly familiar with shader coding. It's possible that there's a better way to get the effect of this change, or even that this change breaks some other use case. Aside from my own experimentation, I'm kind of flying blind here...

[kargaroc]

Patch works for me (Arch linux, AMDGPU + Mesa driver)