Pushing image transport logic down the stack

[Mathieu Lacage]

hi keith, 

On Mon, 2006-09-04 at 16:32 -0700, Keith Packard wrote:

> One question here is how to notify the application that the data have
> been read by the graphics card. A possibility not yet addressed is to
> invalidate the PTEs for the data and block the process when it tries to
> write additional data there, or perhaps even allocate new pages in place
> of the old ones so that the application can paint the next frame in the
> same logical location. I know this is currently inefficient, but there's
> a strong interest in fixing these kinds of hardware issues in coming
> generations.

I think the only sane way to deal with such issues is to design a
generic synchronization mechanism for your application and hardware and
OS: trying to design domain-specific solutions to the notification and
synchronization problems seems doomed to fail because then the
application (the X server and/or the X client) needs to deal with
multiplexing correctly multiple sources of notification events.

At one point, I did try to come up with such a generic solution and I
believe it could be used in that case. It is detailed below. Feel free
to ignore this email if you don't think it is relevant to what you are
trying to do.

The idea is that the application should be able to insert two kinds of
"synchronization" tokens in the data/command stream sent to the
hardware:
  - "stalling" synchronization tokens
  - "normal" synchronization tokens
Each token has a destination which can be the address of a specific
component in the pipeline or the broadcast address (one could imagine
also using group addresses but I never found any actual use for such a
thing). Each token also should have a unique id. 

Then, the only thing the application needs to do is insert tokens in the
command stream and wait for events going in the event buffer. Whenever a
synchronization token reaches a component, if the address of the token
matches that of the component, it should report the token id together
with the component id in the event buffer. If the synchronization token
is a "stalling" token, the component should then stall until the
application restarts it. Otherwise, the component could keep on doing
stuff. If the event buffer is full, the component should also stall
(losing events is not ok).

This model has a number of nice properties:
  - the application can control in a fine-grained way which events it
needs and request notifications
  - the application controls the pipelining since it can decide whether
or not to use "stalling" synchronization tokens
  - the application has a nicely multiplexed event source

Note that it should be easy to make this model work with multiple
sources of synchronization tokens and commands by attaching to each
token a specific event buffer handle: it would be an id for the event
buffer in which to report the event. This also allows the application to
create multiple event buffers, and separate event types across the
buffers to not have to do the dreaded read-ahead-events-in-event-buffer.

Such a generic linux API would be really cool from the point of view of
an application developer but it would require collaboration from the X
library, the X server, the DRI layer, the kernel, and the hardware.
Alas, I have never given much thought to how easy it would be to
introduce such a model incrementally in the system.

Mathieu
--