On Tue, 2 Mar 2004, Sottek, Matthew J wrote:
> Smaller is good, but can you give an example of "benchmark
> rigging"?
Rather than using mi to break down a complex primitive into
spans and then sending the list of spans to the driver, XAA
would replace mi so it could send individual spans to the
driver as soon as it computed them, thus improving CPU/GPU
concurrency. It's helps alot when you've got a small fifo
as you do with MMIO. I doesn't help for DMA though, and
it's not worth the code bloat.
>
> >3) No assumptions about offscreen memory usage. Leave it entirely
> > up to the driver. I'll provide a sample linear heap manager.
> > You can use whatever you want.
>
> So is the new design "surface based"? i.e. blits are coordinates
> relative to a surface (off-screen or on-screen). If so, this is
> good. The rectangular memory "single surface" Xaa is not a very
> good match for modern hardware.
It's surface based.
>
> Also, I would like to make sure that the new design has a much
> improved syncing mechanism. Syncing should be, at a minimum,
> on a per-surface basis. Perhaps even a bounded region of a
> surface is justified. As GUI's become more "media rich" the
> amount of data coming from the CPU to the graphics engine is
> increasing. This means more puts and consequently lots of syncing
> for many hardware types. The current global sync design waits
> too long and forces idle time unnecessarily. Other driver models
> abandoned the single sync a long time back.
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.
>
> I think we should also address the "setup for"..."subsequent"
> design concept. Seems like most designs would be better fit
> with a single entry point that provides all the information,
> perhaps with an "n" option to indicate how many such calls are
> expected with the same "setup" data. Command engines could then
> batch commands together, or a driver could send a batch of
> commands to a kernel driver. In my opinion it is more useful to
> know how many similar commands are being sent (or at least know
> when the last one is sent) than the current method.
The entry point for rects is an array not a single rect.
The implementation will send as many rects as it can in one
bunch. The SetupFor and Subsequent behavior still exists
and you may get multiple batches of rects after a SetupFor,
usually because XAA2 doesn't want to allocate the memory
to send everything in a single array, which can easily be
megabytes of data. I disagree with the idea of merging
SetupFor and Subsequent. Separating state and primitives
are very common (eg. OpenGL) and I don't like the idea of
sending the state down every primitive. Besides, you don't
actually have to do anything in the SetupFor other than
note the state to send down in the Subsequent if you don't
want to.
Mark.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
