Attached is the vmware.log from a crashed virtual machine. The exact message provided by VMWare, not that it reveals much is:
VMware Fusion has encountered an error and has shut down the virtual machine.
Click Restart to start the virtual machine again. Click Report to collect data and to request support from VMware.
... 'report' seems to harvest a lot of information about my machine — such as which other applications I have installed by trawling my /Applications folder — so I'll decline to provide that publicly.
Is "2019-02-24T21:43:46.040-05:00| svga| E105: PANIC: Unsupported vertex format SVGA3D_R16_SINT" perhaps the relevant complaint?
On the off chance it is, to try to be as clear as possible:
- I have two pipelines here, one of which works and one of which doesn't;
- both use the same vertex array and attribute bindings;
- the vertex and fragment shaders are also 'similar' but the main difference is that the crashing pipeline does a little more than the regular one — it uses more varyings to do a more complicated calculation.
Attribute bindings are all provided explicitly to the OpenGL driver, per the fact that I'm using the same vertex array with multiple shaders. I check there for all relevant GL errors, so I'm sure I'm not crossing GL_MAX_VERTEX_ATTRIBS since that'd be reported. Similarly, I do all the proper checks for compilation errors on my shaders; none are reported.
Concretely, this is a shader that helps to simulate a CRT. As in, really simulate it. So each piece of geometry is a single raster scan, with an underlying signal. In the first case, the input is unfiltered RGB. So there's not a lot more to it than keeping track of the input texture coordinate. In the second case, the input is composite video. So additional varyings are information about phase and amplitude of the colour subcarrier, and a bunch of extra texture coordinates to allow for frequency-range filtering. Then the fragment shader is doing some trig and some windowed filtering.
If that's actually the problem, and it's really true that I've just found an instance where the GLSL compiler tries to use hardware that isn't available and has no final recourse but to declare an unrecoverable machine, any idea whether this is fixed in Fusion 11?
The host machine, should that prove to be helpful, is a first-generation Retina MacBook. So an Intel HD Graphics 5300.
Within the virtual machine glxinfo reports (after a reboot):
thomasharte@ubuntu:~$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE; LLVM;
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.2.2
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
