Vertex buffers and the ring walker method

Michel Dänzer michel at
Tue Jun 12 01:31:05 PDT 2012

[ The xorg-driver-ati list would probably be better for this ]

On Mon, 2012-06-11 at 18:09 -0700, Connor Behan wrote:
> 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?

I doubt there's any reason why the ring walker method wouldn't work with

BTW, I assume you're always testing your code with direct rendering
enabled, so the R128CCE* paths are hit. Because I don't see how the
other Composite paths could work at all as they 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.

Have you got that working BTW?

> == 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.

Not for CPU access...

For GPU acceess, the code

        pSrc->devPrivate.ptr - info->ExaDriver->memoryBase

can't work, as devPrivate.ptr is normally NULL. You need to use

Earthling Michel Dänzer           |         
Libre software enthusiast         |          Debian, X and DRI developer

More information about the xorg-devel mailing list