next »

[Crimsontide]

In Direct3D9 (I'm assuming for 10 and 11 as well, though I haven't looked at em much yet), as you all know, all scene drawing has to be enclosed between a pair of calls to Begin and End.  After that has occured you call Present to show the scene.  Now I understand the idea behind it: Begin/End signal to the driver to start drawing, as well as a way of grouping or blocking commands for a single frame.  Present simply flips the backbuffer.

The thing is, is there ever a situation where you would use multiple Begin/End blocks for a single Present (or vice-versa), or a situation where you might delay a Present a while after End is called?

To put it another way.  What advantages does having a separate End function give?  What would be lost if End/Present were rolled into a single function?  Why have an End?  Why not just Begin/Present (or why have a Present, and not just have Begin/End)?

[Mikademus]

In Direct3D9 (I'm assuming for 10 and 11 as well, though I haven't looked at em much yet), as you all know, all scene drawing has to be enclosed between a pair of calls to Begin and End.  After that has occured you call Present to show the scene.  Now I understand the idea behind it: Begin/End signal to the driver to start drawing, as well as a way of grouping or blocking commands for a single frame.  Present simply flips the backbuffer.

The thing is, is there ever a situation where you would use multiple Begin/End blocks for a single Present (or vice-versa), or a situation where you might delay a Present a while after End is called?

To put it another way.  What advantages does having a separate End function give?  What would be lost if End/Present were rolled into a single function?  Why have an End?  Why not just Begin/Present (or why have a Present, and not just have Begin/End)?

It has been a while since I last coded pure D3D (I now exclusively use middleware renderers) but afairecall using multiple or nested begin/ends is vehemently discouraged.

[Skofo]

In Direct3D

HERESY!

[Crimsontide]

In Direct3D

HERESY!

You know of anything better?  Both DirectX and OpenGL are a complete mess.

[J. Kyle Pittman]

If I'm not mistaken, you have to call BeginScene() and EndScene() for each render target that you want to draw to.  Or more specifically, I believe you can't call SetRenderTarget() within a BeginScene()/EndScene() pair.  So if you're only ever drawing to the backbuffer, you can safely wrap EndScene() and Present() into a single call.  But if you're drawing to multiple render targets, you'll need to call BeginScene() and EndScene() before and after writing to each target, and you'll only want to Present() once at the very end.

Edit: Apparently I am mistaken.  I just found this post which suggests that you only need to call BeginScene() and EndScene() when changing the backbuffer, not when switching to additional render target textures.  Looks like I'll be refactoring my renderer tonight....  

Edit edit: And here it is from MSDN (http://msdn.microsoft.com/en-us/library/ee421698%28VS.85%29.aspx) (emphasis mine):

There should be at most one IDirect3DDevice9::BeginScene/IDirect3DDevice9::EndScene pair between any successive calls to present  (either IDirect3DDevice9::Present or IDirect3DSwapChain9::Present). IDirect3DDevice9::BeginScene should be called once before any rendering is performed, and IDirect3DDevice9::EndScene should be called once after all rendering for a frame has been submitted to the runtime. To enable maximal parallelism between the CPU and the graphics accelerator, it is advantageous to call IDirect3DDevice9::EndScene as far ahead of calling present as possible.

I'll definitely be doing some refactoring tonight.

[Crimsontide]

Ya I remember that quote directly, and what baffles me both now (and at the time) is that I can't think of a single situation where you wouldn't call Present immedietly after End.  I mean even if ur rendering to multiple backbuffers, you'd Begin/End/Present the 1st and then Begin/End/Present the 2nd.

I'm all up for waiting as long as possible, but during that wait, what else would I be doing?

[J. Kyle Pittman]

Yeah, I got nothing.  Seems like you would always want to do those back-to-back.

[Crimsontide]

Ok here's another one.

Direct3D9 has a render state D3DRS_STENCILREF, that has apparently disappeared in D3D11.  Anyone know what it did and why it has disappeared?

[J. Kyle Pittman]

Going back to the EndScene/Present discussion, I suppose you could Present the previous frame at the start of your render step, then BeginScene/draw stuff/EndScene.  So then on the next frame, you'd be running your game logic while the GPU was handling the draw calls from the current frame.  You might incur a one-frame latency cost, but it could also decrease your frame time by not bottlenecking the CPU on the Present call immediately after drawing.

I'll probably give this a try tonight and see what sort of results I get.

[David Pittman]

My understanding of that is that Present blocks until the GPU is done, so you're just wasting CPU cycles if you call it back to back with EndScene.

I once tried to change things up so I called Present just before BeginScene instead of just after EndScene. It caused problems on the first frame (obviously, and would have been easy to fix) but also didn't noticeably improve performance. Perhaps I'm just too CPU-bound for it to matter.

[Zaphos]

Ok here's another one.

Direct3D9 has a render state D3DRS_STENCILREF, that has apparently disappeared in D3D11.  Anyone know what it did and why it has disappeared?

I don't know about the D3D11 part of this, but you can still look up the docs for D3D9 stuff, so the "what it did" part is easy to google.

D3DRS_STENCILFUNC
    Comparison function for the stencil test. Values are from the D3DCMPFUNC enumerated type. The default value is D3DCMP_ALWAYS.
    The comparison function is used to compare the reference value to a stencil buffer entry. This comparison applies only to the bits in the reference value and stencil buffer entry that are set in the stencil mask (set by the D3DRS_STENCILMASK render state). If TRUE, the stencil test passes.
D3DRS_STENCILREF
    An int reference value for the stencil test. The default value is 0.

[Will Vale]

I think BeginScene/EndScene were added originally to support cards doing tiled rendering, where the command buffer for the scene needs to be captured in its entirety and then replayed across multiple tiles to produce the image. The PowerVR used to do this, and there's a reasonable chance that this style of hardware is coming back - see Larrabee.

They're probably also useful for drivers to hook in to do certain kinds of command buffer processing, such as replaying the command buffer twice for doing 3D, etc. etc. I'd be happier if MS exposed the CPU/command buffer/GPU interaction more, like we see on consoles, but I don't know if this is really going to happen. Shame really, it's an awesome programming paradigm.

You'll find yourself needing to call EndScene prematurely in current DX9 apps if you need to use StretchRect. This is important for doing MSAA resolves, buffer save and restore, etc. I've use this a lot in CAD software, only a little in games.

HTH,

Will

[Golds]

Ok here's another one.

Direct3D9 has a render state D3DRS_STENCILREF, that has apparently disappeared in D3D11.  Anyone know what it did and why it has disappeared?

i'm an opengl guy, but my guess is that the stencil buffer has been done away with the intent of doing all those sorts of effects with your own pixel shaders.  Is immediate mode even supported in D3D11?

[Crimsontide]

Ehh.. haven't looked into D3D11 much.  My general understanding is that it is generally immediate with the option of doing retained-like with the use of command lists and such.  TBH command lists seem kinda silly to me.  I can't see many a situations where pre-recoding a command list on one thread, then playing it back on another makes alot of sense.  I guess if they were pre-stored in some sort of fast/shared memory and u could 'replay' them multiple times this might alleviate some bus traffic.  Seems like alot of work though.

As far as stencil buffers go, everything else in D3D9 (stencil wise) maps pretty much 1:1 to D3D11.  Its just been cleaned up a little bit (which is nice).  Except I couldn't find any mention of an equivalent of D3DRS_STENCILREF.

[Zaphos]

Ok here's another one.

Direct3D9 has a render state D3DRS_STENCILREF, that has apparently disappeared in D3D11.  Anyone know what it did and why it has disappeared?

i'm an opengl guy, but my guess is that the stencil buffer has been done away with the intent of doing all those sorts of effects with your own pixel shaders.  Is immediate mode even supported in D3D11?

Did you mean: "is fixed function even supported"?  Immediate mode vs retained mode was an older issue, and retained mode was discontinued ...