Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Mar 2007
Online Last Active Today, 05:39 PM

#4980681 Graphics programming book recommendations

Posted by MJP on 16 September 2012 - 12:25 PM

Real-Time Rendering, 3rd Edition and Physically-Based Rendering are my top picks. Principles of Digital Image Synthesis is also really good, plus it's free.

#4980237 Own created graphics window

Posted by MJP on 14 September 2012 - 06:40 PM

It's usually called a "splash screen" or "splash window". You can roll your own by making a borderless window, or you can try using something like this.

#4980135 FX compiler using more temporary registers than necessary

Posted by MJP on 14 September 2012 - 12:35 PM

How much it differs depends on the architecture. In my experience the microcode will still retain the overall structure of the shader assembly as far things like stripping dead code, unrolling loops, branches, etc., but there will usually be differences in exactly how it uses registers and how many instructions it needs since the assembly ISA won't match the microcode ISA. In some cases there can be quite a difference between the instructions, especially when you consider that Nvidia and newer AMD hardware only operate in terms of scalar instructions.

Unfortunately register allocation isn't really something you have much control of in DirectX, as I'm sure you're aware of by now. Even if you did, it's hard to make decisions regarding ALU instructions vs. register pressure without knowledge of the actual hardware that your shader will run on. On console platforms I've worked on you have more control over registers since that makes sense for a fixed platform, but as far as PC goes the advice I've seen from IHV's is to "just trust the driver to do the right thing". I couldn't really tell you how the D3D compiler or the driver makes its decisions regarding register allocation, I haven't seen that publicly documented or disclosed anywhere.

#4980130 #include isn't working

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

I don't think it's an include problem. Everything in DirectXMath.h is in the DirectX namespace. The simplest way to fix this is to add "using namespace DirectX;" to the top of your cpp file.

#4979920 FX compiler using more temporary registers than necessary

Posted by MJP on 13 September 2012 - 08:20 PM

Are you looking at the D3D shader assembly? Because that assembly is just an intermediate format. At runtime the driver will JIT compile it to whatever microcode format is supported by that hardware, which means your assembly is not an accurate reflection of register usage or even which instructions get executed. You need to use vendor-specific tools for that kind of information.

#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
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.CPUAccessFlags = 0;
desc.MiscFlags = (autogen) ? D3D11_RESOURCE_MISC_GENERATE_MIPS : 0;
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)
	    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) )
		    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.