Brian S. Julin writes:
> Chris and I are working on this tonight. I'm going to try to abstract
> what I see in the chipset docs available to me (matrox, and vgadoc).
I don't know much about hardware design, features and all, but I
suspect that there could be different levels of ROps: from hardware
based bitwise ops to GGI level color blending. plus stencil buffer,
z buffer, texture map...
> > libxmi defines a number of these and I'm also doing this kind of thing
> > in the libart renderer. It would be good to have this unified.
>
> Definitely. I'll look at libart and xmi when I'm done and see if I missed
> anything.
Well, from what I understand from the sourceqs, libxmi renders
sets of span, given by a starting pos and a length, computed
by shape algorithms. You can decide what ROP is actually used
to render these spans (XOR, blend...)
libart works more or less the same way (at least for the svp part).
When you render an svp, the renderer use a callback to build
a y-sorted set of 'steps'. These steps are pretty much like
the xmi spans, expect that a 'pixel fill' value for each step
is sampled on a uchar. You can use this value as an alpha factor.
The set of steps is internally given to a rasterizer callback,
which, in libart, does alpha blending. No other ROP is defined
but It can be easily achieved through the callback interface.
I have a working version but I'm not completely satisfied
with the API yet.
> For negotiation purposes, A BLT is defined by three resources.
> The "motor" resource defines positioning capabilities of the BLT engine
> (scaling, mainly in the case of BLTs). Then each chunk of memory to be
> used as a source is represented as a "tank" resource, the properties
> therein defining the pixel layout (including alpha/z) and some stuff to
> do with alignment in the video RAM. Finally, what I am working on
> tonight is the "carb" resource which defines translations done to the
> data in the tank on the way to the motor (ROPs, CLUTs, keying,
> endian/format translation, etc.)
>
> Now, that is for negotiation and acquisition of the source. LibBlit is
> there to hide the unneeded fields from the negotiation process, to make
> usage of the BLT engine simple by providing sensible defaults, and to
> add any feilds that are needed for runtime use. The end user will rarely
> work with the "motor" "tank" and "carb" directly.
>
> We're still trying to glue it all together in a usable fashion, so
> comments are welcome.
I'll have a in-depth look at libGAlloc (I don't have much time
right now, unfortunately)
> In answer to your question about varying the ROPs:
>
> > > /* Multi-Source blitting operation. Blits all bobs from
> > > * the source-list into blt using the given rop from the list.
> > > * It performs stretching, if width and height are != 0
> > > */
> > > int ggiBltCrossBlit(ggiBlt_source_list src, size_t nmemb,
> > > ggiBlt_t blt, int width, int height);
>
> ... src contains a structure that defines a buffer to blit from
> and the rops to use, so the rops do vary (you can have more
> than one ggiBlt_source pointing to the same buffer with a different ROP).
>
> There is also to consider the possibility of having a function like this:
>
> int ggiBltPolyCrossBlit(ggiBlt_source_list src, size_t nmemb,
> ggiBlt_t blt, int *width, int *height);
>
> ...to queue up a series of BLT operations. As to whether to break
> out the ROP from the ggiBlt_source that is a matter of whether
> there will be a large enough need to vary either the buffer source
> or the ROP but not both, with a large value of nmemb, such that the
> memory saved/convenience is worth the extra API functions.
>
> --
> Brian
Eric.
