In your message of 15 August 2002 you write:
> The second is that when
> compositing images with window contents, placing the compositing software
> right next to the frame buffer means that only the pixels which are
> translucent in the source image need be read from the frame buffer.
Actually that is incorrect. Reading data pixel-wise from the
framebuffer can be significantly slower than reading them in
sequential order. The reason is that the HW can use burst mode type
access (bus as well as SRAM) to read data more efficiently.
> Of course, you could also look at the Matrox code and implement similar
> acceleration for whatever video card you like; that will make Render a lot
> faster, and doing some of the common cases isn't really that much work.
That is one of my major headaches in implementing X Render. Modern
Graphics HW split up the 2D engine from the 3D engine. The matrox chip
you refer to is really one of the last ones, where the 2D engine was
combined with the 3D engine.
Hence you will have to implement XRender on y typical 3D engine that
has been geared towards Direct3D/OpenGL. And this is where the
headache starts:
1. Source and Mask in reality had to be implemented as texture maps,
where the Mask would proably be a alpha-texture. PseudoColor maps
could in theory be implemented as palletized textures, but few
graphics to implement them still, as having luts for trilinear
texture filtering gets kind of expensive. Now the issue with using
textures for Source and Mask is that they are texture and they are
also pixmaps at the same time, to which one could render to
(including by the current composite operation). For most HW,
texture are either in dedicated memory (where they cannot be drawn
to), or are in a different format (tiled memory organisation), have
certain size restrictions that make them difficult to keep on
HW. But essentially they are read only objects, rather than the
read&write paradigma of XRender.
2. After the process of combining Source and Mask, the 3D engines
blender has used for combining the result with the destination.
Direct3D/OpenGL do use a powerful but simple scheme of having a
source factor and a destination factor, where with modern graphics
engines, those factors are independantly controllable for the rgb
and the alpha channel(s). XRender now only uses a single operator,
that has been defined in a way, that makes it often impossible
possible to map the functionality to existing (and most likely
furture) HW. An example is the PictOpSaturate. This operator is not
implementable in HW without changeing the texture formats on the
fly.
3. The way that picture object are associated with pixmaps do force an
X-Server implementation to support many new pixmap formats. If an
X-Server implements HW caching of pixmaps, this is a verys
significant problem.
My suggestions for making XRender to be implementable on real existing
HW (without having to resort to the statement that only few fast paths
are in reality to be HW accelerated) would be:
- make Source and Mask readonly objects, associated with a
picture. Then a driver can convert the data into usable formats and
directly make use of them.
- replace the notion of PseudoColor pictures by having simple
intensity formats (could do almost the same, and it's supported by
HW).
- rework the operators so that they are mappable to exisiting HW.
- have picture objects independant of pixmaps.
As we tried to implement XRender (and have not given up more than 3
times because of the convolutedness, and the fact that pretty much all
applications seen out there using on the alpha blending capability),
one can today only use maybe the source/destination beling capability
along with a scratch texture surface). Caching of glyphs is next to
impossible given the semantics of operators and the read&write nature
of pictures. Actually with that in mind and the fact that for most
operations the cost of setting up the graphics engine is higher than
simply doing it in SW, it seems that a software only implementation
makes way more sence than attempting to put this concept onto real HW.
- Thomas
--
Thomas Roell /\ Das Reh sprint hoch,
Xi Graphics / \/\ _ das Reh springt weit,
[EMAIL PROTECTED] / / \ \ was soll es tun,
/ Oelch! \ \ es hat ja Zeit.
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
