Texture formats and multi pass

Started by
5 comments, last by BenS1 13 years, 9 months ago
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

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.

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
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.
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
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.
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

This topic is closed to new replies.

Advertisement