Only one dx9 rendertarget on the GFFX?

[tb]

Hi!

http://www.nvnews.net/images/news/200301/caps_viewer.jpg

Thought 4 is minimum for dx9 specs, but I'am not sure.

Thomas

 

[Tagrineth]

Well keep in mind that apparently the current drivers don't support DX9...

 

[Dave Baumann]

Ummm, thats the point of that image - its showing it is DX9 drivers (read NVNEWS).

 

[OpenGL guy]

http://www.nvnews.net/images/news/200301/caps_viewer.jpg

Thought 4 is minimum for dx9 specs, but I'am not sure.

I believe this just confirms what we learned a long time ago based on the CineFX documents and OpenGL extensions nvidia provided. Namely that the NV30 cannot output more than 128-bits and that "multiple render targets" are in a packed format. For example, 4 32-bit surfaces would be packed inside a single 128-bit surface.

Comments?

 

[Tahir2]

What does it mean to the layman?

 

[pcchen]

That means you can use its render target as one 128 bits FP, or two 64 bits FP, or four 32 bits integer render targets. However, you have to do it by yourself (pack/unpack). Of course, it is more flexible than this. For example, you can use one 64 bits FP and two 32 bits integers. (All in 4D vectors).

However, the potential difference can be a problem to some developers: they have to support multiple render targets and packed render target.

 

[OpenGL guy]

What does it mean to the layman?

On the 9700 Pro, you could allocate 4 different color buffers and have output from the pixel shader go to 1, 2, 3 or all 4 of them. These color buffers can be 16-bit, 32-bit, 64-bit or 128-bit. (I believe they have to all be the same format.)

*Edit: removed description of GeForce FX packed formats as pcchen did a better job*

 

[Dave Baumann]

OGL Guy, can you flesh out what practical use MRT's would be to a developer / us? What would they be used for?

 

[Luminescent]

Pcchen, I don't see how voltage has anything to do with developers and render targets (drum roll please).

 

[OpenGL guy]

OGL Guy, can you flesh out what practical use MRT's would be to a developer / us? What would they be used for?

I'm not an apps person, but here's the way I see it:
- render some stuff with color and Z
- enable MRTs with same Z buffer
- now you can get multiple output data for a single Z compare/update

An example of MRTs in traditional OpenGL is GL_FRONT_BACK rendering where you would render to the front buffer and back buffer simultaneously. MRTs give you more flexibility than that but I still can't tell you what you'd use it for

I've seen a demo using it. Pretty cool but I haven't checked to see exactly what it's doing.

 

[demalion]

Luminescent, that was very very bad.

Where is the groan smiley?

 

[JF_Aidan_Pryde]

OGL Guy, can you flesh out what practical use MRT's would be to a developer / us? What would they be used for?

As MRT outputs up to four different colours, it's useful in storing intermediate results in multi-pass rendering. You can render with different levels of depth accuracy to create depth of field, non-photorealistic renderings etc. This is from one of the R. Huddy slides, at GDC or SIGG I think.

 

[fresh]

You can do all sorts of effects. Like you can output the per pixel normal into one buffer, a floating point depth into another and then combine these to extract edge information. ATI has some white papers on their site detailing the use of MRT.

It's a shame that the GFFX seems to lack so many features.

 

[pcchen]

You still can do these with a packed render target.

 

[OpenGL guy]

You still can do these with a packed render target.

But only with a total of 128-bits.

 

[KimB]

You still can do these with a packed render target.

But only with a total of 128-bits.

And how much of a limitation is this? More to the point, why would you want to use MRT for more than 128 bits of precision on the 9700 Pro (assuming it can do this)?

 

[JF_Aidan_Pryde]

You still can do these with a packed render target.

But only with a total of 128-bits.

And how much of a limitation is this? More to the point, why would you want to use MRT for more than 128 bits of precision on the 9700 Pro (assuming it can do this)?

It's not unconceivable that you'd want four outputs, some of which will require more than 32-bits. But I agree it's no 'biggie'.

 

[KimB]

It's not unconceivable that you'd want four outputs, some of which will require more than 32-bits. But I agree it's no 'biggie'.

Right, but for what? In particular, why would you need greater than a total of 128 bits for PS output?

For one thing, unless there are many passes, it is rather pointless to store more than 64 bits of color data in a single output, and the massive instruction count of the FX should help to reduce the need to have large numbers of passes. When this is necessary, then we probably will not be talking about realtime rendering.

So, with the FX, you may want to output 64-bit color into the packed 128-bit buffer reasonably-often, leaving 64 bits more to store. I could imagine using 32 bits of this for normal information for lighting (two 16-bit floats), leaving another 32-bits for...something.

Regardless, it really seems that the primary reason for using the packed pixel formats and multiple render targets is for increased speed in complex multipass rendering. In the end, this performance is the important thing for such algorithms. And the main way to get this performance seems to be to save intermediate data between passes so as to reduce recalculation each pass.

 

[OpenGL guy]

It's not unconceivable that you'd want four outputs, some of which will require more than 32-bits. But I agree it's no 'biggie'.

Right, but for what? In particular, why would you need greater than a total of 128 bits for PS output?

Perhaps so you can multipass MRTs with more than 32-bits?

For one thing, unless there are many passes, it is rather pointless to store more than 64 bits of color data in a single output, and the massive instruction count of the FX should help to reduce the need to have large numbers of passes. When this is necessary, then we probably will not be talking about realtime rendering.

So, with the FX, you may want to output 64-bit color into the packed 128-bit buffer reasonably-often, leaving 64 bits more to store. I could imagine using 32 bits of this for normal information for lighting (two 16-bit floats), leaving another 32-bits for...something.

How about generating a vertex buffer? You'd need much more than 128-bits.

Regardless, it really seems that the primary reason for using the packed pixel formats and multiple render targets is for increased speed in complex multipass rendering. In the end, this performance is the important thing for such algorithms. And the main way to get this performance seems to be to save intermediate data between passes so as to reduce recalculation each pass.

Above you said this wouldn't be used for realtime rendering, now you say they are performance enhancing features, while these aren't mutually exclusive, the set of intersections is rather small.

Anyway, I believe you are missing quite a few applications of MRTs with more than 128-bits.

 

[Neeyik]

Just noticed something in that DX CAPS shot:

MaxTextureBlendStages 8
MaxSimultaneousTextures 8

Is that right? A GF4 is 8 & 4, but I thought the GFFX was supposed to show higher values than 8 & 8.

Oh and can somebody show the full listing for the DevCaps and DevCaps2?