On Tue, 16 Jul 2002, Helge Bahmann wrote:
> Hello list!
>
> Apologies if this is the wrong forum, but I do not know a better place to
> post.
>
> First, let's say that I am trying to do somehting ... "interesting" ...
> with the X server. So far understanding most of the architecture has not
> been too hard thanks to generally very readable coding style and helpful
> comments. (Oh, if someone can recommend a book on this topic it would not
> hurt nevertheless.)
>
> Anyway, the thing I really do not understand is the notion of
> asynchronicity in request processing; let's take this example: Client
> issues request to draw a line, so the ProcPolyLine dispatcher function is
> called in the server, which in turn may eventually call into the driver.
> But what is guaranteed to have been done on return from the dispatcher
> function?
>
> a) the pixels have been drawn into the frame buffer
> b) the hardware has been instructed to draw a line, but we don't know if
> it has finished yet
>
> (of course the question also applies to other requests, like CopyArea)
>
> Option a) is certainly true for non-accelerated drawing, but it seems a
> waste of resources for accelerated drawing, so I assume this is not the
> case (is it?), and some remarks in the driver sources also indicate
> otherwise
It's not necessarily true for non-accelerated rendering either.
In the case of a shadow framebuffer these requests will write to
the shadow buffer, but won't necessarily be propagated to the real
framebuffer at that time.
>
> As far as my (in this area rather poor) understanding goes, something like
> b) is happening in the driver code; but then I do not understand how
> synchronization with other requests is handled -- I mean, what happens
> when another request wants to draw in the same area, how can it be sure
> that the line drawing has completed? Is there some interface exported for
> this, e.g. a completion callback or similiar? Or is this kind of
> synchronization purely internal to the hardware driver (to maintain the
> illusion of a) )?
>
Actually b) is not guaranteed either. In the case of PIO/MMIO
engines it's generally the case that the hardware has been programmed
and the primitives are in flight and will complete at some time in
the future. For DMA engines, however, primitives may be batched up
across requests and kicked off before the X-server goes back to
waiting on its file descriptors. All requests made through the
graphics engine are pipelined so there are no ordering problems.
The complications happen when mixing hardware and software rendering.
This is the business of XAA - the hardware acceleration layer.
It keeps track of whether or not there are potentially primitives
in the graphics pipeline and flushes the pipeline whenever it
needs to fall back to software. The graphics driver itself
can (and in some drivers does) override XAA functionality at
a high enough level that it needs to deal with the synchronization
itself in some cases.
Perhaps if you were to elaborate on what "interesting" thing
you are trying to do?
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
