On Tue, 2 Mar 2004, Sottek, Matthew J wrote:
> > It's currently global because the hardware I work on doesn't
> >have to fall back to software very often. Bookkeeping on a per-
> >surface basis is a simple modification and one I will add. This
> >precludes using XAA2 with hardware that doesn't support concurrent
> >SW and HW access to the framebuffer, but that's OK since that
> >stuff is old and we're trying to move forward here. HW that sucks
> >can use the old XAA.
>
> It shouldn't preclude this from working. You just need the call
> to look like sync(xaa_surface_t *surface) and let old hardware
> sync the whole engine regardless of the input. It helps those
> who can use it and is the same as what you have now for everyone
> else.
I don't understand your reasoning.
The difference with per-surface as opposed to global sync state
is that you don't have to sync when CPU rendering to a surface that
has no previously unsynced GPU rendering. The point of this is
to ALLOW concurrent CPU and GPU rendering into video ram except
in the case where both want to render to the same surface. There
are old hardware that allow no concurrent CPU and GPU rendering
at all.
Even with Sync() passing the particular surface which is necessitating
the sync, I would expect all drivers to be syncing the whole chip
without caring what the surface was. Most hardware allow you to
do checkpointing in the command stream so you can tell how far
along the execution is, but a Sync can happen at any time. Are
you really going to be checkpointing EVERY 2D operation?
> I still contend that it would be a benefit to know how many
> rects associated with the same state are going to be sent
> (even if you send those in multiple batches for array size
> limitations) this allows a driver to batch things up as it
> sees fit.
I don't know the amount of data coming. The old XAA (and
cfb for that matter) allocated the pathelogical case: number
of rects times number of clip rects. It doesn't know how many
there are until it's done computing them, but it knows the
upper bounds. I have seen this be over 8 Meg! The new XAA
has a preallocated scratch space (currently a #define for the
size). When the scratch buffer is full, it flushes it out to
the driver. If XAA is configured to run with minimal memory,
the maximum batch size will be small.
> Currently a driver cannot batch things efficiently
> because there is no way to know when the end of the batch
> should happen. An array of rects is a good start but not a
> complete solution.
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.
>
> I also have some questions regarding the memory management.
> Who is responsible for system memory surfaces (and any
> migration to/from video memory)?
System memory pixmaps are handled by fb as always. XAA2
holds the migration logic.
> Who is responsible for populating surfaces? Does X get a virtual
> address (or offset from base), width, height, pitch and populate
> the surface itself or does the driver have to handle cpu_to_screen
> to do it? What about unknown surface types? (compressed?)
XAA doesn't care about surface particulars. It asks the driver
if it could stick this pixmap in videoram for it because the migration
logic says it should go in videoram. The driver can refuse or can
accept by returning an XAASurface for it. XAA passes that surface
back to you in the SetupFor function. To XAA, it's just a device
independent structure. The driver has private storage in the
XAASurface.
>
> How does X tell the driver what the surface will be used for? A
> RENDER surface could have different alignment or tiling properties
> than a 2d only surface. That information would be needed at allocation
> time.
>
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.
Mark.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
