search

RobertBeckebans / RBDOOM-3-BFG

Doom 3 BFG Edition source port with updated DX12 / Vulkan renderer and modern game engine features
https://www.moddb.com/mods/rbdoom-3-bfg
GNU General Public License v3.0
1.38k stars 247 forks source link

MacOS and Vulkan not displaying models #591

Closed tomgreen66 closed 1 year ago

tomgreen66 commented 2 years ago

Having compiled with Vulkan using MoltenVK and updating the glslang repo to a newer version due to issues compiling it seems the models are not showing up and just invisible. See screenshots.

image

image

Nothing obvious in the logs to show why this is occurring. Works find when compiled with OpenGL. I am using Mojave with latest VulkanSDK 1.2.176.1.

BielBdeLuna commented 2 years ago

a problem in the skinned models but not in the "static" models, do you get any message in the console? any warning message?

tomgreen66 commented 2 years ago

Nothing jumps out. Even tried running with MVK_DEBUG=1 but bug in 1.2.176.1 sdk breaks that method. Fixed in just released 1.2.182.0 so can try that later. Shall I upload the console output?

RobertBeckebans commented 2 years ago

Try to run it with +set developer 1 +set logfile 2 and paste the logfile.

SRSaunders commented 2 years ago

I am not seeing these errors on my setup using Vulkan SDK 1.2.176.1. Skinned characters are visible and no errors on save or autosave. Tested on Mojave and Bug Sur using a Radeon RX 580 GPU, also tested on an older MacBook Pro 2012 running Catalina (Intel GPU). Note the installer for Vulkan SDK 1.2.176.1 does not complete properly on Mojave. See https://vulkan.lunarg.com/issue/view/609cf8d85df1127f84292948. You have to complete the install manually using sudo on the command line. Please check if your Vulkan install completed properly.

Another idea: Are you using Robert's new baked lighting files (are these even applicable to Vulkan)? I currently do not have them so I am wondering if this is somehow making a difference.

tomgreen66 commented 2 years ago

Thanks for the advice, will try getting logs and check installations. Noticed the error on install of VulkanSDK and ran command but will check again. Feel it's something silly. On late 2013 Macbook Pro Intel Iris Pro with Mojave.

SRSaunders commented 2 years ago

If you think the issue is related to dynamic models and skinning, you could try turning it off by setting r_useGPUSkinning to 0. If this fixes it, then we may be looking at a GPU capabilities issue that would have to be detected at runtime. Note the Vulkan renderer currently assumes GPU skinning is available on all GPUs, Mac included. I have not run into a problem here so far, but I have only a limited number of macOS machines and configs to test on.

tomgreen66 commented 2 years ago

Bingo - set r_useGPUSkinning 0 fixes it. Hmmm, wonder what my card doesnt support. Would output from vulkaninfo help or the output from the console log still be useful?

SRSaunders commented 2 years ago

Good news that you have confirmed it! I would like to see the output from vulkaninfo for your GPU. Also, the console log output would be helpful, but please use the Xcode debug version (i.e. the one using the Vulkan loader vs. MoltenVK) and set r_vkEnableValidationLayers 1 and set r_useGPUSkinning 1 within your autoexec.cfg file before launching the application, i.e. I would like to look for Vulkan device setup information on launch and Vulkan validation layer errors when the game tries to draw GPU skinned characters.

If you could post both of these as file attachments it would allow me to make a comparison to my setups and look for differences/problems. Thanks.

tomgreen66 commented 2 years ago

Hi, I ran the following from the commandline after setting the options in ~/Library/Application\ Support/RBDOOM-3-BFG/base/autoexec.cfg vulkaninfo.txt qconsole.log

vulkaninfo > vulkaninfo.txt
export MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE=1
./RBDoom3BFG.xcodevulkandebug +set developer 1 +set logfile 2 2>&1 | tee debug_console.txt

I attach the qconsole.log from the base directory but can send the full console output (debug_console.txt) when game runs if that helps.

The error that stands out:

[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-vkCreateSampler-maxSamplerAllocationCount-04110 ] Object 0: handle = 0x7fb41c00ca18, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xb408bc0b | vkCreateSampler(): Number of currently valid sampler objects (4496) is not less than the maximum allowed (1024). The Vulkan spec states: There must be less than VkPhysicalDeviceLimits::maxSamplerAllocationCount VkSampler objects currently created on the device. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-vkCreateSampler-maxSamplerAllocationCount-04110)'
SRSaunders commented 2 years ago

Thanks for logging and posting this info. Unfortunately, the maxSamplerAllocationCount validation error is not the problem in this case, as I see these errors on my setups too. It's a separate issue that arises from exceeding a device resource limit (perhaps on macOS only?) but does not appear to affect model visibility with GPU skinning. When I have more time I would like to dig into this to see if it can be solved.

I have compared your vulkaninfo and console logs for Intel Iris Pro (SDK 1.2.182.0 on Mojave) to my Intel HD 4000 setup (SDK 1.2.182.0 but on Catalina) and see almost no differences. The minor differences (some resources limits, a few features) don't seem to be related to GPU Skinning. The problem may be more subtle and related to MoltenVK host memory coherency. There is a known issue with MoltenVK/Metal on Mojave and earlier versions of Catalina (<10.15.6) regarding CPU/GPU memory coherency (see https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/MoltenVK_Runtime_UserGuide.md#limitations). I thought I had solved this problem already by adjusting memory allocation flags but perhaps it is still lingering in some cases. And I am not sure why this problem would manifest with Intel graphics and not AMD graphics (i.e. my RX580 on Mojave).

In any case, to test this hypothesis I plan to boot my MacBook Pro 2012/HD 4000 with Mojave and see what happens. Would it be possible for you to test on your machine with Catalina or Big Sur (version 10.15.6 or greater)? We could then compare notes and go from there.

UPDATE - I set up my MacBook Pro 2012/Intel HD 4000 GPU with Mojave 10.14.6, Xcode 10.3 and Vulkan SDK 1.2.182.0 in order to duplicate your setup as closely as possible. I used the cmake-xcode-vulkan-debug.sh script, built and ran the game. Unfortunately I cannot duplicate your issue - the game works properly with GPU Skinning (r_useGPUSkinning 1). This seems to take the spotlight off my original hypothesis that memory coherency is the culprit - perhaps it is not.

The only differences in vulkaninfo between the two machines is that: 1) Iris Pro supports VK_EXT_fragment_shader_interlock and its sub features while HD 4000 does not 2) VkSurfaceCapabilitiesKHR currentExtent width, height=512 for Iris Pro and width, height=256 for HD 4000, 3) by default imageViewFormatSwizzle is enabled on your Iris Pro GPU (no need for the environment variable)

I don't know how VK_EXT_fragment_shader_interlock works, but it is also not present on my AMD RX 580. Could this additional feature of your GPU have anything to do with the operation of GPU Skinning?

tomgreen66 commented 2 years ago

Wow, thanks for all the investigation so far. I'm just about to go on holiday for a week but should be able to try some of your suggestions when I return.

SRSaunders commented 2 years ago

Thanks - have a good break and let me know once you have any additional info.

tomgreen66 commented 2 years ago

Just to say -

  1. Finally got Catalina installed on another volume and booted it up. Installed brew, installed dependencies and pointed to latest Vulkan SDK and updated the glslang submodule and it still seems to not display models (this is on 10.15.6).
  2. Tried older versions of Vulkan SDK before Interlock support was added (vulkansdk-macos-1.1.114.0/) and it didnt make a difference.
  3. Also tried enabling the interlock feature by adding the extension in the code but didnt make a difference.
  4. Tried turning off some of the features from the card since vkGetPhysicalDeviceFeatures2 is used to get the features rather than just force the features we want.

Also noticed some oddities for example

https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/c4030850abf860f64349772881d0ed4b8d9823ed/neo/renderer/Vulkan/RenderBackend_VK.cpp#L522-L528

Doesnt seem to be called. Is that expected? Happy to try other things.

SRSaunders commented 2 years ago

Thanks very much for trying all these things. The code you show above should definitely be called - it is called on my test machines (AMD and Intel GPUs). This adds the VK_KHR_portability_subset extension to the device, which the Vulkan spec indicates is required for portability implementations like MoltenVK. Have you used the cmake-xcode-vulkan-debug.sh script to build? If you put a breakpoint on line 525 with a debug build, it should stop during initialization (note that Xcode release builds do not have symbols and do not stop at breakpoints).

Also, it seems that Catalina does not solve your GPU skinning issue, which takes away my initial theory that you are suffering from a known memory coherency bug. GPU skinning requires information back from the GPU which may still be the problem with your GPU, but perhaps not a simple one. Do you have a different Mac model you could try out?

I will be getting temporary access to a 2015 Retina MacBook Pro this weekend. It has an Intel Iris Graphics 6100 GPU which I would like to try out for comparison, and attempt to duplicate your issue. So far I have not been able to duplicate it.

In the mean time, you can use r_useGPUSkinning 0 as a work-around.

Update: Does your machine happen to be a 15" dual GPU (Intel + Nvidia)? Exactly which machine is it?

tomgreen66 commented 2 years ago

The exact version of the Mac I have from system report:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro11,2
  Processor Name:   Intel Core i7
  Processor Speed:  2 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Hyper-Threading Technology:   Enabled
  Memory:   16 GB

and video spec is

  Chipset Model:    Intel Iris Pro
  Type: GPU
  Bus:  Built-In
  VRAM (Dynamic, Max):  1536 MB
  Vendor:   Intel
  Device ID:    0x0d26
  Revision ID:  0x0008
  Metal:    Supported, feature set macOS GPUFamily1 v4
SRSaunders commented 2 years ago

I have tested the following machines + Intel GPUs with the most recent macOS Vulkan build and see no problems. I can't duplicate the issue you are experiencing with GPU Skinning. Comparing the output from VulkanInfo does not provide any obvious clues either. And the VK_EXT_fragment_shader_interlock feature, while not present on the Intel HD Graphics 4000 GPU, is also present on the Intel Iris Graphics 6100 GPU (like your Iris Pro 5200) so that is not likely the cause - as you determined anyways from your previous testing.

I wonder if there is a GPU Skinning capability limitation or even a MoltenVK/Metal driver defect with the Iris Pro 5200 chip of that generation. Unfortunately I have exhausted my diagnostic options at this point. I suppose you could try to trace through the problem with the debugger but I imagine that could be quite tricky and time consuming. Unless this issue can be duplicated by others on different machines/GPUs, I suggest you simply set r_useGPUSkinning 0 on your machine.

Thanks for all your efforts and I am sorry that I can't duplicate the problem.

13" Mid 2012 MacBook Pro (MacBookPro9,2) running Mojave 10.14.6/Vulkan 1.2.182.0 - GPU Skinning working fine:

 Chipset Model: Intel HD Graphics 4000
  Type: GPU
  Bus:  Built-In
  VRAM (Dynamic, Max):  1536 MB
  Vendor:   Intel
  Device ID:    0x0166
  Revision ID:  0x0009
  Metal:    Supported, feature set macOS GPUFamily1 v4

Retina 13" early 2015 MacBook Pro (MacBookPro12,1) running Mojave 10.14.6/Vulkan 1.2.182.0 - GPU Skinning working fine:

Chipset Model:  Intel Iris Graphics 6100
  Type: GPU
  Bus:  Built-In
  VRAM (Dynamic, Max):  1536 MB
  Vendor:   Intel
  Device ID:    0x162b
  Revision ID:  0x0009
  Metal:    Supported, feature set macOS GPUFamily1 v4
tomgreen66 commented 2 years ago

Just wanted to check. I thought the whole option to enable swizzle is done in code now - I see the following when I dont specify environment variable to enable it: 

--------------------------------------
------- Initializing renderSystem --------
Binarize File: '_default' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
Binarize File: '_white' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
Binarize File: '_black' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
Binarize File: '_cyan' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
Binarize File: '_flat' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
Binarize File: '_alphaNotch' - reason 'generated image'
[Vulkan] ERROR: [ Validation ] Code 0 : 'Validation Error: [ VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465 ] Object 0: handle = 0x7fed040b4618, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x82ae5050 | vkCreateImageView (portability error): swizzle is disabled for this device. The Vulkan spec states: If the [VK_KHR_portability_subset] extension is enabled, and VkPhysicalDevicePortabilitySubsetFeaturesKHR::imageViewFormatSwizzle is VK_FALSE, all elements of components must be VK_COMPONENT_SWIZZLE_IDENTITY. (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-VkImageViewCreateInfo-imageViewFormatSwizzle-04465)'
[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: The value of vkCreateImageView(VkImageViewCreateInfo::components) (VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_R), when applied to a VkImageView, requires full component swizzling to be enabled both at the time when the VkImageView is created and at the time any pipeline that uses that VkImageView is compiled. Full component swizzling can be enabled via the MVKConfiguration::fullImageViewSwizzle config parameter or MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE environment variable.
[Vulkan] ERROR: [ MoltenVK ] Code 0 : 'VK_ERROR_FEATURE_NOT_PRESENT: The value of vkCreateImageView(VkImageViewCreateInfo::components) (VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_ONE, VK_COMPONENT_SWIZZLE_R), when applied to a VkImageView, requires full component swizzling to be enabled both at the time when the VkImageView is created and at the time any pipeline that uses that VkImageView is compiled. Full component swizzling can be enabled via the MVKConfiguration::fullImageViewSwizzle config parameter or MVK_CONFIG_FULL_IMAGE_VIEW_SWIZZLE environment variable.'
Sys_Error: VK: VK_ERROR_FEATURE_NOT_PRESENT - vkCreateImageView( vkcontext.device, &viewCreateInfo, NULL, &view )
AL lib: (EE) alc_cleanup: 1 device not closed
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
Abort trap: 6

Will continue to explore - currently looking at the https://github.com/KhronosGroup/VK-GL-CTS for Vulkan conformance.

SRSaunders commented 2 years ago

Debug builds still require the ENV variable because they use the Vulcan lib with validation layers. Xcode debug builds predefine the variable for runtime debugging but for command line execution you must do this manually.

Release and retail builds use MoltenVK directly, bypass the validation layers, and enable swizzle in the code. See the shell scripts and CMakeLists.txt for details. The -DUSE_MoltenVK cmake variable controls this.

Update: I mentioned in an earlier post that the vulkaninfo output from your card showed imageViewFormatSwizzle = true and that you may not need to define the swizzle ENV variable. However, if you had previously set the ENV variable before running vulkaninfo, this masked the unmodified output of vulkaninfo. If the unmodified output (i.e. without ENV variable set) shows imageViewFormatSwizzle = false then you need to set the ENV variable before running debug builds from the command line. Release and retails builds override this setting at runtime via an MVK-specific API and do not have this requirement.

Note the swizzle ENV variable may not be required for debug builds running on Catalina and Big Sur. It seems that the swizzle feature may be set as default on for these versions of macOS. You can run vulkaninfo to test this on your machine.

tomgreen66 commented 2 years ago

Hi. Now updated to Big Sur and still see the issue. I have looked into using Xcode with the GPU frame debugging - https://developer.apple.com/documentation/metal/frame_capture_debugging_tools - and can see each rendering as Vulkan displays them but other than what looks like the textures for the ship and person not being used there is nothing obvious. Seems to be a number of reports that my Intel GPU has a few bugs with other things so might just have to put it down to bad GPU.

SRSaunders commented 2 years ago

@tomgreen66 - I am not sure if this would help, but I have a private fork of Sascha Willems' Vulkan Samples project that compiles for macOS (I know the Brenwill group has their own folk as well, but it has not been updated in over a year). In this project Sascha has a sample that tests vertex skinning. This might be a way to independently test skinning on your specific machine/GPU - separate from RBDOOM-3-BFG. I have not merged my work back to my GitHub repo yet, since I am still working on getting sample animation working properly using Objective-C++ and the Cocoa framework of the Mac port. I am not an ObjC++ programmer and have not worked with Cocoa before, so this aspect is proving a bit time consuming for me. Nonetheless, I could merge back my work to date if this would be useful for you. Please let me know...

tomgreen66 commented 2 years ago

Hi - just cloned https://github.com/SaschaWillems/Vulkan.git and built it for MacOS - main thing I had to do was change the Other C++ flags from -ObjC++ to -x objective-c++ to override the use of -x according to file type used earlier in the compiler flags. Seemed to work and have build the gltfskinning example and it seems to work. If you have any other ideas happy to try them. One thing I think might be worth doing is looking further at Vulkan conformance since it has lots of tests. Many fail unfortunately and a particular test fails catastrophically so have to edit those tests out. Think the MoltenVK developers are also using it as a way to check conformance.

SRSaunders commented 2 years ago

Good news that you have the project compiling on macOS and the skinning example works on your hardware. Your compile flags fix was simpler and more efficient than mine, where I worked on the Mac subproject under the Xcode directory. Both are valid but yours did not involve mucking around with the ObjC++ Cocoa framework stuff that I had to learn :)

Re the results of the test, on my R580 GPU all examples run successfully (62 out of 76) except for the following:

Failing examples (14): conditionalrender, conservativeraster, deferredshadows, descriptorindexing, geometryshader, pipelinestatistics, rayquery, raytracingbasic, raytracingcallable, raytracingreflections, raytracingshadows, texturesparseresidency, variablerateshading, viewportarray

RobertBeckebans commented 1 year ago

The old Vulkan backend has been deprecated.