> The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection? The way it's wo

> The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection? The way it's working in my mind has about the same number of lookups as FXAA, but I'm honestly not sure how that'd pan out in practice. We'll see. > As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer. Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format. No need for the internal format, though -- raw depth buffers are A-OK. > As you can see, the bit depth restriction means that you would end up with 2x bandwidth usage with the z based edge detector, especially on the older hardware where you do not have the bandwidth to spare. It would be a different case if you can sample the hardware z-buffer. One thing to keep in mind is that yes, you're rendering it to texture and you incur some overhead there, but you don't have to pull that data back to the CPU so you're dependent on bandwidth between the GPU and its memory, not main memory. Sure, it's double the memory used there, but that's negligible from a bandwidth perspective. Also a good thing to note that you generally already have your depth buffer if you're doing deferred rendering, and you can do all the AA based on that, in theory.