[ERROR] NVAPI error (C:\code\rtsdk\adobe-ae\cc13.1\src\Util\DriverInfo.cpp:78):
[LOG 4] CPU fallback enabled
Getting this error while executing following command (on After effect enabled enviornment)
C:\Program Files\Adobe\Adobe After Effects CC 2015.3\Support Files>aerender -pro
ject D:\proj\01.aep
Please revert asap
Disable Ray-traced 3D in target comps
I mean, it was rendering 40 seconds per frame, got 4 hours for a minute.
After spending quite some time, turns out it was this that was triggering the "CPU fallback enabled"
And, for some reason, it only affected comps that had cameras in.
Related
Status: the problem lowered, but compared to other users reports it persists.
I have moved to UE4.27.0 and the startup time lowered from 11 (v4.26.2) to 6 minutes! (the RAM usage lowered too!) But doesnt compare to the speed other ppl report "almost instantly"...
It is not compiling anything, not even shaders, it is like the 6th time I run it for one project.
Should I try to disable plugins? but Im new with UE and dont want to difficult my usage. Tho, for ex., I have nothing VR related to test so it could really be initially disabled.
HD READ SPEED? NO
I have tested moving UE4Editor whole engine path (100GB) to a 3xSSD(Stripes), but the UE4Editor startup time remained the same. My HD were it is too, is fast but not so fast as the 3xSSD.
CPU USAGE? MAY BE if it could use 4 cores could solve it?
UE4Editor startup uses A SINGLE CORE ONLY, i can confirm with htop and system monitor, it is possible to see only a single core being used 100% and it changes between the 4 cores, so only one is used at 100% per time.
I tested this command line parameter -USEALLAVAILABLECORES after the project URL for UE4Editor, but nothing changed. I read that option is ignored in some machines, so may be if I patch it's usage it could work on mine?
GPU? no?
a report about an integrated graphics card (weak one) says it doesnt interfere with the startup time.
LOG for UE4Editor v4.27.0 with the new biggest intervals ("..." means ommited log lines to make it easier to read; "!(interval in seconds)" is just to easy reading it (no ommitted lines here)):
[2021.09.15-23.38.20:677][ 0]LogHAL: Linux SourceCodeAccessSettings: NullSourceCodeAccessor
!22s
[2021.09.15-23.38.42:780][ 0]LogTcpMessaging: Initializing TcpMessaging bridge
[2021.09.15-23.38.42:782][ 0]LogUdpMessaging: Initializing bridge on interface 0.0.0.0:0 to multicast group 230.0.0.1:6666.
!16s
[2021.09.15-23.38.58:158][ 0]LogPython: Using Python 3.7.7
...
[2021.09.15-23.39.01:817][ 0]LogImageWrapper: Warning: PNG Warning: Duplicate iCCP chunk
!75s
[2021.09.15-23.40.16:951][ 0]SourceControl: Source control is disabled
...
[2021.09.15-23.40.26:867][ 0]LogAndroidPermission: UAndroidPermissionCallbackProxy::GetInstance
!16s
[2021.09.15-23.40.42:325][ 0]LogAudioCaptureCore: Display: No Audio Capture implementations found. Audio input will be silent.
...
[2021.09.15-23.41.08:207][ 0]LogInit: Transaction tracking system initialized
!9s
[2021.09.15-23.41.17:513][ 0]BlueprintLog: New page: Editor Load
!23s
[2021.09.15-23.41.40:396][ 0]LocalizationService: Localization service is disabled
...
[2021.09.15-23.41.45:457][ 0]MemoryProfiler: OnSessionChanged
!13s
[2021.09.15-23.41.58:497][ 0]LogCook: Display: CookSettings for Memory: MemoryMaxUsedVirtual 0MiB, MemoryMaxUsedPhysical 16384MiB, MemoryMinFreeVirtual 0MiB, MemoryMinFreePhysical 1024MiB
SPECS:
I'm using ubuntu 20.04.
My CPU is 4 cores 3.6GHz.
GeForce GT 710 1GB.
Related question but for older UE4: https://answers.unrealengine.com/questions/987852/view.html
Unreal Engine needs a high-end pc with a lot of RAM, fast SSD's, a good CPU and a medium graphic card. First of all there are always some shaders that needs to be compiled from the engine, and a lot of assets to be loaded in the startup time. As I can see you're on Linux you are probably using a self-compiled Unreal Engine version.... not the best thing to do for a newbie, because this may cause several problems on load time, startup, compiling and a lot of other stuff. If it's the first times you're using Unreal, try using it on Windows, it's all easier.
I'm running Matlab R2015b on my mac with OSX 10.11 El Captain. When starting Matlab, changing the directory in file explorer or when saving a file / running an unsaved file. A yellow processing box appears in the bottom left and Matlab consumes more and more resources. When the process is not canceled Matlab uses more than 400% CPU (low memory usage) and does not react for about 10 minutes or even more. Most times there is no feedback what happend - Today I got following error after start up and the "processing" stuff:
Exception in thread "Explorer NavigationContext request queue" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.String.substring(String.java:1913)
at java.util.StringTokenizer.nextToken(StringTokenizer.java:352)
at com.mathworks.matlab.api.explorer.FileLocation.getTokens(FileLocation.java:268)
at com.mathworks.matlab.api.explorer.FileLocation.getParent(FileLocation.java:123)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.resolveLocation(VirtualFileSystem.java:285)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.getTarget(VirtualFileSystem.java:276)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.resolveLocation(VirtualFileSystem.java:285)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.getTarget(VirtualFileSystem.java:276)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.resolveLocation(VirtualFileSystem.java:285)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.getTarget(VirtualFileSystem.java:276)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.resolveLocation(VirtualFileSystem.java:285)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.getTarget(VirtualFileSystem.java:276)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.isMountPoint(VirtualFileSystem.java:239)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.toExternalEntry(VirtualFileSystem.java:324)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileSystem.toExternalEntry(VirtualFileSystem.java:319)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileList$MountingReceiver.receive(VirtualFileList.java:101)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileList$MountingReceiver.receive(VirtualFileList.java:90)
at com.mathworks.util.AsyncReceiverUtils$3.receive(AsyncReceiverUtils.java:77)
at com.mathworks.mlwidgets.explorer.model.realfs.StatToEntryAdapter.receive(StatToEntryAdapter.java:55)
at com.mathworks.mlwidgets.explorer.model.realfs.StatToEntryAdapter.receive(StatToEntryAdapter.java:16)
at com.mathworks.util.NativeJava.listFiles(Native Method)
at com.mathworks.mlwidgets.explorer.model.realfs.RealFileList.readFilesAndFolders(RealFileList.java:50)
at com.mathworks.mlwidgets.explorer.model.overlayfs.OverlayFileList.readFilesAndFolders(OverlayFileList.java:42)
at com.mathworks.mlwidgets.explorer.model.vfs.VirtualFileList.readFilesAndFolders(VirtualFileList.java:52)
at com.mathworks.mlwidgets.explorer.model.table.UiFileList.readAndUpdateCache(UiFileList.java:358)
at com.mathworks.mlwidgets.explorer.model.table.UiFileList.access$500(UiFileList.java:43)
at com.mathworks.mlwidgets.explorer.model.table.UiFileList$6.run(UiFileList.java:323)
at com.mathworks.util.RequestQueue.execute(RequestQueue.java:129)
at com.mathworks.util.RequestQueue.access$000(RequestQueue.java:25)
at com.mathworks.util.RequestQueue$2.run(RequestQueue.java:79)
at java.lang.Thread.run(Thread.java:745)
When running an INTEGRITY 178 ARINC/APEX image on a PPC SBC, using uboot console we load the program with tftpboot and initiate execution with bootelf. (We actually enter an extra RETURN after the bootelf command so that the INTEGRITY copyright banner displays on the uboot console when the target begins execution.)
Question: Why is there about a 12 second delay between the bootelf command and the apparent beginning of execution of the application portion of the image? And if there is a way to reduce this delay?
Potential sources uboot, POST, GHNet network initialization, other sources...?
Thanks,
mlk
For us, the filesystem initialization is the longest delay at boot.
I am trying to call two kernels as shown below
for (t=0; t<=time_total; t++)
{
//kernel calls
kernel1<<<noOfBlocks,noOfThreadsPerBlock>>>(** SOME PARAMETERS **);
checkCudaError(cudaThreadSynchronize());
kernel2<<<noOfBlocks,noOfThreadsPerBlock>>>(** SOME PARAMETERS **);
checkCudaError(cudaThreadSynchronize());
}
And the structure of the second kernel is
var[index+0]=**SOME CALCULATION**
var[index+1]=**SOME CALCULATION**
var[index+2]=**SOME CALCULATION**
Now when I execute this code, checkCudaError does not report anything and the code is executed giving some output but visual studio gives the following exception
First-chance exception at 0x7640c41f in **.exe: Microsoft C++ exception: cudaError_enum at memory location 0x0039f9c4..
First-chance exception at 0x7640c41f in **.exe: Microsoft C++ exception: cudaError_enum at memory location 0x0039f9c4..
And when I check on Nsight it says kernel 2 is having the following error
CUDA_ERROR_LAUNCH_OUT_OF_RESOURCES
Now the problem is that var array in kernel 2 is giving some of the rows correct some are copies of other row values and some are garbage.
Also when I do this
var[index+0]=3
var[index+1]=3
var[index+2]=3
All the values of var are set to 3
A few side notes:
cudaThreadSynchronize() is deprecated in favor of cudaDeviceSynchronize().
The fact that nsight is reporting an error on the 2nd kernel launch, but your error checking code is not, leads me to believe your error checking code is broken.
Now, regarding your issue, out of resources is frequently due to a code requesting too many registers (too many registers per thread times the number of threads per threadblock requested.) Try re-compiling your code specifying -Xptxas -v to get verbose output, and then recompiling again with -maxrregcount 20 (or something like that) to try to work around this for test purposes.
If this "fixes" your problem, you may then want to consider the following:
See if there is a way you can re-order or restructure your code to reduce the register pressure
If not, then adjust your maxrregcount value upwards to approximately the highest value that will allow your code to compile and run according to the launch configurations (number of threads per block) that you care about. You may also want to benchmark your code at different levels of this setting, as it can affect occupancy. Usually if you have it set to the highest value that will compile and run, then you are limiting yourself to one threadblock per SM at execution time. This may be OK, or there may be a lower setting that is better, allowing two threadblocks per SM residency, and possibly higher performance. Only benchmarking your code will tell.
I have a Core Data iOS app that uses private queue concurrency in a background process. I'm getting a deadlock that makes the UI freeze up from time to time (fairly regularly, to be honest) - but all the info I get from the debugger (LLDB) is that it is stuck on pthread_mutex_lock. The stack trace is no longer than that, which makes debugging near on impossible:
thread #1: tid = 0x2503, 0x3b5060fc libsystem_kernel.dylib`__psynch_mutexwait + 24, stop reason = signal SIGSTOP
frame #0: 0x3b5060fc libsystem_kernel.dylib`__psynch_mutexwait + 24
frame #1: 0x3b44f128 libsystem_c.dylib`pthread_mutex_lock + 392
The XCode process pane is similarly only showing those two entries on the stack.
I'm quite new to this multithreading stuff so am at a total loss where to begin with fixing the issue. Any suggestions for how to go about debugging this?
Your stack is obviously longer than two frames, you can't start a thread with pthread_mutex_lock. So the truncation of the stack frame is pretty clearly just a bug in the lldb unwinder. If you have an ADC account, please file a bug about this at bugreporter.apple.com. Also if you're not using the most recent version of lldb you can get your hands on you might want to try that, maybe it fixed whatever bug you are seeing. You can install multiple Xcode's side by side so you don't have to remove the one you are currently using to try a newer one.
You might also try another tool that will give you a backtrace (e.g. the Instruments time profiler) when your app gets into this state, since it uses a different unwinder. That will at least let you see what the full backtrace is.