Vulkan support in MacOS? about rbdoom-3-bfg HOT 13 OPEN

Hi,

Thanks for pointing me to PR #818. I checked it out and did see some improvements. Initially, I overlooked your note about also needing to apply the nvrhi pull request (RobertBeckebans/nvrhi#6). After sorting out a minor hiccup with that, I was able to compile and run the game successfully.

On my M1 Pro, the performance issues appear to be resolved and the graphics are noticeably better. I haven't figured out how to enable the FPS overlay yet, so I can't make a direct comparison with the OpenGL version. But overall, it's looking good.

Thanks again for the help.

from rbdoom-3-bfg.

Great news! Thanks for testing so quickly.

You can turn on the FPS overlay by setting com_showFPS 2 in the console (or autoexec.cfg). To enable the console (~) add set com_allowConsole 1 to your autoexec.cfg file.

I am quite interested in your before and after results for the M1 Pro, as well as differences vs. the old OpenGL version.

from rbdoom-3-bfg.

There is a notable improvement in FPS with Vulkan after the patch, especially during aircraft takeoff where FPS previously dropped below 10. The performance is also significantly better when compared to OpenGL.

Vulkan Unpatched

OpenGL

Vulkan Patched

from rbdoom-3-bfg.

This looks good, but I want to fix all the single architecture build scripts (i.e. non-universal) to support both x86 and Apple Silicon using Homebrew. This means adding your changes to:

cmake-macos-release.sh
cmake-macos-retail.sh
cmake-xcode-debug.sh
cmake-xcode-release.sh

I would also like to fix the cmake-xcode-universal.sh script to test for MacPorts and make sure the openal-soft universal variant is installed.

Would you mind if I added your changes as I have described here? I would add a new commit to my open PR and credit you for your code.

from rbdoom-3-bfg.

Same performance issue on m1 pro, i moved to version 1.4 instead for opengl

from rbdoom-3-bfg.

I have been working on this problem in the background and believe it is now solved by PR #818. Please retest after applying this pull request to the master branch and let me know if it fixes your issues. See results of tests on Apple M1 Air. Hopefully your M2Max will show similar if not better results.

Note you will also have to apply RobertBeckebans/nvrhi#6 (and RobertBeckebans/nvrhi#4 if you are using the nvrhi head vs. detached at RobertBeckebans/nvrhi@1cbc9e9) to the nvrhi installation located in /neo/extern/nvrhi. PR #818 is dependent on this change.

from rbdoom-3-bfg.

This is all excellent news. Thank you very much for testing and demonstrating the improvement using the new Vulkan nvrhi stream. The only odd thing is the messed-up GPU-side timing info in the FPS overlay.

Which version of the Vulkan SDK are you using? If not the latest, would you mind installing the 1.3.261.1 version from LunarG (containing MoltenVK 1.2.5) and retesting the last case (Vulkan Patched) above? I believe this should solve the GPU-side timing stats issues for Apple Silicon machines. Please let me know.

Scratch the retest. I suspect there may be something wrong with the timestamp calibration when using the newest version of the SDK. Not an issue with SDK 1.3.250.1 (MoltenVK 1.2.4). Please confirm the version you are using.

from rbdoom-3-bfg.

I am using vulkansdk-macos-1.3.261.1

from rbdoom-3-bfg.

FYI I have raised an issue KhronosGroup/MoltenVK#2039 with MoltenVK regarding GPU timestamp calibration in vulkansdk-macos-1.3.261.1

On a different topic, I would like to ask about your experience using the pre-canned cmake-xcode-xxx.sh files on Apple Silicon when configuring the RBDoom3BFG build. Are you using brew or MacPorts? And did you have to edit the shell script to alter any build instructions? I am considering updating the shell scripts for macOS/Xcode to be more friendly to Apple Silicon since that is becoming the dominant platform. I would appreciate your perspective as a user.

from rbdoom-3-bfg.

I've modified the cmake-macos-release.sh release script to work on both my Intel and M1 Macs without requiring Xcode. My setup relies on Homebrew and aims for quick command-line compilation.

I've added a variable for the openal-soft prefix to make it more flexible. Here's the snippet for your reference:

cd ..
rm -rf build
mkdir build
cd build

# Determine the Homebrew prefix for openal-soft
OPENAL_PREFIX=$(brew --prefix openal-soft 2>/dev/null)

if [ -z "$OPENAL_PREFIX" ]; then
  echo "Error: openal-soft is not installed via Homebrew."
  echo "Either install it using 'brew install openal-soft' or provide the path manually."
  exit 1
fi

# change or remove -DCMAKE_OSX_DEPLOYMENT_TARGET=<version> to match supported runtime targets
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_OSX_DEPLOYMENT_TARGET=12.1 -DFFMPEG=OFF -DBINKDEC=ON -DUSE_MoltenVK=ON -DOPENAL_LIBRARY=$OPENAL_PREFIX/lib/libopenal.dylib -DOPENAL_INCLUDE_DIR=$OPENAL_PREFIX/include ../neo -Wno-dev

I noticed that the README assumes users are going to utilize Xcode for Apple Silicon builds. Given my changes, should I submit a PR?

from rbdoom-3-bfg.

Sure, go ahead.

from rbdoom-3-bfg.

Thanks. Your changes added to #818.

from rbdoom-3-bfg.

FYI @asemarafa - Issue KhronosGroup/MoltenVK#2039 regarding GPU timers on Apple Silicon is fixed in MoltenVK 1.2.6. This will be shipped as part of the upcoming Vulkan SDK 1.3.268.1 (note that Vulkan SDK 1.3.268.0 packaged MoltenVK 1.2.5 by mistake and should not be used). Once this is available the RBDoom3BFG performance HUD display will again work correctly for GPU timers on Apple Silicon.

from rbdoom-3-bfg.