• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Jiraya
      For a 2D game, does using a float2 for position increases performance in any way?
      I know that in the end the vertex shader will have to return a float4 anyway, but does using a float2 decreases the amount of data that will have to be sent from the CPU to the GPU?
       
    • By ucfchuck
      I am feeding in 16 bit unsigned integer data to process in a compute shader and i need to get a standard deviation.
      So I read in a series of samples and push them into float arrays
      float vals1[9], vals2[9], vals3[9], vals4[9]; int x = 0,y=0; for ( x = 0; x < 3; x++) { for (y = 0; y < 3; y++) { vals1[3 * x + y] = (float) (asuint(Input1[threadID.xy + int2(x - 1, y - 1)].x)); vals2[3 * x + y] = (float) (asuint(Input2[threadID.xy + int2(x - 1, y - 1)].x)); vals3[3 * x + y] = (float) (asuint(Input3[threadID.xy + int2(x - 1, y - 1)].x)); vals4[3 * x + y] = (float) (asuint(Input4[threadID.xy + int2(x - 1, y - 1)].x)); } } I can send these values out directly and the data is as expected

                             
      Output1[threadID.xy] = (uint) (vals1[4] ); Output2[threadID.xy] = (uint) (vals2[4] ); Output3[threadID.xy] = (uint) (vals3[4] ); Output4[threadID.xy] = (uint) (vals4[4] ); however if i do anything to that data it is destroyed.
      If i add a
      vals1[4] = vals1[4]/2; 
      or a
      vals1[4] = vals[1]-vals[4];
      the data is gone and everything comes back 0.
       
       
      How does one go about converting a uint to a float and performing operations on it and then converting back to a rounded uint?
    • By fs1
      I have been trying to see how the ID3DInclude, and how its methods Open and Close work.
      I would like to add a custom path for the D3DCompile function to search for some of my includes.
      I have not found any working example. Could someone point me on how to implement these functions? I would like D3DCompile to look at a custom C:\Folder path for some of the include files.
      Thanks
    • By stale
      I'm continuing to learn more about terrain rendering, and so far I've managed to load in a heightmap and render it as a tessellated wireframe (following Frank Luna's DX11 book). However, I'm getting some really weird behavior where a large section of the wireframe is being rendered with a yellow color, even though my pixel shader is hard coded to output white. 

      The parts of the mesh that are discolored changes as well, as pictured below (mesh is being clipped by far plane).

      Here is my pixel shader. As mentioned, I simply hard code it to output white:
      float PS(DOUT pin) : SV_Target { return float4(1.0f, 1.0f, 1.0f, 1.0f); } I'm completely lost on what could be causing this, so any help in the right direction would be greatly appreciated. If I can help by providing more information please let me know.
    • By evelyn4you
      Hello,
      i try to implement voxel cone tracing in my game engine.
      I have read many publications about this, but some crucial portions are still not clear to me.
      At first step i try to emplement the easiest "poor mans" method
      a.  my test scene "Sponza Atrium" is voxelized completetly in a static voxel grid 128^3 ( structured buffer contains albedo)
      b. i dont care about "conservative rasterization" and dont use any sparse voxel access structure
      c. every voxel does have the same color for every side ( top, bottom, front .. )
      d.  one directional light injects light to the voxels ( another stuctured buffer )
      I will try to say what i think is correct ( please correct me )
      GI lighting a given vertecie  in a ideal method
      A.  we would shoot many ( e.g. 1000 ) rays in the half hemisphere which is oriented according to the normal of that vertecie
      B.  we would take into account every occluder ( which is very much work load) and sample the color from the hit point.
      C. according to the angle between ray and the vertecie normal we would weigth ( cosin ) the color and sum up all samples and devide by the count of rays
      Voxel GI lighting
      In priciple we want to do the same thing with our voxel structure.
      Even if we would know where the correct hit points of the vertecie are we would have the task to calculate the weighted sum of many voxels.
      Saving time for weighted summing up of colors of each voxel
      To save the time for weighted summing up of colors of each voxel we build bricks or clusters.
      Every 8 neigbour voxels make a "cluster voxel" of level 1, ( this is done recursively for many levels ).
      The color of a side of a "cluster voxel" is the average of the colors of the four containing voxels sides with the same orientation.

      After having done this we can sample the far away parts just by sampling the coresponding "cluster voxel with the coresponding level" and get the summed up color.
      Actually this process is done be mip mapping a texture that contains the colors of the voxels which places the color of the neighbouring voxels also near by in the texture.
      Cone tracing, howto ??
      Here my understanding is confus ?? How is the voxel structure efficiently traced.
      I simply cannot understand how the occlusion problem is fastly solved so that we know which single voxel or "cluster voxel" of which level we have to sample.
      Supposed,  i am in a dark room that is filled with many boxes of different kind of sizes an i have a pocket lamp e.g. with a pyramid formed light cone
      - i would see some single voxels near or far
      - i would also see many different kind of boxes "clustered voxels" of different sizes which are partly occluded
      How do i make a weighted sum of this ligting area ??
      e.g. if i want to sample a "clustered voxel level 4" i have to take into account how much per cent of the area of this "clustered voxel" is occluded.
      Please be patient with me, i really try to understand but maybe i need some more explanation than others
      best regards evelyn
       
       
  • Advertisement
  • Advertisement
Sign in to follow this  

DX11 Single big shader buffer for hardware instancing

This topic is 1834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I saw this part from the battlefield3 presentation (http://dice.se/wp-content/uploads/GDC11_DX11inBF3_Public.pdf) on page 30 where they show how they transfer transformations of each instance to the shader using a single big buffer and a const buffer with indices to index this buffer at the right position using the SV_InstanceID semantic. Can someone tell me what exactly this buffer is ? 

This part here: 

Buffer<float4> instanceVectorBuffer : register(t0);

 

I'm not too familiar with buffers in directx11 beyond constant buffers...

Isn't register(t0) for texture slots ?  Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

And last how would I set such a buffer in the DX11 API ?

Share this post


Link to post
Share on other sites
Advertisement

The MSDN documentation is very lacking in explaining these concepts...

IIRC:

The t registers are similar to the c registers, but they're designed for random memory access patterns (like texture lookups) rather than constant memory access patterns (e.g. it's assumed that every pixel will read the same constants, but may read different texels). You can bind both textures and DX11 buffer objects to the t registers and then load values from them in the shader.

 

You bind values to the t registers using *SSetShaderResources, which takes "shader resource views". You can create a view of a texture, which is the common case, but you can also create a view of a buffer.

 

As mentioned above, you should prefer this method of binding buffers to t registers when you're going to be performing random lookups into the buffer. If every pixel/vertex/etc is going to read the same values from the buffer, then you should bind it to a c register using the usual method.

Also they seem to use 3x4 floats for their transformations, so does that mean they construct their transformation matrix inside the shader using translation, rotation and scale vectors ?

No, in a regular transformation matrix that's been constructed from a traslation + rotation + scale, the 4th row/column (depending on your conventions) will always be [0,0,0,1] so you can hard-code that value in the shader to save some space in the buffer.

 

I'm still not as experienced with DX11 as I am with DX9, so I hope that's correct cool.png

Edited by Hodgman

Share this post


Link to post
Share on other sites

Yes I meant 3 x float4 (sorry for the confusing syntax smile.png  )

Alright thanks for the info.

 

EDIT: By the way this buffer then should be dynamic, correct? Since I need to put in or remove elements during rendering.

Edited by lipsryme

Share this post


Link to post
Share on other sites

The advantage of a buffer over cbuffer is the size (128mb vs 64kb, although in typical scenario 2-4mb should be enough) which allows you to store a frame worth of data to the buffer, also it allows you to fill the buffer once so you'll minimize buffer updates to minimum. The minor inconvenience is that you'll be able to store only float data (probably you can get around this with some bit manipulation method). 

 

The buffer is pratically a texture and you'd bind it as vertex shader resource.

 

 

[source]
float4x4 GetInstanceMatrix(uint InstID,uint Offset)
{
uint BufferOffset = InstID * ElementsPerInstance + StartIndex + Offset;
 
// InstID = InstanceID
// ElementsPerInstance, how many float4's there are per drawn instance (typically 3 for a single mesh if 4x3 matrices are used)
// StartIndex = location of the first float4 inside the buffer for the first instance
// Offset (used to retrieve bone matrices)
 
float4 r0 = InstanceData.Load(BufferOffset + 0);
float4 r1 = InstanceData.Load(BufferOffset + 1);
float4 r2 = InstanceData.Load(BufferOffset + 2);
float4 r3 = float4(0.0f,0.0f,0.0f,1.0f);
 
return float4x4(r0,r1,r2,r3);
}
 
[/source]
 
Inside the vertex shader you may use the above code to retrieve the transform matrix for each vertex. 
 
Cheers!

Share this post


Link to post
Share on other sites

The advantage of a buffer over cbuffer is the size (128mb vs 64kb, although in typical scenario 2-4mb should be enough)

Another important advantage from a tbuffer over a cbuffer is that cbuffer suffer from constant waterfalling, which make them a horrible fit for scalable hw accelerated vertex skinning (indexing the constant buffer with a different index in each vertex).

When you're not suffering constant waterfalling, cbuffers can be faster though, for well.... constant data.

Share this post


Link to post
Share on other sites

Ok this may sound stupid, but what about just using regular instancing?Has this method been benchmarked against regular instancing with a second vertex buffer?

Share this post


Link to post
Share on other sites

Ok this may sound stupid, but what about just using regular instancing?Has this method been benchmarked against regular instancing with a second vertex buffer?

 

If you mean that regular instancing means using a second vertex buffer, I remember reading some years ago that one of the big companies wrote that shaders using a second vertex stream will take a performance hit. It had something to do with the fact that the vertex declaration structure gets pretty big. 

 

I think that the problem with classic instancing is also, that you'll need to define a vertex declaration for each different vertex shader type where the parameters are different. Normally of course you would just have a transform matrix as instance data for the vertex shader, but what if you need also some other per instance parameters, such as color, inverse world matrix or some other parameter which makes your instance different from the others. When using second vertex stream you'll need a different vertex declaration for each case.

 

In the case of the generic buffer, you'll need just one vertex declaration since the vertex data won't change. After it is the job of the vertex shader to extract the desired data from the generic buffer. Of course you'll need to make sure that the buffer contains the expected data. Also, since the buffer can be pretty big you'll be updating data much less often to the graphic card, which reduces API calls. Also, the program side logic get simpler when you don't need to worry so much about "will the data fit to the buffer or not, do I have to make several draw calls instead of one".

 

Of course, under D3D11 the instancing just another parameter that you can access in the vertex shader (InstanceID) and after that you may read or generate the instancing data in the best way you can imagine, though vertex streams can't be randomly accessed. 

 

Cheers!

Share this post


Link to post
Share on other sites

So..I've created the buffer like this:

	D3D11_BUFFER_DESC instanceBufferDesc = {};
	
	instanceBufferDesc.Usage = D3D11_USAGE_DYNAMIC;
	instanceBufferDesc.BindFlags = D3D11_BIND_SHADER_RESOURCE;
	instanceBufferDesc.ByteWidth = sizeof(XMFLOAT4);
	instanceBufferDesc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
	instanceBufferDesc.MiscFlags = 0;
	instanceBufferDesc.StructureByteStride = 0;

	hr = this->device->CreateBuffer(&instanceBufferDesc, NULL, &this->instanceTransformBuffer);

 

is that correct so far ?

 

 
Now I'm a little clueless on how to create the shader resource view from this.
Any ideas ? Do I set the shader resource view description to NULL ?
 
This seems to work without errors:
	D3D11_SHADER_RESOURCE_VIEW_DESC shaderResourceDesc;
	shaderResourceDesc.Format = DXGI_FORMAT_R32_FLOAT;
	shaderResourceDesc.ViewDimension = D3D11_SRV_DIMENSION_BUFFER;
	shaderResourceDesc.Buffer.FirstElement = 0;
	shaderResourceDesc.Buffer.ElementWidth = 4;
	shaderResourceDesc.Buffer.ElementOffset = 0;

	hr = this->device->CreateShaderResourceView(this->instanceTransformBuffer, &shaderResourceDesc, &this->instanceTransformBuffer_SRV);

 

 

Now if the above is correct, how can I basically push float4's onto the buffer ?

Edited by lipsryme

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement