Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Mar 2007
Offline Last Active Today, 02:34 AM

#5089237 DX11 - Sending Textures

Posted by on 26 August 2013 - 12:10 PM

You probably LOAD the texture once on the gpu. and probably BIND it to some slot once per frame.

This. When you create the texture and provide the texture data, that data is normally stored directly in GPU memory and will stay there until you release it. Binding textures to a shader stage is just a mechanism for letting shaders know which textures to use.

#5088733 Questions about Sampling / Reconstruction filter

Posted by on 24 August 2013 - 01:44 PM

To add to Brother Bob's explanation...this process is generally known as resampling. It's actually the same exact process that would happen if you resize an image in Photoshop. The basic steps go something like this:


1. You have some continuous signal

2. You discretely sample that signal

3. You use a reconstruction filter to re-create a continuous signal

4. You sample the reconstructed continuous signal at different sample points

The one thing to keep in mind is that steps #3 and #4 usually happen at the exact same time in computer graphics. You don't reconstruct the entire continuous signal, you just know where you want to re-sample and so you reconstruct the continuous signal at that exact sample point. This reconstruction then becomes the value you store in your new discrete representation.

#5087506 Using both D3D9 and D3D11

Posted by on 20 August 2013 - 01:30 AM

As far as I know there's nothing inherently dangerous about having your app load both the D3D9 and D3D11 DLL's. I've been doing this for years since the PIX marker functions are exported from D3D9.DLL, and I don't believe it's been the cause of any problems. The old samples from the SDK also did the same thing.

#5087215 Dynamic global illumination (Molecule Engine)

Posted by on 19 August 2013 - 12:33 AM

Well he refers to it as radiosity, so I would assume that it's based on form factors. If you have lightmap then you can pre-compute form factors between texels pretty easily. Then at runtime you just need some means of dynamically computing lighting at each texel, and you can iteratively compute the indirect lighting using your pre-computed for factors. For such a low amount of texels you could probably just brute-force force it by having each texel iterate over all of the form factors, at least if you strip out form factors that are below some threshold. But there's lots of existing optimizations for radiosity that you could borrow to make it really fast.

#5087194 [Visual Studio 2012]What does this error mean?

Posted by on 18 August 2013 - 10:17 PM

You're definitely leaking something if you're getting that output. It's still possible to leak even if you generally use smart pointers, since there may be cases where your smart pointers aren't being used or where the proper destructors don't get called.

#5086944 constant buffer data layout mismatch between app/shader

Posted by on 17 August 2013 - 09:28 PM


Plus, if you don't want the matrix to be transposed, add:
#pragma pack_matrix( row_major )

at the top of every shader file you want the matrix to work as passed in.



You can also use row_major when declaring the float4x4 in your constant buffer, or use the /Zpr command-line option for fxc.exe.

#5086943 constant buffer data layout mismatch between app/shader

Posted by on 17 August 2013 - 09:27 PM

The issue is that the float4x4 needs to be aligned to 16-bytes to satisfy the constant buffer packing rules (described in the link Hodgman provided). This is why the two float variables are packed normally, and then 8 bytes of padding is inserted. I'd suggesting reading that documentation and becoming familiar with the exact rules.

Note that on the C++ side of things, you can also achieve the same result by having the compiler align the matrix for you using __declspec(align(16)) when defining your Matrix type, or when declaring the Matrix member of your struct.

#5086940 Using some ConstantBuffer values causing CreateShader to fail

Posted by on 17 August 2013 - 09:21 PM

Do you have the debug layer enabled? It should give you more detailed info about why CreateVertexShader call is failing.

#5086430 Creating 2D texture array

Posted by on 16 August 2013 - 02:50 AM

You need one per subresource in your texture, which means you will have ArraySize * MipLevels subresources. For the ordering you pass the data for Mip 0 of Index 0, then Mip 1 of Index 0, and so on for all Mip levels. Then you go to Mip 0 of Index 1, then Mip 1, and so on for all array slices. You can calculate the subresource index by doing ArrayIndex * NumMips + MipLevel.

Also just so you know, the DirectXTex package has a command-line tool called Texassembler that can pack a bunch of textures into a texture array and save it as DDS format, which can be convenient.

#5086296 Buffer<uint> reading wrong values

Posted by on 15 August 2013 - 04:21 PM

Yeah the debug layer output can be a lifesaver sometimes! If you want, you can actually set it up to break into the debugger when a warning or error occurs. I usually do this so that I know right away that something is wrong, and also so that I know exactly where it's coming from.  It's really easy to do:


ID3D11InfoQueue* infoQueue = NULL;
device->QueryInterface(__uuidof(ID3D11InfoQueue), reinterpret_cast<void**>(&infoQueue));
infoQueue->SetBreakOnSeverity(D3D11_MESSAGE_SEVERITY_WARNING, TRUE);
infoQueue->SetBreakOnSeverity(D3D11_MESSAGE_SEVERITY_ERROR, TRUE);


As for the BRDF, it's basically an energy-conserving Blinn-Phong BRDF paired with a Fresnel term. The energy-conserving Blinn-Phong model does indeed come from the "Physically Based Shading"  side of things. If you're not familiar with the basics, I'd recommend reading through Real-Time Rendering 3rd Edition. It's a fantastic book all-around, but it has a great chapter that describe the physics of lighting and reflectance, as well another chapter that gives a comprehensive overview of BRDF's and the basics of physically based shading models. I'd also recommend reading through Naty Hoffman's presentations and course notes from SIGGRAPH. The slides from this year's course can be found here, but his course notes aren't up yet. You can also find last year's material here.

#5086237 Device Context Question

Posted by on 15 August 2013 - 02:42 PM

You can just set the hull and domain shader to NULL if you're not using them anymore.

#5086235 Buffer<uint> reading wrong values

Posted by on 15 August 2013 - 02:40 PM

It sounds like you're doing everything correctly, so I'm not sure what the problem is. You shouldn't need to do anything to the buffer after the compute shader is done writing to it, you should be able to just read from it in your pixel shader assuming that the UAV and SRV were set up correctly. If you didn't set up the UAV or SRV correctly the debug layer will usually output a warning to let you know that you did something wrong, assuming that you enabled the debug layer when creating the device.

#5085881 Percentage Closer Filtering

Posted by on 14 August 2013 - 12:37 PM


Are you creating your device with the D3D11_CREATE_DEVICE_DEBUG flag and checking for warnings/errors in your debugger output? It's possible that you messed something up when creating the sampler state, and that's screwing up the shader.


I donot have D3D11_CREATE_DEVICE_DEBUG flag.



You should always, always, *always* be using it for debug builds. Always.

#5085641 Uber (Compute) Shader construction

Posted by on 13 August 2013 - 03:05 PM

When you hard code a constant into HLSL or Cg code the end result is the same as having that constant specified in a constant buffer and bound at runtime. 

Well that of course isn't true. Any constants that are hard-coded into the shader can be folded into the instructions and used to optimize the resulting assembly/bytecode. In materials a lot of parameters end up having a value of 0 or 1. If those parameters are hard-coded then any multiplication with those values can be optimized away completely. Or in the case of 0, all operations involved in producing the value to be multiplied with that parameter can be stripped away. With values in a constant buffer the compiler can't make these assumptions, and must issue wasted instructions and possibly consume additional registers. There are also cases where the hardware supports modifiers that allow multiplications by certain values to be folded into a previous instruction. For instance AMD's GCN ISA supports modifiers that allow for a free multiplication by 0.25, 0.5, 2, or 4.

#5084552 Easy-to-use Version Control on Windows? Needs to be able to easily ignore cer...

Posted by on 09 August 2013 - 06:55 PM

Yeah Perforce very much likes to be in control of files in the repo, and generally doesn't behave well when you go behind its back. So if you want to delete a file you have to tell P4 to delete it, and it will then delete it from your hard drive. If you happen to delete a file locally it won't even be aware it's gone, and if you try to sync on it (Get Latest in P4V) it won't replace it. The only way it will replace it is if you use -f to force a sync.