4 ms·

> Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferre

by hormis 15y ago

> Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers. FXAA is acceptable for the other techniques as well. However, MSAA is, in my opinion, a better technique as it uses supersampling at the edges and is already hardware assisted. FXAA's strength is that it is less expensive than MSAA memory and bandwidth wise. Both are a premium in deferred shading as you are using a 4x RBGA16 texture render target or something close to it :) > If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge. 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? > 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. > Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb147221%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb14... > All render target surfaces used together must have the same bit depth but can be of different formats, unless the D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is set. 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.

maximilianburke 15y ago
> 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. This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. See "Reading the Depth-Stencil Buffer as a Texture" on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205074(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb20...
daeken 15y ago
> 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.
- hormis 15y ago
  > he way it's working in my mind has about the same number of lookups as FXAA, However, the FXAA will have a clear win as it works over a partly transparent polygon. So you will have to combine both an RBG and z based to get the same result as an FXAA. > you're dependent on bandwidth between the GPU and its memory, not main memory. The bandwidth I was talking about was the older cards which do not have bandwidth or fill rate to keep 60fps with deferred shading, no AA. FXAA would be a candidate there if it is a pure RGB technique on the composited frame, especially as it is cheaper than MSAA.
hormis 15y ago
> This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. Missed that one as I have been mostly playing around in DX9 and only a bit of DX10. There is the case of the billboarded or partly transparent texture. The z-based edge methods will not work in these cases as you render them with z-write off. Meaning, atleast in those cases, FXAA is a clear winner over both MSAA and z-based edge detection.

by hormis 15y ago

maximilianburke 15y ago

> 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. This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. See "Reading the Depth-Stencil Buffer as a Texture" on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205074(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb20...

daeken 15y ago

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

hormis 15y ago
> he way it's working in my mind has about the same number of lookups as FXAA, However, the FXAA will have a clear win as it works over a partly transparent polygon. So you will have to combine both an RBG and z based to get the same result as an FXAA. > you're dependent on bandwidth between the GPU and its memory, not main memory. The bandwidth I was talking about was the older cards which do not have bandwidth or fill rate to keep 60fps with deferred shading, no AA. FXAA would be a candidate there if it is a pure RGB technique on the composited frame, especially as it is cheaper than MSAA.

hormis 15y ago

> This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target. Missed that one as I have been mostly playing around in DX9 and only a bit of DX10. There is the case of the billboarded or partly transparent texture. The z-based edge methods will not work in these cases as you render them with z-write off. Meaning, atleast in those cases, FXAA is a clear winner over both MSAA and z-based edge detection.