Hello,

I was wondering if XNA allows the programmer to control the double buffer of the pipeline. More concretely, are there functions to flush (and block for completion) the pipeline for a frame, and another for swapping the buffer, or is that a thing that XNA deeply encapsulates and the user does not have access to it?

I'm looking for something like the glFinish in OpenGL. SwapBuffers would belong to Windows API.

Thanks,
Francisco.

The Game class does a double-buffer flip when Game.Draw() returns.

If you are inside some processing, you can create your own frame, and display it. You start by calling GraphicsDevice.Clear(), and end by calling GraphicsDevice.Present().

To wait for the completion of a given rendering command, the easiest way is to issue a query that brackets the drawing (such as a depth fragments pass query), and then block for that query to complete.

This is where my mewbie attributes come up to surface eheh. Thanks for your reply and explanation.

I am having hard time to understand what is to issue a query... (newbie touch)

I was wondering if I could migrate a project of my own to XNA. The only requisite is to have a network sync barrier, right after the back buffer has been totally written, and just before the back and front buffer are swapped.

What i understood from the first approach is to do a clear, draw the meshes, do my stuff (which would be the barrier), and do Present: In this approach, the draw is a synchronous or asynchronous call (will it block or not until all primitives are effectively rendered)? On the other side, how lightweight is Present method (is it just a swap, or has it more hidden and significative overhead)?

The second approach, i haven't understood (my bad) :/

Packing up these questions in one: do you think that it is possible to synchronize the render in different computers (in a LAN) this way? In other ways? In any way?

I'm actually just looking for an expert opinion. If affirmative, I'll gladly dig into docs and specs to find out how.

Yours,
Francisco Pires

Francisco Pires:

I am having hard time to understand what is to issue a query...

http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.occlusionquery.aspx


But see below.

Francisco Pires:

I was wondering if I could migrate a project of my own to XNA. The only requisite is to have a network sync barrier, right after the back buffer has been totally written, and just before the back and front buffer are swapped.

Why do you need force this sync at all? That is not normally necessary (or a good idea) in DirectX - it's usually better to just call Present (or if you are using the XNA Framework Game class, let it call Present for you in the usual way after your Draw method returns) and then let the driver/runtime figure out the details.

I'm curious to understand why you think an explicit graphics pipeline flush would be needed?

Thanks for the reply and link! It was quite elucidative.

About the need to force a sync, it is not usual nor recommended in standalone applications. But this is for a multi-projective clustered environment (CAVE like system). In this scenario, it is crucial that all cluster nodes wait for each other completion, before buffer swap occurs, otherwise tearing effects will appear (this is called frame-lock).

Of course, I could try to develop a predictive algorithm, to find out how long each machine should wait before calling the Present method. This has two drawbacks: it is not straightforward to implement, and if some spatial organization or shaders are in place, the work load in each computer will be quite different (due to different number of geometry in each local viewport), and the algorithm will become unstable.

It is preferrable to have lower frame rates but guarantee that the swapping is done when all machines are ready for it.

I hope I was clear enough in my explanation :)

Cheers,
Francisco Pires

If you're doing genlocking, multi-pipe rendering or anything of the sort, you want to use the native C++ API, which has special features and bits for doing that sort of thing, which XNA and managed code does not expose. Additionally, you probably want to use hardware with explicit genlock support (QUadro FX 4600 etc). And, in the end, you may find that OpenGL extensions aimed towards this market make more sense than trying to do it on top of DirectX (although with Direct3D 10, DXGI and Vista, it's a lot better than it used to be!)

Also, when it comes to networking, the Xbox Live! networking that's built into XNA (and is the only networking you can do on an Xbox through XNA) is not precise or low-latency enough to be used as a frame flip signal. In general, trying to do a CAVE with XNA Game Studio sounds like a project destined for mediocrity to me.

In fact, the (concluded) project is built on OpenGL using C++. I was wondering a port to .NET, and particularly to XNA for educational purposes, not that i was really expecting to reach real-time perfomance in mid-sized scenarios (maybe with models, and that would be quite pleasing by itselt).

There is also some richness in the .NET framework that would allow me to be creative in the implementation of the whole configuration and authoring of the environment and the scene. And I confess that I would have to try it in Xbox, but with low expectations :)

Having said that, no project can be mediocre ;)

Anyway, I suppose that there is no way to stop the application right before the buffer swap, is there? Reminding of one of the first suggestions, is there any query class for color buffer completion?

Regards,
Francisco Pires

The only query class in the XNA Framework is for depth buffer occlusion. To force a CPU/GPU sync, you have a couple of options:

• Block the CPU until an OcclusionQuery completes
• GetData on a rendertarget immediately after drawing to it

Whether these things will help for your scenario, I have no idea. They will certainly have a negative impact on your framerate! I'd be inclined to try this both with and without an explicit stall, to find out what happens if you just synchronize your CPU code via the network traffic and let the GPU flip fall wherever it may. That might look terrible, but I have a feeling it might also not turn out as bad as you expect (it's likely to work much better if you have the same GPU and driver in all your machines). I'd certainly be interested to hear what you find out if you try this!

It won't be hard to set up a prototype, for testing your proposed techniques. As soon as I have some feedback to give, I'll post back. Thanks for the tips and interest :)

Cheers,
Francisco Pires

To hold the current thread, just sit tight in a while(true) loop.

volatile int currentNetworkPacket;
volatile int expectedNetworkPacket;

while (currentNetworkPacket < expectedNetworkPacket)
  /* do nothing */;
++expectedNetworkPacket;

This is assuming that the network receive runs on another thread, and will increment currentNetworkPacket on a regular basis. Also, you can't run Live! networking on another thread (on your own), so you can only do this on Windows, using System.Net or similar code.

And, yes, a lot of projects can be mediocre. It's been my experience that most projects are, even if they are "declared" a "success." Sometimes, such "successes" are worse than failure...

Yes a lot of projects can be mediocre. But all depends on the expectations and intent. And I don't do my living on CG, it's just an hobby and a learning opportunity. I don't understand why you insist in tagging a project you don't know the purposes as mediocre. I'll just consider that you're defending XNA by forwarding its limitations to the project's relevance. At least I hope so...

Two notes about the code snippet you sent. I don't want to block the thread, but the graphics pipeline, just before swapping buffers.

/* Do nothing */ would be a tremendous performance killer. Most likely I would block on socket receive, or at least put a Sleep(0) inside the cicle, or even use an event infrastructure to handle the barrier. And more, that approach would only work in 2-node cluster. Barriers for more nodes require other algorithms.

but thanks for the whole criticism ;)

We already suggested how to block the graphics pipe: create a z buffer query, and then block on that query. That will make sure the graphics pipeline is finished up to the query finish state.
To then block before flipping the buffer, you have to block the thread that will be calling Present(). There is no other way around it.
If you're using native synchronization primitives for blocking, then you may run into some unfortunate effects of the Windows scheduler, which really isn't intended for "soft real-time" usage. A spinloop allows for much better timing, assuming the pre-emption quantum gets re-set when you actually go on to Present() (which is not guaranteed, btw).
Regarding warning about mediocrity: If you're just playing around, then you can do all this, and it'll probably almost work. I just wouldn't want to show up at a customer's site, finding a system built out of XNA and intended to do multi-pipe rendering, and then be told "it almost works, now your job is to make it really work," because to make it "really work" I'd likely have to start over from scratch using tools intended for the job. It's a difference of expectations, and a warning to people other than you who may be reading this thread, and may draw poor conclusions without a proper warning.

I was wondering if I could migrate a project of my own to XNA.

Why migrate a project to XNA? If you managed to code something using OpenGL or DirectX without XNA, you've achieved a good thing. Not using XNA is superior to using XNA. XNA is only for beginners who don't know how to handle windows, how to handle keyboard/mouse input, how to load/display bitmaps,... and therefore need assistance. Or have I misunderstood something?

Aura4:

Or have I misunderstood something?

Yes, I rather think you have. Such as the ability to deploy to 360 without paying an arm and a leg, rapid concept prototyping, managed code, Live Networking API, Content Pipeline...

Every technology has a content pipeline of some sort. The XNA build part is pretty good, as such things go, but the fact that animation is an add-on, that they don't address physics at all, and that you're on your own for the DCC tool exporters weigh it down compared to some other offerings (say, Panda3D, or the commercial options). Similarly, most technologies have some rapid prototyping set-up, dynamic language bindings, etc. The only thing that really keeps me with XNA is the ability to deploy to the 360 for a mere $99/year. That's its one unassailable, bedrock-anchored strength that nobody else can touch!