Jump to content
  • Advertisement
Sign in to follow this  
BenS1

Texture formats and multi pass

This topic is 3039 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

Hi

I'm in the process of writing a heightmap generation utility to create level data for use in my game.

Whilst I've already written the code to do this using the CPU, it would be much much faster if I coudl get the GPU to do the work instead.

Normally when I write shaders the input samplers are in R8G8B8A8 format, as is the output, but for my heightmap I need the input and output texture formats to be simple single component 16bit Integers.

Firstly is this format widely supported?

And secondly, do I achieve this by setting the format to DXGI_FORMAT_R16_UINT when I create the texture?

Also, I need to process the heightmap over and over hundreds or even thousands of times. I presume I can do this just by using multiple passes as proving the output of one pass as an input texture to the next pass?

I presume the process of turning a output texture (A render target) into an input texture is almost instantanious (i.e. theres no memory copying of the texture involved)?

Thanks
Ben

Share this post


Link to post
Share on other sites
Advertisement
DXGI_FORMAT_R16_UINT is a single channel 16 bit unsigned integer format. Sounds like what you want. Support should not be a problem.

Yes, you can play ping-pong with two textures. As you set just references to the pipeline there will be no additional copy necessary.

But keep in mind if you are doing only a small amount of work per pass the overhead could be larger than the win.

Share this post


Link to post
Share on other sites
Excellent thanks for your reply.

I could in theory do all the work in a single pass but it would be processing a LOT of instructions (Or rather a few instructions but in a loop), and I suspect there is a max number of instructions per shader? Therefore I can maybe process say 16 iterations per actual pass (Or whatever the actual limit turns out to be).

For example, if I need to prcoess 1024 iterations I could process 16 iterations per pass and therefore require 64 passes.

Thanks for your help

Ben

Share this post


Link to post
Share on other sites
Since you're mentioning DXGI formats, I'm assuming you're talking about DX10+ here. In that case you're effectively not going to have any instruction limit in your shaders, since you'll be using SM4.0 or greater. That shader model also supports flow control constructs for looping, which can greatly reduce your instruction count.

Share this post


Link to post
Share on other sites
Thanks MJP

You're correct, I'm actually using DirectX 11.

Glad to hear that there is no instruction limit which I thought was the case now (I think the original shaders had something like a 32 instruction limit?).

I presume there is no time limit either? I mean, potentially if I decided to do all the processing in a single pass instead of multiple passes then it could potentially take well over an hour to render a single frame... do you know if that would trigger something to timeout?

Thanks
Ben

Share this post


Link to post
Share on other sites
Windows will assume the driver has stopped responding and reset it if rendering a frame takes longer than a couple of seconds or so. You'll need to split the work up into small enough blocks so that you don't run into that.

You may also want to look into using compute shaders.

Share this post


Link to post
Share on other sites
Ok thanks. I figured that there would probably be some kind of timeout somewhere.

Yeah I've had a brief look at DirectCompute and decided using a pixel shader looked simpler, but thats probably just because I haven't used COmputer shaders before. Maybe I should give them a go.

Thanks
Ben

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!