This isn't really a big issue, but I don't know where else to put this. I've noticed that a couple of people in the issues archives, and myself, have had a instant crash referring to a lack of Vertex Shader Storage Block support on our GPUs, which would be odd, since all the GPUs in question are OpenGL 4.3+ compliant, which introduced SSBOs in the first place. Having a closer look, it turns out that you didn't need to support Vertex Shaders in SSBOs in order to achieve OpenGL 4.3 compliance, and as a consequence, a lot of GPUs released between 2010 and 2012 (especially those made by AMD) used hacky methods to implement SSBOs that could work with Compute and Fragment Shaders, but couldn't implement support for Vertex Shaders, presumably due to the nature of their pipeline. As a consequence, Ironwail's Vertex Pulling techniques simply don't work on this hardware, despite it technically fulfilling the OpenGL 4.3 requirements.
I'll be frank ; I do not know enough about the wizardry that puts Ironwail together to understand whether or not it would be possible, let alone reasonable, to try and implement a compatibility switch that falls back to doing things with VBOs the old-fashioned way. Furthermore, this is a major edge case ; by mid-2012, most GPU manufactueres were making hardware that didn't have this issue, and so it's really only a small window of people who'd be affected by this problem (and in my personal experience, this thing runs like greased lightning with literally any other machine I throw at it). But I figured it was worth mentioning and trying to locate the cause for the issue, for anyone else who comes across this issue and wonders why their supposedly OpenGL compliant hardware just doesn't want to run Ironwail.
Anyway, Here's the relevant output from me trying to run Ironwail (running this on a 2012-era HP Pavilion laptop, with an a4-4300m APU with Radeon HD 7420g integrated graphics):
Video initialization
Video mode: 1366 x 768 24bit Z24 S8 60Hz
GL_VENDOR: Mesa
GL_RENDERER: AMD ARUBA (DRM 2.50.0 / 6.1.0-48-amd64, LLVM 15.0.6)
GL_VERSION: 4.5 (Core Profile) Mesa 25.0.7-2~bpo12+1
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_buffer_storage
FOUND: ARB_multi_bind
FOUND: ARB_clip_control
ERROR-OUT BEGIN QUAKE ERROR: Your system appears to meet the minimum requirements, however an error was encountered during OpenGL initialization. This could be caused by a driver or an engine bug. Please report this issue, including the following details:
Error linking world|OIT 0; DITHER 0; MODE 0 program:
error: Too many vertex shader storage blocks (3/0)
Engine: Ironwail 0.8.1 (64-bit) OpenGL: 4.5 (Core Profile) Mesa 25.0.7-2~bpo12+1 GPU: AMD ARUBA (DRM 2.50.0 / 6.1.0-48-amd64, LLVM 15.0.6) Vendor: Mesa
If there's anything that'd be relevant to add from glxinfo or lspci, please let me know. Cheers
This isn't really a big issue, but I don't know where else to put this. I've noticed that a couple of people in the issues archives, and myself, have had a instant crash referring to a lack of Vertex Shader Storage Block support on our GPUs, which would be odd, since all the GPUs in question are OpenGL 4.3+ compliant, which introduced SSBOs in the first place. Having a closer look, it turns out that you didn't need to support Vertex Shaders in SSBOs in order to achieve OpenGL 4.3 compliance, and as a consequence, a lot of GPUs released between 2010 and 2012 (especially those made by AMD) used hacky methods to implement SSBOs that could work with Compute and Fragment Shaders, but couldn't implement support for Vertex Shaders, presumably due to the nature of their pipeline. As a consequence, Ironwail's Vertex Pulling techniques simply don't work on this hardware, despite it technically fulfilling the OpenGL 4.3 requirements.
I'll be frank ; I do not know enough about the wizardry that puts Ironwail together to understand whether or not it would be possible, let alone reasonable, to try and implement a compatibility switch that falls back to doing things with VBOs the old-fashioned way. Furthermore, this is a major edge case ; by mid-2012, most GPU manufactueres were making hardware that didn't have this issue, and so it's really only a small window of people who'd be affected by this problem (and in my personal experience, this thing runs like greased lightning with literally any other machine I throw at it). But I figured it was worth mentioning and trying to locate the cause for the issue, for anyone else who comes across this issue and wonders why their supposedly OpenGL compliant hardware just doesn't want to run Ironwail.
Anyway, Here's the relevant output from me trying to run Ironwail (running this on a 2012-era HP Pavilion laptop, with an a4-4300m APU with Radeon HD 7420g integrated graphics):
If there's anything that'd be relevant to add from glxinfo or lspci, please let me know. Cheers