What i965 bottlenecks would still exist if we fixed memcpy and I830WaitSync?

[Keith Packard]

On Fri, 2007-07-13 at 15:25 -0700, Carl Worth wrote:

>  * Glyphs pinned in system memory, (Keith says he's working on a fix
>    for this)

Eric and I chatted briefly about this, and I did a bit of investigatory
coding. I'm thinking of just placing glyphs in pixmaps and letting the
existing pixmap migration mechanisms move them to video memory for
acceleration. The issue here is that on a multi-card system, you'll get
multiple pixmaps. Which seems bad, but I've got several possible ideas
on how to mitigate the damage a bit.

Once pixmaps move to TTM, we'll have additional adventures sharing
objects across multiple DRI drivers.

>  * Artificial separation of system and video memory on i965 (memcpy
>    pain). I'm told that the TTM work will fix this. Where can I find
>    status on that work or perhaps find how I could help?

The TTM work is blocking this activity, but isn't the whole solution.
Once we have a new DRI-based memory manager, we will just use that for
all pixmaps for UMA machines -- mapping them through the GTT when we
want to accelerate drawing (which is all of the time). This will use the
TTM mechanism, and hence share allocation strategies with DRI objects.

You might pin Eric down during Guadec and find out whether there are
places you could help here. Almost all of this work has no significant
device dependencies.

>  * Excessive waiting in the i965 driver. I can hopefully mitigate much
>    of this with some simple caching, (reducing the waiting to happen
>    only every N operations instead of on every operation). Eliminating
>    the waiting altogether would be even better---but I'd need some
>    advice on how to do that. Anybody have that?

Again, once we move to TTM, we have the ability to track object usage
through the hardware and eliminate the need to flush the pipeline
completely when waiting for objects to become available.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070713/ce3048b3/attachment.pgp>