I was hoping somebody could clear up a few queries I have.

I understand that render targets and depth stencil buffers are held in shared EDRAM on the 360. From the docs and what people have said It is pretty clear that when changing a render target, the current render target is lost (in terms of its content).

What is not clear is if everything in EDRAM is lost.

1) Does changing a render target also invalidate the current depth stencil?
2) Does changing a depth stencil invalidate the previous depth stencil (like render targets)

It would be nice to know what actually happends to these render targets when they are not set any more, and what resolve actually does. Does it force a memory copy and then automatically restore it back for you when you set the render target again? If so can this apply to the backbuffer too?

Yes to both 1 and 2: any change invalidates everything.

In the 1.0 Framework, rendertargets are quite simply gone when they are not set any more. The shared EDRAM is being used for something else, so the rendertarget quite literally does not exist in any sense that the GPU would recognise. If you resolved it before unsetting, the data has been copied into a texture, and is still available in that texture, but the texture is a separate thing to the rendertarget. The behavior is literally "copy from EDRAM into a regular texture, then wipe the contents of EDRAM and reuse it for some other object".

In 2.0, the default behavior is the same, but you have a new option to restore the contents of EDRAM when you set the rendertarget back again. That can sometimes be convenient, but isn't free (it causes a lot of extra copying around of data), hence it is off by default and I don't think we're using that option in any of our samples or starter kits. It will always be more efficient to structure your drawing code so it can work with the default discard behavior, rather than asking us to restore the buffer contents for you.

Shawn Hargreaves:

any change invalidates everything.

I thought that would be the case. It just makes managing things a little more difficult.

Imagine a situation where you are drawing a reflective and refractive surface mid frame (like water). This involves switching the render target and drawing a couple of times.

The only way I can think of recovering from this situation on the 360 would be:

Resolving the backbuffer/current render target to a texture before switching render targets.
Render to new render targets (may even have their own depthstencil due to the size >= rt limitation).
Resolve the new render targets.
Set target and depth stencil back to original.
Clear target and depth stencil. (Is this really needed?)
Render the backbuffer on a quad to restore color data.
Render scene again up to this item with color writes disabled to restore depth stencil data.

The last step can be avoided by sorting the draw order so that we dont care about the depth stencil any more (i.e last), it ust makes it rather inflexible.

You can almost always rejig things like that to avoid needing to switch buffers mid-scene, though. Instead of:

• Draw first part of scene
• Draw shadow map
• Draw shadowed object
  
• Draw reflection image to rendertarget
• Draw water
• Draw remainder of scene

You can reorder this to:

• Draw shadow map
  
• Draw reflection image to rendertarget
• Draw first part of scene
• Draw shadowed object
  
• Draw water
• Draw remainder of scene
  

That can actually give you a nice performance boost on Windows, too. Although Windows drivers will make both orderings work identically, they often have to do internal work to make the first order function correctly, and can loose performance benfits like compressed Z data in the process.

Related to this...

If changing the rendertarget invalidates the depth buffer, this means that there are some cases where we cannot take advantage of doing a Z-pass before anything else, right?

Like if I wanted to make a deffered engine on the 360, I'd need several passes for this (position, normal, velocity, etc). But now I cannot take advantage of reducing work by having a Z-pass before anything, since the depth buffer is lost after each pass.

Indeed, both deffered rendering and an early Z-pass have the same objective: reducing the number of pixels on which we apply complex shaders, so a Z-pass may not be very interesting in combination with deffered redering. But for the sake of argument: is there a way to get around this?

Catalin Zima:

But for the sake of argument: is there a way to get around this?

Multiple rendertargets. You shouldn't need more than one pass for the deferred rendering.

Yes, but I thought MRTs were not supported on the 360.

Will they be in 2.0?

I just want to double check something.

You said "any change invalidates everything". Does this include the backbuffer and depth stencil created when creating the device. By that I mean if I render to a render target, does the original backbuffer/depth stencil become invalidated?

Catalin Zima:

Yes, but I thought MRTs were not supported on the 360.

Will they be in 2.0?

Yes.

Michael Coles:

I just want to double check something.

You said "any change invalidates everything". Does this include the backbuffer and depth stencil created when creating the device. By that I mean if I render to a render target, does the original backbuffer/depth stencil become invalidated?

Yes. There's nothing special about the default backbuffer and depth stencil: they are just rendertargets like any other, except they happen to be automatically created for you, and the default backbuffer is activated by setting null rather than an explicit object.

They have the same discard and restore semantics as any manually created buffers.

Shawn Hargreaves:

Catalin Zima:

Yes, but I thought MRTs were not supported on the 360.Will they be in 2.0?

Yes.

Cool :) One more reason to impatiently wait for it.