Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


MJP

Member Since 29 Mar 2007
Offline Last Active Today, 12:15 AM

#4979792 Mip map initialisation

Posted by MJP on 13 September 2012 - 11:51 AM

The way you're trying to do things would require that you have the mipmap data already generated when you created the function. There is no "automatic" mip generation for IMMUTABLE textures, since they require that you pass all of the required data to it. What you're actually doing in your code is you're passing the top-level mip data to all of the lower-resolution mip levels, which isn't right. If you do have all of the mips generated, then for each D3D11_SUBRESOURCE_DATA you need to have it point to the data for that mip. You would also need to set the proper pitch for that mip level, which get smaller as you go up in the levels.

If you don't actually have the mips generated and you want them to be generated by the hardware, you need to set it up differently. Here's an example of how to do it, taken from the WICTextureLoader sampler from DirectXTex:

// Create texture
D3D11_TEXTURE2D_DESC desc;
desc.Width = twidth;
desc.Height = theight;
desc.MipLevels = (autogen) ? 0 : 1;
desc.ArraySize = 1;
desc.Format = format;
desc.SampleDesc.Count = 1;
desc.SampleDesc.Quality = 0;
desc.Usage = D3D11_USAGE_DEFAULT;
desc.BindFlags = (autogen) ? (D3D11_BIND_SHADER_RESOURCE | D3D11_BIND_RENDER_TARGET) : (D3D11_BIND_SHADER_RESOURCE);
desc.CPUAccessFlags = 0;
desc.MiscFlags = (autogen) ? D3D11_RESOURCE_MISC_GENERATE_MIPS : 0;
D3D11_SUBRESOURCE_DATA initData;
initData.pSysMem = temp.get();
initData.SysMemPitch = static_cast<UINT>( rowPitch );
initData.SysMemSlicePitch = static_cast<UINT>( imageSize );
ID3D11Texture2D* tex = nullptr;
hr = d3dDevice->CreateTexture2D( &desc, (autogen) ? nullptr : &initData, &tex );
if ( SUCCEEDED(hr) && tex != 0 )
{
    if (textureView != 0)
    {
	    D3D11_SHADER_RESOURCE_VIEW_DESC SRVDesc;
	    memset( &SRVDesc, 0, sizeof( SRVDesc ) );
	    SRVDesc.Format = format;
	    SRVDesc.ViewDimension = D3D11_SRV_DIMENSION_TEXTURE2D;
	    SRVDesc.Texture2D.MipLevels = (autogen) ? -1 : 1;
	    hr = d3dDevice->CreateShaderResourceView( tex, &SRVDesc, textureView );
	    if ( FAILED(hr) )
	    {
		    tex->Release();
		    return hr;
	    }
	    if ( autogen )
	    {
		    assert( d3dContext != 0 );
		    d3dContext->UpdateSubresource( tex, 0, nullptr, temp.get(), static_cast<UINT>(rowPitch), static_cast<UINT>(imageSize) );
		    d3dContext->GenerateMips( *textureView );
	    }
    }
}



#4979614 Single responsibility principle and dependencies

Posted by MJP on 13 September 2012 - 01:07 AM

Even if you roll your own mesh class you'll still the device to create vertex buffers, so you'll have the same problem. In general D3D9 just doesn't have any real multithreading capability, it wasn't until D3D11 that we got the ability create resources and submit commands on multiple threads. Probably the best you can do is handle any I/O and decompression on a worker thread, and then let the main thread use the device to actually create the D3D resources.


#4979578 Does alpha blending shall be gamma corrected?

Posted by MJP on 12 September 2012 - 10:30 PM

That's not quite true for D3D9, it actually depends on the hardware. DX10+ hardware will do the blending in linear space, while older DX9 hardware will do the blending in sRGB space. There's even a cap bit for it: D3DPMISCCAPS_POSTBLENDSRGBCONVERT. Unfortunately you can only check that cap if you're using an Ex device on Vista or Win7, and there's no way to turn it off. So if you use frame buffer gamma correction, it's possible that your game will look different on DX9 and DX10 hardware. The only safe thing to do is to manually perform sRGB conversion at the end of your pixel shader, in which case you get consistent behavior on both platforms.


#4978733 Rendertargets + viewports and device caps in Direct3D11?

Posted by MJP on 10 September 2012 - 05:38 PM

For the most part caps were removed. The way it works is that each feature level has a minimum set of of required functionality. So for instance if a device supports feature level 10, then you can count on it supporting 8192x8192 textures. The list of this functionality is here: http://msdn.microsof...2(v=vs.85).aspx. There are also some pages containing which operations are supported for which DXGI format given a feature level, which can be found here: http://msdn.microsof...2(v=vs.85).aspx. The are still a few optional features, which are listed here: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476124%28v=vs.85%29.aspx. You can query for them with ID3D11Device::CheckFeatureSupport.

The viewport in D3D11 is almost exactly the same as in D3D9, in that it's just a transformation applied to primitives after projection and before rasterization. So for instance you can use it to only render to the top half of a render target. The one thing that changed in D3D10 was that you can now specify multiple viewports, and then select which one to use for each primitive that you emit from a geometry shader. But that's probably not something you'll have much use for.


#4978690 [Compute Shader] Groupshared memory as slow as VRAM

Posted by MJP on 10 September 2012 - 02:41 PM

I suppose it's possible that your hardware doesn't actually have on-chip shared memory and just uses global memory instead, but I've not heard of that ever being the case. Although mobile hardware isn't usually well-documented, so who knows. You could try using GPU PerfStudio or AMD's APP profiling suite, but I'm not sure if either those will give you enough information to narrow down the problem. Perhaps you might want to try running some samples that make use of shared memory to see if they also perform poorly on your hardware.

Also just so you know, shared memory isn't L1. On AMD and Nvidia hardware It's its own special type of on-chip memory, and it's separate from the caches.


#4978124 Rendering question

Posted by MJP on 08 September 2012 - 05:16 PM

There doesn't have to be any overhead at runtime. You already need to compile different versions of your executable for each platform you target, so when you compile them you can just have the engine use the appropriate rendering code path for that platform and ignore everything else.


#4978095 Just a quick shader question

Posted by MJP on 08 September 2012 - 02:34 PM

Back in the old days before HDR, it was common to store some "glow" value in either the alpha channel or a separate render target. This value could be derived from some specific glow texture, or you could use the results of your specular lighting, or something along those lines. You can also just use a threshold or lower exposure to get your bloom source with LDR rendering, but in general you'll usually end up with more things blooming than you'd like. With HDR things are more natural since you can naturally express really bright light sources and bright surfaces.


#4978093 General questions on hdr and tonemapping

Posted by MJP on 08 September 2012 - 02:30 PM

I usually just use a floating point texture format like R16_FLOAT or R32_FLOAT for storing log(luminance), and those formats have a sign bit. Which format are you currently using?


#4978092 What do you use for Audio in DirectX applications?

Posted by MJP on 08 September 2012 - 02:25 PM

I'm only including this:

#include <xaudio2.h>
#include <x3daudio.h>
#include <xaudio2fx.h>

#pragma comment (lib, "xaudio2.lib")
#pragma comment (lib, "x3daudio.lib")

It worked fine before with just

#include <xaudio2.h>
#pragma comment (lib, "xaudio2.lib")

However I don't understand why implementing 3D audio causes the problem.I mean the same headers and libraries are included in the SDK 3D Audio sample and I can run it fine,however when I use these functions in my project,the missing DLL thing comes up.Now I've checked project options carefuly at both my project and the SDK sample one,all the settings are the same,I checked all their code,there is no reference in the source for such a dll,so perhaps it's called for in the libs?But how can that be if those libs were made over 2 years ago while this dll that it wants is from Windows 8


Those libraries you're linking to are import libraries. Basically they're just stubs that allow to linker to hook up your code's function calls to the functions exported by the DLL, instead of having to manually ask for the address of the DLL function at runtime. When you link to a DLL's import lib your app now has a dependency on that DLL, which means it will attempt to load that DLL when the app starts up. If it can't find the right DLL, you get that error.


#4977391 Small question about Bloom RT formats

Posted by MJP on 06 September 2012 - 04:22 PM

A R10G10B10A2 backbuffer won't give you any extra dynamic range, it will just give you more precision for the standard displayable range. Either way there's no guarantee that the display won't just convert it to something else when it outputs.


#4977361 Specular Highlight - fx-File - Vertexshader only

Posted by MJP on 06 September 2012 - 02:42 PM

When calculating the half vector, what you want is the view direction. This is a normalized vector pointing from the surface towards the camera. What you're doing is taking the view space position and negating it, which is equivalent to (0, 0, 0) - viewSpacePosition gives you the view direction in view space. However your normal and I'm assuming your light direction are in world space, so you'll want the world space view direction. You should pass in the world space camera position through a constant buffer, then use normalize(g_cameraPositionWorldSpace - worldPos.xyz) when calculating your half vector.


#4977101 Cube Map Rendering only depth ! No color writes. - BUG

Posted by MJP on 06 September 2012 - 01:07 AM

Depth-only rendering is definitely good when you can do it. In some cases the advantage will be nullified because you'll become vertex or triangle setup bound, but I'd still recommend doing it.

You don't have to use SV_Depth to output 1 - z/w. You just need to tweak your projection matrix. In most math libraries you can just reverse the near and far clip planes and you'll get the desired result. I wouldn't recommend any kind of SV_Depth output unless you really have to. Even the conservative depth stuff will still have some performance impact.


#4976157 How to down/up sample a render target

Posted by MJP on 03 September 2012 - 01:42 PM

You can read up on image scaling if you want some background info. The basic idea is that you sample one or more texels from the source render target, apply some sort of filter to those texels, and output the result. You're probably already familar with the "point" and "linear" filtering modes that are built-in to the hardware, which you can use just by taking a single texture sample with the appropriate sampler settings. But you can also implement more complex filters manually in your shader, if you wish.

For downscaling depth, things are a bit more tricky since some of the conventional wisdom used for scaling color images won't necessarily apply. Most people just end up using point filtering to downscale depth, which preserves edges but increases aliasing. To implement that, it really is as easy as you think it is: just use a pixel shader to sample the full-size render target, and output the value to your half-size render target.


#4976123 Move Object Based on Camera's Direction

Posted by MJP on 03 September 2012 - 11:44 AM

A view matrix is the inverse of your camera's transformation matrix. A transformation matrix takes you from an object's local space to world space, while a view matrix takes you from world space to the camera's local space. If you invert the view matrix to get the transformation matrix, the camera's forward direction will be the third row of the matrix (the Z basis). For a view matrix you can also just transpose instead of inverting and grab the third row, which is equivalent to grabbing the _13, _23, and _33 components from the view matrix. Once you have the forward direction, you can just do position += forwardDir * moveAmt.


#4975819 Error #342: device_shader_linkage_semanticname_not_found

Posted by MJP on 02 September 2012 - 02:37 PM

Everything you've posted looks okay. Are you sure you have the right input layout and vertex shader bound when that error message gets output? If you capture a frame in PIX, you can double-click on the error and it will take you to the exact call that caused it. Then you can check the state of your device context, and make sure it's what you expect it to be.




PARTNERS