   [XNA] Xbox 360 porting question
  Hey, I've been porting over my teams Imagine Cup entry over tot he Xbox 360 and I ran into a strange problem when it came to rendering the depth to as texture.Leaving the depth render target format as "Single" I get this result:Changing the format to "Color" (The same as the backbuffer) yields the correct result:I've been trying to figure out what's going wrong here for a while and I just can't figure it. This has had the effect of making my shadows stop working due to (I'm assuming, I haven't looked into it properly yet) the precision issues of this render target format.Has anyone experienced this when running on the Xbox 360? It works fine in Windows.   
I don't have much experience with running XNA on the 360 but this staple answer generally seems to be helpful [smile]Quote:Make sure you don't alpha blend when you draw to this texture, and that you are point sampling when you read from it. Xbox can't do filtering on float textures.;  Thanks for the tip. Where did you find it?I can't test it out right now but as soon as I get back into the labs tomorrow I'll give it a shot.Does it matter if I'm not actually doing any alpha blending? I just need the render state disabled, right?   ;Quote:Thanks for the tip. Where did you find it?Over here on the XNA Forums, it's by Shawn Hargreaves. We ran into some issues with using floating point formats on the 360 too and this proved to be the problem; especially using linear instead of point filtering is easily overlooked.Quote:Does it matter if I'm not actually doing any alpha blending? I just need the render state disabled, right?I'm not 100% sure, but I think that's the case yep. Regardless of what you're actually doing, the renderstate already would be causing blending, which gives bad results.;  A follow up question: It seems switching render targets is rather slow on the Xbox. Switching between the various buffers I've got for the game effects causes intermittent stutters. Would using MRT be a more efficient way? If so, why? Surely all the buffers still need to be moved to and from the eDRAM which is, I'm assuming, why switching render targets is slow anyway.   ;You got me there... I'll venture an answer but unfortunately I don't have any hands on experience with this. Hopefully MJP will chip in since he's the resident XBox Optimizer [smile]I'm going on a little project on the 360 that involved some GPGPU operations that are making upwards of 40 render target switches per frame and still render with a good framerate. So it would seem that render target switches on the 360 aren't inherently slow. For the rest I have to go on what I've read. The catch seems to be that render targets get fit into this thing called the EDRAM buffer, which is blazingly fast but only 10MB in size. This becomes a problem when your render targets are either too large or too 'wide' (many bytes per pixel) to fit into this 10MB buffer. This is transparently fixed by something called predicate tiling, but I seem to recall reading some posts that this should be avoided like the plague because it causes performance issues. That's not very scientific nor do I have any links to MS posts confirming this, but in general the advice seems to be to pick your RTs so that they (and the accompanying Depth/Stencil buffer) fit the 10MB limit.;  Hmm, I thought that might be the problem. It's gonna be tricky trying to fit all of the buffers into that 10MB. Even having a 1280x720 back buffer with a depth buffer seems like it'd be too big to fit in there. =/I'll wait to see if anyone else has any advice first though!   ;  To be honest, I haven't noticed much of a performance impact with tiling.  It probably depends on what kind/how much data you're passing in your draw calls, and where your bottleneck is, but I did a test recently for a fairly complex rendering pass, and noticed very little difference when tiling was happening vs when it was not.For your performance issue, make sure you are *not* setting RenderTargetUsage.PreserveContents.  That is slow on the xbox.  Other than that, not sure what's wrong - I haven't noticed any particular problem with lots of rendertarget switches on the xbox.  It does need to copy the data out of EDRAM, but it seems to be fairly quick.   ;  I've made sure to create the targets with PlatformContents set. I have 3 buffers, the colour, the depth seen from the game camera and the depth seen from the directional light. So I need to perform 3 passes on the geometry to get those buffers filled then one final post-process pass that uses that data.It just seemed that, in my tests, disabling all passes but the main colour one certainly seemed to clear up the stuttering.   ;  So I have disabled all render target switches, I'm only rendering the "colour buffer". I have disabled texture switching and I'm only using a single shader to perform basic lighting. The stutter persists (Though far less intense but I feel this is not due directly related to the setting of render targets).I'm sorting the renderables by model and then by texture. The only thing I can think that might possibly be bottle necking this system is that I'm not grouping all of the primitives that use the same texture into a single DrawPrimitive call. I could attempt to do instancing using a 3rd vertex stream (I'm using the first two for keyframe data) to hold the world transformations for each individual renderable to render them all in one batch. Does this sound like a useful thing to do?EDIT: I'm guessing that it's not possible to only provide the part vertices/indices once and create multiple instances of them on the GPU on the 360 without geometry shaders?   