Yes I also need the return address which wasn't in the email about the credit. Also how to you erase the unit? Holding power or cmd+R doesn't seem to work on the M1 macs.

This was the CMake command to build with Rez. Finally got it to generate a non-zero file. The -useDF to use the data fork was important. I guess will move to command line Rez builds instead, but the plugin isn't recognized like it is when Xcode processes the .r file. That may have other causes. add_custom_command(TARGET ${myTargetApp} PRE_BUILD DEPENDS ${MY_SOURCE_DIR}/MyResource.r COMMAND ${rezCompiler} several .r are located across the build I ${MY_SOURCE_DIR}/resources/ arch x86_64 use the datafork useDF needs to specify for Carbon.r and CoreServices.r? #-F Carbon #-F CoreServices where to find framework files isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/ o "${MY_SOURCE_DIR}/${myTargetApp}.rsrc" ${MY_SOURCE_DIR}/MyResource.r )

The forums allow a reply and then say the content is restricted. That loses so many replies. So we think we found the issue with dyld return the same dylib on hotload and even on relaunch of the application. Unlike linux, which sets RTLD_LOCAL by default, Apple's "man dlopen" indicates that RTLD_GLOBAL is set by default on macOS. We verfied with "image list -b -m foo.dylib" that the timestamp doesn't update while running when the dylib is changed out during a hotload with the default setting (RTLD_GLOBAL) and we only set RTLD_NOW. Also relaunching the app, still returns the old dylib and no the new one in the folder. So something about the internal caching and trying to accelerate re-launch isn't correct. We now set RTLD_LOCAL | RGLD_NOW and are seeing the correct dylib behavior. The new dylib is picked up during app execution and when the app is relaunched.

We also have the same issue. This used to work in iOS 9, and was blocked in iOS 10+. Can we have a mode or entitlement that removes the code blocking mmap from an alternate folder? There are many titles that need to hotload C++ dylibs during development, and this restriction totally kills that. Our min-spec can't move off iOS 9 until this issue is addressed. Swift supports hotloading now, so this really can't be an Apple only feature.

I believe this code is only used during development, but I only found out it broke trying to move our base deployment off of 10.9. 10.14 worked, and 10.15 didn't. On another thread, I'd also mentioned that iOS 10+ blocking mmap also prevents C++ dylib hotloading. I feel like blocking this prevents all gamedevs from hotloading their C++ game logic. That's a big deal when you're trying to modify code and content quickly. As games get bigger in size and complexity, the time to launch increases. Even Unity or Unreal require a reload after engine changes. If Apple's going to really push game tech, then this would be a big help even if we have to set a security/dev-only entitlement. Anyways, Quinn thanks so much for the quick response on this.

I have another instance of shader generation in an Xcode project. We are using a makefile that runs various command line tools for this. This neither outputs full paths for the shaders or headers. But I still need to be able to click through to the shaders and headers that are a part of the project.

Pretty sure the limitation is in dynamic indexing into Argument Buffers, so maybe constant indexing works. You need iPhone 11+ or macOS on a Tier 2 GPU which are newer Intel/AMD parts. I have the Vulkan specs for this, but don't have them handy, but it's newer phones. Useful for raytracing and also to avoid needing to use sparse textures. Bindless graphics are the way things are headed now, but Nvidia had this technology for over 10 years in OpenGL.

This problem still happens with an iPad Air3 and Xcode 12.4 connected via a physical cable. Can this issue be fixed? There's a long history on Stack Overflow of this bug happening, and not being fixed since Xcode 6. The device loses a connection, and then Xcode reports that the device is locked even when unplugged and plugged back in. The device is unlocked before and after the replug. This happens pretty easily when bumping a cable connected to a usb-c port that then loses the connection, and when the app is relaunched Xcode thinks it's locked. The only workaround is to quit Xcode and restart it, but fixing the bug would avoid this. The only way I've found to fix it and keep Xcode up is to unpair the device and re-trust it again.

https://feedbackassistant.apple.com/feedback/9119311

https://feedbackassistant.apple.com/form-response/18663156

This is on macOS Big Sur 11.2.3, but was broken 2 or 3 macOS ago when I first hit this. I think the workaround is to somehow load the library from memory, but I thought that's what newLibraryWithData did.

Edit: That's nil on first load of the shader, ...

Our hotloading, for better or worse, builds a metallib per vert/frag file. Then when that file changes or any dependencies, a new metallib is built and we load that one. The problem is that we hand this data off to Metal and it doesn't run it. Previously, I saw this problem even with a single metallib containing all the shaders. The Metal shader cache doesn't test for modification date on the library, or do any hash tests on the shader content. So it sees the same named library, and returns the old version not the new one. So then the old shaders are return over and over again. There is already a Radar on this issue. I'll try to build a sample app that demonstrates this. Not being able to hotload shaders is quite limiting and unique to the Metal api.

Yes, this makes it hard to visually and performance tune games. Here's the feedback link. https://feedbackassistant.apple.com/feedback/9149476

https://feedbackassistant.apple.com/feedback/9188429