Re: GetRenderTargetData() issues


"Murrgon" <murrgon@xxxxxxxxxxx> wrote in message news:ep6%23c2FdGHA.3712@xxxxxxxxxxxxxxxxxxxxxxx
From everything I have read, before GetRenderTargetData() can actually
do the copy, all pending operations on the device *must* be completed
before hand. Thus you are going to introduce this huge wait while
everything finishes before it will copy the data for you.

There is no reason for GetRenderTargetData() no to be put in the queue.
Exactly for the same reason that Present() doesn't wait for anything, its just placed in the queue.


The call to GRTD(), in my case, takes a lot longer than the call to
lock the resultant texture. I don't see how the lock could possibly
take longer, as you are locking a *system memory* surface, which is
generally pretty fast.

Simply because GetRenderTargetData() doesn't need CPU synchronization.
But lock() does, and so will block for the surface to be ready.
And when is the surface ready? When the source and destination surface queue is empty.

I'm not saying the driver you are benchmarking does this, clearly it does not.
But what you believe need to happen is actually a driver design bug.

What driver are you testing with ?

Stephan


Stephan Schaem wrote:
It should not stall.
What should stall is the lock of the system surface to access the result of GetRTData()

Stephan

"Murrgon" <murrgon@xxxxxxxxxxx> wrote in message news:eirHFREdGHA.1276@xxxxxxxxxxxxxxxxxxxxxxx
Are there any rules or tips about using GetRenderTargetData()
in the most optimal way? I realize it stalls the pipeline,
but I'm wondering if there are better times to call it than
others. I have seen some code on the net that uses an
IDirect3DQuery9 to force a flush before calling
GetRenderTargetData(). If GRTD is going to do a flush anyway,
is this really going to improve anything?

Thank you


.

Relevant Pages

  • Re: location of bioq lock
    ... > to work on the queue, ... > So we need to know where the lock is. ... Each bioq is owned by the consumer of it, i.e. the individual driver. ... locking it is the responsibility of the driver. ...
    (freebsd-current)
  • Re: location of bioq lock
    ... queue is owned by the driver, and the locking scheme remains the same. ... from a different scheduler than the default, it can be easily plugged in. ... process you have to lock each queue before playing with it. ...
    (freebsd-current)
  • Re: location of bioq lock
    ... > queue is owned by the driver, and the locking scheme remains the same. ... > from a different scheduler than the default, it can be easily plugged in. ... > process you have to lock each queue before playing with it. ...
    (freebsd-current)
  • Re: OS Question
    ... driver, should not distress you. ... I've made the unwarranted assumption that having multiple threads is ... To protect data in user mode ... Permanence (if apps all crash the lock state is retained because ...
    (microsoft.public.development.device.drivers)
  • Re: Seeing lock order reversal
    ... 21 vm page queue free mutex -- ... 18 UMA zone -- ... 18 sleep mtxpool -- ... 15 process lock -- ...
    (freebsd-current)