Problems with SurfaceFormat.Bgra1010102 on the XBOX360

If I have the above line right after I create my GraphicsDeviceManager, anything I render to the screen comes out as total garbage in terms of color values *except* while one of the 360's panels (or whatever they're called - the ones the big X button brings up) is rendering. In that case everything renders fine.

Simple example, I render out a farily heavily tessellated quad who's verts range from -32 to +32 in world space (in both X and Z directions, Y = 0). My vertex shader passes abs( worldPos.xz ) into the pixel shader as a texture coordinate and the pixel shader returns float4( frac( texCoord ), 0, 1 ).

I expect this to give me a repeating pattern of squares that range from black in one corner to yellow in the opposite corner, mirrored about the X and Z axis. If I leave the surface format at it's default value, I get exactly that. If I set it to 1010102 then the it shades the right pixels but it fills them with the wrong values and I get pretty much random colors - though if I bring up a panel it renders as it should in the background.

I've tried setting a breakpoint on my DrawIndexedPrimitives call and comparing render states through the debugger but I just can't figure out what the difference is between the panel being up and it being hidden. I'm guessing the difference is hidden somewhere inside of wherever it is that XNA stuck Present (or whatever it's 360 equivalent is).

Do I need to create an explicit render target and resolve that to the backbuffer myself (which is what I suspect the crazy side panel drawing code does to the backbuffer) or am I just missing a flag somewhere

Standard 800x600 (alas, no HD for me...yet).

I don't even set it explicitely, I just let the GraphicsDeviceManager do it for me. The only things I set on it are minimum shader versions (from when I was still targeting this at PC) and the preferred depth/stencil format to Depth24Stencil8 (since I'll be using the stencil at some point) though the random example I posted above has same the problem with or without those lines.

It's odd because it's basically behaving as though it's treating the 1010102 data as 8888, or maybe it's secretly writing 8888 and then thinking it's 1010102 - one of the two, I really don't know which and don't care...it should work or there should be an error telling me what I'm doing wrong...right

Simplest repro case there is:

Create a blank XBOX 360 project. In the Draw call, change the clear color to Color.Green. Run it. Note the color. Change the Game1 constructor to read as follows:

graphics = new GraphicsDeviceManager( this );

graphics.PreferredBackBufferFormat = SurfaceFormat.Bgra1010102;

content = new ContentManager( Services );

Run that and note the color again - it's different. Press the XBOX guide button and note how the shade changes.

If you want it to be really obvious then try rendering a model as well. Almost any model will do - I copied p2_rocket.x in from the Space Wars sample and copy-pasted in the code from "How To: Render a Model" in the XNA documentation (minus the position/rotation thing - I was too lazy and only kept the bone matrix part of the world transform).

According to the debugger my device's PresentationParameters have BackBufferFormat set to Bgra1010102, BackBufferWidth set to 800 and BackBufferHeight set to 600. These values are correctly reflected by the size values in both the DepthStencilBuffer and the Viewport.

It's not really a big deal at this point since I've already changed my code to render into a separate 1010102 buffer and then render from that buffer into the actual (now Bgr32) back buffer with a pixel shader that does some other cool stuff...I just wonder why this doesn't work out of the box or at least throw an exception or something.

I've already changed my code to render into a separate 1010102 buffer

Are you really sure you get Bgra1010102 Because it is the preferred backbuffer format. Doesn't mean you'll always get what you prefer. Do a Debug.WriteLine on GraphicsDevice.PresentationParameters.BackBufferFormat and make sure. If I do Bgra1010102 on Windows I will end up getting Bgr32 instead.

When I set it on a rendertarget it doesn't work at all, which is really strange since my d3dcapsviewer says my card should be able to do it. But It could be something with multi monitor setup or something.

That was the first thing I checked, and yes, the GraphicsDevice's PresentationPrameters.BackBufferFormat was being set to Bgra1010102 on the XBOX (unless both the debugger and Debug.WriteLine are outright lying to me...but I somehow doubt that).

As for my new render target I'm pretty sure it's 1010102. I tried setting it down to an 888 format and I got visible banding (which is what you'd expect from a lower-precision format), and just to be sure I wasn't getting some random float format I did a GetData on my render target into an array of byte and checked the values and they are consistent with a 1010102 format (and definitely aren't float or 888 values). So 1010102 is fine as a render target and it's also fine as a texture source (again, if it did a hidden conversion to 888 at any point I'd see banding, which I don't).

I took another look at having a 1010102 framebuffer and as far as I can tell the GPU renders into it correctly, but the video out hardware then goes and reads it as though it's an 888 format. It works when a guide is up since the guide code is (or as far as I can tell, must be) binding my framebuffer as a texture (which works OK) and using it to render into the real framebuffer in 888 format. Either 1010102 needs to stop being a valid framebuffer format (but continue to be valid for render targets) or someone needs to tell the video out hardware what format it's actually reading. Unless I'm just being an idiot and forgetting to set a flag on something...

Anyone from MSFT wanna tell me if it's my code that's the issue, or if I need to go post a bug on the Connect site