Re: [Mesa-dev] [PATCH v2 6/6] mesa: Make a function is_transform_feedback_active_and_unpaused.
On 12/16/2012 07:49 AM, Brian Paul wrote:
On Sat, Dec 15, 2012 at 11:09 PM, Paul Berry wrote:
The rather unweildy logic for determining this condition was repeated
in a large number of places. This patch consolidates it to a single
inline function.
@@ -111,4 +113,11 @@ _mesa_PauseTransformFeedback(void);
extern void GLAPIENTRY
_mesa_ResumeTransformFeedback(void);
+static inline bool
+is_transform_feedback_active_and_unpaused(struct gl_context *ctx)
+{
+ return ctx->TransformFeedback.CurrentObject->Active &&
+ !ctx->TransformFeedback.CurrentObject->Paused;
+}
Non-private core Mesa functions should have the _mesa_ prefix. It's a
long name already. Maybe use the "xfb" abbreviation?
The ctx parameter could be const-qualified.
Yeah, I like both those suggestions.
I had also been thinking of 'really_active' instead of
'active_and_unpaused'. _mesa_is_xfb_really_active() doesn't seem to
lose and clarity from _mesa_is_xfb_active_and_unpaused(). I'm not too
hung up on it, though. *shrug*
Reviewed-by: Brian Paul
With Brian's suggestions incorporated, it's
Reviewed-by: Ian Romanick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vl/compositor: fix weave shader bugs
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel always being off by one.
If y was .5:
y' = round(y) + 0.5 = 1.5
Fixing this also means the LRP function has to swap the pixels it, since
it's now the other way around for top/bottom.
WIth these fixes only chroma for top and bottom pixel rows are wrongly
interpolated
in my test program:
--- nvidia
+++ nouveau
@@ -1,4 +1,4 @@
-YCbCr[0] = 00c080
+YCbCr[0] = 00b070
YCbCr[1] = 00b070
YCbCr[2] = 029050
YCbCr[3] = 207050
@@ -61,4 +61,4 @@
YCbCr[60] = 0c5070
YCbCr[61] = c05090
YCbCr[62] = 0e70b0
-YCbCr[63] = e080c0
+YCbCr[63] = e070b0
Signed-off-by: Maarten Lankhorst
---
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 7ea13bf..bc69669 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -199,11 +199,13 @@ create_frag_shader_weave(struct vl_compositor *c)
/* calculate the texture offsets
* t_tc.x = i_tc.x
-* t_tc.y = (round(i_tc.y) + 0.5) / height * 2
+* t_tc.y = (round(i_tc.y - 0.5) + 0.5) / height * 2
*/
for (i = 0; i < 2; ++i) {
ureg_MOV(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_X), i_tc[i]);
- ureg_ROUND(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ), i_tc[i]);
+ ureg_SUB(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
+ i_tc[i], ureg_imm1f(shader, 0.5f));
+ ureg_ROUND(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
ureg_src(t_tc[i]));
ureg_MOV(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_W),
ureg_imm1f(shader, i ? 0.75f : 0.25f));
ureg_ADD(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
@@ -234,11 +236,11 @@ create_frag_shader_weave(struct vl_compositor *c)
ureg_ROUND(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ), i_tc[0]);
ureg_ADD(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ),
ureg_src(t_tc[0]), ureg_negate(i_tc[0]));
- ureg_MUL(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_XY),
+ ureg_MUL(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ),
ureg_abs(ureg_src(t_tc[0])), ureg_imm1f(shader, 2.0f));
ureg_LRP(shader, t_texel[0], ureg_swizzle(ureg_src(t_tc[0]),
TGSI_SWIZZLE_Y, TGSI_SWIZZLE_Z, TGSI_SWIZZLE_Z, TGSI_SWIZZLE_Z),
-ureg_src(t_texel[1]), ureg_src(t_texel[0]));
+ureg_src(t_texel[0]), ureg_src(t_texel[1]));
/* and finally do colour space transformation
* fragment = csc * texel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Fix creation of shared and scanout textures.
Looks fine.
I'm curious, what does this fix in practice?
Jose
- Original Message -
> NOTE: This is a candidate for the stable branches.
> ---
> src/gallium/drivers/llvmpipe/lp_texture.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
> b/src/gallium/drivers/llvmpipe/lp_texture.c
> index 2e9c6bf..f17a04a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
> @@ -295,7 +295,9 @@ llvmpipe_resource_create(struct pipe_screen
> *_screen,
> /* assert(lpr->base.bind); */
>
> if (resource_is_texture(&lpr->base)) {
> - if (lpr->base.bind & PIPE_BIND_DISPLAY_TARGET) {
> + if (lpr->base.bind & (PIPE_BIND_DISPLAY_TARGET |
> +PIPE_BIND_SCANOUT |
> +PIPE_BIND_SHARED)) {
> /* displayable surface */
> if (!llvmpipe_displaytarget_layout(screen, lpr))
> goto fail;
> --
> 1.8.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vl/compositor: fix weave shader bugs
On 18.12.2012 09:18, Maarten Lankhorst wrote:
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel always being off by one.
If y was .5:
y' = round(y) + 0.5 = 1.5
Fixing this also means the LRP function has to swap the pixels it, since
it's now the other way around for top/bottom.
WIth these fixes only chroma for top and bottom pixel rows are wrongly
interpolated
in my test program:
Sounds good, but what's the reason that first and last row is
interpolated wrong? Just some issues with the border color/wrap handling?
--- nvidia
+++ nouveau
@@ -1,4 +1,4 @@
-YCbCr[0] = 00c080
+YCbCr[0] = 00b070
YCbCr[1] = 00b070
YCbCr[2] = 029050
YCbCr[3] = 207050
@@ -61,4 +61,4 @@
YCbCr[60] = 0c5070
YCbCr[61] = c05090
YCbCr[62] = 0e70b0
-YCbCr[63] = e080c0
+YCbCr[63] = e070b0
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian König
---
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 7ea13bf..bc69669 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -199,11 +199,13 @@ create_frag_shader_weave(struct vl_compositor *c)
/* calculate the texture offsets
* t_tc.x = i_tc.x
-* t_tc.y = (round(i_tc.y) + 0.5) / height * 2
+* t_tc.y = (round(i_tc.y - 0.5) + 0.5) / height * 2
*/
for (i = 0; i < 2; ++i) {
ureg_MOV(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_X), i_tc[i]);
- ureg_ROUND(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ), i_tc[i]);
+ ureg_SUB(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
+ i_tc[i], ureg_imm1f(shader, 0.5f));
+ ureg_ROUND(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
ureg_src(t_tc[i]));
ureg_MOV(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_W),
ureg_imm1f(shader, i ? 0.75f : 0.25f));
ureg_ADD(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_YZ),
@@ -234,11 +236,11 @@ create_frag_shader_weave(struct vl_compositor *c)
ureg_ROUND(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ), i_tc[0]);
ureg_ADD(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ),
ureg_src(t_tc[0]), ureg_negate(i_tc[0]));
- ureg_MUL(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_XY),
+ ureg_MUL(shader, ureg_writemask(t_tc[0], TGSI_WRITEMASK_YZ),
ureg_abs(ureg_src(t_tc[0])), ureg_imm1f(shader, 2.0f));
ureg_LRP(shader, t_texel[0], ureg_swizzle(ureg_src(t_tc[0]),
TGSI_SWIZZLE_Y, TGSI_SWIZZLE_Z, TGSI_SWIZZLE_Z, TGSI_SWIZZLE_Z),
-ureg_src(t_texel[1]), ureg_src(t_texel[0]));
+ureg_src(t_texel[0]), ureg_src(t_texel[1]));
/* and finally do colour space transformation
* fragment = csc * texel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/llvm: improve cube map handling
Add support for cube map arrays, TEX2, TXB2, TXL2, fix SHADOWCUBE.
Signed-off-by: Vadim Girlin
---
The patch includes minimal fix for radeonsi to avoid breaking the build or
introducing regressions, but probably some additional changes are required
to make new features really work on SI.
src/gallium/drivers/r600/r600_llvm.c | 3 +
src/gallium/drivers/radeon/radeon_llvm.h | 3 +-
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 86 +-
src/gallium/drivers/radeonsi/radeonsi_shader.c | 14 +++-
4 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 8f1ed26..17d362c 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -421,9 +421,12 @@ LLVMModuleRef r600_tgsi_llvm(
bld_base->op_actions[TGSI_OPCODE_DDX].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_DDY].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TEX].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_TEX2].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXB].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_TXB2].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXD].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXL].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_TXL2].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXF].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXQ].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXP].emit = llvm_emit_tex;
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
index 61f3772..b8dc771 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -153,7 +153,8 @@ static inline LLVMValueRef bitcast(
void radeon_llvm_emit_prepare_cube_coords(struct lp_build_tgsi_context *
bld_base,
- LLVMValueRef *arg, unsigned target);
+ struct lp_build_emit_data *
emit_data,
+ unsigned coord_arg);
void radeon_llvm_context_init(struct radeon_llvm_context * ctx);
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 647b665..d390f92 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -513,29 +513,29 @@ static void kil_emit(
}
}
-
+/* coord_arg - index of the source coord vector in the emit_data->args array */
void radeon_llvm_emit_prepare_cube_coords(
struct lp_build_tgsi_context * bld_base,
- LLVMValueRef *arg,
-unsigned target)
+ struct lp_build_emit_data * emit_data,
+ unsigned coord_arg)
{
- boolean shadowcube = (target == TGSI_TEXTURE_SHADOWCUBE);
+
+ unsigned target = emit_data->inst->Texture.Texture;
+ unsigned opcode = emit_data->inst->Instruction.Opcode;
struct gallivm_state * gallivm = bld_base->base.gallivm;
LLVMBuilderRef builder = gallivm->builder;
LLVMTypeRef type = bld_base->base.elem_type;
LLVMValueRef coords[4];
LLVMValueRef mad_args[3];
- unsigned i, cnt;
+ LLVMValueRef idx;
+ unsigned i;
LLVMValueRef v = build_intrinsic(builder, "llvm.AMDGPU.cube",
LLVMVectorType(type, 4),
- arg, 1, LLVMReadNoneAttribute);
-
- /* save src.w for shadow cube */
- cnt = shadowcube ? 3 : 4;
+ &emit_data->args[coord_arg], 1, LLVMReadNoneAttribute);
- for (i = 0; i < cnt; ++i) {
- LLVMValueRef idx = lp_build_const_int32(gallivm, i);
+ for (i = 0; i < 4; ++i) {
+ idx = lp_build_const_int32(gallivm, i);
coords[i] = LLVMBuildExtractElement(builder, v, idx, "");
}
@@ -554,13 +554,42 @@ void radeon_llvm_emit_prepare_cube_coords(
coords[1] = lp_build_emit_llvm_ternary(bld_base, TGSI_OPCODE_MAD,
mad_args[0], mad_args[1], mad_args[2]);
- /* apply yxwy swizzle to cooords */
+ /* apply xyz = yxw swizzle to cooords */
coords[2] = coords[3];
coords[3] = coords[1];
coords[1] = coords[0];
coords[0] = coords[3];
- *arg = lp_build_gather_values(bld_base->base.gallivm, coords, 4);
+ /* all cases except simple cube map sampling require special handling
+* for coord vector */
+ if (target != TGSI_TEXTURE_CUBE ||
+ opcode != TGSI_OPCODE_TEX) {
+
+ /* load source coord.w component - array_index for cube arrays
or
+* compare value for SHADOWCUBE */
+ idx = lp_build_cons
[Mesa-dev] glsl: IR clone of ir_loop doesn't remap variable reference
Hi, Something that hit me in GLSL Optimizer (which is based on Mesa's GLSL). Cloning ir_loop just sets "counter" to the old counter. So in situations like: 1) loop controls are set, 2) and after that inlining happens, cloning the instructions including original variable It ends up in a situation where function body has one ir_variable object, but a loop counter there points to another ir_variable (before it was cloned). Not sure how/if that's relevant to Mesa though -- it might. I've fixed it in my tree with this: https://github.com/aras-p/glsl-optimizer/commit/c2919f69#diff-0 -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vl/compositor: fix weave shader bugs
Op 18-12-12 11:42, Christian König schreef: > On 18.12.2012 09:18, Maarten Lankhorst wrote: >> Writemask was XY instead of YZ (thanks to calim for spotting it). >> >> The pixel calculation resulted in the pixel always being off by one. >> If y was .5: >> >> y' = round(y) + 0.5 = 1.5 >> >> Fixing this also means the LRP function has to swap the pixels it, since >> it's now the other way around for top/bottom. >> >> WIth these fixes only chroma for top and bottom pixel rows are wrongly >> interpolated >> in my test program: > > Sounds good, but what's the reason that first and last row is interpolated > wrong? Just some issues with the border color/wrap handling? If I had to guess it interpolates the first and last row, rather than using the exact value of that line for the top/bottom chroma samples there. So it's just border handling sampling from both surfaces that's wrong I think. As you can see in the diff below, it repeats the cbcr[1] value for cbcr[0], similar for cbcr[63] and cbcr[62]: >> >> --- nvidia >> +++ nouveau >> @@ -1,4 +1,4 @@ >> -YCbCr[0] = 00c080 >> +YCbCr[0] = 00b070 >> YCbCr[1] = 00b070 >> YCbCr[2] = 029050 >> YCbCr[3] = 207050 >> @@ -61,4 +61,4 @@ >> YCbCr[60] = 0c5070 >> YCbCr[61] = c05090 >> YCbCr[62] = 0e70b0 >> -YCbCr[63] = e080c0 >> +YCbCr[63] = e070b0 >> >> Signed-off-by: Maarten Lankhorst > > Reviewed-by: Christian König Thanks, will commit. The program I used for testing is attached. Also I seem to be getting a lockup if I convert that program to use YV12 format instead, nouveau requires the interlaced buffer handling for vdec, and disables support for progressive video buffers. Would probably also need the separate patch, for fixing up vl_video_buffer_surfaces. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vl/video_buffer: fix up surface ordering for the interlaced case
It seems the other code expects surface[0..1] to be the luma field in
interlaced case.
See for example vdpau/surface.c vlVdpVideoSurfaceClear and
vlVdpVideoSurfacePutBitsYCbCr.
Signed-off-by: Maarten Lankhorst
---
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 511485f..d61dab2 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -356,20 +356,20 @@ vl_video_buffer_surfaces(struct pipe_video_buffer *buffer)
pipe = buf->base.context;
depth = buffer->interlaced ? 2 : 1;
- for (i = 0, surf = 0; i < depth; ++i ) {
- for (j = 0; j < VL_NUM_COMPONENTS; ++j, ++surf) {
+ for (i = 0, surf = 0; i < VL_NUM_COMPONENTS; ++i) {
+ for (j = 0; j < depth; ++j, ++surf) {
assert(surf < (VL_NUM_COMPONENTS * 2));
- if (!buf->resources[j]) {
+ if (!buf->resources[i]) {
pipe_surface_reference(&buf->surfaces[surf], NULL);
continue;
}
if (!buf->surfaces[surf]) {
memset(&surf_templ, 0, sizeof(surf_templ));
-surf_templ.format =
vl_video_buffer_surface_format(buf->resources[j]->format);
-surf_templ.u.tex.first_layer = surf_templ.u.tex.last_layer = i;
-buf->surfaces[surf] = pipe->create_surface(pipe,
buf->resources[j], &surf_templ);
+surf_templ.format =
vl_video_buffer_surface_format(buf->resources[i]->format);
+surf_templ.u.tex.first_layer = surf_templ.u.tex.last_layer = j;
+buf->surfaces[surf] = pipe->create_surface(pipe,
buf->resources[i], &surf_templ);
if (!buf->surfaces[surf])
goto error;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vl/compositor: fix weave shader bugs
Op 18-12-12 13:04, Maarten Lankhorst schreef:
> Op 18-12-12 11:42, Christian König schreef:
>> On 18.12.2012 09:18, Maarten Lankhorst wrote:
>>> Writemask was XY instead of YZ (thanks to calim for spotting it).
>>>
>>> The pixel calculation resulted in the pixel always being off by one.
>>> If y was .5:
>>>
>>> y' = round(y) + 0.5 = 1.5
>>>
>>> Fixing this also means the LRP function has to swap the pixels it, since
>>> it's now the other way around for top/bottom.
>>>
>>> WIth these fixes only chroma for top and bottom pixel rows are wrongly
>>> interpolated
>>> in my test program:
>> Sounds good, but what's the reason that first and last row is interpolated
>> wrong? Just some issues with the border color/wrap handling?
> If I had to guess it interpolates the first and last row, rather than using
> the exact value of that line for the top/bottom chroma samples
> there. So it's just border handling sampling from both surfaces that's wrong
> I think.
>
> As you can see in the diff below, it repeats the cbcr[1] value for cbcr[0],
> similar for cbcr[63] and cbcr[62]:
>>> --- nvidia
>>> +++ nouveau
>>> @@ -1,4 +1,4 @@
>>> -YCbCr[0] = 00c080
>>> +YCbCr[0] = 00b070
>>> YCbCr[1] = 00b070
>>> YCbCr[2] = 029050
>>> YCbCr[3] = 207050
>>> @@ -61,4 +61,4 @@
>>> YCbCr[60] = 0c5070
>>> YCbCr[61] = c05090
>>> YCbCr[62] = 0e70b0
>>> -YCbCr[63] = e080c0
>>> +YCbCr[63] = e070b0
>>>
>>> Signed-off-by: Maarten Lankhorst
>> Reviewed-by: Christian König
> Thanks, will commit.
>
> The program I used for testing is attached.
Now it is!
> Also I seem to be getting a lockup if I convert that program to use YV12
> format instead, nouveau requires the interlaced buffer handling for vdec,
> and disables support for progressive video buffers. Would probably also need
> the separate patch, for fixing up vl_video_buffer_surfaces.
>
> ~Maarten
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(*x))
#define ok(a) do { ret = a; if (ret != VDP_STATUS_OK) { fprintf(stderr, "%s:%u %u %s\n", __FUNCTION__, __LINE__, ret, vdp_get_error_string(ret)); exit(1); } } while (0)
VdpGetProcAddress * vdp_get_proc_address;
VdpGetErrorString * vdp_get_error_string;
VdpGetApiVersion * vdp_get_api_version;
VdpGetInformationString * vdp_get_information_string;
VdpDeviceDestroy * vdp_device_destroy;
VdpGenerateCSCMatrix * vdp_generate_csc_matrix;
VdpVideoSurfaceQueryCapabilities * vdp_video_surface_query_capabilities;
VdpVideoSurfaceQueryGetPutBitsYCbCrCapabilities * vdp_video_surface_query_get_put_bits_y_cb_cr_capabilities;
VdpVideoSurfaceCreate * vdp_video_surface_create;
VdpVideoSurfaceDestroy * vdp_video_surface_destroy;
VdpVideoSurfaceGetParameters * vdp_video_surface_get_parameters;
VdpVideoSurfaceGetBitsYCbCr * vdp_video_surface_get_bits_y_cb_cr;
VdpVideoSurfacePutBitsYCbCr * vdp_video_surface_put_bits_y_cb_cr;
VdpOutputSurfaceQueryCapabilities * vdp_output_surface_query_capabilities;
VdpOutputSurfaceQueryGetPutBitsNativeCapabilities * vdp_output_surface_query_get_put_bits_native_capabilities;
VdpOutputSurfaceQueryPutBitsIndexedCapabilities * vdp_output_surface_query_put_bits_indexed_capabilities;
VdpOutputSurfaceQueryPutBitsYCbCrCapabilities * vdp_output_surface_query_put_bits_y_cb_cr_capabilities;
VdpOutputSurfaceCreate * vdp_output_surface_create;
VdpOutputSurfaceDestroy * vdp_output_surface_destroy;
VdpOutputSurfaceGetParameters * vdp_output_surface_get_parameters;
VdpOutputSurfaceGetBitsNative * vdp_output_surface_get_bits_native;
VdpOutputSurfacePutBitsNative * vdp_output_surface_put_bits_native;
VdpOutputSurfacePutBitsIndexed * vdp_output_surface_put_bits_indexed;
VdpOutputSurfacePutBitsYCbCr * vdp_output_surface_put_bits_y_cb_cr;
VdpBitmapSurfaceQueryCapabilities * vdp_bitmap_surface_query_capabilities;
VdpBitmapSurfaceCreate * vdp_bitmap_surface_create;
VdpBitmapSurfaceDestroy * vdp_bitmap_surface_destroy;
VdpBitmapSurfaceGetParameters * vdp_bitmap_surface_get_parameters;
VdpBitmapSurfacePutBitsNative * vdp_bitmap_surface_put_bits_native;
VdpOutputSurfaceRenderOutputSurface * vdp_output_surface_render_output_surface;
VdpOutputSurfaceRenderBitmapSurface * vdp_output_surface_render_bitmap_surface;
VdpDecoderQueryCapabilities * vdp_decoder_query_capabilities;
VdpDecoderCreate * vdp_decoder_create;
VdpDecoderDestroy * vdp_decoder_destroy;
VdpDecoderGetParameters * vdp_decoder_get_parameters;
VdpDecoderRender * vdp_decoder_render;
VdpVideoMixerQueryFeatureSupport * vdp_video_mixer_query_feature_support;
VdpVideoMixerQueryParameterSupport * vdp_video_mixer_query_parameter_support;
VdpVideoMixerQueryAttributeSupport * vdp_video_mixer_query_attribute_support;
VdpVideoMixerQueryParameterValueRange * vdp_video_mixer_query_parameter_value_range;
VdpVideoMixerQueryAttributeValueRange * vdp_video_mixer_query_attribute_value_range;
VdpVideoMixerCreate * vdp_video_mixer_create;
VdpVideoMixerSetFeatureEnable
Re: [Mesa-dev] [PATCH] radeon/llvm: improve cube map handling
On Die, 2012-12-18 at 14:24 +0400, Vadim Girlin wrote: > Add support for cube map arrays, TEX2, TXB2, TXL2, fix SHADOWCUBE. > > Signed-off-by: Vadim Girlin > --- > > The patch includes minimal fix for radeonsi to avoid breaking the build or > introducing regressions, but probably some additional changes are required > to make new features really work on SI. Indeed. I confirmed there are no regressions with piglit quick-driver.tests on radeonsi, thanks! Reviewed-by: Michel Dänzer Tested-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: Fix creation of shared and scanout textures.
On Tue, Dec 18, 2012 at 11:20 AM, Jose Fonseca wrote:
> Looks fine.
>
> I'm curious, what does this fix in practice?
It fixes Weston crashing when running with llvmpipe.
>
> Jose
>
> - Original Message -
>> NOTE: This is a candidate for the stable branches.
>> ---
>> src/gallium/drivers/llvmpipe/lp_texture.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
>> b/src/gallium/drivers/llvmpipe/lp_texture.c
>> index 2e9c6bf..f17a04a 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
>> @@ -295,7 +295,9 @@ llvmpipe_resource_create(struct pipe_screen
>> *_screen,
>> /* assert(lpr->base.bind); */
>>
>> if (resource_is_texture(&lpr->base)) {
>> - if (lpr->base.bind & PIPE_BIND_DISPLAY_TARGET) {
>> + if (lpr->base.bind & (PIPE_BIND_DISPLAY_TARGET |
>> +PIPE_BIND_SCANOUT |
>> +PIPE_BIND_SHARED)) {
>> /* displayable surface */
>> if (!llvmpipe_displaytarget_layout(screen, lpr))
>> goto fail;
>> --
>> 1.8.0.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vl/compositor: fix weave shader bugs
On 18.12.2012 13:21, Maarten Lankhorst wrote: Op 18-12-12 13:04, Maarten Lankhorst schreef: Op 18-12-12 11:42, Christian König schreef: On 18.12.2012 09:18, Maarten Lankhorst wrote: Writemask was XY instead of YZ (thanks to calim for spotting it). The pixel calculation resulted in the pixel always being off by one. If y was .5: y' = round(y) + 0.5 = 1.5 Fixing this also means the LRP function has to swap the pixels it, since it's now the other way around for top/bottom. WIth these fixes only chroma for top and bottom pixel rows are wrongly interpolated in my test program: Sounds good, but what's the reason that first and last row is interpolated wrong? Just some issues with the border color/wrap handling? If I had to guess it interpolates the first and last row, rather than using the exact value of that line for the top/bottom chroma samples there. So it's just border handling sampling from both surfaces that's wrong I think. As you can see in the diff below, it repeats the cbcr[1] value for cbcr[0], similar for cbcr[63] and cbcr[62]: --- nvidia +++ nouveau @@ -1,4 +1,4 @@ -YCbCr[0] = 00c080 +YCbCr[0] = 00b070 YCbCr[1] = 00b070 YCbCr[2] = 029050 YCbCr[3] = 207050 @@ -61,4 +61,4 @@ YCbCr[60] = 0c5070 YCbCr[61] = c05090 YCbCr[62] = 0e70b0 -YCbCr[63] = e080c0 +YCbCr[63] = e070b0 Signed-off-by: Maarten Lankhorst Reviewed-by: Christian König Thanks, will commit. The program I used for testing is attached. Now it is! Thanks and wow, I always wanted to hack together such a test program for VDPAU, but never found time to do so. And now your diff above makes a bit more sense to me :) For the correct interpolation on the first/last line you probably need just another adjustment on the LRP factor, shouldn't be to hard to hack, but at least I don't really have time for that. Also I seem to be getting a lockup if I convert that program to use YV12 format instead, nouveau requires the interlaced buffer handling for vdec, and disables support for progressive video buffers. Would probably also need the separate patch, for fixing up vl_video_buffer_surfaces. Well, as said before (depending a bit on the codec and generation I think) AMD hardware can do both, but I already added some flags indicating to the state tracker what the driver can do and prefers to have. Shouldn't be to hard to just return the right values there. Regarding the order for the interlaced surfaces: I can live with any implementation. IIRC I changed that while it was in development, maybe I have missed the use in the VDPAU state tracker. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: add support for later transform feedback extensions
I'm not very familiar with these features, but if this passes piglit tests then
it sounds good to me FWIW.
It's however weird that using draw->pt.max_index + 1 (i.e., maximum fecthed
vertex) for count_from_stream_output works in general. I'd imagine it to be
some sort of runtime determined amount (which would depend among other things
on the bound geometry shader).
Jose
- Original Message -
> This adds support to draw for the new features of transform feedback.
>
> a) fix count_from_stream_output, using max_index+1 for now but it
> looks
> like it should be valid as its derived from the vertex elements/vbo.
>
> b) fix striding and dst offsets in output buffers - was just wrong
> before.
>
> c) fix crash if tfb is suspended (so.num_targets == 0)
>
> This also enables the new features on softpipe. It should be possible
> to enable them on llvmpipe as well after this commit, but would need
> to schedule piglit runs.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/auxiliary/draw/draw_pt.c | 9 +++--
> src/gallium/auxiliary/draw/draw_pt_so_emit.c | 12 +---
> src/gallium/drivers/softpipe/sp_screen.c | 2 +-
> 3 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_pt.c
> b/src/gallium/auxiliary/draw/draw_pt.c
> index ddaedcd..50b9efa 100644
> --- a/src/gallium/auxiliary/draw/draw_pt.c
> +++ b/src/gallium/auxiliary/draw/draw_pt.c
> @@ -464,7 +464,7 @@ draw_vbo(struct draw_context *draw,
> {
> unsigned instance;
> unsigned index_limit;
> -
> + unsigned count;
> assert(info->instance_count > 0);
> if (info->indexed)
>assert(draw->pt.user.elts);
> @@ -518,6 +518,11 @@ draw_vbo(struct draw_context *draw,
>
> draw->pt.max_index = index_limit - 1;
>
> + count = info->count;
> + if (count == 0) {
> + if (info->count_from_stream_output)
> + count = draw->pt.max_index + 1;
> + }
>
> /*
> * TODO: We could use draw->pt.max_index to further narrow
> @@ -531,7 +536,7 @@ draw_vbo(struct draw_context *draw,
> draw_pt_arrays_restart(draw, info);
>}
>else {
> - draw_pt_arrays(draw, info->mode, info->start, info->count);
> + draw_pt_arrays(draw, info->mode, info->start, count);
>}
> }
> }
> diff --git a/src/gallium/auxiliary/draw/draw_pt_so_emit.c
> b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
> index ecf287f..80a164a 100644
> --- a/src/gallium/auxiliary/draw/draw_pt_so_emit.c
> +++ b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
> @@ -118,6 +118,7 @@ static void so_emit_prim(struct pt_so_emit *so,
> for (i = 0; i < num_vertices; ++i) {
>const float (*input)[4];
>unsigned total_written_compos = 0;
> + int ob;
>/*debug_printf("%d) vertex index = %d (prim idx = %d)\n", i,
>indices[i], prim_idx);*/
>input = (const float (*)[4])(
> (const char *)input_ptr + (indices[i] *
> input_vertex_stride));
> @@ -126,15 +127,17 @@ static void so_emit_prim(struct pt_so_emit *so,
> unsigned idx = state->output[slot].register_index;
> unsigned start_comp = state->output[slot].start_component;
> unsigned num_comps = state->output[slot].num_components;
> - int ob = state->output[slot].output_buffer;
> +
> + ob = state->output[slot].output_buffer;
>
> buffer = (float *)((char *)draw->so.targets[ob]->mapping +
> draw->so.targets[ob]->target.buffer_offset
> +
> -draw->so.targets[ob]->internal_offset);
> +draw->so.targets[ob]->internal_offset) +
> state->output[slot].dst_offset;
> memcpy(buffer, &input[idx][start_comp], num_comps *
> sizeof(float));
> - draw->so.targets[ob]->internal_offset += num_comps *
> sizeof(float);
> total_written_compos += num_comps;
>}
> + for (ob = 0; ob < draw->so.num_targets; ++ob)
> + draw->so.targets[ob]->internal_offset += state->stride[ob]
> * sizeof(float);
> }
> so->emitted_vertices += num_vertices;
> ++so->emitted_primitives;
> @@ -193,6 +196,9 @@ void draw_pt_so_emit( struct pt_so_emit *emit,
> if (!emit->has_so)
>return;
>
> + if (!draw->so.num_targets)
> + return;
> +
> emit->emitted_vertices = 0;
> emit->emitted_primitives = 0;
> emit->generated_primitives = 0;
> diff --git a/src/gallium/drivers/softpipe/sp_screen.c
> b/src/gallium/drivers/softpipe/sp_screen.c
> index 564da5e..840cff6 100644
> --- a/src/gallium/drivers/softpipe/sp_screen.c
> +++ b/src/gallium/drivers/softpipe/sp_screen.c
> @@ -155,10 +155,10 @@ softpipe_get_param(struct pipe_screen *screen,
> enum pipe_cap param)
> case PIPE_CAP_USER_VERTEX_BUFFERS:
> case PIPE_CAP_USER_INDEX_BUFFERS:
> case PIPE_CAP_USER_CONSTANT_BUFFERS:
> + case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
>return
Re: [Mesa-dev] [PATCH 1/4] meta: Pause/resume an active occlusion query over any meta operation
Ian Romanick writes: > I think we need a flag to select this behavior. There are some meta ops > that *do* generate fragments (e.g., _mesa_meta_DrawPixels), and this > will prevent them from being counted. OK. Today I'm writing new piglit tests for all of this. I'll try to get coverage over all of the meta ops so the tests can guide the correct behavior here. -Carl pgpRi2PqjqN6s.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: work around ddx over alignment
From: Jerome Glisse
This force surface allocated from ddx to be consider as height
aligned on 8 and fix 1D->2D tiling transition that result from
this.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/r600/r600_texture.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 56e9b64..9373451 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -89,7 +89,8 @@ static int r600_init_surface(struct r600_screen *rscreen,
struct radeon_surface *surface,
const struct pipe_resource *ptex,
unsigned array_mode,
-bool is_flushed_depth)
+bool is_flushed_depth,
+bool from_ddx)
{
const struct util_format_description *desc =
util_format_description(ptex->format);
@@ -107,6 +108,10 @@ static int r600_init_surface(struct r600_screen *rscreen,
surface->array_size = 1;
surface->last_level = ptex->last_level;
+ if (from_ddx) {
+ surface->npix_y = align(surface->npix_y, 8);
+ }
+
if (rscreen->chip_class >= EVERGREEN && !is_flushed_depth &&
ptex->format == PIPE_FORMAT_Z32_FLOAT_S8X24_UINT) {
surface->bpe = 4; /* stencil is allocated separately on
evergreen */
@@ -539,7 +544,8 @@ struct pipe_resource *r600_texture_create(struct
pipe_screen *screen,
}
r = r600_init_surface(rscreen, &surface, templ, array_mode,
- templ->flags & R600_RESOURCE_FLAG_FLUSHED_DEPTH);
+ templ->flags & R600_RESOURCE_FLAG_FLUSHED_DEPTH,
+ false);
if (r) {
return NULL;
}
@@ -627,7 +633,7 @@ struct pipe_resource *r600_texture_from_handle(struct
pipe_screen *screen,
else
array_mode = V_038000_ARRAY_LINEAR_ALIGNED;
- r = r600_init_surface(rscreen, &surface, templ, array_mode, false);
+ r = r600_init_surface(rscreen, &surface, templ, array_mode, false,
true);
if (r) {
return NULL;
}
--
1.8.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: work around ddx over alignment
Reviewed-by: Marek Olšák
Thank you!
Marek
On Tue, Dec 18, 2012 at 6:50 PM, wrote:
> From: Jerome Glisse
>
> This force surface allocated from ddx to be consider as height
> aligned on 8 and fix 1D->2D tiling transition that result from
> this.
>
> Signed-off-by: Jerome Glisse
> ---
> src/gallium/drivers/r600/r600_texture.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_texture.c
> b/src/gallium/drivers/r600/r600_texture.c
> index 56e9b64..9373451 100644
> --- a/src/gallium/drivers/r600/r600_texture.c
> +++ b/src/gallium/drivers/r600/r600_texture.c
> @@ -89,7 +89,8 @@ static int r600_init_surface(struct r600_screen *rscreen,
> struct radeon_surface *surface,
> const struct pipe_resource *ptex,
> unsigned array_mode,
> -bool is_flushed_depth)
> +bool is_flushed_depth,
> +bool from_ddx)
> {
> const struct util_format_description *desc =
> util_format_description(ptex->format);
> @@ -107,6 +108,10 @@ static int r600_init_surface(struct r600_screen *rscreen,
> surface->array_size = 1;
> surface->last_level = ptex->last_level;
>
> + if (from_ddx) {
> + surface->npix_y = align(surface->npix_y, 8);
> + }
> +
> if (rscreen->chip_class >= EVERGREEN && !is_flushed_depth &&
> ptex->format == PIPE_FORMAT_Z32_FLOAT_S8X24_UINT) {
> surface->bpe = 4; /* stencil is allocated separately on
> evergreen */
> @@ -539,7 +544,8 @@ struct pipe_resource *r600_texture_create(struct
> pipe_screen *screen,
> }
>
> r = r600_init_surface(rscreen, &surface, templ, array_mode,
> - templ->flags &
> R600_RESOURCE_FLAG_FLUSHED_DEPTH);
> + templ->flags & R600_RESOURCE_FLAG_FLUSHED_DEPTH,
> + false);
> if (r) {
> return NULL;
> }
> @@ -627,7 +633,7 @@ struct pipe_resource *r600_texture_from_handle(struct
> pipe_screen *screen,
> else
> array_mode = V_038000_ARRAY_LINEAR_ALIGNED;
>
> - r = r600_init_surface(rscreen, &surface, templ, array_mode, false);
> + r = r600_init_surface(rscreen, &surface, templ, array_mode, false,
> true);
> if (r) {
> return NULL;
> }
> --
> 1.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2856,7 +2856,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
mask &= ~GL_STENCIL_BUFFER_BIT;
}
else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
- _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
+ _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS) ||
+ /* OpenGL/ES specification is not very clear about it. But GLES3
+* conformance test expects GL_INVALID_OPERATION in case of
below
+* listed combination of formats for read/draw buffers.
+*/
+ (readRb->InternalFormat == GL_DEPTH32F_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH24_STENCIL8) ||
+ (readRb->InternalFormat == GL_DEPTH24_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH32F_STENCIL8)) {
It seems like this is just trying to verify that the depth bits are the
same for both buffers.
_mesa_get_format_buts(readRb->Format, GL_DEPTH_BITS) !=
_mesa_get_format_buts(drawRb->Format, GL_DEPTH_BITS)
Right? I suspect there is some spec text that supports generating an
error in that scenario.
/* There is no need to check the stencil datatype here, because
* there is only one: GL_UNSIGNED_INT.
*/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2856,7 +2856,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
mask &= ~GL_STENCIL_BUFFER_BIT;
}
else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
- _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
+ _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS) ||
+ /* OpenGL/ES specification is not very clear about it. But GLES3
+* conformance test expects GL_INVALID_OPERATION in case of
below
+* listed combination of formats for read/draw buffers.
+*/
+ (readRb->InternalFormat == GL_DEPTH32F_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH24_STENCIL8) ||
+ (readRb->InternalFormat == GL_DEPTH24_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH32F_STENCIL8)) {
/* There is no need to check the stencil datatype here, because
* there is only one: GL_UNSIGNED_INT.
*/
I found this text:
From the OpenGL 3.0 spec, section 4.3 (page 277):
"Calling BlitFramebuffer will result in an INVALID_OPERATION error if
mask includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and the source and
destination depth and stencil buffer formats do not match."
This text also appears in the ES 3.0 and GL 4.2 specs.
I believe the existing code's interpretation of this paragraph was:
- if DEPTH_BUFFER_BIT is set, source & destination depth buffer
formats must match.
- if STENCIL_BUFFER_BIT is set, source & destination stencil buffer
formats must match.
An alternate interpretation that might appease those tests is:
- if *either* DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT is set, both the
depth *and* stencil formats must match.
If that's the case, you can simply check readRb->Format ==
drawRb->Format. It seems reasonable to me, at least for packed formats.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] meta: Add functionality to do _mesa_meta_BlitFrameBuffer() using glsl
On 12/17/2012 07:33 PM, Anuj Phogat wrote:
This patch rewrites _mesa_meta_BlitFrameBuffer() function to add support
for blitting with GLSL/GLSL ES shaders. These changes were required to
support glBlitFrameBuffer() in gles3. This patch, along with other patches
in this series, make 16 failing framebuffer_blit test cases in gles3
conformance pass.
v2: properly handle flipped blits for source and destination renderbuffers
/ textures. Add support for GL_TEXTURE_RECTANGLE in
_mesa_meta_BlitFrameBuffer.
Create a temp depth texture to support depth buffer blitting.
These changes don't cause any regressions in gles3 conformance and piglit
quick.tests.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/common/meta.c | 460 +++-
1 files changed, 356 insertions(+), 104 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index f95d207..13bd155 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -222,6 +222,9 @@ struct blit_state
GLuint ArrayObj;
GLuint VBO;
GLuint DepthFP;
+ GLuint ShaderProg;
+ GLuint RectShaderProg;
+ struct temp_texture depthTex;
};
@@ -1145,7 +1148,7 @@ static void
init_temp_texture(struct gl_context *ctx, struct temp_texture *tex)
{
/* prefer texture rectangle */
- if (ctx->Extensions.NV_texture_rectangle) {
+ if (_mesa_is_desktop_gl(ctx) && ctx->Extensions.NV_texture_rectangle) {
tex->Target = GL_TEXTURE_RECTANGLE;
tex->MaxSize = ctx->Const.MaxTextureRectSize;
tex->NPOT = GL_TRUE;
@@ -1206,6 +1209,21 @@ get_bitmap_temp_texture(struct gl_context *ctx)
return tex;
}
+/**
+ * Return pointer to depth temp_texture.
+ * This does some one-time init if needed.
+ */
+static struct temp_texture *
+get_temp_depth_texture(struct gl_context *ctx)
+{
+ struct temp_texture *tex = &ctx->Meta->Blit.depthTex;
+
+ if (!tex->TexObj) {
+ init_temp_texture(ctx, tex);
+ }
+
+ return tex;
+}
/**
* Compute the width/height of texture needed to draw an image of the
@@ -1389,6 +1407,158 @@ init_blit_depth_pixels(struct gl_context *ctx)
strlen(program2), (const GLubyte *) program2);
}
+static void
+setup_ff_blit_framebuffer(struct gl_context *ctx,
+ struct blit_state *blit)
+{
+ struct vertex {
+ GLfloat x, y, s, t;
+ };
+ struct vertex verts[4];
+
+ if (blit->ArrayObj == 0) {
+ /* one-time setup */
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1, &blit->ArrayObj);
+ _mesa_BindVertexArray(blit->ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffers(1, &blit->VBO);
+ _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, blit->VBO);
+ _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
+ NULL, GL_DYNAMIC_DRAW_ARB);
+
+ /* setup vertex arrays */
+ _mesa_VertexPointer(2, GL_FLOAT, sizeof(struct vertex), OFFSET(x));
+ _mesa_TexCoordPointer(2, GL_FLOAT, sizeof(struct vertex), OFFSET(s));
+ _mesa_EnableClientState(GL_VERTEX_ARRAY);
+ _mesa_EnableClientState(GL_TEXTURE_COORD_ARRAY);
+ }
+
+ /* setup projection matrix */
+ _mesa_MatrixMode(GL_PROJECTION);
+ _mesa_LoadIdentity();
+ _mesa_Ortho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);
+
+}
+
+static void
+setup_glsl_blit_framebuffer(struct gl_context *ctx,
+struct blit_state *blit,
+GLenum target)
+{
+ struct vertex {
+ GLfloat x, y, s, t;
+ };
+ struct vertex verts[4];
+ const char *vs_source;
+ char *fs_source;
+ GLuint vs, fs;
+ void *mem_ctx;
+ GLuint ShaderProg;
+ GLboolean texture_2d = (target == GL_TEXTURE_2D);
+
+ /* Check if already initialized */
+ if (blit->ArrayObj == 0) {
+
+ /* create vertex array object */
+ _mesa_GenVertexArrays(1, &blit->ArrayObj);
+ _mesa_BindVertexArray(blit->ArrayObj);
+
+ /* create vertex array buffer */
+ _mesa_GenBuffers(1, &blit->VBO);
+ _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, blit->VBO);
+ _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
+ NULL, GL_DYNAMIC_DRAW_ARB);
+
+ /* setup vertex arrays */
+ _mesa_VertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE,
+ sizeof(struct vertex), OFFSET(x));
+ _mesa_VertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE,
+ sizeof(struct vertex), OFFSET(s));
+ }
+
+ /* Generate a fragment shader program appropriate for the texture target */
+ if ((target == GL_TEXTURE_2D && blit->ShaderProg != 0) ||
+ (target == GL_TEXTURE_RECTANGLE && blit->RectShaderProg != 0)) {
+ return;
+ }
+
+ mem_ctx = ralloc_context(NULL);
+
+ if ((ctx->API == API_OPENGLES2 && ctx->Version < 30) ||
+ ctx->Const.GLSLVersion < 130) {
If we get ctx->API == API_OPENGLES2 && ctx->Version < 30 we should bail.
There is n
Re: [Mesa-dev] [PATCH 4/6] intel: Fix framebuffer blitting to GL_COLOR_ATTACHMENTi when i!=0
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |5 +-
src/mesa/drivers/dri/intel/intel_fbo.c | 85 --
2 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index e8604e7..41a8734 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -263,8 +263,9 @@ try_blorp_blit(struct intel_context *intel,
}
for (unsigned i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; ++i) {
dst_irb = intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i]);
- do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0, srcY0,
- dstX0, dstY0, dstX1, dstY1, mirror_x, mirror_y);
+if (dst_irb)
+do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0, srcY0,
+ dstX0, dstY0, dstX1, dstY1, mirror_x, mirror_y);
}
break;
case GL_DEPTH_BUFFER_BIT:
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 6a66521..d0e9fe2 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -793,44 +793,65 @@ intel_blit_framebuffer_copy_tex_sub_image(struct
gl_context *ctx,
GLbitfield mask, GLenum filter)
{
if (mask & GL_COLOR_BUFFER_BIT) {
+ GLboolean result = false;
Use bool.
const struct gl_framebuffer *drawFb = ctx->DrawBuffer;
const struct gl_framebuffer *readFb = ctx->ReadBuffer;
- const struct gl_renderbuffer_attachment *drawAtt =
- &drawFb->Attachment[drawFb->_ColorDrawBufferIndexes[0]];
+ const struct gl_renderbuffer_attachment *drawAtt;
struct intel_renderbuffer *srcRb =
intel_renderbuffer(readFb->_ColorReadBuffer);
- /* If the source and destination are the same size with no
- mirroring, the rectangles are within the size of the
- texture and there is no scissor then we can use
- glCopyTexSubimage2D to implement the blit. This will end
- up as a fast hardware blit on some drivers */
- if (srcRb && drawAtt && drawAtt->Texture &&
- srcX0 - srcX1 == dstX0 - dstX1 &&
- srcY0 - srcY1 == dstY0 - dstY1 &&
- srcX1 >= srcX0 &&
- srcY1 >= srcY0 &&
- srcX0 >= 0 && srcX1 <= readFb->Width &&
- srcY0 >= 0 && srcY1 <= readFb->Height &&
- dstX0 >= 0 && dstX1 <= drawFb->Width &&
- dstY0 >= 0 && dstY1 <= drawFb->Height &&
- !ctx->Scissor.Enabled) {
- const struct gl_texture_object *texObj = drawAtt->Texture;
- const GLuint dstLevel = drawAtt->TextureLevel;
- const GLenum target = texObj->Target;
-
- struct gl_texture_image *texImage =
-_mesa_select_tex_image(ctx, texObj, target, dstLevel);
-
- if (intel_copy_texsubimage(intel_context(ctx),
-intel_texture_image(texImage),
-dstX0, dstY0,
-srcRb,
-srcX0, srcY0,
-srcX1 - srcX0, /* width */
-srcY1 - srcY0))
-mask &= ~GL_COLOR_BUFFER_BIT;
+ /* Blit to all active draw buffers */
+ for (int i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
+ int idx = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
+ if (idx != -1) {
+ drawAtt = &drawFb->Attachment[idx];
+ }
+ else
+ continue;
if (idx == -1)
continue;
drawAtt = &drawFb->Attachment[idx];
...
+
+ /* If the source and destination are the same size with no
+mirroring, the rectangles are within the size of the
+texture and there is no scissor then we can use
+glCopyTexSubimage2D to implement the blit. This will end
+up as a fast hardware blit on some drivers */
+ if (srcRb && drawAtt && drawAtt->Texture &&
+ srcX0 - srcX1 == dstX0 - dstX1 &&
+ srcY0 - srcY1 == dstY0 - dstY1 &&
+ srcX1 >= srcX0 &&
+ srcY1 >= srcY0 &&
+ srcX0 >= 0 && srcX1 <= readFb->Width &&
+ srcY0 >= 0 && srcY1 <= readFb->Height &&
+ dstX0 >= 0 && dstX1 <= drawFb->Width &&
+ dstY0 >= 0 && dstY1 <= drawFb->Height &&
+ !ctx->Scissor.Enabled) {
+const struct gl_texture_object *texObj = drawAtt->Texture;
+const GLuint dstLevel = drawAtt->Text
Re: [Mesa-dev] [PATCH 4/6] intel: Fix framebuffer blitting to GL_COLOR_ATTACHMENTi when i!=0
On 12/18/2012 11:20 AM, Ian Romanick wrote:
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-off-by: Anuj Phogat
Also... if this patch doesn't depend on previous patches in the series,
it should be marked as a candidate for the 9.0 branch.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |5 +-
src/mesa/drivers/dri/intel/intel_fbo.c | 85
--
2 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index e8604e7..41a8734 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -263,8 +263,9 @@ try_blorp_blit(struct intel_context *intel,
}
for (unsigned i = 0; i <
ctx->DrawBuffer->_NumColorDrawBuffers; ++i) {
dst_irb =
intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i]);
- do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0,
srcY0,
- dstX0, dstY0, dstX1, dstY1, mirror_x, mirror_y);
+ if (dst_irb)
+do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0,
srcY0,
+ dstX0, dstY0, dstX1, dstY1, mirror_x,
mirror_y);
}
break;
case GL_DEPTH_BUFFER_BIT:
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 6a66521..d0e9fe2 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -793,44 +793,65 @@ intel_blit_framebuffer_copy_tex_sub_image(struct
gl_context *ctx,
GLbitfield mask, GLenum
filter)
{
if (mask & GL_COLOR_BUFFER_BIT) {
+ GLboolean result = false;
Use bool.
const struct gl_framebuffer *drawFb = ctx->DrawBuffer;
const struct gl_framebuffer *readFb = ctx->ReadBuffer;
- const struct gl_renderbuffer_attachment *drawAtt =
- &drawFb->Attachment[drawFb->_ColorDrawBufferIndexes[0]];
+ const struct gl_renderbuffer_attachment *drawAtt;
struct intel_renderbuffer *srcRb =
intel_renderbuffer(readFb->_ColorReadBuffer);
- /* If the source and destination are the same size with no
- mirroring, the rectangles are within the size of the
- texture and there is no scissor then we can use
- glCopyTexSubimage2D to implement the blit. This will end
- up as a fast hardware blit on some drivers */
- if (srcRb && drawAtt && drawAtt->Texture &&
- srcX0 - srcX1 == dstX0 - dstX1 &&
- srcY0 - srcY1 == dstY0 - dstY1 &&
- srcX1 >= srcX0 &&
- srcY1 >= srcY0 &&
- srcX0 >= 0 && srcX1 <= readFb->Width &&
- srcY0 >= 0 && srcY1 <= readFb->Height &&
- dstX0 >= 0 && dstX1 <= drawFb->Width &&
- dstY0 >= 0 && dstY1 <= drawFb->Height &&
- !ctx->Scissor.Enabled) {
- const struct gl_texture_object *texObj = drawAtt->Texture;
- const GLuint dstLevel = drawAtt->TextureLevel;
- const GLenum target = texObj->Target;
-
- struct gl_texture_image *texImage =
-_mesa_select_tex_image(ctx, texObj, target, dstLevel);
-
- if (intel_copy_texsubimage(intel_context(ctx),
-intel_texture_image(texImage),
-dstX0, dstY0,
-srcRb,
-srcX0, srcY0,
-srcX1 - srcX0, /* width */
-srcY1 - srcY0))
-mask &= ~GL_COLOR_BUFFER_BIT;
+ /* Blit to all active draw buffers */
+ for (int i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
+ int idx = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
+ if (idx != -1) {
+ drawAtt = &drawFb->Attachment[idx];
+ }
+ else
+ continue;
if (idx == -1)
continue;
drawAtt = &drawFb->Attachment[idx];
...
+
+ /* If the source and destination are the same size with no
+mirroring, the rectangles are within the size of the
+texture and there is no scissor then we can use
+glCopyTexSubimage2D to implement the blit. This will end
+up as a fast hardware blit on some drivers */
+ if (srcRb && drawAtt && drawAtt->Texture &&
+ srcX0 - srcX1 == dstX0 - dstX1 &&
+ srcY0 - srcY1 == dstY0 - dstY1 &&
+ srcX1 >= srcX0 &&
+ srcY1 >= srcY0 &&
+ srcX0 >= 0 && srcX1 <= readFb->Width &&
+ srcY0 >= 0 && srcY1 <= readFb->Height &&
+ dstX0 >= 0 && dstX1 <= drawFb->Width &&
+ dstY0 >= 0 && dstY1 <= dra
Re: [Mesa-dev] [PATCH 5/6] mesa: Fix GL error generation in _mesa_GetFramebufferAttachmentParameteriv()
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
Signed-off-by: Anuj Phogat
Reviewed-by: Ian Romanick
---
src/mesa/main/fbobject.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9e32836..d87239e 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -250,6 +250,7 @@ _mesa_get_fb0_attachment(struct gl_context *ctx, struct
gl_framebuffer *fb,
return &fb->Attachment[BUFFER_FRONT_LEFT];
case GL_FRONT_RIGHT:
return &fb->Attachment[BUFFER_FRONT_RIGHT];
+ case GL_BACK:
case GL_BACK_LEFT:
return &fb->Attachment[BUFFER_BACK_LEFT];
case GL_BACK_RIGHT:
@@ -2369,7 +2370,8 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum target,
GLenum attachment,
* OES_framebuffer_object spec refers to the EXT_framebuffer_object
* spec.
*/
- if (!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object) {
+ if ((!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object)
+ && !_mesa_is_gles3(ctx)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glGetFramebufferAttachmentParameteriv(bound FBO = 0)");
return;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] mesa: Fix framebuffer blitting to GL_COLOR_ATTACHMENTi when i!=0
On 12/17/2012 07:35 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
It also fixes a blitting case when drawAttachment->Texture ==
readAttachment->Texture. This was causing an assertion failure in intel's
i965 drivers (intel_miptree_attach_map()) with gles3 conformance test case:
framebuffer_blit_functionality_minifying_blit
V2: Fixed a case when number of draw buffer attachments are zero.
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 14 +-
src/mesa/swrast/s_blit.c | 33 ++---
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index d87239e..f4e427b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2818,8 +2818,20 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
/* get color read/draw renderbuffers */
if (mask & GL_COLOR_BUFFER_BIT) {
+ const GLuint numColorDrawBuffers =
+ ctx->DrawBuffer->_NumColorDrawBuffers;
colorReadRb = readFb->_ColorReadBuffer;
- colorDrawRb = drawFb->_ColorDrawBuffers[0];
+
+ if (numColorDrawBuffers > 0) {
+ for (int i = 0; i < numColorDrawBuffers; i++) {
+if (ctx->DrawBuffer->_ColorDrawBuffers[i] != NULL) {
+ colorDrawRb = ctx->DrawBuffer->_ColorDrawBuffers[i];
+ break;
+ }
+ }
+ }
+ else
+ colorDrawRb = NULL;
/* From the EXT_framebuffer_object spec:
*
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index b0c56a4..c579572 100644
--- a/src/mesa/swrast/s_blit.c
+++ b/src/mesa/swrast/s_blit.c
@@ -111,6 +111,9 @@ blit_nearest(struct gl_context *ctx,
GLbitfield buffer)
{
struct gl_renderbuffer *readRb, *drawRb;
+ struct gl_renderbuffer_attachment *readAtt, *drawAtt;
+ struct gl_framebuffer *readFb = ctx->ReadBuffer;
+ struct gl_framebuffer *drawFb = ctx->DrawBuffer;
const GLint srcWidth = ABS(srcX1 - srcX0);
const GLint dstWidth = ABS(dstX1 - dstX0);
@@ -146,8 +149,18 @@ blit_nearest(struct gl_context *ctx,
switch (buffer) {
case GL_COLOR_BUFFER_BIT:
- readRb = ctx->ReadBuffer->_ColorReadBuffer;
- drawRb = ctx->DrawBuffer->_ColorDrawBuffers[0];
+ readAtt = &readFb->Attachment[readFb->_ColorReadBufferIndex];
+ for (int i = 0; i < drawFb->_NumColorDrawBuffers; i++) {
+ int idx = drawFb->_ColorDrawBufferIndexes[i];
+ if (idx != -1) {
+ drawAtt = &drawFb->Attachment[idx];
+ }
+ else {
+continue;
Shouldn't this break when a non -1 index is found?
if (idx != -1) {
drawAtt = &drawFb->Attachment[idx];
break;
}
+ }
+ }
+ readRb = readFb->_ColorReadBuffer;
+ drawRb = drawAtt->Renderbuffer;
if (readRb->Format == drawRb->Format) {
mode = DIRECT;
@@ -159,8 +172,10 @@ blit_nearest(struct gl_context *ctx,
break;
case GL_DEPTH_BUFFER_BIT:
- readRb = ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
- drawRb = ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
+ readAtt = &readFb->Attachment[BUFFER_DEPTH];
+ drawAtt = &drawFb->Attachment[BUFFER_DEPTH];
+ readRb = readAtt->Renderbuffer;
+ drawRb = drawAtt->Renderbuffer;
/* Note that for depth/stencil, the formats of src/dst must match. By
* using the core helpers for pack/unpack, we avoid needing to handle
@@ -175,8 +190,10 @@ blit_nearest(struct gl_context *ctx,
pixelSize = 4;
break;
case GL_STENCIL_BUFFER_BIT:
- readRb = ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer;
- drawRb = ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer;
+ readAtt = &readFb->Attachment[BUFFER_STENCIL];
+ drawAtt = &drawFb->Attachment[BUFFER_STENCIL];
+ readRb = readAtt->Renderbuffer;
+ drawRb = drawAtt->Renderbuffer;
mode = UNPACK_S;
pixelSize = 1;
break;
@@ -208,7 +225,9 @@ blit_nearest(struct gl_context *ctx,
return;
}
- if (readRb == drawRb) {
+ if ((readRb == drawRb) ||
+ (readAtt->Texture && drawAtt->Texture &&
+(readAtt->Texture == drawAtt->Texture))) {
/* map whole buffer for read/write */
/* XXX we could be clever and just map the union region of the
* source and dest rects.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] intel: Fix framebuffer blitting to GL_COLOR_ATTACHMENTi when i!=0
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp |5 +-
src/mesa/drivers/dri/intel/intel_fbo.c | 85 --
2 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index e8604e7..41a8734 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -263,8 +263,9 @@ try_blorp_blit(struct intel_context *intel,
}
for (unsigned i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; ++i) {
dst_irb = intel_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[i]);
- do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0, srcY0,
- dstX0, dstY0, dstX1, dstY1, mirror_x, mirror_y);
+if (dst_irb)
+do_blorp_blit(intel, buffer_bit, src_irb, dst_irb, srcX0, srcY0,
+ dstX0, dstY0, dstX1, dstY1, mirror_x, mirror_y);
}
This change looks unrelated. Why is it in this patch?
break;
case GL_DEPTH_BUFFER_BIT:
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 6a66521..d0e9fe2 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -793,44 +793,65 @@ intel_blit_framebuffer_copy_tex_sub_image(struct
gl_context *ctx,
GLbitfield mask, GLenum filter)
{
if (mask & GL_COLOR_BUFFER_BIT) {
+ GLboolean result = false;
const struct gl_framebuffer *drawFb = ctx->DrawBuffer;
const struct gl_framebuffer *readFb = ctx->ReadBuffer;
- const struct gl_renderbuffer_attachment *drawAtt =
- &drawFb->Attachment[drawFb->_ColorDrawBufferIndexes[0]];
+ const struct gl_renderbuffer_attachment *drawAtt;
struct intel_renderbuffer *srcRb =
intel_renderbuffer(readFb->_ColorReadBuffer);
- /* If the source and destination are the same size with no
- mirroring, the rectangles are within the size of the
- texture and there is no scissor then we can use
- glCopyTexSubimage2D to implement the blit. This will end
- up as a fast hardware blit on some drivers */
- if (srcRb && drawAtt && drawAtt->Texture &&
- srcX0 - srcX1 == dstX0 - dstX1 &&
- srcY0 - srcY1 == dstY0 - dstY1 &&
- srcX1 >= srcX0 &&
- srcY1 >= srcY0 &&
- srcX0 >= 0 && srcX1 <= readFb->Width &&
- srcY0 >= 0 && srcY1 <= readFb->Height &&
- dstX0 >= 0 && dstX1 <= drawFb->Width &&
- dstY0 >= 0 && dstY1 <= drawFb->Height &&
- !ctx->Scissor.Enabled) {
- const struct gl_texture_object *texObj = drawAtt->Texture;
- const GLuint dstLevel = drawAtt->TextureLevel;
- const GLenum target = texObj->Target;
-
- struct gl_texture_image *texImage =
-_mesa_select_tex_image(ctx, texObj, target, dstLevel);
-
- if (intel_copy_texsubimage(intel_context(ctx),
-intel_texture_image(texImage),
-dstX0, dstY0,
-srcRb,
-srcX0, srcY0,
-srcX1 - srcX0, /* width */
-srcY1 - srcY0))
-mask &= ~GL_COLOR_BUFFER_BIT;
+ /* Blit to all active draw buffers */
+ for (int i = 0; i < ctx->DrawBuffer->_NumColorDrawBuffers; i++) {
+ int idx = ctx->DrawBuffer->_ColorDrawBufferIndexes[i];
+ if (idx != -1) {
+ drawAtt = &drawFb->Attachment[idx];
+ }
+ else
+ continue;
Could we please do:
if (idx == -1)
continue;
drawAtt = &drawFb->Attachment[idx];
it's just a bit easier to read.
+ /* If the source and destination are the same size with no
+mirroring, the rectangles are within the size of the
+texture and there is no scissor then we can use
+glCopyTexSubimage2D to implement the blit. This will end
+up as a fast hardware blit on some drivers */
+ if (srcRb && drawAtt && drawAtt->Texture &&
+ srcX0 - srcX1 == dstX0 - dstX1 &&
+ srcY0 - srcY1 == dstY0 - dstY1 &&
+ srcX1 >= srcX0 &&
+ srcY1 >= srcY0 &&
+ srcX0 >= 0 && srcX1 <= readFb->Width &&
+ srcY0 >= 0 && srcY1 <= readFb->Height &&
+ dstX0 >= 0 && dstX1 <= drawFb->Width &&
+ dstY0 >= 0 && dstY1 <= drawFb->Height &&
+ !ctx->Scissor.Enabled) {
+const struct gl_texture_obje
Re: [Mesa-dev] [PATCH 5/6] mesa: Fix GL error generation in _mesa_GetFramebufferAttachmentParameteriv()
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9e32836..d87239e 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -250,6 +250,7 @@ _mesa_get_fb0_attachment(struct gl_context *ctx, struct
gl_framebuffer *fb,
return &fb->Attachment[BUFFER_FRONT_LEFT];
case GL_FRONT_RIGHT:
return &fb->Attachment[BUFFER_FRONT_RIGHT];
+ case GL_BACK:
case GL_BACK_LEFT:
return &fb->Attachment[BUFFER_BACK_LEFT];
case GL_BACK_RIGHT:
@@ -2369,7 +2370,8 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum target,
GLenum attachment,
* OES_framebuffer_object spec refers to the EXT_framebuffer_object
* spec.
*/
- if (!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object) {
+ if ((!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object)
+ && !_mesa_is_gles3(ctx)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glGetFramebufferAttachmentParameteriv(bound FBO = 0)");
return;
This makes glGetFramebufferAttachmentParameteriv() accept GL_BACK on
desktop GL (which is not allowed) and also allows ES 3 to accept the
GL_*_LEFT/RIGHT targets (which are also not allowed).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 5/6] mesa: Fix corner cases of BindBufferBase with transform feedback.
On 12/15/2012 10:09 PM, Paul Berry wrote:
This patch implements the following behaviours, which are mandated by
the GL 4.3 and GLES3 specs.
1. Regarding the GL_TRANSFORM_FEEDBACK_BUFFER_SIZE query: "If the
... size was not specified when the buffer object was bound
(e.g. if it was bound with BindBufferBase), ... zero is returned."
(GL 4.3 section 6.7.1 "Indexed Buffer Object Limits and Binding
Queries").
2. "BindBufferBase binds the entire buffer, even when the size of the
buffer is changed after the binding is established. It is
equivalent to calling BindBufferRange with offset zero, while size
is determined by the size of the bound buffer at the time the
binding is used." (GL 4.3 section 6.1.1 "Binding Buffer Objects to
Indexed Targets"). I interpret "at the time the binding is used"
to mean "at the time of the call to glBeginTransformFeedback".
3. "Regardless of the size specified with BindBufferRange, or
indirectly with BindBufferBase, the GL will never read or write
beyond the end of a bound buffer. In some cases this constraint may
result in visibly different behavior when a buffer overflow would
otherwise result, such as described for transform feedback
operations in section 13.2.2." (GL 4.3 section 6.1.1 "Binding
Buffer Objects to Indexed Targets").
Item 1 has been part of the spec all the way back to the inception of
the EXT_transform_feedback extension. Items 2 and 3 were added in GL
4.2 and GLES 3.
Prior to GL 4.2, in place of items 2 and 3, the spec simply said
"BindBufferBase is equivalent to calling BindBufferRange with offset
zero and size equal to the size of buffer." For transform feedback,
Mesa behaved as though this meant "...equal to the size of buffer at
the time of the call to BindBufferBase". However, this was
problematic because it left it ambiguous what to do if the buffer is
shrunk between the call to BindBuffer{Base,Range} and the call to
BeginTransformFeedback. Prior to this patch, Mesa's behaviour was to
try to write beyond the end of the buffer, likely resulting in memory
corruption. In light of this, I'm interpreting the spec change as a
clarification, not an intended behavioural change, so I'm making the
change apply regardless of API version.
Fixes GLES3 conformance test transform_feedback2_pause_resume.test.
Cc: Eric Anholt
Reviewed-by: Ian Romanick
---
src/mesa/main/get.c | 3 +-
src/mesa/main/mtypes.h| 13 +++-
src/mesa/main/transformfeedback.c | 69 ++-
3 files changed, 68 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index f3dbda2..273a79f 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1574,7 +1574,8 @@ find_value_indexed(const char *func, GLenum pname, GLuint
index, union value *v)
goto invalid_value;
if (!ctx->Extensions.EXT_transform_feedback)
goto invalid_enum;
- v->value_int64 = ctx->TransformFeedback.CurrentObject->Size[index];
+ v->value_int64
+ = ctx->TransformFeedback.CurrentObject->RequestedSize[index];
return TYPE_INT64;
case GL_TRANSFORM_FEEDBACK_BUFFER_BINDING:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 18ab2db..96b84d8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1825,8 +1825,19 @@ struct gl_transform_feedback_object
/** Start of feedback data in dest buffer */
GLintptr Offset[MAX_FEEDBACK_BUFFERS];
- /** Max data to put into dest buffer (in bytes) */
+
+ /**
+* Max data to put into dest buffer (in bytes). Computed based on
+* RequestedSize and the actual size of the buffer.
+*/
GLsizeiptr Size[MAX_FEEDBACK_BUFFERS];
+
+ /**
+* Size that was specified when the buffer was bound. If the buffer was
+* bound with glBindBufferBase() or glBindBufferOffsetEXT(), this value is
+* zero.
+*/
+ GLsizeiptr RequestedSize[MAX_FEEDBACK_BUFFERS];
};
diff --git a/src/mesa/main/transformfeedback.c
b/src/mesa/main/transformfeedback.c
index 4782a6f..dd03038 100644
--- a/src/mesa/main/transformfeedback.c
+++ b/src/mesa/main/transformfeedback.c
@@ -247,6 +247,55 @@ _mesa_init_transform_feedback_functions(struct
dd_function_table *driver)
/**
+ * Fill in the correct Size value for each buffer in \c obj.
+ *
+ * From the GL 4.3 spec, section 6.1.1 ("Binding Buffer Objects to Indexed
+ * Targets"):
+ *
+ * BindBufferBase binds the entire buffer, even when the size of the buffer
+ * is changed after the binding is established. It is equivalent to calling
+ * BindBufferRange with offset zero, while size is determined by the size of
+ * the bound buffer at the time the binding is used.
+ *
+ * Regardless of the size specified with BindBufferRange, or indirectly with
+ * BindBufferBase, the GL will never read or write beyond the end of a bound
+ * buffer. In some cases this constraint may r
Re: [Mesa-dev] [PATCH 6/6] mesa: Fix framebuffer blitting to GL_COLOR_ATTACHMENTi when i!=0
On 12/17/2012 07:35 PM, Anuj Phogat wrote:
This patch fixes a case when blitting to a framebuffer with
renderbuffers/textures attached to GL_COLOR_ATTACHMENT{1, 2, ...}.
Earlier we were incorrectly blitting to GL_COLOR_ATTACHMENT0 by default.
It also fixes a blitting case when drawAttachment->Texture ==
readAttachment->Texture. This was causing an assertion failure in intel's
i965 drivers (intel_miptree_attach_map()) with gles3 conformance test case:
framebuffer_blit_functionality_minifying_blit
V2: Fixed a case when number of draw buffer attachments are zero.
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 14 +-
src/mesa/swrast/s_blit.c | 33 ++---
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index d87239e..f4e427b 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2818,8 +2818,20 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
/* get color read/draw renderbuffers */
if (mask & GL_COLOR_BUFFER_BIT) {
+ const GLuint numColorDrawBuffers =
+ ctx->DrawBuffer->_NumColorDrawBuffers;
colorReadRb = readFb->_ColorReadBuffer;
- colorDrawRb = drawFb->_ColorDrawBuffers[0];
+
+ if (numColorDrawBuffers > 0) {
+ for (int i = 0; i < numColorDrawBuffers; i++) {
+if (ctx->DrawBuffer->_ColorDrawBuffers[i] != NULL) {
+ colorDrawRb = ctx->DrawBuffer->_ColorDrawBuffers[i];
+ break;
+ }
+ }
+ }
+ else
+ colorDrawRb = NULL;
This looks wrong to me. You're looping through all the draw buffers,
advancing the pointer until you find the first drawbuffer, then
stopping...but you're not doing any checks.
I believe you actually want to check the read buffer against *each* of
the draw buffers, i.e.
colorReadRb = readFb->_ColorReadBuffer;
for (int i = 0; i < numColorDrawBuffers; i++) {
if (ctx->DrawBuffer->_ColorDrawBuffers[i] == NULL) {
continue;
/* From the EXT_framebuffer_object spec: ... */
if (colorReadRb == NULL || colorDrawRb == NULL) {
colorReadRb = colorDrawRb = NULL;
mask &= ~GL_COLOR_BUFFER_BIT;
break;
} else if (!compatible_color_datatypes(...)) {
...error...
return;
}
}
}
It looks like the compatible_resolve_formats check (below) should also
be in this loop, so it happens on a per-buffer basis.
I believe my interpretation of checking the read buffer against *all*
color draw buffers is correct. For example, this spec text:
"The read buffer contains signed integer values and **any** draw buffer
does not contain signed integer values."
...really seems to imply that we should be applying these error checks
to each of the draw buffers in turn.
/* From the EXT_framebuffer_object spec:
*
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index b0c56a4..c579572 100644
--- a/src/mesa/swrast/s_blit.c
+++ b/src/mesa/swrast/s_blit.c
@@ -111,6 +111,9 @@ blit_nearest(struct gl_context *ctx,
GLbitfield buffer)
{
struct gl_renderbuffer *readRb, *drawRb;
+ struct gl_renderbuffer_attachment *readAtt, *drawAtt;
+ struct gl_framebuffer *readFb = ctx->ReadBuffer;
+ struct gl_framebuffer *drawFb = ctx->DrawBuffer;
const GLint srcWidth = ABS(srcX1 - srcX0);
const GLint dstWidth = ABS(dstX1 - dstX0);
@@ -146,8 +149,18 @@ blit_nearest(struct gl_context *ctx,
switch (buffer) {
case GL_COLOR_BUFFER_BIT:
- readRb = ctx->ReadBuffer->_ColorReadBuffer;
- drawRb = ctx->DrawBuffer->_ColorDrawBuffers[0];
+ readAtt = &readFb->Attachment[readFb->_ColorReadBufferIndex];
+ for (int i = 0; i < drawFb->_NumColorDrawBuffers; i++) {
+ int idx = drawFb->_ColorDrawBufferIndexes[i];
+ if (idx != -1) {
+ drawAtt = &drawFb->Attachment[idx];
+ }
+ else {
+continue;
if (idx == -1)
continue;
drawAtt = &drawFb->Attachment[idx];
but again, I'm skeptical here since this loop finds the last draw
attachment and doesn't do anything with the prior ones...
+ }
+ }
+ readRb = readFb->_ColorReadBuffer;
+ drawRb = drawAtt->Renderbuffer;
if (readRb->Format == drawRb->Format) {
mode = DIRECT;
@@ -159,8 +172,10 @@ blit_nearest(struct gl_context *ctx,
break;
case GL_DEPTH_BUFFER_BIT:
- readRb = ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
- drawRb = ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer;
+ readAtt = &readFb->Attachment[BUFFER_DEPTH];
+ drawAtt = &drawFb->Attachment[BUFFER_DEPTH];
+ readRb = readAtt->Renderbuffer;
+ drawRb = drawAtt->Renderbuffer;
/* No
Re: [Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke wrote:
> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/main/fbobject.c | 10 +-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>> index 4b7d4ab..9e32836 100644
>> --- a/src/mesa/main/fbobject.c
>> +++ b/src/mesa/main/fbobject.c
>> @@ -2856,7 +2856,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0,
>> GLint srcX1, GLint srcY1,
>> mask &= ~GL_STENCIL_BUFFER_BIT;
>> }
>> else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
>> - _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
>> + _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS) ||
>> + /* OpenGL/ES specification is not very clear about it. But
>> GLES3
>> +* conformance test expects GL_INVALID_OPERATION in case
>> of below
>> +* listed combination of formats for read/draw buffers.
>> +*/
>> + (readRb->InternalFormat == GL_DEPTH32F_STENCIL8 &&
>> +drawRb->InternalFormat == GL_DEPTH24_STENCIL8) ||
>> + (readRb->InternalFormat == GL_DEPTH24_STENCIL8 &&
>> +drawRb->InternalFormat == GL_DEPTH32F_STENCIL8)) {
>> /* There is no need to check the stencil datatype here, because
>> * there is only one: GL_UNSIGNED_INT.
>> */
>
>
> I found this text:
>
> From the OpenGL 3.0 spec, section 4.3 (page 277):
> "Calling BlitFramebuffer will result in an INVALID_OPERATION error if mask
> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and the source and
> destination depth and stencil buffer formats do not match."
>
> This text also appears in the ES 3.0 and GL 4.2 specs.
>
> I believe the existing code's interpretation of this paragraph was:
>
> - if DEPTH_BUFFER_BIT is set, source & destination depth buffer formats
> must match.
> - if STENCIL_BUFFER_BIT is set, source & destination stencil buffer
> formats must match.
>
> An alternate interpretation that might appease those tests is:
>
> - if *either* DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT is set, both the
> depth *and* stencil formats must match.
>
> If that's the case, you can simply check readRb->Format == drawRb->Format.
> It seems reasonable to me, at least for packed formats.
gles3 conformance test cases expect no GL error when blitting between
formats GL_STENCIL_INDEX8 and GL_DEPTH24_STENCIL8.
But expect invalid operation when blitting between formats
GL_DEPTH24_STENCIL8 and GL_DEPTH32F_STENCIL8. This behavior
doesn't seem to match above interpretation of spec.
Making the changes suggested by you and Ian cause many other
gles3 conform BlitFrameBuffer test cases fail.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
On 12/18/2012 12:05 PM, Anuj Phogat wrote:
On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke wrote:
On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2856,7 +2856,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0,
GLint srcX1, GLint srcY1,
mask &= ~GL_STENCIL_BUFFER_BIT;
}
else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
- _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
+ _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS) ||
+ /* OpenGL/ES specification is not very clear about it. But
GLES3
+* conformance test expects GL_INVALID_OPERATION in case
of below
+* listed combination of formats for read/draw buffers.
+*/
+ (readRb->InternalFormat == GL_DEPTH32F_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH24_STENCIL8) ||
+ (readRb->InternalFormat == GL_DEPTH24_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH32F_STENCIL8)) {
/* There is no need to check the stencil datatype here, because
* there is only one: GL_UNSIGNED_INT.
*/
I found this text:
From the OpenGL 3.0 spec, section 4.3 (page 277):
"Calling BlitFramebuffer will result in an INVALID_OPERATION error if mask
includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and the source and
destination depth and stencil buffer formats do not match."
This text also appears in the ES 3.0 and GL 4.2 specs.
I believe the existing code's interpretation of this paragraph was:
- if DEPTH_BUFFER_BIT is set, source & destination depth buffer formats
must match.
- if STENCIL_BUFFER_BIT is set, source & destination stencil buffer
formats must match.
An alternate interpretation that might appease those tests is:
- if *either* DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT is set, both the
depth *and* stencil formats must match.
If that's the case, you can simply check readRb->Format == drawRb->Format.
It seems reasonable to me, at least for packed formats.
gles3 conformance test cases expect no GL error when blitting between
formats GL_STENCIL_INDEX8 and GL_DEPTH24_STENCIL8.
But expect invalid operation when blitting between formats
GL_DEPTH24_STENCIL8 and GL_DEPTH32F_STENCIL8. This behavior
doesn't seem to match above interpretation of spec.
Making the changes suggested by you and Ian cause many other
gles3 conform BlitFrameBuffer test cases fail.
Okay. That seems reasonable too, since:
"If a buffer is specified in mask and does not exist in both the read
and draw framebuffers, the corresponding bit is silently ignored."
Reading between the lines a bit, perhaps when GL_STENCIL_BIT is set, the
depth formats must match...unless one of the two buffers doesn't have
depth, in which case it's not blitted, so the format check should be
ignored. That would allow the GL_STENCIL_INDEX8/GL_DEPTH24_STENCIL8 case.
Likewise, if GL_DEPTH_BIT is set, the stencil formats must
match...unless one of the two buffers doesn't have stencil.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
On Tue, Dec 18, 2012 at 12:12 PM, Kenneth Graunke wrote:
> On 12/18/2012 12:05 PM, Anuj Phogat wrote:
>>
>> On Tue, Dec 18, 2012 at 11:09 AM, Kenneth Graunke
>> wrote:
>>>
>>> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..9e32836 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2856,7 +2856,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0,
GLint srcX1, GLint srcY1,
mask &= ~GL_STENCIL_BUFFER_BIT;
}
else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS)
!=
- _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
+ _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)
||
+ /* OpenGL/ES specification is not very clear about it.
But
GLES3
+* conformance test expects GL_INVALID_OPERATION in case
of below
+* listed combination of formats for read/draw buffers.
+*/
+ (readRb->InternalFormat == GL_DEPTH32F_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH24_STENCIL8) ||
+ (readRb->InternalFormat == GL_DEPTH24_STENCIL8 &&
+drawRb->InternalFormat == GL_DEPTH32F_STENCIL8)) {
/* There is no need to check the stencil datatype here,
because
* there is only one: GL_UNSIGNED_INT.
*/
>>>
>>>
>>>
>>> I found this text:
>>>
>>> From the OpenGL 3.0 spec, section 4.3 (page 277):
>>> "Calling BlitFramebuffer will result in an INVALID_OPERATION error if
>>> mask
>>> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and the source and
>>> destination depth and stencil buffer formats do not match."
>>>
>>> This text also appears in the ES 3.0 and GL 4.2 specs.
>>>
>>> I believe the existing code's interpretation of this paragraph was:
>>>
>>>- if DEPTH_BUFFER_BIT is set, source & destination depth buffer
>>> formats
>>> must match.
>>>- if STENCIL_BUFFER_BIT is set, source & destination stencil buffer
>>> formats must match.
>>>
>>> An alternate interpretation that might appease those tests is:
>>>
>>>- if *either* DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT is set, both the
>>> depth *and* stencil formats must match.
>>>
>>> If that's the case, you can simply check readRb->Format ==
>>> drawRb->Format.
>>> It seems reasonable to me, at least for packed formats.
>>
>>
>> gles3 conformance test cases expect no GL error when blitting between
>> formats GL_STENCIL_INDEX8 and GL_DEPTH24_STENCIL8.
>> But expect invalid operation when blitting between formats
>> GL_DEPTH24_STENCIL8 and GL_DEPTH32F_STENCIL8. This behavior
>> doesn't seem to match above interpretation of spec.
>> Making the changes suggested by you and Ian cause many other
>> gles3 conform BlitFrameBuffer test cases fail.
>
>
> Okay. That seems reasonable too, since:
>
> "If a buffer is specified in mask and does not exist in both the read and
> draw framebuffers, the corresponding bit is silently ignored."
>
> Reading between the lines a bit, perhaps when GL_STENCIL_BIT is set, the
> depth formats must match...unless one of the two buffers doesn't have depth,
> in which case it's not blitted, so the format check should be ignored. That
> would allow the GL_STENCIL_INDEX8/GL_DEPTH24_STENCIL8 case.
>
> Likewise, if GL_DEPTH_BIT is set, the stencil formats must match...unless
> one of the two buffers doesn't have stencil.
Yeah, this make sense. I'll make the relevant changes for both GL_DEPTH_BIT
and GL_STENCIL_BIT blitting error checks. Thanks Ken.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [alternate PATCH 1.1/6] mesa: Handle GL_BACK correctly for ES 3.0 in glDrawBuffers().
In ES 3.0, when calling glDrawBuffers() on the window system
framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
is no stereo rendering in ES 3.0, this is a single buffer, unlike
desktop where it may be two (and thus isn't allowed).
For single-buffered configs, GL_BACK ironically means the front (and
only) buffer. I'm not sure that it matters, however, as ES shouldn't
have front buffer rendering in the first place.
Fixes es3conform framebuffer_blit_coverage_default_draw_buffer_binding.
---
src/mesa/main/buffers.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
These two patches are a proposed replacement for Anuj's patch 1/6.
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index aa9b9f0..244f4de 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -94,7 +94,7 @@ supported_buffer_bitmask(const struct gl_context *ctx,
* GL_FRONT_AND_BACK), return the corresponding bitmask of BUFFER_BIT_* flags.
*/
static GLbitfield
-draw_buffer_enum_to_bitmask(GLenum buffer)
+draw_buffer_enum_to_bitmask(const struct gl_context *ctx, GLenum buffer)
{
switch (buffer) {
case GL_NONE:
@@ -102,6 +102,19 @@ draw_buffer_enum_to_bitmask(GLenum buffer)
case GL_FRONT:
return BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_FRONT_RIGHT;
case GL_BACK:
+ if (_mesa_is_gles3(ctx)) {
+/* From the ES 3.0 specification, page 180:
+ * "When draw buffer zero is BACK, color values are written into
+ * the sole buffer for single-buffered contexts, or into the back
+ * buffer for double-buffered contexts."
+ *
+ * Since there is no stereo rendering in ES 3.0, only return the
+ * LEFT bits. This also satisfies the "n must be 1" requirement.
+ */
+if (ctx->DrawBuffer->Visual.doubleBufferMode)
+ return BUFFER_BIT_BACK_LEFT;
+return BUFFER_BIT_FRONT_LEFT;
+ }
return BUFFER_BIT_BACK_LEFT | BUFFER_BIT_BACK_RIGHT;
case GL_RIGHT:
return BUFFER_BIT_FRONT_RIGHT | BUFFER_BIT_BACK_RIGHT;
@@ -241,7 +254,7 @@ _mesa_DrawBuffer(GLenum buffer)
else {
const GLbitfield supportedMask
= supported_buffer_bitmask(ctx, ctx->DrawBuffer);
- destMask = draw_buffer_enum_to_bitmask(buffer);
+ destMask = draw_buffer_enum_to_bitmask(ctx, buffer);
if (destMask == BAD_MASK) {
/* totally bogus buffer */
_mesa_error(ctx, GL_INVALID_ENUM,
@@ -321,7 +334,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
return;
}
- destMask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
+ destMask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
/* From the OpenGL 3.0 specification, page 258:
* "Each buffer listed in bufs must be one of the values from tables
@@ -451,7 +464,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
GLenum *buffers,
const GLbitfield supportedMask = supported_buffer_bitmask(ctx, fb);
GLuint output;
for (output = 0; output < n; output++) {
- mask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
+ mask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
ASSERT(mask[output] != BAD_MASK);
mask[output] &= supportedMask;
}
--
1.8.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [alternate PATCH 1.2/6] mesa: Make ES3 glDrawBuffers() only accept BACK/NONE for the winsys fbo.
Nothing was explicitly checking this.
---
src/mesa/main/buffers.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 244f4de..065ef2a 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -316,6 +316,16 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
supportedMask = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
usedBufferMask = 0x0;
+ /* From the ES 3.0 specification, page 180:
+* "If the GL is bound to the default framebuffer, then n must be 1
+* and the constant must be BACK or NONE."
+*/
+ if (_mesa_is_gles3(ctx) && _mesa_is_winsys_fbo(ctx->DrawBuffer) &&
+ (n != 1 || (buffers[0] != GL_NONE && buffers[0] != GL_BACK))) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, "glDrawBuffers(buffer)");
+ return;
+ }
+
/* complicated error checking... */
for (output = 0; output < n; output++) {
if (buffers[output] == GL_NONE) {
--
1.8.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] i965: Add perf debug for texture relayout.
Relayout is expensive, so it's something developers (both us and others)
should know about when it happens.
---
src/mesa/drivers/dri/intel/intel_tex_validate.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
b/src/mesa/drivers/dri/intel/intel_tex_validate.c
index ad173c9..2f1b354 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_validate.c
@@ -79,6 +79,11 @@ intel_finalize_mipmap_tree(struct intel_context *intel,
GLuint unit)
intel_miptree_get_dimensions_for_image(&firstImage->base.Base,
&width, &height, &depth);
+ perf_debug("Creating new %s %dx%dx%d %d..%d miptree to handle finalized "
+ "texture miptree.\n",
+ _mesa_get_format_name(firstImage->base.Base.TexFormat),
+ width, height, depth, tObj->BaseLevel, intelObj->_MaxLevel);
+
intelObj->mt = intel_miptree_create(intel,
intelObj->base.Target,
firstImage->base.Base.TexFormat,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i965: Assert that relayout laid out something that won't need it again.
The ETC1 changes failed at this, so let's make sure it will be caught in
testing next time.
---
src/mesa/drivers/dri/intel/intel_tex_validate.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c
b/src/mesa/drivers/dri/intel/intel_tex_validate.c
index 2f1b354..3f21601 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_validate.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_validate.c
@@ -113,6 +113,12 @@ intel_finalize_mipmap_tree(struct intel_context *intel,
GLuint unit)
if (intelObj->mt != intelImage->mt) {
intel_miptree_copy_teximage(intel, intelImage, intelObj->mt);
}
+
+ /* After we're done, we'd better agree that our layout is
+ * appropriate, or we'll end up hitting this function again on the
+ * next draw
+ */
+ assert(intel_miptree_match_image(intelObj->mt,
&intelImage->base.Base));
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965: Also fix validation of Z32F_S8 textures.
This was caught by the assertion in the next commit. This causes 8 depthstencil cases to start passing (presumably because of fewer broken texture validates happening) while regressing 3. Given that this causes there to be no more failures at the 585 and 146 sizes while only introducing failures at the 292 size that is broken for other depth/stencil formats as well, I'm comfortable with this. --- src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c index 901d0ea..580d021 100644 --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c @@ -607,6 +607,8 @@ intel_miptree_match_image(struct intel_mipmap_tree *mt, gl_format mt_format = mt->format; if (mt->format == MESA_FORMAT_X8_Z24 && mt->stencil_mt) mt_format = MESA_FORMAT_S8_Z24; + if (mt->format == MESA_FORMAT_Z32_FLOAT && mt->stencil_mt) + mt_format = MESA_FORMAT_Z32_FLOAT_X24S8; if (mt->etc_format != MESA_FORMAT_NONE) mt_format = mt->etc_format; -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] i965: Fix validation of ETC miptrees.
When comparing to the teximage's format, we have to look at the
format-the-mt-was-created-for not the format-actually-stored-in-the-mt.
Improves glbenchmark 2.1 offscreen test performance 159% +/- 17% (n=3).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54582
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 6096827..901d0ea 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -604,12 +604,14 @@ intel_miptree_match_image(struct intel_mipmap_tree *mt,
if (target_to_target(image->TexObject->Target) != mt->target)
return false;
- if (image->TexFormat != mt->format &&
- !(image->TexFormat == MESA_FORMAT_S8_Z24 &&
-mt->format == MESA_FORMAT_X8_Z24 &&
-mt->stencil_mt)) {
+ gl_format mt_format = mt->format;
+ if (mt->format == MESA_FORMAT_X8_Z24 && mt->stencil_mt)
+ mt_format = MESA_FORMAT_S8_Z24;
+ if (mt->etc_format != MESA_FORMAT_NONE)
+ mt_format = mt->etc_format;
+
+ if (image->TexFormat != mt_format)
return false;
- }
intel_miptree_get_dimensions_for_image(image, &width, &height, &depth);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] i965: Fix hiz resolves getting stomped by depth offset validation.
Fixes all the remaining non-Z32F_S8 depthstencil-render-miplevels tests in piglit. --- This causes the other Z32F change in the series I sent out earlier today to result in all depthstencil-render-miplevels tests passing. My plan is to push this series before that one. src/mesa/drivers/dri/i965/brw_draw.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index cb8e682..faa29d1 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -436,17 +436,17 @@ static bool brw_try_draw_prims( struct gl_context *ctx, intel_prepare_render(intel); + /* This workaround has to happen outside of brw_state_upload() because it +* may flush the batchbuffer for a blit, affecting the state flags. +*/ + brw_workaround_depthstencil_alignment(brw); + /* Resolves must occur after updating renderbuffers, updating context state, * and finalizing textures but before setting up any hardware state for * this draw call. */ brw_predraw_resolve_buffers(brw); - /* This workaround has to happen outside of brw_state_upload() because it -* may flush the batchbuffer for a blit, affecting the state flags. -*/ - brw_workaround_depthstencil_alignment(brw); - /* Bind all inputs, derive varying and size information: */ brw_merge_inputs( brw, arrays ); -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Add perf debug for depth/stencil alignment workaround.
Fixing these rendering bugs has been implicated in performance
regressions (which may be unfixable), but at least knowing that it's
happening should help diagnose those regressions.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index b0a1918..d7724e3 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -370,6 +370,10 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw)
}
if (rebase_depth) {
+ perf_debug("HW workaround: blitting depth level %d to a temporary "
+"to fix alignment (depth tile offset %d,%d)\n",
+depth_irb->mt_level, tile_x, tile_y);
+
intel_renderbuffer_move_to_temp(intel, depth_irb);
/* In the case of stencil_irb being the same packed depth/stencil
* texture but not the same rb, make it point at our rebased mt, too.
@@ -427,6 +431,10 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw)
}
if (rebase_stencil) {
+ perf_debug("HW workaround: blitting stencil level %d to a temporary "
+ "to fix alignment (stencil tile offset %d,%d)\n",
+ stencil_irb->mt_level, stencil_tile_x, stencil_tile_y);
+
intel_renderbuffer_move_to_temp(intel, stencil_irb);
stencil_mt = get_stencil_miptree(stencil_irb);
@@ -443,6 +451,14 @@ brw_workaround_depthstencil_alignment(struct brw_context
*brw)
} else if (depth_irb && !rebase_depth) {
if (tile_x != stencil_tile_x ||
tile_y != stencil_tile_y) {
+perf_debug("HW workaround: blitting depth level %d to a temporary "
+ "to match stencil level %d alignment (depth tile offset
"
+ "%d,%d, stencil offset %d,%d)\n",
+ depth_irb->mt_level,
+ stencil_irb->mt_level,
+ tile_x, tile_y,
+ stencil_tile_x, stencil_tile_y);
+
intel_renderbuffer_move_to_temp(intel, depth_irb);
tile_x = depth_irb->draw_x & tile_mask_x;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] intel: Remove a couple of dead function prototypes.
--- src/mesa/drivers/dri/intel/intel_mipmap_tree.h |5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h index 3a465da..eb4ad7f 100644 --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.h +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.h @@ -518,11 +518,6 @@ void intel_miptree_slice_set_needs_depth_resolve(struct intel_mipmap_tree *mt, uint32_t level, uint32_t depth); -void -intel_miptree_all_slices_set_need_hiz_resolve(struct intel_mipmap_tree *mt); - -void -intel_miptree_all_slices_set_need_depth_resolve(struct intel_mipmap_tree *mt); /** * \return false if no resolve was needed -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] mesa: Fix GL error generation in _mesa_GetFramebufferAttachmentParameteriv()
On Tue, Dec 18, 2012 at 11:35 AM, Kenneth Graunke wrote:
> On 12/12/2012 03:25 PM, Anuj Phogat wrote:
>>
>> This allows query on default framebuffer in
>> glGetFramebufferAttachmentParameteriv()
>> for gles3. Fixes unexpected GL errors in gles3 conformance test case:
>> framebuffer_blit_functionality_multisampled_to_singlesampled_blit
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/main/fbobject.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>> index 9e32836..d87239e 100644
>> --- a/src/mesa/main/fbobject.c
>> +++ b/src/mesa/main/fbobject.c
>> @@ -250,6 +250,7 @@ _mesa_get_fb0_attachment(struct gl_context *ctx,
>> struct gl_framebuffer *fb,
>> return &fb->Attachment[BUFFER_FRONT_LEFT];
>> case GL_FRONT_RIGHT:
>> return &fb->Attachment[BUFFER_FRONT_RIGHT];
>> + case GL_BACK:
>> case GL_BACK_LEFT:
>> return &fb->Attachment[BUFFER_BACK_LEFT];
>> case GL_BACK_RIGHT:
>> @@ -2369,7 +2370,8 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum
>> target, GLenum attachment,
>> * OES_framebuffer_object spec refers to the
>> EXT_framebuffer_object
>> * spec.
>> */
>> - if (!_mesa_is_desktop_gl(ctx) ||
>> !ctx->Extensions.ARB_framebuffer_object) {
>> + if ((!_mesa_is_desktop_gl(ctx) ||
>> !ctx->Extensions.ARB_framebuffer_object)
>> + && !_mesa_is_gles3(ctx)) {
>> _mesa_error(ctx, GL_INVALID_OPERATION,
>> "glGetFramebufferAttachmentParameteriv(bound FBO =
>> 0)");
>> return;
>
>
> This makes glGetFramebufferAttachmentParameteriv() accept GL_BACK on desktop
> GL (which is not allowed) and also allows ES 3 to accept the GL_*_LEFT/RIGHT
> targets (which are also not allowed).
Right. I'll put relevant API and version checks in this function.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Don't waste space for MAX_CLIP_PLANES in pull constant buffer.
The new VS uploads clip planes like any other parameters; this extra
allocation was for the old VS which uploaded them specially. With the
old VS gone, this just wastes space and bandwidth.
---
src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c
b/src/mesa/drivers/dri/i965/gen6_vs_state.c
index d293482..579fffb 100644
--- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
@@ -58,8 +58,7 @@ gen6_upload_vs_push_constants(struct brw_context *brw)
int i;
param = brw_state_batch(brw, AUB_TRACE_VS_CONSTANTS,
- (MAX_CLIP_PLANES + nr_params) *
- 4 * sizeof(float),
+ nr_params * 4 * sizeof(float),
32, &brw->vs.push_const_offset);
for (i = 0; i < brw->vs.prog_data->nr_params; i++) {
--
1.8.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [alternate PATCH 1.1/6] mesa: Handle GL_BACK correctly for ES 3.0 in glDrawBuffers().
On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke wrote:
> In ES 3.0, when calling glDrawBuffers() on the window system
> framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
> is no stereo rendering in ES 3.0, this is a single buffer, unlike
> desktop where it may be two (and thus isn't allowed).
>
> For single-buffered configs, GL_BACK ironically means the front (and
> only) buffer. I'm not sure that it matters, however, as ES shouldn't
> have front buffer rendering in the first place.
>
> Fixes es3conform framebuffer_blit_coverage_default_draw_buffer_binding.
> ---
> src/mesa/main/buffers.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> These two patches are a proposed replacement for Anuj's patch 1/6.
>
patch 1/6 is still required to fix failures related to
glGetFramebufferAttachmentParameteriv
in framebuffer_blit_functionality_multisampled_to_singlesampled_blit test case.
I'll soon post an updated patch.
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index aa9b9f0..244f4de 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -94,7 +94,7 @@ supported_buffer_bitmask(const struct gl_context *ctx,
> * GL_FRONT_AND_BACK), return the corresponding bitmask of BUFFER_BIT_*
> flags.
> */
> static GLbitfield
> -draw_buffer_enum_to_bitmask(GLenum buffer)
> +draw_buffer_enum_to_bitmask(const struct gl_context *ctx, GLenum buffer)
> {
> switch (buffer) {
>case GL_NONE:
> @@ -102,6 +102,19 @@ draw_buffer_enum_to_bitmask(GLenum buffer)
>case GL_FRONT:
> return BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_FRONT_RIGHT;
>case GL_BACK:
> + if (_mesa_is_gles3(ctx)) {
> +/* From the ES 3.0 specification, page 180:
> + * "When draw buffer zero is BACK, color values are written into
> + * the sole buffer for single-buffered contexts, or into the
> back
> + * buffer for double-buffered contexts."
> + *
> + * Since there is no stereo rendering in ES 3.0, only return the
> + * LEFT bits. This also satisfies the "n must be 1" requirement.
> + */
> +if (ctx->DrawBuffer->Visual.doubleBufferMode)
> + return BUFFER_BIT_BACK_LEFT;
> +return BUFFER_BIT_FRONT_LEFT;
> + }
> return BUFFER_BIT_BACK_LEFT | BUFFER_BIT_BACK_RIGHT;
>case GL_RIGHT:
> return BUFFER_BIT_FRONT_RIGHT | BUFFER_BIT_BACK_RIGHT;
> @@ -241,7 +254,7 @@ _mesa_DrawBuffer(GLenum buffer)
> else {
>const GLbitfield supportedMask
> = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
> - destMask = draw_buffer_enum_to_bitmask(buffer);
> + destMask = draw_buffer_enum_to_bitmask(ctx, buffer);
>if (destMask == BAD_MASK) {
> /* totally bogus buffer */
> _mesa_error(ctx, GL_INVALID_ENUM,
> @@ -321,7 +334,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> return;
> }
>
> - destMask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
> + destMask[output] = draw_buffer_enum_to_bitmask(ctx,
> buffers[output]);
>
> /* From the OpenGL 3.0 specification, page 258:
>* "Each buffer listed in bufs must be one of the values from tables
> @@ -451,7 +464,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n, const
> GLenum *buffers,
>const GLbitfield supportedMask = supported_buffer_bitmask(ctx, fb);
>GLuint output;
>for (output = 0; output < n; output++) {
> - mask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
> + mask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
> ASSERT(mask[output] != BAD_MASK);
> mask[output] &= supportedMask;
>}
> --
> 1.8.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [alternate PATCH 1.2/6] mesa: Make ES3 glDrawBuffers() only accept BACK/NONE for the winsys fbo.
On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke wrote:
> Nothing was explicitly checking this.
> ---
> src/mesa/main/buffers.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 244f4de..065ef2a 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -316,6 +316,16 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
> supportedMask = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
> usedBufferMask = 0x0;
>
> + /* From the ES 3.0 specification, page 180:
> +* "If the GL is bound to the default framebuffer, then n must be 1
> +* and the constant must be BACK or NONE."
> +*/
> + if (_mesa_is_gles3(ctx) && _mesa_is_winsys_fbo(ctx->DrawBuffer) &&
> + (n != 1 || (buffers[0] != GL_NONE && buffers[0] != GL_BACK))) {
> + _mesa_error(ctx, GL_INVALID_OPERATION, "glDrawBuffers(buffer)");
> + return;
> + }
> +
> /* complicated error checking... */
> for (output = 0; output < n; output++) {
>if (buffers[output] == GL_NONE) {
> --
> 1.8.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [alternate PATCH 1.1/6] mesa: Handle GL_BACK correctly for ES 3.0 in glDrawBuffers().
On Tue, Dec 18, 2012 at 4:35 PM, Anuj Phogat wrote:
> On Tue, Dec 18, 2012 at 1:26 PM, Kenneth Graunke
> wrote:
>> In ES 3.0, when calling glDrawBuffers() on the window system
>> framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
>> is no stereo rendering in ES 3.0, this is a single buffer, unlike
>> desktop where it may be two (and thus isn't allowed).
>>
>> For single-buffered configs, GL_BACK ironically means the front (and
>> only) buffer. I'm not sure that it matters, however, as ES shouldn't
>> have front buffer rendering in the first place.
>>
>> Fixes es3conform framebuffer_blit_coverage_default_draw_buffer_binding.
>> ---
>> src/mesa/main/buffers.c | 21 +
>> 1 file changed, 17 insertions(+), 4 deletions(-)
>>
>> These two patches are a proposed replacement for Anuj's patch 1/6.
>>
> patch 1/6 is still required to fix failures related to
> glGetFramebufferAttachmentParameteriv
> in framebuffer_blit_functionality_multisampled_to_singlesampled_blit test
> case.
> I'll soon post an updated patch.
>
Please ignore this comment. I confused it with my patch 2/6.
>> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
>> index aa9b9f0..244f4de 100644
>> --- a/src/mesa/main/buffers.c
>> +++ b/src/mesa/main/buffers.c
>> @@ -94,7 +94,7 @@ supported_buffer_bitmask(const struct gl_context *ctx,
>> * GL_FRONT_AND_BACK), return the corresponding bitmask of BUFFER_BIT_*
>> flags.
>> */
>> static GLbitfield
>> -draw_buffer_enum_to_bitmask(GLenum buffer)
>> +draw_buffer_enum_to_bitmask(const struct gl_context *ctx, GLenum buffer)
>> {
>> switch (buffer) {
>>case GL_NONE:
>> @@ -102,6 +102,19 @@ draw_buffer_enum_to_bitmask(GLenum buffer)
>>case GL_FRONT:
>> return BUFFER_BIT_FRONT_LEFT | BUFFER_BIT_FRONT_RIGHT;
>>case GL_BACK:
>> + if (_mesa_is_gles3(ctx)) {
>> +/* From the ES 3.0 specification, page 180:
>> + * "When draw buffer zero is BACK, color values are written into
>> + * the sole buffer for single-buffered contexts, or into the
>> back
>> + * buffer for double-buffered contexts."
>> + *
>> + * Since there is no stereo rendering in ES 3.0, only return the
>> + * LEFT bits. This also satisfies the "n must be 1"
>> requirement.
>> + */
>> +if (ctx->DrawBuffer->Visual.doubleBufferMode)
>> + return BUFFER_BIT_BACK_LEFT;
>> +return BUFFER_BIT_FRONT_LEFT;
>> + }
>> return BUFFER_BIT_BACK_LEFT | BUFFER_BIT_BACK_RIGHT;
>>case GL_RIGHT:
>> return BUFFER_BIT_FRONT_RIGHT | BUFFER_BIT_BACK_RIGHT;
>> @@ -241,7 +254,7 @@ _mesa_DrawBuffer(GLenum buffer)
>> else {
>>const GLbitfield supportedMask
>> = supported_buffer_bitmask(ctx, ctx->DrawBuffer);
>> - destMask = draw_buffer_enum_to_bitmask(buffer);
>> + destMask = draw_buffer_enum_to_bitmask(ctx, buffer);
>>if (destMask == BAD_MASK) {
>> /* totally bogus buffer */
>> _mesa_error(ctx, GL_INVALID_ENUM,
>> @@ -321,7 +334,7 @@ _mesa_DrawBuffers(GLsizei n, const GLenum *buffers)
>> return;
>> }
>>
>> - destMask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
>> + destMask[output] = draw_buffer_enum_to_bitmask(ctx,
>> buffers[output]);
>>
>> /* From the OpenGL 3.0 specification, page 258:
>>* "Each buffer listed in bufs must be one of the values from
>> tables
>> @@ -451,7 +464,7 @@ _mesa_drawbuffers(struct gl_context *ctx, GLuint n,
>> const GLenum *buffers,
>>const GLbitfield supportedMask = supported_buffer_bitmask(ctx, fb);
>>GLuint output;
>>for (output = 0; output < n; output++) {
>> - mask[output] = draw_buffer_enum_to_bitmask(buffers[output]);
>> + mask[output] = draw_buffer_enum_to_bitmask(ctx, buffers[output]);
>> ASSERT(mask[output] != BAD_MASK);
>> mask[output] &= supportedMask;
>>}
>> --
>> 1.8.0.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Reviewed-by: Anuj Phogat
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] mesa: Fix GL error generation in glBlitFramebuffer()
V2:
If mask has GL_STENCIL_BUFFER_BIT set, the depth formats for readRenderBuffer
and drawRenderBuffer must match unless one of the two buffers doesn't have
depth, in which case it's not blitted, so the format check should be ignored.
Same comment goes for stencil formats in depth renderbuffers if mask has
GL_DEPTH_BUFFER_BIT set.
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4b7d4ab..89054ed 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2855,11 +2855,20 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
if ((readRb == NULL) || (drawRb == NULL)) {
mask &= ~GL_STENCIL_BUFFER_BIT;
}
- else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
- _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) {
-/* There is no need to check the stencil datatype here, because
- * there is only one: GL_UNSIGNED_INT.
- */
+ else if ((_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
+_mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) ||
+ /* There is no need to check the stencil datatype here, because
+ * there is only one: GL_UNSIGNED_INT.
+ * The depth formats must match unless one of the two buffers
+ * doesn't have depth, in which case it's not blitted, so the
+ * format check should be ignored.
+ */
+ ((_mesa_get_format_bits(readRb->Format, GL_DEPTH_BITS) > 0) &&
+(_mesa_get_format_bits(drawRb->Format, GL_DEPTH_BITS) > 0) &&
+((_mesa_get_format_bits(readRb->Format, GL_DEPTH_BITS) !=
+ _mesa_get_format_bits(drawRb->Format, GL_DEPTH_BITS)) ||
+ (_mesa_get_format_datatype(readRb->Format) !=
+ _mesa_get_format_datatype(drawRb->Format) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glBlitFramebufferEXT(stencil buffer size mismatch)");
return;
@@ -2884,7 +2893,15 @@ _mesa_BlitFramebuffer(GLint srcX0, GLint srcY0, GLint
srcX1, GLint srcY1,
else if ((_mesa_get_format_bits(readRb->Format, GL_DEPTH_BITS) !=
_mesa_get_format_bits(drawRb->Format, GL_DEPTH_BITS)) ||
(_mesa_get_format_datatype(readRb->Format) !=
- _mesa_get_format_datatype(drawRb->Format))) {
+_mesa_get_format_datatype(drawRb->Format)) ||
+ /* The stencil formats must match unless one of the two buffers
+* doesn't have stencil, in which case it's not blitted, so the
+* format check should be ignored.
+*/
+ ((_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) > 0) &&
+(_mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS) > 0) &&
+(_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) !=
+ _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glBlitFramebufferEXT(depth buffer format mismatch)");
return;
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 5/6] mesa: Fix GL error generation in _mesa_GetFramebufferAttachmentParameteriv()
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv()
for gles3. Fixes unexpected GL errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
V2: Use _mesa_is_gles3() check to restrict allowed attachment types to
specific APIs.
Signed-off-by: Anuj Phogat
---
src/mesa/main/fbobject.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 89054ed..517bf13 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -245,6 +245,25 @@ _mesa_get_fb0_attachment(struct gl_context *ctx, struct
gl_framebuffer *fb,
{
assert(_mesa_is_winsys_fbo(fb));
+ if (_mesa_is_gles3(ctx)) {
+ assert(attachment == GL_BACK ||
+ attachment == GL_DEPTH ||
+ attachment == GL_STENCIL);
+ switch (attachment) {
+ case GL_BACK:
+ /* Since there is no stereo rendering in ES 3.0, only return the
+ * LEFT bits.
+ */
+ if (ctx->DrawBuffer->Visual.doubleBufferMode)
+return &fb->Attachment[BUFFER_BACK_LEFT];
+ return &fb->Attachment[BUFFER_FRONT_LEFT];
+ case GL_DEPTH:
+ return &fb->Attachment[BUFFER_DEPTH];
+ case GL_STENCIL:
+ return &fb->Attachment[BUFFER_STENCIL];
+ }
+ }
+
switch (attachment) {
case GL_FRONT_LEFT:
return &fb->Attachment[BUFFER_FRONT_LEFT];
@@ -2369,11 +2388,19 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum
target, GLenum attachment,
* OES_framebuffer_object spec refers to the EXT_framebuffer_object
* spec.
*/
- if (!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object) {
+ if ((!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_framebuffer_object)
+ && !_mesa_is_gles3(ctx)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glGetFramebufferAttachmentParameteriv(bound FBO = 0)");
return;
}
+
+ if (_mesa_is_gles3(ctx) && attachment != GL_BACK &&
+ attachment != GL_DEPTH && attachment != GL_STENCIL) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glGetFramebufferAttachmentParameteriv(attachment)");
+ return;
+ }
/* the default / window-system FBO */
att = _mesa_get_fb0_attachment(ctx, buffer, attachment);
}
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 5/6] mesa: Fix corner cases of BindBufferBase with transform feedback.
Paul Berry writes: > This patch implements the following behaviours, which are mandated by > the GL 4.3 and GLES3 specs. > > 1. Regarding the GL_TRANSFORM_FEEDBACK_BUFFER_SIZE query: "If the >... size was not specified when the buffer object was bound >(e.g. if it was bound with BindBufferBase), ... zero is returned." >(GL 4.3 section 6.7.1 "Indexed Buffer Object Limits and Binding >Queries"). > > 2. "BindBufferBase binds the entire buffer, even when the size of the >buffer is changed after the binding is established. It is >equivalent to calling BindBufferRange with offset zero, while size >is determined by the size of the bound buffer at the time the >binding is used." (GL 4.3 section 6.1.1 "Binding Buffer Objects to >Indexed Targets"). I interpret "at the time the binding is used" >to mean "at the time of the call to glBeginTransformFeedback". > > 3. "Regardless of the size specified with BindBufferRange, or >indirectly with BindBufferBase, the GL will never read or write >beyond the end of a bound buffer. In some cases this constraint may >result in visibly different behavior when a buffer overflow would >otherwise result, such as described for transform feedback >operations in section 13.2.2." (GL 4.3 section 6.1.1 "Binding >Buffer Objects to Indexed Targets"). Acked-by: Eric Anholt The previous BindBufferBase spec text was ridiculous, and this is much better and should be an improvement for any user of the API. (I don't want this series to block on my review, because I don't think I'll get to it in the next day and others seem to have stepped up) pgpvlOi8l37Vh.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
