Quick render target Qs

[Graham]

A couple of quick questions I can't find answers to (try as I might...)

First,
is there any hardware out there that supports the equivalent of an rg88 16bit render target format? My x1800 doesn't seem to... Does xenos?

And does xenos support mixed bitdepth render targets in MRT? (curious)

I'm pretty sure Jawed answered both of these in the past, but for the life of me I can't find the posts in question.

Cheers.

 

[Jawed]

Perhaps you're thinking of this:

http://www.beyond3d.com/forum/showthread.php?p=716900

The Radeon X1x00 Programming Guide (which comes as part of the ATI SDK) indicates the following renderable 16-bit formats:

R5G6B5
A4R4G4B4

R16 floating point

Up to four simultaneous color render targets are supported with a single z-buffer. Each target can have independent blend functions and write masks. The x- and y-dimensions of all targets must be identical, but the bit depths can vary. Multiple render targets also support alpha test but only on the value written to the first target.

I have to admit, I really dunno how anyone is supposed to take advantage of all that Xenos goodness when forced to program it on PC. ARGH.

Jawed

 

[Graham]

Righteo thanks for the quick reply

I'm thinking about different ways to write/store normals in a deferred render, and was thinking normalised 8bit XY would work, because the texture sampler can apparently compute the Z for you... But ohh well. (it was going to work out just under 10mb for 1280x720 too...). 565 normals don't look so flash unfortunately.

 

[Jawed]

I found the notes for Xenos texture formats:

The following texture formats are supported:

• 8, 8:8, 8:8:8:8
• 1:5:5:5, 5:6:5, 6:5:5, 4:4:4:4
• 10:11:11, 11:11:10, 2:10:10:10
• 16-bit per component fixed point (one-, two-, and four-component)
• 32-bit per component fixed point (one-, two-, and four-component)
• 16-bit per component floating point (limited filtering)
• 32-bit per component floating point (no filtering)
• DXT1, DXT2, DXT3, DXT4, DXT5
• 24:8 fixed point (matches z-buffer format)
• 24:8 floating point (matches z-buffer format)
• New compressed formats for normal maps, luminance, and so on, as described following

Fetching up to 32-bit deep textures runs at full speed (one bilinear cycle), fetching 64-bit deep textures runs at half-speed, and fetching 128-bit deep textures runs at quarter speed. A special fast mode exists that allows four-component, 32-bit-per-component floating-point textures to be fetched at half-speed rather than quarter-speed. The packed 32-bit formats (10:11:11, 11:11:10, 2:10:10:10) are expanded to 16 bits per component when filtered so they run at half speed. Separate nonfilterable versions of these formats exist that run at full speed.

When filtering 16-bit per component floating-point textures, each 16-bit value is expanded to a 16.16 fixed-point value and filtered, potentially clamping the range of the values. The total size of the expanded values determines at which rate the sampling operates (full speed for one-component sampling, half speed for two-component sampling, and quarter speed for four-component sampling). Separate nonfilterable 16-bit-per-component floating-point formats also exist.

DXT1 compressed textures are expanded to 32 bits per pixel, resulting in a significant improvement in quality over the expansion to 16 bits per pixel that existed on Xbox.

The following new compressed texture formats are available:

• DXN—a two-component 8-bit-per-pixel format made up of two DXT4/5 alpha blocks
• DXT3A—a single-component 4-bit-per-pixel format made up of a DXT2/3 alpha block
• DXT5A—a single-component 4-bit-per-pixel format made up of a DXT4/5 alpha block
• CTX1—a two-component 4-bit-per-pixel format similar to DXT1 but with 8:8 colors instead of 5:6:5 colors
• DXT3A_AS_1_1_1_1—a four-component format encoded in a DXT2/3 alpha block where each bit is expanded into a separate channel

The texture formats with eight or fewer bits per component, including the compressed texture formats, can be gamma corrected using an approximation to the sRGB gamma 2.2 curve to convert from gamma space to linear light space. This correction happens for free and is applied to sampled data prior to any texture filtering.

A special type of texture fetch can index into a texture “stack” that is up to 64 textures deep. A texture stack is a set of 2D textures (potentially with mipmaps) that are stored contiguously in memory.

Jawed

 

[Jawed]

And there's Memexport, but I suppose you have no way to program it.

One of the most revolutionary aspects of the Xbox 360 GPU is the ability for shaders to write data to main memory at arbitrary, programmable offsets. This export to memory can be used in place of or in addition to the normal shader outputs. One caveat is that source/destination coherency is not automatically maintained. In other words, a write to a memory location is not automatically guaranteed to complete before a read from the same location by another vertex or pixel. Coherency can be enforced between primitives by placing synchronization commands in the command buffer.

The following export formats are supported:

• 8, 8:8, 8:8:8:8
• 1:5:5:5, 5:6:5, 6:5:5, 4:4:4:4
• 10:11:11, 11:11:10, 2:10:10:10
• 16-bit per component fixed point (one-, two-, and four-component)
• 32-bit per component fixed point (one-, two-, and four-component)
• 16-bit per component floating point (one-, two-, and four-component)
• 32-bit per component floating point (one-, two-, and four-component)

A typical scenario for shader memory export is to process vertices that are going to be used multiple times in different rendering passes. For example, if a skinned mesh is going to be processed multiple times (for a z-prepass or shadowing), it is more efficient to skin the mesh once and export the skinned data to a memory buffer that is used in subsequent rendering passes than to skin the mesh in each rendering pass.

Jawed

 

[Graham]

This is odd..

I just dug this up in the MSDN 360 device cap page:

SupportsMultipleRenderTargetsIndependentBitDepths false

http://msdn2.microsoft.com/en-us/library/bb313967.aspx

It also says it lacks support for auto mipmap generation, which is a bummer.
Maybe it's an XNA limitation (*shock horror*)


*unrelated

Does anyone know what you need to compile a shader with the XPS_3_0 or XVS_3_0 profiles?

 

[akira888]

Concerning automated mipmap generation and XNA, here's a post on MSDN explaining MS's (not entirely satisfying) position from an XNA Framework developer.