Vertex buffers and the ring walker method

[Connor Behan]

I hope this message doesn't reek of frustration because I've already
received a lot of help, particularly from Michel Daenzer. My question is
related to the r128 RenderAccel that I've been trying to implement:
https://bugs.freedesktop.org/show_bug.cgi?id=47866. Forget what I said
about certain color depths not being supported, or certain blend
controls not being supported. The problem is that when I write a vertex
bundle, nothing happens. Period.

== Well defined question ==

I have finally found something that might explain why nothing is drawn.
A very old version of mesa has a comment "PCI cards use the ring walker
method, ie. the vertex buffer data is actually part of the command
stream." The card I've been testing on is AGP and the example code I've
been using was mainly tested on PCI. What is the alternative to the ring
walker method for AGP? My register file defines WALK_RING, WALK_LIST and
WALK_IND so I think I should use one of the other two. But then how do I
send vertex buffer data if not through the command stream? I need *some*
way of telling my card what the vertex co-ordinates are.

== My flawed understanding of how it should work when WALK_RING is
supported ==

The only guidance I've been able to find, comes from r128_composite.c in
the kdrive ATI driver. The four vertices that need to be drawn are the
four corners of the texture, and the card expects 8 pieces of
information each time. Up to a fudge factor, they are:

dstX, dstY, 0, 1, srcX / w, srcY / h, maskX / w, maskY / h

and they need to be sent as "integer representations of an IEEE float",
hence the union. Before these 32 register writes, two other registers
are written. The one immediately before tells the card that there will
be four vertices, that these vertices should be treated as "TRI_FAN" and
that it should use the "ring walker method". The register write before
that tells the card what the 8 pieces of information should be. Now I
believe dstX, dstY and 0 are always needed. Because I specified bits
that have "S_T" and "S2_T2" in the name, this tells it to expect source
and mask co-ordinates respectively. The 1 is specified with an "RHW"
bit, whatever that means. If I were to tell it to expect a color, say
"DIFFUSE_ARGB", then there would be 9 pieces of information... I'd have
to put a colour between the 1 and srcX / w.

== What the problem is not ==

After hundreds of tries to use WALK_RING or work around it, I looked at
what would happen when I blindly copied pixels to the screen instead.
For composited text, the source picture is a black repeating pixel. The
information about the shape of the text is encoded in the mask which has
some parts transparent and some parts opaque. So I turned my Composite
hooks into Copy hooks and copied Mask to Dest. Obviously this is stupid
because the alpha channel would be taken literally causing everything to
get out of sync:

argbargbargb
rgbrgbrgbrgb

The text is therefore the wrong size and the wrong color and looks
horribly mangled. However, I think it's kinda neat how I can actually
make out what it says. This means that the pixmaps are in memory like
they're supposed to be and I haven't gotten the texture offsets wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120611/82d009e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120611/82d009e9/attachment.pgp>