flashing problem with samples on Metal in macOS Ventura Topic is solved

[jwwalker]

Last summer, in issue #323, I came up with a hack that got Sample_PlanarReflections working on Mac with Metal rendering, more or less. But when I try it now, there is an irregular flickering between the correct image and all black. I tried a few of the other samples, and they're not doing that. I don't know what has changed, except that I'm now using macOS 13.2, and previously I was using macOS 12.6 or so.

[dark_sylinc]

That sounds like a possible driver bug.

If the driver decides to start the raster pass before the compute pass that blurs the reflections finishes you'll see such behavior.

I see that Apple added memoryBarrierWithResources. It would be bizarre if suddenly this is required.

But without knowing what hack you used, it's impossible to tell.

[jwwalker]

I mentioned the hack in the comments on issue #323:

In MipmapsGaussianBlur_cs.metal, I tried changing the 3rd parameter of the two write calls from p.dstLodIdx to 0, that seems to fix it!

By the way, my Mac has two GPUs, one AMD and one Intel. I tried selecting each in the configuration dialog, and there was no difference. I don't know if that tells you anything.

[jwwalker]

I see that you asked about the memoryBarrierWithResources idea on Twitter, and decided that wasn't the problem. Should I open a new Issue on GitHub, or add comments to my existing Issue #323, or what?

[dark_sylinc]

I'm looking into it now.

Your "hack" was no hack after all. It was the proper fix.

As for why it stopped working on macOS, I see Vulkan is complaining that we are setting the planar reflection as a texture while building it (or at least, without barriers) thus that might explain the problems in macOS.

PS: Have you tried a full rebuild? XCode has the nasty habit of leaving lingering bits here and there from old builds.

[dark_sylinc]

Does the problem go away if you comment this?

Code: Select all

// mirror->setTexture( 0, mPlanarReflections->getTexture( 0 ) );

In PlanarReflectionsGameState.cpp line 162

[dark_sylinc]

Mmm, I just checked the Vulkan error, it was silly one that shouldn't have affected Metal.

You can still try commenting out the mirror->setTexture but I don't think that's gonna fix it.

Unless your glitch is due to something being out of date (i.e. delete the build folder and perform a full rebuild), it may be an Apple bug and should be reported to Apple (it works on macOS 12, it works on iOS 14, and it works on all of our other backends)

Also could you upload a video of the glitch? Show both planes.

[jwwalker]

You can still try commenting out the mirror->setTexture but I don't think that's gonna fix it.

No, it makes the mirror on the right stop being a mirror, but the flashing continues.

Unless your glitch is due to something being out of date (i.e. delete the build folder and perform a full rebuild), it may be an Apple bug and should be reported to Apple (it works on macOS 12, it works on iOS 14, and it works on all of our other backends)

Also could you upload a video of the glitch? Show both planes.

I tried a full rebuild.

What do you mean by "show both planes"?

[dark_sylinc]

What do you mean by "show both planes"?

I mean show both mirrors (not necessarily at the same time, i.e. first show one for 8 seconds, the rotate 180 and show the othe other)

[jwwalker]

Ok, here is a recording:

[media]https://www.jwwalker.com/images/planar% ... ording.mp4[/media]

Hmm, the tool tip says that media BBCode is "media embed", but it's not actually embedding.

[jwwalker]

For what it's worth, I sent Apple a bug report, number FB11991063.

[dark_sylinc]

Ah the whole thing flashes!?

Yeah this looks more like an Apple driver bug.

[dark_sylinc]

They will likely ask you for a way to repro. Include these steps:

1. Download build_ogre_macOS.sh

2. Modify the script to include -D OGRE_BUILD_COMPONENT_PLANAR_REFLECTIONS=1 so that it reads:

   Code: Select all

   cmake -D OGRE_CONFIG_THREAD_PROVIDER=0 \
   -D OGRE_CONFIG_THREADS=0 \
   -D OGRE_BUILD_COMPONENT_SCENE_FORMAT=0 \
   -D OGRE_BUILD_SAMPLES2=1 \
   -D OGRE_BUILD_SAMPLES2=1 \
   -D OGRE_BUILD_COMPONENT_PLANAR_REFLECTIONS=1\ # MODIFIED!
   -D OGRE_BUILD_TESTS=0 \
   -D OGRE_BUILD_RENDERSYSTEM_GL3PLUS=0 \
   -D OGRE_BUILD_LIBS_AS_FRAMEWORKS=0 \
   -G Xcode ../ || exit $?

3. Execute build_ogre_macOS.sh

4. Run Sample_PlanarReflections

5. The XCode project can be found in build/OGRE-Next.xcodeproj

[jwwalker]

Thanks, I added those details to my bug report.

[jwwalker]

I decided to try those "steps to reproduce", and the script didn't work. It got as far as the line

Code: Select all

git clone --branch ${{OGRE_BRANCH_NAME}} https://github.com/OGRECave/ogre-next || exit $?

and that produced an error,

Code: Select all

${{OGRE_BRANCH_NAME}}: bad substitution

Are those curly braces supposed to be doubled like that?

[jwwalker]

When the build script says

Code: Select all

OGRE_BRANCH_NAME="{0}"

is the intent that the branch name should be a parameter to the script, so you'll run it by saying

Code: Select all

./build_ogre_macOS.sh master

?

If so, it ought to be "${1}".

I had to make several changes to get the build script to run at all, and then there was a compile error in OgreMain. The compile errors had to do with confusion about OgreTagPoint.h existing in both OgreMain/src and OgreMain/src/Animation. When I was building in a more manual fashion, I fixed that error by setting the Xcode build setting USE_HEADERMAP to NO, but I don't know what CMake changes would accomplish that.

[jwwalker]

Woops! Now that I tried rebuilding everything from scratch, it seems that ALL the samples are doing the crazy flashing on macOS Ventura, even Sample_Tutorial01_Initialization!

By the way, answering my own question, I think that CMakeLists.txt needs to say

Code: Select all

set( CMAKE_XCODE_ATTRIBUTE_USE_HEADERMAP NO )

somewhere under Apple.

[dark_sylinc]

When the build script says

Ooops. That was the wrong link. The right link is: https://github.com/OGRECave/ogre-next/b ... e_macOS.sh

The version I gave you earlier was a template meant to be parsed by Python.

[dark_sylinc]

Woops! Now that I tried rebuilding everything from scratch, it seems that ALL the samples are doing the crazy flashing on macOS Ventura, even Sample_Tutorial01_Initialization!

Ok that makes it simpler, if something as basic as a clear screen flashes. Is this on both Debug & Release or just one of them?

Does capturing with XCode work?

Usually something like this boils down to something wrong in OgreMetalWindow.mm, like an issue with the CAMetalDrawable.

Does this problem also happen with Tutorial00_Basic? (I don't know if 00 works on macOS though).
The main difference is that Tutorial00 uses our native interface, while the rest use SDL.

By the way, answering my own question, I think that CMakeLists.txt needs to say

Code: Select all

set( CMAKE_XCODE_ATTRIBUTE_USE_HEADERMAP NO )

somewhere under Apple.

Can you try again with the right script? Needing this setting would be new for me, the script works fine on XCode 14.something.

Cheers

[jwwalker]

By the way, answering my own question, I think that CMakeLists.txt needs to say

Code: Select all

set( CMAKE_XCODE_ATTRIBUTE_USE_HEADERMAP NO )

somewhere under Apple.

Can you try again with the right script? Needing this setting would be new for me, the script works fine on XCode 14.something.

Yes, with the right script, I still get compile errors in src/OgreTagPoint.cpp, which seems to be reading the header Animation/OgreTagPoint.h. I'm using Xcode 14.2.

[jwwalker]

Woops! Now that I tried rebuilding everything from scratch, it seems that ALL the samples are doing the crazy flashing on macOS Ventura, even Sample_Tutorial01_Initialization!

Ok that makes it simpler, if something as basic as a clear screen flashes. Is this on both Debug & Release or just one of them?

Does capturing with XCode work?

Usually something like this boils down to something wrong in OgreMetalWindow.mm, like an issue with the CAMetalDrawable.

Does this problem also happen with Tutorial00_Basic? (I don't know if 00 works on macOS though).
The main difference is that Tutorial00 uses our native interface, while the rest use SDL.

Both Debug and Release.

Yes, it happens in Tutorial00_Basic. Only difference is that Tutorial00_Basic looks like it's alternating between blue and white, whereas Tutorial01 alternates between blue and black.

Sorry, what does "capturing with Xcode" mean?

[dark_sylinc]

Use the XCode GPU debugger (the Camera icon).

The capture can also be saved to file and sent to others.

We have a pinned post to guide you through that.

[dark_sylinc]

BTW this is an extreme long shot but it is worth a try: Does the problem go away if you set CMake variable OGRE_RESTRICT_ALIASING to OFF and change # define DECL_MALLOC __attribute__( ( malloc ) ) from OgrePlatform.h to # define DECL_MALLOC ?

It wouldn't be the first time that a compiler became better at optimizing, and turns out it revealed a bug in our code (it's basically a very aggressive optimization).

I doubt this is the case because this shouldn't affect debug builds, but it's not entirely impossible.

[jwwalker]

For Metal, the GPU capture icon is not a camera icon, but a Metal icon.

The only thing I'm seeing from the Metal API Validation is a message that there is a Render Encoder with no work encoded to it.

A GPU trace file

[dark_sylinc]

Mmm... I wonder if this is an @autorelease pool issue. i.e. The ptrs getting released too early.