Examples not working on macOS with Ogre2.2 #422
Comments
|
the tests on our homebrew CI builds were all failing as well to so we had to switch back to running ogre 1.x tests on macOS in Fortress, #407. |
|
The segmentation fault should be fixed by this PR: [OSX] Fix segmentation fault when creating a CocoaWindow #225. There is an issue compiling one of shader pieces on macOS because I am trying to isolate the cause of the rendering issue - not sure if it's a shader problem or something in the way the ignition-rendering uses Ogre2-2 that is different from the Ogre Samples. The Ogre2 examples: Sample_Tutorial03_DeterministicLoop and Sample_PbsMaterials are both working with the GL3Plus render system, so it should be feasible to get Fortress running on macOS. |
chapulina
added
macOS
|
great, that sounds promising. We can update our ogre2.2 formula (and probably also the debs) to pull from a new commit upstream when it's ready. Thanks! |
OGRECave/ogre-next#225 has been merged into ogre-next/v2-2 and ogre-next/main. I've checked that cherry-picking it into the commit used by osrf/simulation/ogre2.2.rb (OGRECave/ogre-next@ec3f70c) addresses the segmentation fault (i.e. no other commits are required). The shader compilation error when running GLSL compile log: 100000002PixelShader_ps
ERROR: 0:1118: No matching function for call to texelFetch(usampler2D, int)
ERROR: 0:1125: No matching function for call to texelFetch(usampler2D, int)
ERROR: 0:1128: Use of undeclared identifier 'idx'
ERROR: 0:1131: Use of undeclared identifier 'idx'
ERROR: 0:1133: Use of undeclared identifier 'idx'
ERROR: 0:1134: Use of undeclared identifier 'idx'
ERROR: 0:1137: Use of undeclared identifier 'posAndType'
ERROR: 0:1140: Use of undeclared identifier 'attenuation'
ERROR: 0:1143: Use of undeclared identifier 'attenuation'
ERROR: 0:1143: Use of undeclared identifier 'attenuation'
ERROR: 0:1145: Use of undeclared identifier 'atten'
ERROR: 0:1145: Use of undeclared identifier 'attenuation'
ERROR: 0:1145: Use of undeclared identifier 'attenuation'
ERROR: 0:1151: Use of undeclared identifier 'lightDiffuse'
ERROR: 0:1151: Use of undeclared identifier 'lightSpecular'
ERROR: 0:1152: Use of undeclared identifier 'atten'
ERROR: 0:1157: No matching function for call to texelFetch(usampler2D, int)
ERROR: 0:1164: No matching function for call to texelFetch(usampler2D, int)
ERROR: 0:1167: Use of undeclared identifier 'idx'
ERROR: 0:1170: Use of undeclared identifier 'idx'
ERROR: 0:1172: Use of undeclared identifier 'idx'
ERROR: 0:1173: Use of undeclared identifier 'idx'
ERROR: 0:1175: Use of undeclared identifier 'idx'
ERROR: 0:1177: Use of undeclared identifier 'idx'
ERROR: 0:1179: Use of undeclared identifier 'posAndType'
ERROR: 0:1182: Use of undeclared identifier 'attenuation'
ERROR: 0:1185: Use of undeclared identifier 'attenuation'
ERROR: 0:1185: Use of undeclared identifier 'attenuation'
ERROR: 0:1187: Use of undeclared identifier 'atten'
ERROR: 0:1187: Use of undeclared identifier 'attenuation'
ERROR: 0:1187: Use of undeclared identifier 'attenuation'
ERROR: 0:1195: Use of undeclared identifier 'spotDirection'
ERROR: 0:1197: Use of undeclared identifier 'spotParams'
ERROR: 0:1197: Use of undeclared identifier 'spotParams'
ERROR: 0:1198: Use of undeclared identifier 'spotAtten'
ERROR: 0:1198: Use of undeclared identifier 'spotAtten'
ERROR: 0:1198: Use of undeclared identifier 'spotParams'
ERROR: 0:1199: Use of undeclared identifier 'atten'
ERROR: 0:1199: Use of undeclared identifier 'spotAtten'
ERROR: 0:1203: Use of undeclared identifier 'spotParams'
ERROR: 0:1205: Use of undeclared identifier 'lightDiffuse'
ERROR: 0:1205: Use of undeclared identifier 'lightSpecular'
ERROR: 0:1206: Use of undeclared identifier 'atten'
libc++abi: terminating with uncaught exception of type Ogre::RenderingAPIException: OGRE EXCEPTION(3:RenderingAPIException): Fragment Program 100000002PixelShader_ps failed to compile. See compile log above for details. in GLSLShader::compile at /Users/rhys/Code/ogre/ogre-next2.2/RenderSystems/GL3Plus/src/GLSL/OgreGLSLShader.cpp (line 314)
zsh: abort ./simple_demo ogre2It's a bit odd. I've created a standalone ogre2 sample based off the
The It would be nice to be able to easily switch rendering features on and off to help track down the origins of this type of error - even to the extent of being able to swap out Pbs for a simpler shader. |
cool, I also just want to make sure that we don't need any more changes upstream to fix the remaining ign-rendering shader compile issue. Just so that we don't roll out 2 different ogre 2.2 versions in a short time.
thanks for testing that! Just brainstorming ideas:
I think the issue is less likely related to Terra as those Hlms are not used if heightmaps are not loaded in the scene. But I could be wrong |
Agree completely - I'm hoping it's just shaders from here on in rather than the C++ code in Ogre, but it could be residual OpenGL < 4.2 compatibility issues.
The Have checked the |
cc @darksylinc, do you have some insights on what could be the causing the Forward3D demo to generate the shader errors (see #422 (comment)) on macOS? |
|
The shader errors were fixed by srmainwaring as he says:
Indeed, the problem is that texelFetching a TBO does not exist in macOS so a workaround is to use a regular texture 2D and use texelFetch on it (which is 2D instead of 1D). Now as to why the screen is clear after the fix could either be a problem with the way srmainwaring fixed it; it could be a bug in how we workaround the problem (alignment issues for being a 2D texture, integer slot not being set since we rely on layout() on normal GLSL/OpenGL*), a driver bug; or a bug caused by missing functionality. It's hard to guess without trying it. *There's a relatively high chance this is the problem. I see |
|
Btw I strongly suggest to place efforts on Metal support instead. I don't see this being a hard endeavour; and getting OpenGL to work on macOS is an uphill battle. |
|
@darksylinc to get rid of the shader compile error I modified @property( GL_ARB_texture_buffer_range )
#define bufferFetch1( buffer, idx ) texelFetch( buffer, idx ).x
@else
#define bufferFetch1( buffer, idx ) bufferFetch( buffer, idx ).x
@endwhere With this the Forward3D sample will run but the lights are not rendering correctly. I think there is something to your suggestion that it's an alignment issue as when the number of lights are increased there are overlapping and incorrectly positioned blocks of lights. Sample_Postprocessing is running but not rendering anything, and I'm not really sure where to start there. I appreciate OpenGL is legacy for macOS now, but if you'd be able to help I'd like to try get ignition fortress working as well as ignition edifice is on macOS (which is functional enough for day to day dev work). I can either open an issue on ogre-next or continue the ogre forum thread I started. Looking to the next version of ignition, I'd very much be in favour of having Metal support as well. I'm hoping that this work on legacy OpenGL can tide things over until then. |
@iche033 this may not be the whole story for what's preventing macOS from running fortress, but it explains why I'm not seeing anything rendered: Compositor local textures not working correctly in macOS with GL3+ #231. |
|
thanks for investigating the issue! I was thinking that we could work around the issue by disabling post processing in regular cameras (and just use the PbsMaterial compositor setup) but lots of sensors also use local textures unfortunately. If the local texture issue turns out that it may take some time to fix, we could try to just get a regular camera working for macOs by adding ifdefs in our code for macOS. |
|
no prob. @darksylinc is being very helpful suggesting lines of investigation and I'm sure we'll eventually get to the bottom of it. On a related note: have been thinking about looking into what would be required to add Metal support to the ogre2 render engine. I realise that the initial thought was the team would not support Metal shaders, but it may turn out to be less effort than trying to maintain OpenGL on macOS. Ogre2 already has mechanisms for creating universal materials. If I was to get the initial port to Metal running would the team support it? |
|
Metal support came up a few times. The main concern was the extra maintenance effort on the shaders down the road but looks like now it's hard to avoid. A few ideas on the shader situation if we were to add Metal support:
3 will probably take quite a bit of effort to do so I am leaning towards 1 and 2 for now. I don't have experience with SPIR-V Cross so I don't know how well it works. If we're able to go from glsl -> spirv -> metal using this conversion tool, it may be the faster way to get something working. |
I'd favour option 1 as well, at least initially. There are only about 17 - 18 shaders specific to ignition-rendering that need to be ported to Metal as all the Ogre HlmsPbs and HlmsUnit versions are there already. That doesn't seem too bad. As it's a bit off topic for this issue I'll open a new feature request for Metal support as a place to gather ideas and outline the effort. |
|
Progress update: The problem in Ogre2 is related to setting up the FBOs for legacy OpenGL. With a partial workaround the ignition-rendering demos will render on macOS, although there are some artefacts. I believe this is arising in some cases because of the order in which the textures are created then attached to FBOs (it looks like a placeholder for a texture may be set in the FBO with the texture creation deferred - which is not supported on macOS) . The good news is that if this is addressed then it should be feasible to have ogre2 GL3+ rending on macOS working again. simple_demo with incorrect rendering artefacts
thermal_camera
transform_control
ogre2_demo with rendering artefacts
|
|
Hi! I'll chime in regarding Metal support: Indeed adding Metal support should be easy, since it's mostly porting shaders and ignition uses few shaders. As for how to port shaders (option 1, 2, 3): Duplicating all shaders (i.e. rewriting them in metal)Pros:
Cons:
Any shaders.Contrary to what ignition devs believe, "any" shader files are not an extension or special functionality. It's a convention. 90% of the shader syntax is the same. Thus we use macros to abstract some of the differences. e.g. The main divergence is that metal provides uniform parameters through a struct that has only local scope while GLSL is via uniform variables with global scope. The convention we use at Ogre is the following: Pros:
Cons:
SPIRV-Cross.I never tried this venue but did hear about it a lot. Epic and Roblox use it. Pros:
Cons
Possible issues:
|
|
@darksylinc thanks for the detailed analysis on options for providing Metal support. I've taken approach 1, at least to start with. This seemed like the least intrusive method with a minimal impact on existing GLSL shaders while getting things up and running. The main change to existing methods is a move to unified vertex and fragment program definitions in the material files. So far it looks promising - all the ign-rendering shaders now have a Metal version and most of the examples that should run on Metal are now running. There's some odd behaviour where an example that runs in my environment won't complete the last render step on @ahcorde's machine, but we're working through that. The last hurdle is to get the QML demo working, which currently relies on a shared OpenGL context between QML and Ogre. IIRC there is a variant of the Qt declarative example that covers this case for Metal - so that's next, and solving that should provide a path to getting the Scene3d plugin working for ign-gui and ign-gazebo. As a follow up it might help with maintenance to move to your second proposal, and consolidate into Any shaders. It could be worth converting one shader as an example so the Ignition team can compare approaches and decide what works best for them. |
|
With the exception of the simple_demo_qml example, this is addressed by #463. The QML example can be followed up separately using a similar approach to that proposed in gazebosim/gz-gui#323. |
This issue is a placeholder to report that an upstream issue with Ogre2.2 is preventing examples that work for Edifice using Ogre2.1 from running in Fortress.
The examples tested include:
simple_demosimple_demo_qmlogre2_demoThe problem is essentially the same in all cases: the application segmentation faults.
The issue is arising in the macOS OpenGL3Plus windows code in Ogre2.2 located in
ogre-next/RenderSystems/GL3Plus/src/windowing/OSX. It appears that ignition-rendering uses this code in a way that is not tested by running the Ogre2 samples, which do run on the environment described below.Environment
OS Version:
Source or binary build?
mainRendering issue
$ system_profiler SPDisplaysDataType 2021-09-23 14:48:58.715 system_profiler[91265:26022571] Device PreExisted [00000001000009d5] AMD Radeon Pro W5700X Graphics/Displays: AMD Radeon Pro W5700X: Chipset Model: AMD Radeon Pro W5700X Type: GPU Bus: PCIe Slot: Slot-1 PCIe Lane Width: x16 VRAM (Total): 16 GB Vendor: AMD (0x1002) Device ID: 0x7310 Revision ID: 0x0000 ROM Revision: 113-D1860W-213 VBIOS Version: 113-D186A2XT-019 Option ROM Version: 113-D186A2XT-019 EFI Driver Version: 01.01.200 Metal Family: Supported, Metal GPUFamily macOS 2 Displays: Cinema HD: Display Type: LCD Resolution: 2560 x 1600 UI Looks like: 2560 x 1600 Framebuffer Depth: 30-Bit Color (ARGB2101010) Display Serial Number: CY628129UG1 Main Display: Yes Mirror: Off Online: Yes Rotation: Supported Automatically Adjust Brightness: Yes Connection Type: DVI or HDMI Adapter Firmware Version: 2.21Description
simple_demo ogre2Steps to reproduce
simple_demoexampleOutput
The text was updated successfully, but these errors were encountered: