-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metal direct property access #2167
Comments
Objective C property accesses normally happen through objc_msgSend and
objc_msgSend should be reasonably fast in the fast path. If you put up
instructions for reproducing the profile some place I can take a look.
|
That's not what I see. Molten just accesses the fields as: MTLRenderPassColorAttachmentDescriptor* mtlColorAttDesc = mtlRPDesc.colorAttachments[caIdx];
mtlColorAttDesc.clearColor = ... While we go through messages: impl RenderPassColorAttachmentDescriptorRef {
pub fn clear_color(&self) -> MTLClearColor {
unsafe {
msg_send![self, clearColor]
}
}
pub fn set_clear_color(&self, clear_color: MTLClearColor) {
unsafe {
msg_send![self, setClearColor:clear_color]
}
}
}
would it help if I just send you the profile I got? I suppose you may not see the debug symbols then... Anyhow, here are the (rough unverified) instructions: # install Steam and Dota
# go to Steam - >Dota2 -> Properties -> DLC and select "Dota 2 - Vulkan Support"
git clone https://github.com/gfx-rs/portability
ln -s "/Users/<your_name>/Library/Application Support/Steam/steamapps/common/dota 2 beta/game" dota2
cd portability
make version-release
# install required dependencies, e.g. XCode, if the build fails
ln -s <this_folder>/target/release/libportability.dylib target/release/libMoltenVK.dylib
make dota-release
# check if Settings -> Video says it's running Vulkan. The console output shouldn't have any "mvk" stuff Thank you in advance for looking into it! |
@kvark dot-syntax for properties in Objective-C is just syntactic sugar for method calls :) The compiler desugars Having trouble finding an official reference for this, but here's a corroborating stack overflow at least: https://stackoverflow.com/a/7423901 |
More generally, is there any downside to avoiding the overhead of I was thinking we could have a |
objc_msgSend already has a method cache so caching function pointers might a huge amount faster. Caching function pointers also has the problem of not knowing when the cache is wrong because the method changed. Also, clang isn't caching function pointers and we see much see much less time in objc_msgSend with MoltenVK than with gfx, which suggests that there's a bigger problem. |
@jrmuizel agreed, there are other inefficiencies that we need to fix (we probably call
Is it typical for APIs like Metal to change methods dynamically? |
Alright, let's discuss the possible optimization of caching the function pointers in a dedicated issue. This one is closed, thanks to explanations above. |
I noticed that native ObjC apps access the properties directly, while we send messages (as
setSomeProperty
andsomeProperty
). This could explain why we are spending much more time (up to 7% total) in the objC message sending.The text was updated successfully, but these errors were encountered: