   D3D11: Create Input-Layout without vertex-shader blob
  HiIs there a way to create an input-layout without having the vertex-shader's blob around? At run-time i can query the current vertex-shader, but it seems there is no way to use that to create an input-layout.The simple problem is, that i can use the same shader with many different meshes that might use different layouts for their vertex-buffers. However, i do not know these layouts beforehand and i think keeping the shader's binary blobs laying around is pretty wasteful (i mean, the signature is only a fraction of the shader). So is there a way to only store the signature? Or to get the signature from the currently bound shader?Thanks for any input.Jan.   
  I highly doubt it's going to cause you any memory / performance issue keeping the blobs around - After all how many shader instances are you going to create anyhow. What I do is to keep the blobs and then store the inputlayouts in the shader class for later use, then when requested are able to look it up for direct use or create it if new layout.Pre-mature optimization is the root of all evils.   ;  beyond that you only need one copy of a shader and one copy of its input layout anyway.   ;  Well, one of the reasons is, that i want to port a library to D3D (from OpenGL) which only creates a vertex-buffer and renders the data. In OpenGL you can query the currently bound shader and then bind the vertex buffers to the slots with the proper names. In D3D i can query the active shader, but it seems there is no way i can create the input-layout, as long as the user of the library not also passes along the current shaders blob.The only way i can think of to make this more automatic, is to create a lookup-table which maps from shader-pointer to blob-pointer. Then i can query at run-time the current vertex-shader, use that to look up the blob-pointer (or shader-class pointer, if i have such an abstraction) and then query or create the proper input-layout.What bugs me about that is, that it couples the vertex-buffers and shaders quite tightly. There is no easy way to integrate the vertex-buffer library into another project that handles shaders differently.Jan.   ;  This annoys me as well.I basically wrote a wrapper for input layout. On creating a new input layout, my wrapper will generate a "dummy" shader in code where the input sig for the vertex shader matches that of the input layout. The actual shader function does nothing, since I only care about that the signature matches the input layout. I create a blob from this temporary shader, and use that to make DX 11 happy when creating the input layout. I destroy the blob after creating the layout since its useless.Luckily you can then use the input layout anywhere, you don't have to use the same vertex shader you used to create the layout.Its kindof hacky but eh :/   ;Quote:Original post by Jan KWhat bugs me about that is, that it couples the vertex-buffers and shaders quite tightly. There is no easy way to integrate the vertex-buffer library into another project that handles shaders differently.Well yeah, but that's kind of the point. See in D3D9 where you just had vertex declarations and vertex shaders, every time you bound one of those to the pipeline the runtime had to check the declaration and the input signature of the shader to match up and validate your vertex attributes. It's part of what made switching shaders expensive. D3D10/11 now let do this ahead of time by creating input layouts, which lets you pay the cost once at initialization and not at runtime.;Quote:Original post by coderchrisLuckily you can then use the input layout anywhere, you don't have to use the same vertex shader you used to create the layout.The docs say that you can only use the same input layout for shaders that have the exact same input signature. I don't know what happens when you don't, but it certainly doesn't sound like it would be guaranteed to work for all shaders/drivers/layouts.;Quote:The docs say that you can only use the same input layout for shaders that have the exact same input signature. I don't know what happens when you don't, but it certainly doesn't sound like it would be guaranteed to work for all shaders/drivers/layouts.Oops... I totally missed that. Nvidia drivers appear not to care about it, but that is a good point... Perhaps in the future they will and I have no idea about ATI drivers.So, if you can only use one input layout per vertex shader, why do they even have a vertex layout entity at all? why not get rid of it all together and say that "whatever vertex shader is bound, thats the format that your vertex data should be in"   ;Quote:Original post by coderchrisSo, if you can only use one input layout per vertex shader, why do they even have a vertex layout entity at all?Not per vertex shader, per input signature. So what you're doing seems completely fine, depending on exactly how you're doing it. The remarks in the documentation says the following:Quote:Once an input-layout object is created from a shader signature, the input-layout object can be reused with any other shader that has an identical input signature (semantics included). This can simplify the creation of input-layout objects when you are working with many shaders with identical inputs.If a data type in the input-layout declaration does not match the data type in a shader-input signature, CreateInputLayout will generate a warning during compilation. The warning is simply to call attention to the fact that the data may be reinterpreted when read from a register. You may either disregard this warning (if reinterpretation is intentional) or make the data types match in both declarations to eliminate the warning.