Hi everyone. I decided to use GPUPerf for our project so I'm new to it. Some modules (optional plugins) of our project are made as lua-modules and are loaded through "require" lua keyword. Everything is working fine but I encounted problem when running app under GPUPerfServer-x64. Here is log:
Message: Server : GPU PerfStudio Server - Version V2.2.791.0
Message: Server : Using Logfile: D:/code/work/gpuperf/Server-x64/pslog.txt
Message: Server : Succesfully enabled DX Peformance Counters in Driver
Message: Server : Available Wrappers:
Message: Server : DX10Server-x64.dll V2.2.791.0 DX10
Message: Server : DX11Server-x64.dll V2.2.791.0 DX11
Message: Server : DX9Server-x64.dll V2.2.791.0 DX9
Message: Server : GLServer-x64.dll V2.2.791.0 OpenGL
Message: Server : Starting web server on port 80
Message: Server : About to launch: D:\code\work\edge\bin\x86_64\msvc_9.0\debug\LandViewer.exe
Message: Server : Params: -lsa3 "d:\code\work\art\terrain.cfg.lua"
Message: Server : Working Directory: D:\code\work\edge\data\
F3 - toggle wireframe
F4 - switch shading mode
F5 - reload all shaders
20100910 235718 ERROR Lua::Config: Can't load scripts/options/options.conf: error loading module 'corrector' from file '../bin/x86_64/msvc_9.0/debug/./corrector.dll':
The specified module could not be found.
Error loading config file scripts/options/options.conf: (null)
So under GPUPerfServer-x64 lua modules fail to load. Any ideas why it could happen? I'm running Win7 x64 Professional, HD 5750, Core 2 Quad Q9300
Are you able to use the 32-bit version of GPU PerfStudio with the 32-bit version of your application? Just trying to clarify if this issue is specific to the 64-bit.
Also, can you confirm whether the modules cannot be found, or if they cannot be loaded? You may find that removing the final "\" from the working directory will resolve the issue, or try using the full path to the dll. If you can confirm that the dll is found, but cannot be loaded, then there may be deeper issues that we have to investigate.
Same problem for 32-bit version. And I'm sure that dll exists (there is a separate error message when dll is not found). I googled a little bit for "The specified module could not be found." and it seems to be some windows text error message for problems when dll could not be loaded. Maybe something with dll's dependencies? What else info I can provide to solve this problem?
To clarify - you mentioned in the first post that "Everything is working fine but I encounted problem when running app under GPUPerfServer-x64." - do you mean the application is running fine, but the error message is being printed in the PerfStudio console window?
If your application is running as expected when launched with PerfStudio, then it is likely that this error happens all the time, but you haven't seen the message before. GPU PerfStudio redirects all standard output to the console, so if your application doesn't have any other way to report it, you may not have seen the messages before.
If your application does not run due to this error, can you please try completely removing the 32-bit and 64-bit builds of your application, then rebuild just one of the versions for testing with PerfStudio? We suspect that there may be a clash in the bit-ness of the dlls being loaded.
If doing the clean and rebuild does not fix the issue, would you be able to send us a copy of your application so that we can investigate the issue? You can send it to me at <firstname>.<lastname>@amd.com (my full name is below).
Finally I had found the reason. When you are loading dll through LoadLibrary WinAPI call and provide relative path it fails. Absolute path is working fine.
I had written a simple app based on tutorial from DirectX SDK to illustrate this problem. It should be started in ./data directory to work correctly. I used windows shortcut for this. And when I started GPUPerf with this shortcut as an argument I get following output:
I was able to reproduce the issue that you are experiencing. I confirmed that the GPUPerfStudio see's the same working directory when it is loading the DLL as when you print it out, so I don't immediately see what he problem is on our side.
I did find a simple solution that appears to work, although I'm not sure why. Immediately after you call GetCurrentDirectory(sizeof(cwd), cwd ); use the returned path and call SetCurrentDirectoryW(cwd);
As I mentioned, I'm not sure why this works, but it seems to allow both the relative and absolute path to work, along with loading the fx file.
Please confirm that this works in your actual application.
No, this is not working for me. Still the same
As I mentioned, I wasn't sure why it made a difference for me. Perhaps I still had some other test code in the there. I'll investigate more.
As an alternative, can you make a relative path to the media that needs to be loaded and just load the DLLs from your local bin directory? One of the changes I made which seemd to work was to put an additional "../" in the relative path, and then I could just double click the exe (without needing to specify a working directory) and the DLLs would load without a problem, however with just those changes the fx file was not found. If you look in the DXUT code, you can find the set of paths that it check's for media, you may just need to move your folder so that it corresponds with one of these paths (or I think you can register an additional path).
I think what is getting confused here is that things can be loaded using either the local directory, or the current working directory as a base for relative paths. I just looked at the MSDN documentation for LoadLibrary, here is some interesting information:
"If a relative path is specified, the entire relative path is appended to every token in the DLL search path list. To load a module from a relative path without searching any other path, use GetFullPathName to get a nonrelative path and call LoadLibrary with the nonrelative path. For more information on the DLL search order, see Dynamic-Link Library Search Order.
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL."
I was able to dig into the issue and have found a solution. The fix did not get in before the GPUPerfStudio 2.3 version was released, but will be included in the next version.