Re: Call ::EndScene as far ahead of calling ::Present

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

[Please do not mail me a copy of your followup]

=?Utf-8?B?TGliX3RlYW0=?= <Libteam@xxxxxxxxxxxxxxxxxxxxxxxxx> spake the secret code
<67FC6863-166F-4383-9ADE-C938A5AC8335@xxxxxxxxxxxxx> thusly:

So, is that wrong to say that the sentense "Call ::EndScene as far ahead of
calling ::Present" does not make sense when ::Present does not wait for GPU
rendering completion ?

It doesn't really make sense to me; see Robert's reply to your original post.

D3D methods generaly enqueue commands which are streamed to the
hardware by the driver.

It sounds like you think that Present is a synchronous, i.e. blocking,
call. Present doesn't really work this way, it essentially just queues
a command, like other methods on the device. However, the D3D runtime
will not allow your application to get too far ahead of the GPU. If
the GPU doesn't process the commands fast enough, eventually your
application will block when you call Present. You're blocked because
the GPU is busy. EndScene may or may not do anything on a card and
doesn't really enter into why Present might block the application. In
the case where the GPU is busy and your application is too far ahead
(I think its 2 frames), calling Present with the "do not wait" flag
can return to the application right away with an HRESULT return value
that says "I'm still drawing". Then your application can do other
things before trying to call Present again, like processing network
I/O.

So, back to my suggestion of doing the "simplest thing that could
possibly work", which implies no use of the "do not wait" flag and
just letting Present block until the GPU is ready to render again.
Unless you a) have really complex frames that are difficult for the
GPU to swallow, or b) you are generating frames really fast, so that
you are limited by vertical refresh, you're not going to see anything
useful coming from using the do not wait flag. In those two cases,
even if you did use the flag, you couldn't do anything useful anyway.
In case a) your frame's scene is already choking the GPU - sending
the next frame to the GPU faster won't help. In case b) you're
already rendering frames faster than 60-80 Hz, so its not taking you
much time to render frames and having more time just means you're
going to render more frames and get back "was still drawing" because
you can't get the GPU to go faster than the VSYNC.

I generally don't recommend turning off VSYNC.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Pilgrimage 2006, Saturday September 23rd: <http://pilgrimage.scene.org>
North America's Longest Running Demoparty
.

Relevant Pages

  • Re: GPU Volume Rendering Slow
    ... and we need to support weaker cards. ... dataset (it fits in video memory, ... How many view aligned quads do you render? ... badwidth between the GPU and the rest of the PC's core. ...
    (comp.graphics.algorithms)
  • Re: Why do commercial DVDs look so much cleaner?
    ... Since a computrs GPU scales far better for repetitive tasks like ... large ramps in encoding speed. ... which you'd normally be using to render ...
    (rec.video.production)
  • [Moving from OGL to DX] Instancing, interpolation and subsets
    ... 1)HW Instancing and D3DMesh ... "I must render, let's say, a tree model loaded from a X file (2 ... 2)Frame interpolation ... I am still a bit puzzled about multiple frames in X files and how to ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: farming out a render?
    ... I had done some research when I was bidding on a large render project ... impressive though, i could render 10,000 frames, make one hell of an edit ... I really should try get my head round screamernet tooo, ...
    (comp.graphics.apps.lightwave)
  • Re: Compressed textures
    ... I was previously considering writing a texture in parallel with begin,end,present and as I understand you, that would have improved things. ... so the driver is always free to choose to ignore the discard-locking-mode. ... I assume present will block when the gpu rendering falls two frames behind? ... I understand the above as that I can not render ahead when I change the object in between render calls. ...
    (microsoft.public.win32.programmer.directx.graphics)