I tried to implement dynamic shader linkage from what I saw in the DirectX11 SDK,but they are using the Effects11 framework and shader reflections.I'm trying to get a cleaner more low-level implementation.For instance - for constants buffer instead of using reflections,I just set a struct.I couldn't find anywhere a clean tutorial on how to implement the dynamic shader linkage in DirectX,everyone uses huge pieces of Effects11 code.
It is possible to use dynamic shader linkage in directx11 without using shader reflection, however it means that you need to know the names of the classes and interfaces at compile time.
I have achieved this myself by using a combination of shader preprocessor macros that i use to declare all of my shader classes, and a common header file that I include in both my shader and my .cpp file.
I've been searching for this problem too.
Check this out:
https://msdn.microsoft.com/en-us/library/windows/desktop/ff471421(v=vs.85).aspx
Maybe this would help. :)
Related
In XCode 9's Metal template, there is one part where it's setting attributes and layouts on a MTLVertexDescriptor.
let mtlVertexDescriptor = MTLVertexDescriptor()
mtlVertexDescriptor.attributes[VertexAttribute.position.rawValue].format = ...
mtlVertexDescriptor.attributes[VertexAttribute.texcoord.rawValue].format = ...
I tried hard, but cannot figure out where the magic keywords position, texcoord and later meshPositions, meshGenerics are coming from.
I guess it's not from the source code, but I didn't find any documentation where these would be specified. For VertexAttribute all I got was the reference page, without any mention about position and texcoord.
XCode points me to ShaderTypes.h, namely this section:
typedef NS_ENUM(NSInteger, VertexAttribute) {
VertexAttributePosition = 0,
VertexAttributeTexcoord = 1,
};
I feel this is the key for understanding this, but I have multiple problems:
As a developer who started with Swift, in a Swift project template this Obj-C part is a bit confusing. Can you explain me clearly what it does exactly?
How does VertexAttributePosition in an NS_ENUM add a magical property .position and VertexAttributeTexcoord -> .texcoord?
Why are none of these documented (Google finds mostly OpenGL related pages), nor can XCode find any help / jump to definition on them?
The clue to understanding what's going on here can be found on this line in the ShaderTypes.h file:
// Header containing types and enum constants shared between Metal shaders and Swift/ObjC source
The express intent of ShaderTypes.h is to declare types that can be used by both the shaders (which are written in Metal Shading Language, a dialect of C++) and the renderer class (which is written in Objective-C or Swift, depending on which you select when opening the template). The way this is achieved is by constructing a header file that can be included in both. The twist comes when using Swift, because Swift lacks a notion of header files except for one special case: bridging headers.
When incorporating C or Objective-C code into a Swift app, you provide a bridging header that imports or declares types and methods you want to use in Swift. In Xcode, you configure this with the "Objective-C Bridging Header" setting in the "Swift Compiler - General" portion of your project's Build Settings. It's kinda buried, but if you go there, you'll see that it's populated with the "ShaderTypes.h" header from the template. That's how your Swift code knows about the VertexAttribute enum type.
In Objective-C, to get the attribute index, you'd use one of the defined enum values directly: VertexAttributePosition, which is functionally equivalent to a literal 0. When that gets imported into Swift, the name of the enum (VertexAttribute) gets stripped off the front, and the values get transformed into lower camel case, per Swift style, e.g. position. You can read more about the particulars here.
The upshot of this is that even though there is no enum value named "position" anywhere in the code, that name gets synthesized for you when you use the Objective-C enumeration from Swift. The rawValue property is the integer value associated with that particular enum value, which can then be used as an index on an attribute or vertex descriptor (again, in this case, it's equal to 0).
None of these are documented because they're defined exclusively in this template. They're not part of the Metal API or really any API; they're just names that provide a convenient label for the underlying constants, in order to make the shader and app code consistent with one another.
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
My eventual goal is the following:
Inside certain function say foo, I want to override malloc function to my custom handler my_malloc. But outside foo, any malloc should still call to malloc as in glibc.
Note: this is different from LD_PRELOAD which would override malloc during the entire program execution.
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
In theory this is possible, but in practice it's too hard to do.
Inside certain function say foo, I want to override malloc function to my custom handler my_malloc. But outside foo, any malloc should still call to malloc as in glibc.
Modifying symbol table (even if it were possible) would not get you to your desired goal.
All calls from anywhere inside your ELF binary (let's assume foo is in the main executable), resolve to the same PLT import slot malloc#plt. That slot is resolved to glibc malloc on the first call (from anywhere in your program, assuming you are not using LD_BIND_NOW=1 or similar). After that slot has been resolved, any further modification to the symbol table will have no effect.
You didn't say how much control over foo you have.
If you can recompile it, the problem becomes trivial:
#define malloc my_malloc
int foo() {
// same code as before
}
#undef malloc
If you are handed a precompiled foo.o, you are linking it with my_malloc.o, and you want to redirect all calls from inside foo.o from malloc to my_malloc, that's actually quite simple to do at the object level (i.e. before final link).
All you have to do is go through foo.o relocation records, and change the ones that say "put address of external malloc here" to "put address of external my_malloc here".
If foo.o contains additional functions besides foo, it's quite simple to limit the relocation rewrite to just the relocations inside foo.
Is it possible to dynamically modify symbol table at runtime in C (in elf format on Linux)?
Yes, it is not easy, but the functionality can be packaged into a library, so at the end of the day, it can be made practical.
Typemock Isolator++
(https://www.typemock.com/isolatorpp-product-page/isolate-pp/)
This is free-to-use, but closed source solution. The usage example from documentation should be instructive
TEST_F(IsolatorPPTests, IsExpired_YearIs2018_ReturnTrue) {
Product product;
// Prepare a future time construct
tm* fakeTime = new tm();
fakeTime->tm_year = 2018;
// Fake the localtime method
FAKE_GLOBAL(localtime);
// Replace the returned value when the method is called
// with the fake value.
WHEN_CALLED(localtime(_)).Return(fakeTime);
ASSERT_TRUE(product.IsExpired());
}
Other libraries of this kind
Mimick, from Q: Function mocking in C?
cpp-stub, from Q: Creating stub functionality in C++
Elfspy, for C++, but sometimes it's OK to test C code from C++ unittests, from Q: C++ mock framework capable of mocking non-virtual methods and C functions
HippoMocks, from Q: Mocking C functions in MSVC (Visual Studio)
the subprojects in https://github.com/coolxv/cpp-stub/tree/master/other
... there is still more, feel free to append ...
Alternate approaches
ld's --wrap option and linker scripts, https://gitlab.com/hedayat/powerfake
various approaches described in answers for Q: Advice on Mocking System Calls
and in answers to Q: How to mock library calls?
Rewrite code to make it testable
This is easier in other languages than C, but still doable even in C. Structure code into small functions without side-effects that can be unit-tested without resorting to trickery, and so on. I like this blog Modularity. Details. Pick One. about the tradeoffs this brings. Personally, I guturally dislike the "sea of small functions and tons of dependency injection" style of code, but I realize that that's the easiest to work with, all things considered.
Excursion to other languages
What you are asking for is trivial to do in Python, with the unittest.mock.patch, or possibly by just assigning the mock into the original function directly, and undoing that at the end of the test.
In Java, there is Mockito/PowerMock, which can be used to replace static methods for the duration of a test. Static methods in Java approximately correspond to regular functions in C.
In Go, there is Mockey, which works similarly to what needs to be done in C. It has similar limitations in that inlining can break this kind of runtime mocking. I am not sure if in C you can hit the issue that very short methods are unmockable because there is not enough space to inject the redirection code; I think more likely not, if all calls go through the Procedure Linkage Table.
I am working on a project in iOS using Xcode. I want to include a library written in C. But I don't know how to use C library in Objective-C.
Here is the link of Library: https://github.com/bcl/aisparser
Can someone help me?
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
extern "C" int function_name(char *blob,int number, double foo) {...}
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).
So I'm using a book called iOS Games by tutorials from Ray Wenderlich and trying to utilize some of the objective-C code found there to make the accelerometer control of a character in my game work. Instead of Objective-C though, I want to use Swift. I ran into an issue when trying to create a var of type GLKVector3, which represents a 3D vector. When I type in:
var raw:GLKVector3 = GLKVector3Make(irrelevant stuff)
I get the following error:
use of module GLKVector3 as type.
I have an import at the top of my swift file for GLKit:
import GLKit
Any ideas how I can get the functionality from the GLKMath files to use in my program?
Swift has added union support in version 1.2. The fields in imported unions are read-only, even if declared with var, but can be passed to and from C functions as necessary.
The release notes for Swift 1.2 imply that the fields may not be accessible at all, but they are still readable for at least the GLKit types:
Swift can now partially import C aggregates containing unions, bitfields, SIMD vector types, and other C language features that are not natively supported in Swift. The unsupported fields will not be accessible from Swift, but C and Objective-C APIs that have arguments and return values of these types can be used in Swift. This includes the Foundation NSDecimal type and the GLKit GLKVector and GLKMatrix types, among others.
With the release of beta version of Xcode 6.3/Swift 1.2 yesterday (Feb 8, 2015) it is now possible to use GLKit from Swift.
Here check my repo: https://github.com/noxytrux/SwiftGeom i actually build a whole lib for that, so you are no more forced to use GLKit or wait for Apple to implement it in swift.
I'm using the DirectX 9 effect framework.
I'd like to create a struct which contains a sampler like so:
struct Test
{
texture tex;
sampler texSamp = sampler_state
{
Texture = <tex>;
};
};
However the shader compiler fails with:
internal error: this-relative Test::tex 'tex' found outsideof function scope
It seems like the idea of the this-relative reference is kind of working, but I need to somehow declare it inside a function, but I'm not sure how that could work, since declaring samplers inside functions doesn't work? Anyone have any ideas?
I though that in HLSL everything is a value type.
You know what implication this would have?
Each time you assigned this struct to some other variable you would do a copy of the sampler.
There are limitation in shading language on many things like number of samplings, not only number of samplers.
It seems that non-numeric types are not supported inside HLSL structs, which is a crying shame for my application.