If every couple hundred user space instructions, a new kernel call is made, the TLB exceptions are going to dominate the application's run-time. If there is a kernel call, and then lots of time spent in user space, the TLB invalidation gets swallowed by the bigger picture. An invalidated TLB causes a lot of virtual memory exception interrupts to reload the TLB as user code attempts to continue execution after returning from a system kernel call. The fix is to keep invalidating the TLB (virtual memory hardware Translation Lookup Buffer) each time code goes from kernel address space back to user space. How often does your code call into the kernel? that is where the meltdown fixes impact performance. However, I do see a big problem with my own code. If anyone do think they have a major vendor's game or app they are sure based on the Metal 2, please let me know. I hope Apple could pay more attention to this issue as they do want to attract more attraction to the new graphics framework.
It's because Metal 2 is still rarely supported by major software. But no one can find evidence the other way. The second reason is that lots app still use the OpenGL driver, which may immune to the bug injected causing this.Īnyway, I can't say this is not my code's fault. Lots of games may also use no advanced effect. For apps like Adobe Dimension, their interactive renderer turn on NO advanced effect (such as soft shadow), and their final renderer is not real time. First, the problem is more obvious when the rendering code turns on more advanced effect. I'm wondering why the community is pretty quiet about this.
Without any change apart from upgrading to 10.13.2, the frame rate drops to 4 FPS. The code is not super optimized but it achieves 20 FPS under 10.13.1. However, I do see a big problem with my own code. By "major" I mean softwares created by Adobe, Microsoft, Apple, etc. I don't have issue with any major software I'm using.
0 kommentar(er)
