Does Radeon 9700 Support 128Bit FP Frame Buffers?

[Dave Baumann]

The 9700 supports writing a full 128b pixel to a non-displayable buffer (it's 32b float per component). It supports up to 10:10:10:2 for displayable buffers.

OK, thanks. My next question is - is that full time? Regarless of the selected display output the front buffer (or non-displayable buffer) will remain at 128bit float precision to maintain accuracy during multipass situations?

i.e. if we were playing an old game, such as Quake3 (which forces mulitpass after two textures regardless of what the hardware supports internally), in 32bit or 16bit display resolutions the mulitpass ops will still be performed at 128bit accuracy?

 

[andypski]

The 9700 supports writing a full 128b pixel to a non-displayable buffer (it's 32b float per component). It supports up to 10:10:10:2 for displayable buffers.

OK, thanks. My next question is - is that full time? Regarless of the selected display output the front buffer (or non-displayable buffer) will remain at 128bit float precision to maintain accuracy during multipass situations?

i.e. if we were playing an old game, such as Quake3 (which forces mulitpass after two textures regardless of what the hardware supports internally), in 32bit or 16bit display resolutions the mulitpass ops will still be performed at 128bit accuracy?

If you were playing an old game such as Quake3 it would request either a 16 or 32 bit back buffer depending on what mode you were running in, so the answer in this case is no - the back buffers used by these applications would still be 16 or 32 bit, not floating point.

The driver could force higher precision formats for the back buffers, but you would expect this to decrease performance and it would also be incorrect behaviour since the buffers should be supplied in the format specified by the application.

- Andy.

 

[Basic]

I don't expect multipass on R300/NV30 to use a high precision back buffer on any applications that aren't explicitly written to use that feature. And if I'm right, then I think that's reasonable priorities from ATi/nvidia.

Edit: oops, too slow.

 

[Dave B(TotalVR)]

Surely if you are writing 128 bits of floating point information to the framebuffer in external memory it will have an enourmous performance cost?

 

[Dave Baumann]

I don't expect multipass on R300/NV30 to use a high precision back buffer on any applications that aren't explicitly written to use that feature. And if I'm right, then I think that's reasonable priorities from ATi/nvidia.

this is whatI'm wondering - if the internal pipeline precision is at 128bit FP in the first place wouldn't an application be implicitly making use of it anyway, regardless of what the application is doing? The application could be arbitarily making use of it in some ops and not others (although I can see that the developer may need to 'enable' the back buffer format if they feel their application would benefit from it, I'd just like some clarification).

 

[andypski]

this is whatI'm wondering - if the internal pipeline precision is at 128bit FP in the first place wouldn't an application be implicitly making use of it anyway, regardless of what the application is doing? The application could be arbitarily making use of it in some ops and not others (although I can see that the developer may need to 'enable' the back buffer format if they feel their application would benefit from it, I'd just like some clarification).

The application will be implicitly making use of the increased accuracy of the floating-point calculations within the pixel shader, however as soon as it forces an additional pass it will also be implicitly truncating the current calculation results to 8 bits of precision as they are written to the frame buffer.

 

[OpenGL guy]

Plus, you can even add mipmaps, which you cannot do with the 128 bpp format.

I've been informed that we can do mipmaps with 128 bit textures, sorry about the misinformation.

 

[fresh]

DemoCoder is correct. The backbuffer is 128bits, and the front buffer is 32 bits (10:10:10:2). Don't really need 128bits for the front buffer. On the PS2 we do something similar (32bit back buffer, 16bit front buffer).

 

[OpenGL guy]

DemoCoder is correct. The backbuffer is 128bits, and the front buffer is 32 bits (10:10:10:2). Don't really need 128bits for the front buffer. On the PS2 we do something similar (32bit back buffer, 16bit front buffer).

Sorry? Who supports a 128 bit BACK buffer? That would make any blending operation tremendously slow.

 

[KimB]

64-bit framebuffers are much more reasonable...I still don't believe there's any need for a 128-bit framebuffer, provided there are some optimizations to prevent error accumulation.

 

[MfA]

OpenGL guys ... what are you suggesting then? Not supporting blending for the 128 bit buffers but just replace? (Not that it matters much, you can always do the it in the pixel shader ... it wont be any faster there though, if using a 128 bit buffer is slow its slow period.)

BTW if 128 bit buffer as a render target is really so slow I hope theres support for 10:10:10:32 or at least a single channel 32 bit FP format ...

 

[OpenGL guy]

OpenGL guys ... what are you suggesting then? Not supporting blending for the 128 bit buffers but just replace? (Not that it matters much, you can always do the it in the pixel shader ... it wont be any faster there though, if using a 128 bit buffer is slow its slow period.)

If you were using a 128 bpp buffer in the pixel shader, you could do whatever you wanted with the data.

 

[fresh]

DemoCoder is correct. The backbuffer is 128bits, and the front buffer is 32 bits (10:10:10:2). Don't really need 128bits for the front buffer. On the PS2 we do something similar (32bit back buffer, 16bit front buffer).

Sorry? Who supports a 128 bit BACK buffer? That would make any blending operation tremendously slow.

I was under the (wrong?) impression that the R300 does. If it doesn't then that would certainly suck for multi pass algorithms.

 

[sireric]

Trying to add another piece of information: Aside from supporting the 128b texel format for writes and reads, the 9700 supports multiple 64b formats, including a c4_16 format where each component is a 16b fixed point value. The components are converted to float internally after reading. I believe that this is a very similar format to the 3D labs format.

The interesting thing about this format is that we support full filtering (including trilinear anisotropic), as well as 3D textures, projected 3D textures, etc... Of course, it does use up more bandwidth to fetch such a texture compared to a 32b per texel format.

FYI.

 

[hax]

I was under the (wrong?) impression that the R300 does. If it doesn't then that would certainly suck for multi pass algorithms.

You guys are getting all confused. The R300 supports 128-bit output to an offscreen buffer. It would not normally be used for a typical back buffer, read implying a swappable buffer (or a buffer in the flip chain) because those buffers typically take on the format of the primary surface/front buffer/display.

 

[hax]

BTW if 128 bit buffer as a render target is really so slow I hope theres support for 10:10:10:32 or at least a single channel 32 bit FP format ...

It would be noticeable on the bandwidth. Imagine a 1600x1200x128bpp surface. That's about 30MB of video memory.

 

[MfA]

Add to that 4X multisampling and we are at 120 MB Is multisampling&framebuffer-compression supported for all the formats too BTW?

 

[Dan G]

The interesting thing about this format is that we support full filtering (including trilinear anisotropic), as well as 3D textures, projected 3D textures, etc... Of course, it does use up more bandwidth to fetch such a texture compared to a 32b per texel format.

FYI.

That's interesting!

In particular, I find myself wondering: is the key to full conventional texture filtering functionality the 16-bit per component aspect, the integer component aspect, or a combination of both?

 

[sireric]

The interesting thing about this format is that we support full filtering (including trilinear anisotropic), as well as 3D textures, projected 3D textures, etc... Of course, it does use up more bandwidth to fetch such a texture compared to a 32b per texel format.

FYI.

That's interesting!

In particular, I find myself wondering: is the key to full conventional texture filtering functionality the 16-bit per component aspect, the integer component aspect, or a combination of both?

Mainly the integer aspect. Floating point interpolators are significantly more expensive from an area perspective. And given that we don't expect floating point textures to become pervasive in the near future (at least filtered ones), it was deemed too expensive a trade-off. One can always perform filtering in the shader, if it were really needed.

We also support a C4_16f format, with 16b floating point, but don't perform any filtering on them.