On Wed, 3 Mar 2004, Sottek, Matthew J wrote:
> > It's the best we can do. I'm not going to compute the
> >clips in two passes: one to find out how many rects there
> >end up being, and one to store the rects.
>
> At least you would be able to indicate the last one which
> would serve the same purpose. Or an optional "flush" call
> to the driver. A batching driver could queue stuff up until a
> flush. A flush would happen after a set of operations that
> originated as a single complex drawing operation.
I have been completely baffled as to why anyone would
ask for such a thing, and then it occurs to me that you
probably think you need this because you can't think of
a better way to solve a particular problem. Basically,
you're going about it all wrong, and what you are asking
for isn't going to help you at all. See the 4.4 "nv"
driver for an example of how to efficiently batch up
rendering for a DMA engine. It wraps the block handler
so it knows when the server will be going back to wait
on more data from the client. When it gets large requests
from XAA, it commits them to hardware immdiately, but it
buffers up smaller ones until the block handler.
Nearly all SetupFor calls are going to have a single
primitive following them. If you are merely trying to
buffer up the parts after a single SetupFor, you are not
aiming high enough. Also, with the current #defines, the
point at which XAA starts flushing out the rects it has
collected is on the order of thousands of rects. It is
not beneficial to be buffering up more than that.
> >> There's no such thing as a "RENDER surface". Pictures are merely
> >>X-drawables with extra state associated with them. Any drawable can
> >>eventually be used as a picture. You will need to keep that in mind
> >>just as you do now.
>
> This has pretty serious implications. Currently the memory manager
> uses rectangular memory which presumably has pitch etc characteristics
> that are usable by the stretch blit/alpha blend components of a
> chip. That makes it reasonable (although probably not ideal) to
> assume that any offscreen surface can be used for RENDER purposes.
>
> Moving to a surface based infrastructure would allow a driver to
> more carfully choose surface parameters... always choosing the
> worst case alignment,pitch, etc characteristics seems like a problem.
>
> This may be a RENDER problem and not just an Xaa problem, but it
> seems like there really needs to be prior indication that a surface
> is being used as a RENDER source or target such that the memory
> manager can make appropriate choices.
RENDER basically assumes you can use any arbitrary X drawable
as a repeatable texture and also support a texture matrix. Go back
a couple years to RENDER discussions and you can find Thomas Roell,
myself, and a bunch of other people complaining to Keith about this.
Basically, RENDER is mostly unaccelerateable on most hardware and
a new XAA isn't going to change that.
Mark.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
