Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is it possible to dynamically allocate memory in HLSL?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Joakitex   Members   -  Reputation: 138

Like
0Likes
Like

Posted 19 February 2012 - 12:13 AM

Hello there, I am working on this graphics engine and I am now learning how to implement lights into the engine using HLSL. I've come across several tutorials that teach you how to create directional lights, multiple point lights, etc, everything works fine but, I want to create a shader that is as generic as possible, and I've encountered a problem with that.

Lets say that I have a structure in HLSL that looks like this:

struct PointLight
{
	 float4 LightColor;
	 float3 LightPosition;
};

And lets also say that I created a level for my game that uses X amount of point lights.

Is there any way to create an X amount of PointLight instances in HLSL during runtime? Is it possible to do something like: PointLight arrayOfLights = new PointLight[X]; ?

Another question, what is the best way in D3D10 to pass variables from the program to a structure member in a shader?

Example:

I want to pass this

D3DXVECTOR3 LPosition(0.0f, 0.0f, 0.0f);

Into this

PointLightInstance.LightPosition;

How should I do this?

Thanks in advance

Sponsor:

#2 MJP   Moderators   -  Reputation: 10231

Like
1Likes
Like

Posted 19 February 2012 - 12:27 AM

You definitely can't dynamically allocate memory in HLSL. But you also don't need to. What you can do is declare a constant buffer in your shader containing an array of your "PointLight" structures with size equal to some maximum number of lights (you can go for something big like 128 if you'd like), and then have another variable in your constant buffer containing the actual number of lights that you want rendered. So your shader would look something like this:
struct PointLight
{
	float4 LightColor;
	float3 LightPosition;
};

static const uint MaxLights = 128;

cbuffer Lights : register(cb0)
{
	PointLight Lights[MaxLights];
	uint NumLights;
}

float4 PSMain(in PSInput input) : SV_Target0
{
	float3 lighting = 0.0f;
	for(uint i = 0; i < NumLights; ++i)
		lighting += ApplyPointLight(Lights[i]);
}

As far as the C++ side of things go, the easiest way to manage this is to have a C++ structure that exactly matches the memory layout of your constant buffer. So you can declare a C++ version of your PointLight struct, as well as a C++ version of the entire constant buffer structure. The one thing that you need to watch out for is in HLSL your PointLight structure will get padded out to some multiple of 16 bytes (float4 size), so you'll need to do the same in C++. Something like this should work:
struct PointLight
{
	D3DXVECTOR4 LightColor;
	D3DXVECTOR3 LightPosition;
	float _Padding;
};

static const UINT32 MaxLights = 128;

struct LightConstantBuffer
{
	PointLight Lights[MaxLights];
	UINT32 NumLights;
};

Then all you need to do is create a dynamic constant buffer resource with the appropriate size (sizeof(LightConstantBuffer), rounded up to the next multiple of 16 bytes) during initialization, then each frame you can Map it to fill it with the current lights + number of lights for each draw call. To fill it you can just cast the void pointer you get back from Map to the type LightConstantBuffer*, and then you can just set all of the values. And don't forget to bind the constant buffer to the pixel shader stage as well.

#3 Tsus   Members   -  Reputation: 987

Like
1Likes
Like

Posted 19 February 2012 - 03:46 AM

Hi!

The term „dynamic memory allocation“ caught my attention. In your case it is not needed, true, but if you stumble upon the case where you would like to allocate memory in shaders, there is a nice workaround.

First, you have to preallocate enough memory (you can’t get around this, since dynamic allocations are not possible.)
You could do so by creating a structured buffer that has room for enough elements. Structured buffers can have an internal counter, which is (and that’s interesting) faster than a plain atomic counter. You can use the current value of the counter as address in the structured buffer. If you’d like to add a new element, you can simply increment the counter and thereby get a new exclusive address. This works without problems across multiple threads (although it is a little bottleneck) and is currently only available in pixel shaders and compute shaders. Dx11.1 will add it to the other shader stages as well.

By the way, you can build linked lists with that, too. The order-independent transparency demos, screen contribution blending and tile-based deferred shading do exactly that.

Declaration in the HLSL:
struct DataElement {
	int someData;
};
RWStructuredBuffer< DataElement >  myBuffer		: register( u0 );

And then the usage:
// prepare the data element to write
DataElement element;
element.someData = 1;

// get address
uint nAddress= myBuffer.IncrementCounter();

// write the data element
myBuffer[ nAddress ] = element;

Cheers! Posted Image

Acagamics e.V. – IGDA Student Game Development Club (University of Magdeburg, Germany)


#4 Joakitex   Members   -  Reputation: 138

Like
0Likes
Like

Posted 19 February 2012 - 11:45 AM

Thanks both of you, this helped me a lot.

Also, a noob question. Do the constant buffers always get padded out to a multiple of the size of the biggest member of the buffer?

If I had this in the shader

struct PointLight
{
	 float4 LightColor;
	 float2 SomeData;
};

The code in C++ would be like this, am I right?

struct PointLight
{
	 D3DXVECTOR4 LColor;
	 D3DXVECTOR2 SomeData;
	 D3DXVECTOR2 Padding;
};


#5 MJP   Moderators   -  Reputation: 10231

Like
1Likes
Like

Posted 19 February 2012 - 03:28 PM

It works that way for structures declared in constant buffers, yes. For variables that aren't structures the packing rules are a bit more complex. See this for more info.

#6 Joakitex   Members   -  Reputation: 138

Like
0Likes
Like

Posted 20 February 2012 - 10:39 PM

Thanks again, I'll take a look at that.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS