Jump to content

  • Log In with Google      Sign In   
  • Create Account


Hornsj3

Member Since 05 Mar 2012
Offline Last Active Jul 16 2013 03:51 AM

Topics I've Started

Why Does CreateInputLayout Work With This Descriptor?

25 June 2012 - 03:35 PM

So I'm playing around with the Input Layout stage of the pipeline and I have a question.

Here's my Input Layout descriptor element
D3D11_INPUT_ELEMENT_DESC inputLayoutDesc[] =
	{	  
		{
			"TEXCOORD", //Semantic name
				0, //Semantic Index
				DXGI_FORMAT_R32G32_FLOAT, //DXGI Format
				0, //Input Slot
				D3D11_APPEND_ALIGNED_ELEMENT, //Number of bytes from start of array to this element
				D3D11_INPUT_PER_VERTEX_DATA, //Input Classification (we are using per vertex not per instance data)
				0 //Instance data step rate, 0 for Per-Vertex data
		},
		{
			"POSITION", //Semantic name
			0, //Semantic Index
			DXGI_FORMAT_R32G32B32_FLOAT, //DXGI Format
			0, //Input Slot
			D3D11_APPEND_ALIGNED_ELEMENT, //Number of bytes from start of array to this element
			D3D11_INPUT_PER_VERTEX_DATA, //Input Classification (we are using per vertex not per instance data)
			0 //Instance data step rate, 0 for Per-Vertex data
		},
	  
	};


Here's my Vertex Shader
struct VS_INPUT
{
float3 Pos : POSITION0;
};
struct PS_INPUT
{
float4 Pos : SV_POSITION; //Screen-space position
};

PS_INPUT VS(VS_INPUT input)
{
PS_INPUT output = (PS_INPUT)0;
output.Pos = float4(input.Pos, 1.0f);

return output;
}


This works fine...meaning I am able to create my input layout object and set it to the input assembler stage.

My question is, why does this work?

From what I have read the input layout has to match the vertex shader input signature. This clearly does not. It seems to me as long as it can match the Position semantic it will allow me to create the object and set it.

It seems like this should not work because it does not exactly match the expected input to the vertex shader.

ID3D11Texture2D COM Interface Question

15 April 2012 - 09:46 AM

Below is a function I am writing to copy data into a texture. My question is will the CreateTexture2D function release the ID3D11Texture2D pointer or do I need to explicitly release it if it holds data?

void InterlockingTiles::recreateTexture()
{
    //Do I need to release this interface to prepare for new data?
    if(m_pTexture)
    {
	    m_pTexture->Release();
    }
    HRESULT hr = m_pDevice->CreateTexture2D(
	    &m_textureDesc,0,&m_pTexture);
   
    if(FAILED(hr))
    {
	    //TODO: throw some exception
    }
}

Performance in Compute: Dispatch vs. Wasted Threads

03 April 2012 - 05:18 AM

Bear with me, this may be a long one.

I'm still perfecting a compute shader to generate custom mip-map values. My current problem is whether or not to have thousands of wasted threads, or multiple dispatch calls.

Here is a sample of how I'm setting up the number of threads in a thread group. This has no wasted threads, so long as my mip-level is at least 32x32.

#define sizeMip32_x 32
#define sizeMip32_y 32

[numthreads(sizeMip32_x, sizeMip32_y, 1)]
void CS32( uint3 DispatchThreadID : SV_DispatchThreadID )
{
  ...
}


The problem arises after start generating 16x16 and below.

On the one hand I could specify separate shaders for each level below 16x16, such as this:


#define sizeMip16_x 16
#define sizeMip16_y 16

[numthreads(sizeMip16_x, sizeMip16_y, 1)]
void CS16( uint3 DispatchThreadID : SV_DispatchThreadID )
{

  ...
}

... continue to 1x1

All of these shaders would be compiled at the same time. I would then use logic in C++ to determine which to call, based on the dimensions of the mip-level. That is approach one.

The second approach is to use logic in the shader, coupled with memory barriers, to generate the mip hierarchy from high resolution down to 1x1.
this would only require the 32x32 shader and 1 dispatch call but will invoke (rough estimate for base level of 512x512) about 200,000 threads which add no value. (256x256 threads mip-level 1 ... to 1x1).

This is because, in the first iteration, each thread will be utilized in calculating the next level. It will sample each pixel in the 4 pixels underlying the mip-level pixel and write the maximum value it finds. The second mip-level calculated will still run all 256x256 threads but will duplicate the work of the 4 adjacent threads (at each level) due to the nature of the algorithm.

So, given all of this, would it be better to have separate shaders and multiple dispatch calls or waste hundreds of thousands of threads in a single dispatch?

XNAMATH unsigned integer vector type?

25 March 2012 - 08:17 PM

I'm struggling with the documentation for XNAMATH, trying to use some form of vector of 4 unsigned integers in my constant buffer.

Below is an example of using a 4 component vector of floats, but I want to use unsigned integers.

ConstantBuffer cb1;
cb1.threadGroupDims = XMFLOAT4(destDim, 0, 0, 0);
m_pContext->UpdateSubresource(m_pConstantBuffer, 0, NULL, &cb1, 0, 0);


Does anyone know the typename?

Thanks.

D3D11 - Are Effect Files Discouraged?

18 March 2012 - 05:46 PM

I am fairly new to DirectX and am going straight to DX11.

I know D3D10 included an effects framework (and D3D11 supplies the source you can build).

My question is, does Microsoft consider the effects framework to be the non-optimal solution? Is the alternative to this the binding and unbinding shaders and resources explicitly through the framework ?

I want to learn the proper way to do this, not the old (if it is, in fact considered out dated) way.

Right now I'm going to be running a compute shader per mip level to construct a data structure using the mip-maps of a texture. This means I need to have one compute shader for each mip level. Each shader must run after the previous mip level has been computed (the next coursest level depends on the previous, finer one). It seems the effects framework would be useful for this, but it could be done by looping through and explicitly setting shaders and dispatching.


Thanks.

PARTNERS