On Fri, 2007-12-21 at 13:40 +0100, Thomas Hellström wrote:

> // Change only the RW flags, and set them to "Write"
> validate(bo, DRM_BO_FLAG_WRITE , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE)
> Render to buffer object.
> // Change only the RW flags, and set them to "READ"
> validate(bo, DRM_BO_FLAG_READ , DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE)
> Use as a texture.
> 
> Is this sufficient to do what you're after?

From the application's perspective, this is descriptive enough, yes. The
problem is that inside the DRM, this information is not available after
the operation has been queued.

Here's a concrete example that might help explain what I was thinking.

        Draw to surface "A" from surface "B".
                paint B onto A
                emit breadcrumb 1
                emit IRQ
        Draw to surface "C" from surface "A".
                paint A onto C
                emit breadcrumb 2
                emit IRQ

Right now, waiting for breadcrumb 1 is not sufficient to be able to use
A to paint onto C. We must emit an MI_FLUSH, so we need to know after
emiting fence 1 that A will be written and must be flushed before being
read. I think what I want is this:

                paint B onto A
                emit breadcrumb 1
                emit IRQ

                flush A
                emit breadcrumb 1.5
                emit IRQ

                paint A onto C
                emit breadcrumb 2
                emit IRQ

sticking a 'flush/breadcrumb/irq' sequence in the middle means I can
know that a flush operation has occurred, and go through and clean any
buffers which were written but not flushed. But, I have to know which
buffers those are, and record which breadcrumb value will be sufficient
to flush them.

The only case where I'll have to wait for the flush operation is when I
want to unbind the object from the GTT; other than that, the flushes can
all go in-line.

-- 
[EMAIL PROTECTED]

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to