<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> 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: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=47866">https://bugs.freedesktop.org/show_bug.cgi?id=47866</a>. 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. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </body> </html>