On 19/01/2015 11:59, Roland Scheidegger wrote :
I always thought you can't resolve z because such an operation just
makes no sense at all. What the hell does it even mean and how do you do
it? Color resolve you just interpolate between the value to get rid of
the aliased edges. But in the depth
Am 17.01.2015 um 14:44 schrieb Axel Davy:
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 6c5703a..351f3c2 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -573,6 +573,7 @@ enum pipe_cap {
BTW, this is the same as the glBlitFramebuffer behavior for MSAA depth buffers.
Marek
On Mon, Jan 19, 2015 at 2:18 PM, Axel Davy axel.d...@ens.fr wrote:
On 19/01/2015 11:59, Roland Scheidegger wrote :
I always thought you can't resolve z because such an operation just
makes no sense at all.
Ah ok makes more sense that way. This is not really something I'd call
resolve though. (And isn't it already assumed drivers can do the
blitting of such buffers already for glBlitFramebuffer?)
Roland
Am 19.01.2015 um 16:10 schrieb Marek Olšák:
BTW, this is the same as the glBlitFramebuffer
Yes, but it's only supported on r700 and later. This is one of the
things in OpenGL that a lot of hardware (r3xx-r6xx) cannot do.
r300-r500 really doesn't support it. R6xx was designed to support it,
but it doesn't work due to hw bugs.
Marek
On Mon, Jan 19, 2015 at 4:31 PM, Roland Scheidegger
I always thought you can't resolve z because such an operation just
makes no sense at all. What the hell does it even mean and how do you do
it? Color resolve you just interpolate between the value to get rid of
the aliased edges. But in the depth buffer, these values represent the
depth
Ok a cap bit sounds reasonable then I guess.
Roland
Am 19.01.2015 um 16:41 schrieb Marek Olšák:
Yes, but it's only supported on r700 and later. This is one of the
things in OpenGL that a lot of hardware (r3xx-r6xx) cannot do.
r300-r500 really doesn't support it. R6xx was designed to support
Potentially this proposed cap should be replaced
by a is_format_supported call with PIPE_BIND_SAMPLER_VIEW
for a multisampled depth format.
Looking at the driver sources, I get the impression only
nouveau and radeon support MSAA. But they may need
some correction, because It looks like for r600
I'm confused by what this flag is allowing. Are we talking about a
blit from MS - non-MS? texelFetch(sampler2DMS) for a depth buffer?
texelFetch(sampler2D) for a MS surface? (is that even allowed in GL?)
Or are we talking about mixing MS and non-MS buffers in the fb? These
are all separate things.
This looks good.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Sat, Jan 17, 2015 at 2:44 PM, Axel Davy axel.d...@ens.fr wrote:
Resolving a multisampled depth texture into
a single sampled texture is supported on = SM4.1
hw. It is possible some previous hw support it.
The ability
Yes, reading depth textures with sampler2DMS is allowed. There is
GL_MAX_DEPTH_TEXTURE_SAMPLES added by GL_ARB_texture_multisample I think.
Both solutions (the new CAP and using is_format_supported) are okay with me.
Marek
On Sun, Jan 18, 2015 at 8:23 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
In d3d9, mixing render targets and depth buffer of different
multisampling is forbidden.
There's a d3d9 hack, called RESZ, which allows to copy a multisampled
depth buffer to
a single sampled depth buffer. This cap was about knowing if that
feature could be supported.
But likely the better
Resolving a multisampled depth texture into
a single sampled texture is supported on = SM4.1
hw. It is possible some previous hw support it.
The ability was tested on radeonsi and nvc0.
Apparently is is also supported for radeon = r700.
This patch adds the MULTISAMPLE_Z_RESOLVE cap and
add it to
13 matches
Mail list logo
