For Intel+NVIDIA dual-GPU "Optimus" setups, an application can export NvOptimusEnablement as explained in OptimusRenderingPolicies.pdf. This option allows an application to ensure the use of the high-speed discrete GPU without needing profile updates or user interaction, which is usually desired for certain classes of applictions.
Is there an equivalent trick for systems with AMD GPUs (Windows-only is fine), and if so, what is it? I have not been able to find any concrete information via Googling; only a lot of people asking the same question on various forums with no answers, or SO articles on the NVIDIA trick with a "maybe AMD has something similar, I don't know" comment.
According to https://community.amd.com/thread/169965
extern "C"
{
__declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
}
This will select the high performance GPU as long as no profile exists that assigns the application to another GPU.
Please make sure to use a 13.35 or newer driver. Older drivers do not support this.
This code will be ignored when you compile on non-windows machines:
#ifdef _WIN32
#include <windows.h>
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
extern "C" __declspec(dllexport) DWORD AmdPowerXpressRequestHighPerformance = 0x00000001;
#endif
Related
I've run into a somewhat unexpected behavior in Xcode/Objective-C. I know it's probably not advised, but if I want to make my own struct in_addr in a .m file, it seems I can't. This implies something rather strange about namespaces and symbol pollution in Objective-C. The same seems to apply for many other networking types and perhaps other POSIX-y things as well.
I came up with a very basic example that demonstrates this behavior. Note that this snippet is the entire contents of the .m file.
#define _SYS_SOCKET_H_
#define _NETINET_IN_H_
#include <stdint.h>
struct in_addr {
uint32_t foo;
};
which yields the build error Redefinition of 'in_addr'.
This implies some fairly strange things about Objective-C. For starters, I wouldn't expect <stdint.h> to bring in any networking types. But even allowing that it might, defining _NETINET_IN_H_ first should prevent the definition of struct in_addr. And yet even still, this code refuses to build.
Is it possible to somehow forgo this forced symbol visibility? Is there a list of symbols that are included, no matter what? Is there a good reason for this behavior?
edit: Stranger still, if i remove <stdint.h> and change the uint32_t to int, this actually does compile.
If you go into the Report navigator and read the full error emitted by the clang tool, you'll see a big hint:
In module 'Darwin' imported from /Users/csrstka/Desktop/asdfasdf/asdfasdf/main.m:1:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/netinet/in.h:302:12: note: field has name 's_addr' here
in_addr_t s_addr;
As you can see, the existing in_addr is coming from the Darwin module, which is implicitly imported due to your #include of stdint.h, which is part of the Darwin module. You can see this if you go to Product > Perform Action > Preprocess in Xcode—instead of copying in all the headers you've imported, there's just one line about importing Darwin.C.stdint.
Basically, there are a few purposes for modules; they improve compile times by cutting down on redundant compilation tasks, and they prevent people from messing with library headers via #defines like you're trying to do. ;-) For more on Objective-C modules, how they work, and the rationale behind them, see this link:
https://clang.llvm.org/docs/Modules.html#introduction
Of particular interest to your question are the following excerpts:
The primary user-level feature of modules is the import operation, which provides access to the API of software libraries. However, today’s programs make extensive use of #include, and it is unrealistic to assume that all of this code will change overnight. Instead, modules automatically translate #include directives into the corresponding module import. For example, the include directive
#include <stdio.h>
will be automatically mapped to an import of the module std.io. Even with specific import syntax in the language, this particular feature is important for both adoption and backward compatibility: automatic translation of #include to import allows an application to get the benefits of modules (for all modules-enabled libraries) without any changes to the application itself. Thus, users can easily use modules with one compiler while falling back to the preprocessor-inclusion mechanism with other compilers.
And later on:
If any submodule of a module is imported into any part of a program, the entire top-level module is considered to be part of the program. As a consequence of this, Clang may diagnose conflicts between an entity declared in an unimported submodule and an entity declared in the current translation unit, and Clang may inline or devirtualize based on knowledge from unimported submodules.
Or, if you'd prefer to turn them off and get more traditional C-like behavior, you can simply set Enable Modules (C and Objective-C) to No in Xcode's Build Settings, or compile without the -fmodules flag if you're using the command line.
I'm confused as to why __declspec(dllexport) or equivalent needs to go in the header file. Say I'm writing a library. Surely the users don't need to know or worry about whether symbols are exported or not, all they care about is that the function declarations are there and will presumably be linked against the shared or static library itself. So why can't all this boilerplate go into source files, for use only at build time?
The only use case I think of is a situation where someone is writing a wrapper of my library and needs to export all of my functions as well, but in general that is not the case - is it really worth the hassle of having all the export stuff inside public headers? Is there something I'm missing, is this a technical limitation of linkers..?
I'm asking because I like my headers and build system to be clean, and as dllexport stuff is generally set/not set based on whether we are building the library as a shared or static library, I find it strange that it should end up inside public headers since it's (to my understanding) fundamentally a build time concept. So can someone please enlighten me on what I am missing?
I'm not really sure I can provide a great answer. My impression is that it serves several purposes:
It speeds the loading of DLLs, particularly when lots of DLLs are used (because there are fewer exported symbols to search through)
It reduces the possibility of symbols colliding at run-time (because there are fewer exported symbols)
It allows the linker to complain about undefined symbols (instead of just assuming it might find them at run time.
I'm sure there are other reasons. I generally wrap my APIs in something like this:
#if defined(MY_LIB_CREATION)
#define MY_LIB_API __declspec(dllexport)
#else
#define MY_LIB_API __declspec(dllimport)
#endif
And then all of my API functions & classes are defined as MY_LIB_API:
class MY_LIB_API Foo {};
MY_LIB_API void bar();
And then in the project file defined MY_LIB_CREATION for the project implementing your library.
I've written a wrapper for a C++ dll in C++/CLI. Inside the wrapper, I made some typedefs. Is there a way to export these names as .NET classes?
Background: the typedef'd classes are some templates. For these templates to work, you need a managed and a native parameter (this is part of the translation). This is impossible for the client of the wrapper to program / know. That's why he needs the different aliases for the used versions of the template.
I exchanged the typedefs with some new class definitions that derive from the template. This should work.
I do not have too much information but typedefing should work only on Clr types. Generic classes, maybe but template classes can not ne typedefed. Also among native types, only the ones that are common (the word "common" may not be correct here.) to .net i.e. double, int, char, Char* (not char*) etc.
This code works and introduces a "new" type to clr.
namespace example
{
#ifdef _WIN64
typedef sizeT UInt64
#else
typedef sizeT UInt32
#endif
}
Now you have size_t of .Net, whose size depends on platform.
I recently started writing a C++/CLI wrapper for a native c++ library. I'm now getting this compile warning
"warning LNK4249: directive '/CLRTHREADATTRIBUTE:STA' conflicts with command line; ignored"
My c++/cli wrapper is set up for MTA in the linker's command line arguments, but I have no idea what file or project is trying to give the STA directive.
I did enough reading to get worried about .NET forcing libraries to become multi-threaded. I've read that this mostly affects my application's use of COM, but I am not really sure if or where my DLL uses COM. I use the interop services to marshal string data and am using 'msclr\auto_gcroot.h' to point to managed classes from unmanaged ones. In the native c++ library that is being wrapped, I include the following headers:
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#include <afxmt.h>
#include "Winsock2.h."
#include <time.h>
Does anybody have any advice that could help me avoid painful experiences in the future, or should I just not worry about it?
So far so good. I haven't seen any real problems with this; I think it is just because MFC is a single threaded library, so it wants to compile that way. So, for my case, I think as long as I treat all MFC objects and such as not thread-safe I'll be okay.
I need to access the MSP and PSP registers (the main and process stack registers) of the Cortex-M3 processor.
I'm writing in C/C++.
The µVision and associated compiler doesn't let you do inline assembly for this Thumb-2 only core (and I'm not sure that'd be such a good idea anyway).
I need to do this so that I can extract the immediate value of an svc instruction regardless of whether it was executed while in thread or handler mode.
Thanks,
I don't have access to a Keil compiler at the moment to verify this, but according to the docs you should be able to use the compiler's "named register variable" feature:
register uint32_t msp __asm("msp");
register uint32_t psp __asm("psp");
http://www.keil.com/support/man/docs/armccref/armccref_cjahjdbg.htm
http://www.keil.com/support/man/docs/armcc/armcc_CHDHCIEE.htm
For something like this I usually use a tiny assembly call-out to do it.
You can use the special register access instruction (MRS / MSR) to access either SP. I think with uVision, the MSP is SP_main, and the PSP is SP_process.
My ARM assembly is a little rusty, but I think it'd be something like:
MRS R0, SP_process // R0 holds retval
BX LR // return
From your question, it seems that you already understand the distinction between the MSP & PSP, and know how to determine which one to read (via the LR).