[Mesa-dev] [PATCH 1/3] glsl: fix indentation in emit_inline_matrix_constructor
---
src/compiler/glsl/ast_function.cpp | 150 ++---
1 file changed, 75 insertions(+), 75 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index c7fdcb2..238993e 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1405,9 +1405,9 @@ emit_inline_matrix_constructor(const glsl_type *type,
zero.d[i] = 0.0;
ir_instruction *inst =
-new(ctx) ir_assignment(new(ctx) ir_dereference_variable(rhs_var),
- new(ctx) ir_constant(rhs_var->type, &zero),
- NULL);
+ new(ctx) ir_assignment(new(ctx) ir_dereference_variable(rhs_var),
+new(ctx) ir_constant(rhs_var->type, &zero),
+NULL);
instructions->push_tail(inst);
ir_dereference *const rhs_ref = new(ctx)
ir_dereference_variable(rhs_var);
@@ -1422,36 +1422,36 @@ emit_inline_matrix_constructor(const glsl_type *type,
* columns than rows).
*/
static const unsigned rhs_swiz[4][4] = {
-{ 0, 1, 1, 1 },
-{ 1, 0, 1, 1 },
-{ 1, 1, 0, 1 },
-{ 1, 1, 1, 0 }
+ { 0, 1, 1, 1 },
+ { 1, 0, 1, 1 },
+ { 1, 1, 0, 1 },
+ { 1, 1, 1, 0 }
};
const unsigned cols_to_init = MIN2(type->matrix_columns,
-type->vector_elements);
+ type->vector_elements);
for (unsigned i = 0; i < cols_to_init; i++) {
-ir_constant *const col_idx = new(ctx) ir_constant(i);
-ir_rvalue *const col_ref = new(ctx) ir_dereference_array(var, col_idx);
+ ir_constant *const col_idx = new(ctx) ir_constant(i);
+ ir_rvalue *const col_ref = new(ctx) ir_dereference_array(var,
col_idx);
-ir_rvalue *const rhs_ref = new(ctx) ir_dereference_variable(rhs_var);
-ir_rvalue *const rhs = new(ctx) ir_swizzle(rhs_ref, rhs_swiz[i],
- type->vector_elements);
+ ir_rvalue *const rhs_ref = new(ctx) ir_dereference_variable(rhs_var);
+ ir_rvalue *const rhs = new(ctx) ir_swizzle(rhs_ref, rhs_swiz[i],
+type->vector_elements);
-inst = new(ctx) ir_assignment(col_ref, rhs, NULL);
-instructions->push_tail(inst);
+ inst = new(ctx) ir_assignment(col_ref, rhs, NULL);
+ instructions->push_tail(inst);
}
for (unsigned i = cols_to_init; i < type->matrix_columns; i++) {
-ir_constant *const col_idx = new(ctx) ir_constant(i);
-ir_rvalue *const col_ref = new(ctx) ir_dereference_array(var, col_idx);
+ ir_constant *const col_idx = new(ctx) ir_constant(i);
+ ir_rvalue *const col_ref = new(ctx) ir_dereference_array(var,
col_idx);
-ir_rvalue *const rhs_ref = new(ctx) ir_dereference_variable(rhs_var);
-ir_rvalue *const rhs = new(ctx) ir_swizzle(rhs_ref, 1, 1, 1, 1,
- type->vector_elements);
+ ir_rvalue *const rhs_ref = new(ctx) ir_dereference_variable(rhs_var);
+ ir_rvalue *const rhs = new(ctx) ir_swizzle(rhs_ref, 1, 1, 1, 1,
+type->vector_elements);
-inst = new(ctx) ir_assignment(col_ref, rhs, NULL);
-instructions->push_tail(inst);
+ inst = new(ctx) ir_assignment(col_ref, rhs, NULL);
+ instructions->push_tail(inst);
}
} else if (first_param->type->is_matrix()) {
/* From page 50 (56 of the PDF) of the GLSL 1.50 spec:
@@ -1469,36 +1469,36 @@ emit_inline_matrix_constructor(const glsl_type *type,
/* If the source matrix is smaller, pre-initialize the relavent parts of
* the destination matrix to the identity matrix.
*/
- if ((src_matrix->type->matrix_columns < var->type->matrix_columns)
- || (src_matrix->type->vector_elements < var->type->vector_elements)) {
+ if ((src_matrix->type->matrix_columns < var->type->matrix_columns) ||
+ (src_matrix->type->vector_elements < var->type->vector_elements)) {
-/* If the source matrix has fewer rows, every column of the destination
- * must be initialized. Otherwise only the columns in the destination
- * that do not exist in the source must be initialized.
- */
-unsigned col =
- (src_matrix->type->vector_elements < var->type->vector_elements)
- ? 0 : src_matrix->type->matrix_columns;
+ /* If the source matrix has fewer rows, every column of the
destination
+ * must be initialized. Otherwise only the columns in the destination
+ * that do not exist in the source must be initialized.
+ */
+ unsigned col =
+(src_matrix->type->vector_elements < var->type->vector_element
[Mesa-dev] [PATCH 3/3] glsl: fix emit_inline_matrix_constructor for doubles
Specifically, for the case where we initialize a dmat with a source
matrix that has fewer columns/rows.
---
src/compiler/glsl/ast_function.cpp | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index 2ed61de..1a44020 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1484,12 +1484,19 @@ emit_inline_matrix_constructor(const glsl_type *type,
for (/* empty */; col < var->type->matrix_columns; col++) {
ir_constant_data ident;
-ident.f[0] = 0.0f;
-ident.f[1] = 0.0f;
-ident.f[2] = 0.0f;
-ident.f[3] = 0.0f;
-
-ident.f[col] = 1.0f;
+if (!col_type->is_double()) {
+ ident.f[0] = 0.0f;
+ ident.f[1] = 0.0f;
+ ident.f[2] = 0.0f;
+ ident.f[3] = 0.0f;
+ ident.f[col] = 1.0f;
+} else {
+ ident.d[0] = 0.0;
+ ident.d[1] = 0.0;
+ ident.d[2] = 0.0;
+ ident.d[3] = 0.0;
+ ident.d[col] = 1.0;
+}
ir_rvalue *const rhs = new(ctx) ir_constant(col_type, &ident);
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glsl: Mark float constants as such
So we don't generate double to conversion float code
---
src/compiler/glsl/ast_function.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index 238993e..2ed61de 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1484,12 +1484,12 @@ emit_inline_matrix_constructor(const glsl_type *type,
for (/* empty */; col < var->type->matrix_columns; col++) {
ir_constant_data ident;
-ident.f[0] = 0.0;
-ident.f[1] = 0.0;
-ident.f[2] = 0.0;
-ident.f[3] = 0.0;
+ident.f[0] = 0.0f;
+ident.f[1] = 0.0f;
+ident.f[2] = 0.0f;
+ident.f[3] = 0.0f;
-ident.f[col] = 1.0;
+ident.f[col] = 1.0f;
ir_rvalue *const rhs = new(ctx) ir_constant(col_type, &ident);
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glsl: fix emit_inline_matrix_constructor for doubles
On Friday, February 19, 2016 9:25:02 AM PST Iago Toral Quiroga wrote: > Specifically, for the case where we initialize a dmat with a source > matrix that has fewer columns/rows. > --- > src/compiler/glsl/ast_function.cpp | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) This series is: Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: small optimization of _mesa_expand_bitmap()
On Thursday, February 18, 2016 8:53:09 AM PST Brian Paul wrote: > Avoid a per-pixel multiply. > --- > src/mesa/main/image.c | 11 --- > 1 file changed, 4 insertions(+), 7 deletions(-) Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix test for big-endian architecture in compiler.h
Am 16.02.2016 um 12:40 schrieb Jonathan Gray: On Tue, Feb 16, 2016 at 08:13:45PM +1100, Jonathan Gray wrote: On Tue, Feb 16, 2016 at 10:37:47AM +0200, Oded Gabbay wrote: On Tue, Feb 16, 2016 at 9:23 AM, Jonathan Gray wrote: On Fri, Feb 12, 2016 at 10:01:21AM +0100, Jochen Rollwagen wrote: Hi, i think i found & fixed a bug in mesa concerning tests for big-endian machines. The defines tested don't exist or are wrongly defined so the test (probably) never fires. The gcc defines on my machine concerning big-endian are jochen@mac-mini:~/sources/mesa$ gcc -dM -E - < /dev/null | grep BIG #define __BIGGEST_ALIGNMENT__ 16 #define __BIG_ENDIAN__ 1 #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ #define _BIG_ENDIAN 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ The tested values in current mesa are quite different :-) The following patch fixes this. I think you have this backwards. On OpenBSD/sparc64 $ gcc -dM -E - < /dev/null | grep BIG $ $ sysctl hw.byteorder hw.byteorder=4321 endian.h defines BYTE_ORDER and it should be included to test it. I was under the impression the headers on linux had similiar defines. Look at how src/gallium/include/pipe/p_config.h does it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev After looking at it last night, I also think a better solution will be to just include in compiler.h file Oded Right, I suspect it will end up looking something like the following untested diff. It would be nice if this didn't have to be duplicated in two places in Mesa though. At least on OpenBSD/amd64 the only place where endian.h is not picked up indirectly when in matters seems to be shaderimage.c, otherwise BYTE_ORDER is defined and compiler.h somehow included. CPU_TO_LE32 isn't used Well, actually it is, via compiler.h: #define LE32_TO_CPU( x ) CPU_TO_LE32( x ) Actually i only stumbled across all of this by chance, i would naively have expected to find info’s about the CPU mesa is running on in a place so exotic as, wait a minute, now let me see, how about……. Mesa/main/cpuinfo.h ! Yeah I know, completely absurd. Well, at least not as absurd as „compiler.h“ (what compiler, anyway ?). Or p_config.h. IMHO there are three alternatives (well, actually four) on how to proceed: 1.Trying to fix compiler.h 2.Taking the Gallium code and putting it in a sane place (like for example cpuinfo.h), nuking compiler.h and thereby eliminating the redundant code between dri and gallium driver 3.With people doing crazy things like running little-endian kernels on pp64 replacing the #ifdef compile-time-checks in the radeon driver by runtime checks 4.Doing nothing I would opt personally for number 2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Libva] vaPutSurface never returns
Questions for VDPAU should probably go to either the Mesa list or the VDPAU list, libva is completely unrelated to this. Well is it possible that you just locked up the GPU? Please take a look at /sys/kernel/debug/dri/0/radeon_fence_info and dmesg. Regards, Christian. Am 18.02.2016 um 23:43 schrieb Vasilis Liaskovitis: Hi, I have an application that renders by binding libva/vdpau surfaces onto GLX pixmaps.Playback works ok for a while, but than the application displays black frames after a few minutes of operation (always reproducible within 1-15 minutes usually). When this happens, gdb backtrace shows that the current call to vdpau_PutSurface (done from the application) never returns. Are there any obious reasons that would lead to vaPutSurface to never return (e.g. some deadlock in libva/vdpau?) Using vdpau driver on radeon. Backtrace of thread waiting in vaPutSurface(): Thread 8 (Thread 0x7fca1f778700 (LWP 3580)): #0 0x7fca55a3e12d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fca5316b262 in poll (__timeout=-1, __nfds=1, __fds=0x7fca1f776a20) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 #2 _xcb_conn_wait (c=c@entry=0x2885500, cond=cond@entry=0x7fca1f776b40, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459 #3 0x7fca5316cadf in wait_for_reply (c=c@entry=0x2885500, request=31161, e=e@entry=0x0) at xcb_in.c:491 #4 0x7fca5316cbf2 in xcb_wait_for_reply (c=0x2885500, request=31161, e=0x0) at xcb_in.c:521 #5 0x7fca419b8004 in vl_dri2_get_flush_reply (scrn=0x2653600) at ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:110 #6 0x7fca419b8101 in vl_dri2_destroy_drawable (scrn=0x2653600) at ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:153 #7 0x7fca419b8185 in vl_dri2_set_drawable (scrn=0x2653600, drawable=71303307) at ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:176 #8 0x7fca419b82c8 in vl_dri2_screen_texture_from_drawable (vscreen=0x2653600, drawable=0x440008b) at ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:193 #9 0x7fca419b61ab in vlVdpPresentationQueueDisplay (presentation_queue=, surface=5, clip_width=1280, clip_height=720, earliest_presentation_time=0) at ../../../../../../src/gallium/state_trackers/vdpau/presentation.c:234 #10 0x7fca423ca6a3 in flip_surface_unlocked (driver_data=driver_data@entry=0x2650c90, obj_output=obj_output@entry=0x291a2b0) at vdpau_video_x11.c:583 #11 0x7fca423cb2e1 in queue_surface_unlocked (obj_surface=, obj_output=0x291a2b0, driver_data=0x2650c90) at vdpau_video_x11.c:610 #12 put_surface_unlocked (flags=32, target_rect=0x7fca1f776f90, source_rect=0x7fca1f776f80, obj_output=0x291a2b0, obj_surface=0x2919bf0, driver_data=0x2650c90) at vdpau_video_x11.c:689 #13 put_surface (driver_data=driver_data@entry=0x2650c90, surface=surface@entry=50331655, drawable=drawable@entry=71303307, drawable_width=, drawable_height=720, source_rect=source_rect@entry=0x7fca1f776f80, target_rect=target_rect@entry=0x7fca1f776f90, flags=flags@entry=32) at vdpau_video_x11.c:755 #14 0x7fca423cb59c in vdpau_PutSurface (ctx=, surface=50331655, draw=0x440008b, srcx=, srcy= out>, srcw=, srch=720, destx=0, desty=0, destw=1280, desth=720, cliprects=0x0, number_cliprects=0, flags=32) at vdpau_video_x11.c:808 #15 0x0040eed2 in on_client_draw (glsink=, buf= out>, data=0x626d40 ) at video.c:619 Full backtrace at:http://pastebin.com/RZqmUkMY Using vdpau driver on radeon and: libX11 1.6.2 libxcb 1.11 or 1.10 mesa 11.0 thank you for any help, - Vasilis ___ Libva mailing list li...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/22] meta/blit: Don't dynamically select the MSAA "emit" function
On Wed, 2016-02-17 at 17:58 -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Just include all 3 versions in the shader. The GLSL type system will
> pick the correct one. This simplifies the code a bit, and it helps pave
> the way for additional simplifications.
>
> For vec4 outputs, we have to make out_color not be a shader output.
> Otherwise the shader will fail to compile due to static writes to both a
> user-defined output and gl_FragColor. This is pretty ugly, and I think
> it should be fixed by not writing to gl_FragColor... but that has its
> own challenges.
I am a bit confused by this last paragraph, isn't this issue fixed in
patch 18?
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/common/meta_blit.c | 23 +--
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c
> b/src/mesa/drivers/common/meta_blit.c
> index 72428f9..355c937 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -550,19 +550,6 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> }
> }
>
> - /* Scale the final result. */
> - if (src_datatype == GL_UNSIGNED_INT || src_datatype == GL_INT) {
> -ralloc_asprintf_append(&sample_resolve,
> - " for (int i = 0; i <
> out_color.length(); i++)\n"
> - " out_color[i] = sample_%d_0;\n",
> - samples);
> - } else {
> -ralloc_asprintf_append(&sample_resolve,
> - " for (int i = 0; i <
> out_color.length(); i++)\n"
> - " out_color[i] = sample_%d_0 /
> %f;\n",
> - samples, (float)samples);
> - }
> -
> fs_source = ralloc_asprintf(mem_ctx,
> "#version 130\n"
> "#extension GL_ARB_texture_multisample:
> require\n"
> @@ -575,17 +562,25 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> "ivec4 merge(ivec4 a, ivec4 b) { return
> (a >> 1) + (b >> 1) + (a & b & 1); }\n"
> /* The divide will happen at the end
> for floats. */
> "vec4 merge(vec4 a, vec4 b) { return a
> + b; }\n"
> + "void emit2(gvec4 s) { for (int i = 0;
> i < out_color.length(); i++) out_color[i] = s; }\n"
> + "void emit(ivec4 s) { emit2(gvec4(s));
> }\n"
> + "void emit(uvec4 s) { emit2(gvec4(s));
> }\n"
> + /* Scale the final result. */
> + "void emit(vec4 s) { emit2(gvec4(s /
> %f)); }\n"
> "\n"
> "void main()\n"
> "{\n"
> "%s\n" /* sample_resolve */
> + "emit(sample_%d_0);\n"
> "}\n",
> vec4_prefix,
> vec4_prefix,
> sampler_array_suffix,
> texcoord_type,
> drawFb->_NumColorDrawBuffers,
> - sample_resolve);
> + (float) samples,
> + sample_resolve,
> + samples);
>}
>
>vs_source = ralloc_asprintf(mem_ctx,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] trace: assorted whitespace and formatting fixes
Both patches are:
Reviewed-by: Eduardo Lima Mitev
On 02/19/2016 01:31 AM, Brian Paul wrote:
> ---
> src/gallium/drivers/trace/tr_context.c | 60
> ++
> 1 file changed, 31 insertions(+), 29 deletions(-)
>
> diff --git a/src/gallium/drivers/trace/tr_context.c
> b/src/gallium/drivers/trace/tr_context.c
> index db6ad40..57f8518 100644
> --- a/src/gallium/drivers/trace/tr_context.c
> +++ b/src/gallium/drivers/trace/tr_context.c
> @@ -50,7 +50,8 @@ struct trace_query
>
>
> static inline struct trace_query *
> -trace_query(struct pipe_query *query) {
> +trace_query(struct pipe_query *query)
> +{
> return (struct trace_query *)query;
> }
>
> @@ -93,7 +94,7 @@ trace_surface_unwrap(struct trace_context *tr_ctx,
>return NULL;
>
> assert(surface->texture);
> - if(!surface->texture)
> + if (!surface->texture)
>return surface;
>
> tr_surf = trace_surface(surface);
> @@ -788,9 +789,9 @@ trace_context_set_framebuffer_state(struct pipe_context
> *_pipe,
>
> /* Unwrap the input state */
> memcpy(&unwrapped_state, state, sizeof(unwrapped_state));
> - for(i = 0; i < state->nr_cbufs; ++i)
> + for (i = 0; i < state->nr_cbufs; ++i)
>unwrapped_state.cbufs[i] = trace_surface_unwrap(tr_ctx,
> state->cbufs[i]);
> - for(i = state->nr_cbufs; i < PIPE_MAX_COLOR_BUFS; ++i)
> + for (i = state->nr_cbufs; i < PIPE_MAX_COLOR_BUFS; ++i)
>unwrapped_state.cbufs[i] = NULL;
> unwrapped_state.zsbuf = trace_surface_unwrap(tr_ctx, state->zsbuf);
> state = &unwrapped_state;
> @@ -870,8 +871,8 @@ trace_context_set_viewport_states(struct pipe_context
> *_pipe,
>
> static struct pipe_sampler_view *
> trace_context_create_sampler_view(struct pipe_context *_pipe,
> - struct pipe_resource *_resource,
> - const struct pipe_sampler_view *templ)
> + struct pipe_resource *_resource,
> + const struct pipe_sampler_view *templ)
> {
> struct trace_context *tr_ctx = trace_context(_pipe);
> struct trace_resource *tr_res = trace_resource(_resource);
> @@ -913,7 +914,7 @@ trace_context_create_sampler_view(struct pipe_context
> *_pipe,
>
> static void
> trace_context_sampler_view_destroy(struct pipe_context *_pipe,
> - struct pipe_sampler_view *_view)
> + struct pipe_sampler_view *_view)
> {
> struct trace_context *tr_ctx = trace_context(_pipe);
> struct trace_sampler_view *tr_view = trace_sampler_view(_view);
> @@ -955,7 +956,7 @@ trace_context_create_surface(struct pipe_context *_pipe,
>
> trace_dump_arg(ptr, pipe);
> trace_dump_arg(ptr, resource);
> -
> +
> trace_dump_arg_begin("surf_tmpl");
> trace_dump_surface_template(surf_tmpl, resource->target);
> trace_dump_arg_end();
> @@ -1009,7 +1010,7 @@ trace_context_set_sampler_views(struct pipe_context
> *_pipe,
> /* remove this when we have pipe->set_sampler_views(..., start, ...) */
> assert(start == 0);
>
> - for(i = 0; i < num; ++i) {
> + for (i = 0; i < num; ++i) {
>tr_view = trace_sampler_view(views[i]);
>unwrapped_views[i] = tr_view ? tr_view->sampler_view : NULL;
> }
> @@ -1459,7 +1460,7 @@ trace_context_transfer_map(struct pipe_context
> *_context,
> *transfer = trace_transfer_create(tr_context, tr_res, result);
>
> if (map) {
> - if(usage & PIPE_TRANSFER_WRITE) {
> + if (usage & PIPE_TRANSFER_WRITE) {
> trace_transfer(*transfer)->map = map;
>}
> }
> @@ -1477,9 +1478,7 @@ trace_context_transfer_flush_region( struct
> pipe_context *_context,
> struct pipe_context *context = tr_context->pipe;
> struct pipe_transfer *transfer = tr_transfer->transfer;
>
> - context->transfer_flush_region(context,
> - transfer,
> - box);
> + context->transfer_flush_region(context, transfer, box);
> }
>
> static void
> @@ -1491,7 +1490,7 @@ trace_context_transfer_unmap(struct pipe_context
> *_context,
> struct pipe_context *context = tr_ctx->pipe;
> struct pipe_transfer *transfer = tr_trans->transfer;
>
> - if(tr_trans->map) {
> + if (tr_trans->map) {
>/*
> * Fake a transfer_inline_write
> */
> @@ -1570,15 +1569,16 @@ trace_context_transfer_inline_write(struct
> pipe_context *_context,
>
> trace_dump_call_end();
>
> - context->transfer_inline_write(context, resource,
> - level, usage, box, data, stride,
> layer_stride);
> + context->transfer_inline_write(context, resource, level, usage, box,
> + data, stride, layer_stride);
> }
>
>
> -static void trace_context_render_condition(struct pipe_context *_context,
> - struct pipe_query *query,
> -
Re: [Mesa-dev] [PATCH] anv: fix warning about unused width variable.
On 02/17/2016 03:23 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> We don't use width outside the debug clause here.
> ---
This issue is still valid, but patch needs rebasing. There are at least
two instances of this problem in gen7_pack.h, maybe more in the rest of
pack header generators.
Eduardo
> src/vulkan/gen_pack_header.py | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/vulkan/gen_pack_header.py b/src/vulkan/gen_pack_header.py
> index 3cabb58..75c4f26 100755
> --- a/src/vulkan/gen_pack_header.py
> +++ b/src/vulkan/gen_pack_header.py
> @@ -62,11 +62,10 @@ __gen_mbo(uint32_t start, uint32_t end)
> static inline uint64_t
> __gen_uint(uint64_t v, uint32_t start, uint32_t end)
> {
> - const int width = end - start + 1;
> -
> __gen_validate_value(v);
>
> #if DEBUG
> + const int width = end - start + 1;
> if (width < 64) {
>const uint64_t max = (1ull << width) - 1;
>assert(v <= max);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa: add GL_OES_texture_stencil8 support
Patch needs rebase, but see a comment below.
On 02/18/2016 02:27 AM, Ilia Mirkin wrote:
> It's basically the same thing as GL_ARB_texture_stencil8 except that
> glCopyTexImage isn't supported, so add STENCIL_INDEX to the list of
> invalid GLES formats for glCopyTexImage.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v1 -> v2: add checking to es3_error_check_format_and_type.
>
> I only get 2 dEQP test failures, and they're both related to the, I believe
> incorrect, computation of baseFormat based on the texture's/rb's real
> internal format instead of the "real" base format it was created with.
>
> docs/GL3.txt | 2 +-
> src/mesa/main/extensions_table.h | 1 +
> src/mesa/main/glformats.c| 7 +++
> src/mesa/main/teximage.c | 2 ++
> 4 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 3c4db06..26847b9 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -256,7 +256,7 @@ GLES3.2, GLSL ES 3.2
>GL_OES_texture_border_clamp DONE (all drivers)
>GL_OES_texture_buffernot started (based on
> GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and
> GL_ARB_texture_buffer_object_rgb32 that are all done)
>GL_OES_texture_cube_map_arraynot started (based on
> GL_ARB_texture_cube_map_array, which is done for all drivers)
> - GL_OES_texture_stencil8 not started (based on
> GL_ARB_texture_stencil8, which is done for some drivers)
> + GL_OES_texture_stencil8 DONE (all drivers
> that support GL_ARB_texture_stencil8)
>GL_OES_texture_storage_multisample_2d_array DONE (all drivers
> that support GL_ARB_texture_multisample)
>
> More info about these features and the work involved can be found at
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index c94928b..3a90bc9 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -345,6 +345,7 @@ EXT(OES_texture_half_float ,
> OES_texture_half_float
> EXT(OES_texture_half_float_linear , OES_texture_half_float_linear
> , x , x , x , ES2, 2005)
> EXT(OES_texture_mirrored_repeat , dummy_true
> , x , x , ES1, x , 2005)
> EXT(OES_texture_npot, ARB_texture_non_power_of_two
> , x , x , ES1, ES2, 2005)
> +EXT(OES_texture_stencil8, ARB_texture_stencil8
> , x , x , x , 30, 2014)
> EXT(OES_texture_storage_multisample_2d_array, ARB_texture_multisample
> , x , x , ES1, 31, 2014)
> EXT(OES_texture_view, ARB_texture_view
> , x , x , x , 31, 2014)
> EXT(OES_vertex_array_object , dummy_true
> , x , x , ES1, ES2, 2010)
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index f528444..2660ecc 100644
> --- a/src/mesa/main/glformats.c
> +++ b/src/mesa/main/glformats.c
> @@ -3153,6 +3153,13 @@ _mesa_es3_error_check_format_and_type(const struct
> gl_context *ctx,
>}
>break;
>
> + case GL_STENCIL_INDEX:
> + if (_mesa_has_OES_texture_stencil8(ctx) &&
> + type == GL_UNSIGNED_BYTE &&
> + internalFormat == GL_STENCIL_INDEX8)
> + break;
> + return GL_INVALID_OPERATION;
> +
Nitpicking, I would prefer the logic inverted, as most of cases in that
function. IMHO, the error condition looks more explicit if one does:
case GL_STENCIL_INDEX:
if (!_mesa_has_OES_texture_stencil8(ctx) ||
type != GL_UNSIGNED_BYTE ||
internalFormat != GL_STENCIL_INDEX8) {
return GL_INVALID_OPERATION;
}
break;
But feel free to ignore this.
After rebasing, patch is:
Reviewed-by: Eduardo Lima Mitev
> case GL_ALPHA:
> case GL_LUMINANCE:
> case GL_LUMINANCE_ALPHA:
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 57765d7..8a4c628 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -2285,8 +2285,10 @@ copytexture_error_check( struct gl_context *ctx,
> GLuint dimensions,
>}
>if (baseFormat == GL_DEPTH_COMPONENT ||
>baseFormat == GL_DEPTH_STENCIL ||
> + baseFormat == GL_STENCIL_INDEX ||
>rb_base_format == GL_DEPTH_COMPONENT ||
>rb_base_format == GL_DEPTH_STENCIL ||
> + rb_base_format == GL_STENCIL_INDEX ||
>((baseFormat == GL_LUMINANCE_ALPHA ||
> baseFormat == GL_ALPHA) &&
> rb_base_format != GL_RGBA) ||
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/22] i965/meta: Delete unused layer shader uniform
On Thu, 2016-02-18 at 16:38 +0100, Iago Toral wrote:
> I sent minor comments to patches 3 and 4. I think you should fix the
> commit log for the latter at least. Otherwise, patches 1-6 are:
>
> Reviewed-by: Iago Toral Quiroga
And patches 7-22 are also:
Reviewed-by: Iago Toral Quiroga
> On Wed, 2016-02-17 at 17:57 -0800, Ian Romanick wrote:
> > From: Ian Romanick
> >
> > Signed-off-by: Ian Romanick
> > ---
> > src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> > b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> > index 488fa6c..00c59f3 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
> > @@ -110,7 +110,6 @@ brw_bind_rep_write_shader(struct brw_context *brw,
> > float *color)
> >"#extension GL_AMD_vertex_shader_layer : enable\n"
> >"#extension GL_ARB_draw_instanced : enable\n"
> >"attribute vec4 position;\n"
> > - "uniform int layer;\n"
> >"void main()\n"
> >"{\n"
> >"#ifdef GL_AMD_vertex_shader_layer\n"
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit
On Thu, 2016-02-18 at 16:13 -0800, Ian Romanick wrote:
> On 02/18/2016 01:47 PM, Ian Romanick wrote:
> > On 02/18/2016 08:44 AM, Neil Roberts wrote:
> >> I made a pathological test case (attached) which repeatedly renders into
> >> an MSAA FBO and then blits it to the screen and measures the framerate.
> >> It checks it with a range of different sample counts. The rendering is
> >> done either by rendering two triangles to fill the framebuffer or by
> >> calling glClear.
> >>
> >> The percentage increase in framerate after applying the patch is like
> >> this:
> >>
> >> With triangles to fill buffer:
> >>
> >> 16 62,27%
> >> 8 48,59%
> >> 4 27,72%
> >> 2 5,34%
> >> 0 0,58%
> >>
> >> With glClear:
> >>
> >> 16 -5,20%
> >> 8 -7,08%
> >> 4 -2,45%
> >> 2 -20,76%
> >> 0 3,71%
> >
> > I find this result interesting. In the samples=0 case, the before and
> > after shaders should be identical. I dug into this a bit, and I think
> > the problem is the previous patch. Using do { ... } while (false) in
> > the macro makes the compiler generate some really, really bad code.
> > Just deleting those two lines makes a huge difference.
> >
> > With do { ... } while (false):
> >
> > SIMD8 shader: 228 instructions. 4 loops. 1554 cycles. 0:0 spills:fills.
> > Promoted 0 constants. Compacted 3648 to 2192 bytes (40%)
> >
> > Without:
> >
> > SIMD8 shader: 159 instructions. 0 loops. 380 cycles. 0:0 spills:fills.
> > Promoted 0 constants. Compacted 2544 to 1600 bytes (37%)
> > SIMD16 shader: 159 instructions. 0 loops. 898 cycles. 0:0 spills:fills.
> > Promoted 0 constants. Compacted 2544 to 1600 bytes (37%)
> >
> > This is for samples=16 and sampler2DMS. The cycle counts are bogus
> > because the 4 loops have their cycle counts statically multiplied by
> > 10... even though the loop will only execute once.
> >
> > So... I'll try some more experiments. I also wonder about changing the
> > SAMPLES > 1 to SAMPLES > 2.
>
> This is weird, and I'm not sure what to make of it. I ran your test at
> a bunch of commits on my branch. Getting rid of gl_FragColor was the
> big win. The GL_EXT_shader_samples_identical patch is still the big
> loss. I'm assuming that causes enough register pressure over the
> previous commit to lose SIMD16. The following patch just removes the
> "do {" and "} while (false)". That gets back some of the losses,
> but not all of it.
I don't know much about this, but using shader_samples_identical should
only give a benefit if we actually get identical samples, otherwise it
means more work, right? I noticed that the test renders a quad with
random colors for each vertex that will be interpolated across the
region, so could it be that we are hitting few cases of identical
samples? Shouldn't the results be expected to be better if we rendered a
flat color instead?
> The raw per-commit data is below.
>
> 5c7f974 Android: disable unused-parameter warning
> With triangles to fill buffer:
>
> 8,419.603882
> 4,633.834045
> 2,595.628113
> 0,795.798157
>
> With glClear:
>
> 8,450.937958
> 4,594.000610
> 2,641.354553
> 0,767.400818
>
> 89b8c0a meta/blit: Replace the gl_FragColor write
> With triangles to fill buffer:
>
> 8,597.943054
> 4,803.083862
> 2,942.862549
> 0,1129.432983
>
> With glClear:
>
> 8,643.500671
> 4,980.392151
> 2,982.704407
> 0,1116.569946
>
> 7025d43 meta/blit: Don't dynamically select the MSAA "merge" function
> With triangles to fill buffer:
>
> 8,599.412598
> 4,954.745056
> 2,933.184021
> 0,1129.305420
>
> With glClear:
>
> 8,582.106079
> 4,965.810303
> 2,975.419434
> 0,1169.180420
>
> b895a4d meta/blit: Use a single, master shader template for MSAA-SS blits
> With triangles to fill buffer:
>
> 8,591.786011
> 4,932.835815
> 2,910.498047
> 0,1072.501099
>
> With glClear:
>
> 8,623.441406
> 4,952.562378
> 2,941.442261
> 0,1081.314819
>
> 197e4be meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit
> With triangles to fill buffer:
>
> 8,559.252869
> 4,795.355103
> 2,781.494202
> 0,941.619568
>
> With glClear:
>
> 8,577.400513
> 4,806.321533
> 2,811.030029
> 0,957.579224
>
> ec01613 fix loop nonsense derp
> With triangles to fill buffer:
>
> 8,559.221558
> 4,788.767944
> 2,786.287170
> 0,1078.632324
>
> With glClear:
>
> 8,575.771545
> 4,956.205750
> 2,813.206482
> 0,.111084
>
> > I will probably also make a patch to fix the damage done by the do { ...
> > } while (false). That's just comedy.
> >
> >> It seems like a pretty convincing win for the triangle case but the
> >> clear case makes it slightly worse. Presumably this is because we don't
> >> do anything to detect the value stored in the MCS buffer when doing a
> >> fast clear so the fast path isn't taken and the shader being more
> >> complicated makes it slower.
> >>
> >> Not sure if we want to try and do anything about that because
> >> potentially the cleared pixels aren't very common in a frame
Re: [Mesa-dev] [PATCH] i965: Add missing null checks in intel_mipmap_tree.c
Reviewed-by: Samuel Iglesias Gonsálvez On Wed, Feb 17, 2016 at 05:07:00PM +0200, Juha-Pekka Heikkila wrote: > Just check miptree_create() returned other than NULL as everywhere > else in the file. > > Signed-off-by: Juha-Pekka Heikkila > --- > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > index 6c233d8..5b0e938 100644 > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c > @@ -726,6 +726,9 @@ intel_miptree_create(struct brw_context *brw, > width0, height0, depth0, num_samples, > layout_flags); > > + if (!mt) > + return NULL; > + > /* If the BO is too large to fit in the aperture, we need to use the > * BLT engine to support it. Prior to Sandybridge, the BLT paths can't > * handle Y-tiling, so we need to fall back to X. > @@ -1527,6 +1530,9 @@ intel_miptree_alloc_mcs(struct brw_context *brw, > 0 /* num_samples */, > mcs_flags); > > + if (!mt->mcs_mt) > + return false; > + > intel_miptree_init_mcs(brw, mt, 0xFF); > > return mt->mcs_mt; > -- > 1.9.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix standalone compiler
Reviewed-by: Samuel Iglesias Gonsálvez On Wed, Feb 17, 2016 at 04:32:11PM -0500, Rob Clark wrote: > From: Rob Clark > > Need to set some non-zero limits for MaxCombinedUniformComponents, > otherwise we hit an "Too many shader uniform components" error > in the linker. > > Signed-off-by: Rob Clark > --- > src/compiler/glsl/main.cpp | 12 > 1 file changed, 12 insertions(+) > > diff --git a/src/compiler/glsl/main.cpp b/src/compiler/glsl/main.cpp > index bdf2f07..d253575 100644 > --- a/src/compiler/glsl/main.cpp > +++ b/src/compiler/glsl/main.cpp > @@ -61,6 +61,7 @@ initialize_context(struct gl_context *ctx, gl_api api) > ctx->Const.MaxComputeSharedMemorySize = 32768; > ctx->Const.Program[MESA_SHADER_COMPUTE].MaxTextureImageUnits = 16; > ctx->Const.Program[MESA_SHADER_COMPUTE].MaxUniformComponents = 1024; > + ctx->Const.Program[MESA_SHADER_COMPUTE].MaxCombinedUniformComponents = > 1024; > ctx->Const.Program[MESA_SHADER_COMPUTE].MaxInputComponents = 0; /* not > used */ > ctx->Const.Program[MESA_SHADER_COMPUTE].MaxOutputComponents = 0; /* not > used */ > ctx->Const.Program[MESA_SHADER_COMPUTE].MaxAtomicBuffers = 8; > @@ -82,12 +83,14 @@ initialize_context(struct gl_context *ctx, gl_api api) >ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs = 8; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits = 0; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxUniformComponents = 128 * 4; > + ctx->Const.Program[MESA_SHADER_VERTEX].MaxCombinedUniformComponents = > 128 * 4; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxInputComponents = 0; /* not > used */ >ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents = 32; > >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits = > ctx->Const.MaxCombinedTextureImageUnits; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxUniformComponents = 16 * 4; > + ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxCombinedUniformComponents > = 16 * 4; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxInputComponents = > ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxOutputComponents = 0; /* > not used */ > @@ -108,12 +111,14 @@ initialize_context(struct gl_context *ctx, gl_api api) >ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs = 16; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits = 0; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxUniformComponents = 512; > + ctx->Const.Program[MESA_SHADER_VERTEX].MaxCombinedUniformComponents = > 512; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxInputComponents = 0; /* not > used */ >ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents = 32; > >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits = > ctx->Const.MaxCombinedTextureImageUnits; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxUniformComponents = 64; > + ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxCombinedUniformComponents > = 64; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxInputComponents = > ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxOutputComponents = 0; /* > not used */ > @@ -134,11 +139,13 @@ initialize_context(struct gl_context *ctx, gl_api api) >ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs = 16; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits = 16; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxUniformComponents = 1024; > + ctx->Const.Program[MESA_SHADER_VERTEX].MaxCombinedUniformComponents = > 1024; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxInputComponents = 0; /* not > used */ >ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents = 64; > >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits = 16; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxUniformComponents = 1024; > + ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxCombinedUniformComponents > = 1024; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxInputComponents = > ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents; >ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxOutputComponents = 0; /* > not used */ > @@ -158,17 +165,20 @@ initialize_context(struct gl_context *ctx, gl_api api) >ctx->Const.Program[MESA_SHADER_VERTEX].MaxAttribs = 16; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxTextureImageUnits = 16; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxUniformComponents = 1024; > + ctx->Const.Program[MESA_SHADER_VERTEX].MaxCombinedUniformComponents = > 1024; >ctx->Const.Program[MESA_SHADER_VERTEX].MaxInputComponents = 0; /* not > used */ >ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents = 64; > >ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxTextureImageUnits
Re: [Mesa-dev] [PATCH 16/25] radeonsi: add PS prolog
On Tue, Feb 16, 2016 at 5:31 PM, Nicolai Hähnle wrote: > So, patches 12-16 also look good to me except for the comments I've sent on > 12-14. Does this mean I can add your Rb on those? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit
Iago Toral writes: > I don't know much about this, but using shader_samples_identical > should only give a benefit if we actually get identical samples, > otherwise it means more work, right? I noticed that the test renders a > quad with random colors for each vertex that will be interpolated > across the region, so could it be that we are hitting few cases of > identical samples? Shouldn't the results be expected to be better if > we rendered a flat color instead? It should all be identical regardless of the color chosen because it is doing per-pixel shading rather than per-sample which means the fragment shader is only run once per pixel and the same value is written to all of the samples. The only case where you get differing samples normally is at the edges of a polygon where the single color is only written to a few of the samples. In this case it is even more identical because the random color is set on a uniform rather than a vertex so it is actually using the same color for the whole framebuffer. However, it is rendered as two triangles which might mean that along the diagonal of the framebuffer where the two triangles meet there will be a polygon edge which means the hardware might not recognise that these all the same color, but that should only be a few pixels and probably won't affect the results very much. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit
On Fri, 2016-02-19 at 11:47 +, Neil Roberts wrote: > Iago Toral writes: > > > I don't know much about this, but using shader_samples_identical > > should only give a benefit if we actually get identical samples, > > otherwise it means more work, right? I noticed that the test renders a > > quad with random colors for each vertex that will be interpolated > > across the region, so could it be that we are hitting few cases of > > identical samples? Shouldn't the results be expected to be better if > > we rendered a flat color instead? > > It should all be identical regardless of the color chosen because it is > doing per-pixel shading rather than per-sample which means the fragment > shader is only run once per pixel and the same value is written to all > of the samples. The only case where you get differing samples normally > is at the edges of a polygon where the single color is only written to a > few of the samples. > > In this case it is even more identical because the random color is set > on a uniform rather than a vertex so it is actually using the same color > for the whole framebuffer. However, it is rendered as two triangles > which might mean that along the diagonal of the framebuffer where the > two triangles meet there will be a polygon edge which means the hardware > might not recognise that these all the same color, but that should only > be a few pixels and probably won't affect the results very much. You're right, I read through the test code too fast :) Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] mesa: add GL_OES_texture_border_clamp support
On Wed, Feb 17, 2016 at 08:46:36PM -0500, Ilia Mirkin wrote:
> Only minor differences to the existing ARB_texture_border_clamp support.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v1 -> v2: added a patch to add the EXT version of this extension
>
> docs/GL3.txt| 2 +-
> src/mapi/glapi/gen/es_EXT.xml | 58
> -
> src/mesa/main/extensions_table.h| 1 +
> src/mesa/main/samplerobj.c | 6 ++--
> src/mesa/main/tests/dispatch_sanity.cpp | 10 ++
> src/mesa/main/texparam.c| 11 ---
> 6 files changed, 80 insertions(+), 8 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index ea7ceef..0957247 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -253,7 +253,7 @@ GLES3.2, GLSL ES 3.2
>GL_OES_shader_io_blocks not started (based on
> parts of GLSL 1.50, which is done)
>GL_OES_shader_multisample_interpolation not started (based on
> parts of GL_ARB_gpu_shader5, which is done)
>GL_OES_tessellation_shader not started (based on
> GL_ARB_tessellation_shader, which is done for some drivers)
> - GL_OES_texture_border_clamp not started (based on
> GL_ARB_texture_border_clamp, which is done)
> + GL_OES_texture_border_clamp DONE (all drivers)
>GL_OES_texture_buffernot started (based on
> GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and
> GL_ARB_texture_buffer_object_rgb32 that are all done)
>GL_OES_texture_cube_map_arraynot started (based on
> GL_ARB_texture_cube_map_array, which is done for all drivers)
>GL_OES_texture_stencil8 not started (based on
> GL_ARB_texture_stencil8, which is done for some drivers)
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 86df980..fb0ef05 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -982,5 +982,61 @@
>
>
>
> -
> +
> +
> +
> +
> +
> +
> +
> +
I have a doubt here that it is repeated along this patch and the following
one...
Shouldn't it be es2="3.2"? Because the extension was in core in OpenGL ES 3.2.
Sam
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + alias="GetTexParameterIiv">
> +
> +
> +
> +
> +
> + alias="GetTexParameterIuiv">
> +
> +
> +
> +
> +
> + alias="SamplerParameterIiv">
> +
> +
> +
> +
> +
> + alias="SamplerParameterIuiv">
> +
> +
> +
> +
> +
> + alias="GetSamplerParameterIiv">
> +
> +
> +
> +
> +
> + alias="GetSamplerParameterIuiv">
> +
> +
> +
> +
> +
> +
> +
>
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index d1e3a99..b07d635 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -333,6 +333,7 @@ EXT(OES_stencil8, dummy_true
> EXT(OES_stencil_wrap, dummy_true
> , x , x , ES1, x , 2002)
> EXT(OES_surfaceless_context , dummy_true
> , x , x , ES1, ES2, 2012)
> EXT(OES_texture_3D , dummy_true
> , x , x , x , ES2, 2005)
> +EXT(OES_texture_border_clamp, ARB_texture_border_clamp
> , x , x , x , ES2, 2014)
> EXT(OES_texture_cube_map, ARB_texture_cube_map
> , x , x , ES1, x , 2007)
> EXT(OES_texture_env_crossbar, ARB_texture_env_crossbar
> , x , x , ES1, x , 2005)
> EXT(OES_texture_float , OES_texture_float
> , x , x , x , ES2, 2005)
> diff --git a/src/mesa/main/samplerobj.c b/src/mesa/main/samplerobj.c
> index fe15508..ca366d9 100644
> --- a/src/mesa/main/samplerobj.c
> +++ b/src/mesa/main/samplerobj.c
> @@ -1518,7 +1518,8 @@ _mesa_GetSamplerParameterIiv(GLuint sampler, GLenum
> pname, GLint *params)
>
> sampObj = _mesa_lookup_samplerobj(ctx, sampler);
> if (!sampObj) {
> - _mesa_error(ctx, GL_INVALID_VALUE,
> + _mesa_error(ctx, (_mesa_is_gles(ctx) ?
> +GL_INVALID_OPERATION : GL_INVALID_VALUE),
>"glGetSamplerParameterIiv(sampler %u)",
>sampler);
>return;
> @@ -1593,7 +1594,8 @@ _mesa_GetSamplerParameterIuiv(GLuint sampler, GLenum
> pname, GLuint *params)
>
> sampObj = _mesa_lookup_samplerobj(ctx, sampler);
> if (!sampObj) {
> - _mesa_error(ctx, GL_INVALID_VALUE,
> + _mesa_error(ctx, (_mesa_is_gles(ctx) ?
> +
Re: [Mesa-dev] [PATCH v2 1/2] mesa: add GL_OES_texture_border_clamp support
On Feb 19, 2016 8:05 AM, "Samuel Iglesias Gonsálvez" wrote: > > On Wed, Feb 17, 2016 at 08:46:36PM -0500, Ilia Mirkin wrote: > > Only minor differences to the existing ARB_texture_border_clamp support. > > > > Signed-off-by: Ilia Mirkin > > --- > > > > v1 -> v2: added a patch to add the EXT version of this extension > > > > docs/GL3.txt| 2 +- > > src/mapi/glapi/gen/es_EXT.xml | 58 - > > src/mesa/main/extensions_table.h| 1 + > > src/mesa/main/samplerobj.c | 6 ++-- > > src/mesa/main/tests/dispatch_sanity.cpp | 10 ++ > > src/mesa/main/texparam.c| 11 --- > > 6 files changed, 80 insertions(+), 8 deletions(-) > > > > diff --git a/docs/GL3.txt b/docs/GL3.txt > > index ea7ceef..0957247 100644 > > --- a/docs/GL3.txt > > +++ b/docs/GL3.txt > > @@ -253,7 +253,7 @@ GLES3.2, GLSL ES 3.2 > >GL_OES_shader_io_blocks not started (based on parts of GLSL 1.50, which is done) > >GL_OES_shader_multisample_interpolation not started (based on parts of GL_ARB_gpu_shader5, which is done) > >GL_OES_tessellation_shader not started (based on GL_ARB_tessellation_shader, which is done for some drivers) > > - GL_OES_texture_border_clamp not started (based on GL_ARB_texture_border_clamp, which is done) > > + GL_OES_texture_border_clamp DONE (all drivers) > >GL_OES_texture_buffernot started (based on GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_range, and GL_ARB_texture_buffer_object_rgb32 that are all done) > >GL_OES_texture_cube_map_arraynot started (based on GL_ARB_texture_cube_map_array, which is done for all drivers) > >GL_OES_texture_stencil8 not started (based on GL_ARB_texture_stencil8, which is done for some drivers) > > diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml > > index 86df980..fb0ef05 100644 > > --- a/src/mapi/glapi/gen/es_EXT.xml > > +++ b/src/mapi/glapi/gen/es_EXT.xml > > @@ -982,5 +982,61 @@ > > > > > > > > - > > + > > + > > + > > + > > + > > + > > + > > + > > I have a doubt here that it is repeated along this patch and the following one... > Shouldn't it be es2="3.2"? Because the extension was in core in OpenGL ES 3.2. That's not what this means... It might be core in gles 100, but the entrypoint should be exposed in gles3. The ext itself is available starting gles2, but int formats only became available in gles3, and this entrypoint only applies to int color formats. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Libva] vaPutSurface never returns
Was about to mention the same thing as Christian :-) Vasilis, is there any reason why you're using vdpau + the vdpau to vaapi adapter, as opposed to the gallium vaapi target directly ? Mesa 11.0.x has the said target (toggle with --enable-va at configure time), although there has been quite a few fixes from Christian, Julien and others since then. As an alternative I'd suggest mesa 11.1.x series (or mesa 11.2.0-rc1 coming out later on today). -Emil On 19 February 2016 at 09:53, Christian König wrote: > Questions for VDPAU should probably go to either the Mesa list or the VDPAU > list, libva is completely unrelated to this. > > Well is it possible that you just locked up the GPU? Please take a look at > /sys/kernel/debug/dri/0/radeon_fence_info and dmesg. > > Regards, > Christian. > > > Am 18.02.2016 um 23:43 schrieb Vasilis Liaskovitis: > > Hi, > > I have an application that renders by binding libva/vdpau surfaces onto GLX > pixmaps.Playback works ok for a while, but than the application displays > black frames after a few minutes of operation (always reproducible within > 1-15 minutes usually). > > When this happens, gdb backtrace shows that the current call to > vdpau_PutSurface (done from the application) never returns. Are there any > obious reasons that would lead to vaPutSurface to never return (e.g. some > deadlock in libva/vdpau?) > > Using vdpau driver on radeon. > > Backtrace of thread waiting in vaPutSurface(): > > Thread 8 (Thread 0x7fca1f778700 (LWP 3580)): > #0 0x7fca55a3e12d in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x7fca5316b262 in poll (__timeout=-1, __nfds=1, > __fds=0x7fca1f776a20) at > /usr/include/x86_64-linux-gnu/bits/poll2.h:46 > #2 _xcb_conn_wait (c=c@entry=0x2885500, cond=cond@entry=0x7fca1f776b40, > vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459 > #3 0x7fca5316cadf in wait_for_reply (c=c@entry=0x2885500, > request=31161, > e=e@entry=0x0) at xcb_in.c:491 > #4 0x7fca5316cbf2 in xcb_wait_for_reply (c=0x2885500, request=31161, > e=0x0) > at xcb_in.c:521 > #5 0x7fca419b8004 in vl_dri2_get_flush_reply (scrn=0x2653600) at > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:110 > #6 0x7fca419b8101 in vl_dri2_destroy_drawable (scrn=0x2653600) at > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:153 > #7 0x7fca419b8185 in vl_dri2_set_drawable (scrn=0x2653600, > drawable=71303307) at > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:176 > #8 0x7fca419b82c8 in vl_dri2_screen_texture_from_drawable > (vscreen=0x2653600, drawable=0x440008b) at > ../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:193 > #9 0x7fca419b61ab in vlVdpPresentationQueueDisplay > (presentation_queue=, surface=5, clip_width=1280, > clip_height=720, earliest_presentation_time=0) > at > ../../../../../../src/gallium/state_trackers/vdpau/presentation.c:234 > #10 0x7fca423ca6a3 in flip_surface_unlocked > (driver_data=driver_data@entry=0x2650c90, > obj_output=obj_output@entry=0x291a2b0) at vdpau_video_x11.c:583 > #11 0x7fca423cb2e1 in queue_surface_unlocked (obj_surface= out>, > obj_output=0x291a2b0, driver_data=0x2650c90) at > vdpau_video_x11.c:610 > #12 put_surface_unlocked (flags=32, target_rect=0x7fca1f776f90, > source_rect=0x7fca1f776f80, obj_output=0x291a2b0, > obj_surface=0x2919bf0, > driver_data=0x2650c90) at vdpau_video_x11.c:689 > #13 put_surface (driver_data=driver_data@entry=0x2650c90, > surface=surface@entry=50331655, drawable=drawable@entry=71303307, > drawable_width=, drawable_height=720, > source_rect=source_rect@entry=0x7fca1f776f80, > target_rect=target_rect@entry=0x7fca1f776f90, > flags=flags@entry=32) > at vdpau_video_x11.c:755 > #14 0x7fca423cb59c in vdpau_PutSurface (ctx=, > surface=50331655, draw=0x440008b, srcx=, > srcy= out>, srcw=, srch=720, destx=0, desty=0, > destw=1280, desth=720, cliprects=0x0, number_cliprects=0, > flags=32) > at vdpau_video_x11.c:808 > #15 0x0040eed2 in on_client_draw (glsink=, > buf= out>, data=0x626d40 ) at video.c:619 > > > Full backtrace at:http://pastebin.com/RZqmUkMY > > Using vdpau driver on radeon and: > > libX11 1.6.2 > libxcb 1.11 or 1.10 > mesa 11.0 > > > thank you for any help, > > - Vasilis > > > ___ > Libva mailing list > li...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libva > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix warning about unused width variable.
On Tue, Feb 16, 2016 at 6:23 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> We don't use width outside the debug clause here.
>
Thanks
> ---
> src/vulkan/gen_pack_header.py | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/vulkan/gen_pack_header.py b/src/vulkan/gen_pack_header.py
> index 3cabb58..75c4f26 100755
> --- a/src/vulkan/gen_pack_header.py
> +++ b/src/vulkan/gen_pack_header.py
> @@ -62,11 +62,10 @@ __gen_mbo(uint32_t start, uint32_t end)
> static inline uint64_t
> __gen_uint(uint64_t v, uint32_t start, uint32_t end)
> {
> - const int width = end - start + 1;
> -
> __gen_validate_value(v);
>
> #if DEBUG
> + const int width = end - start + 1;
> if (width < 64) {
>const uint64_t max = (1ull << width) - 1;
>assert(v <= max);
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: set correct error code if swapbuffers fails
On 19 February 2016 at 05:40, Tapani Pälli wrote: > Pinging Emil with this one .. > Should have mentioned it beforehand - I pushed it yesterday. Hopefully others won't object :-) Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] egl: support EGL_LARGEST_PBUFFER in eglCreatePbufferSurface(...)
On 19 February 2016 at 05:34, Tapani Pälli wrote: > > On 02/18/2016 08:19 PM, Emil Velikov wrote: >> >> Hi guys, >> >> On 15 February 2016 at 10:54, Tapani Pälli wrote: >>> >>> From: Daniel Czarnowski >>> >>> Patch provides a 'sane default' for a set pbuffer surface size when >> >> Perhaps too cheeky of a question but "who is to determine these 'sane >> defaults'" ? > > > I agree this is not ideal but it's a lot better than complete failure? The > default set in the patch is quite conservative. We could have a driver hook > but I'm not convinced it's worth it in this particular case, again this is > really a case for robustness testing, not for a real life application. > >> If those are OK for one hardware/generation they won't be for another. >> I believe the whole problem boils down to the fact that we don't do >> anything in case of EGL_LARGEST_PBUFFER. Looking at GLX - >> GLX_LARGEST_PBUFFER seems to be in the same boat :-\ >> >> Imho one should honour it while creating the surface. Afaics the spec >> isn't clear if height/width should be ignored when the bool is set (or >> I missed that hunk), so I'm leaning towards "yes". > > > The spec is "if we can't allocate the size what is requested we allocate max > possible size": > > "Use EGL_LARGEST_PBUFFER to get the largest available pbuffer when the > allocation of the pbuffer would otherwise fail." > > So we would try to allocate what is requested but we have a limit that says > it will fail so let's not. IIRC X driver has 32k for max pixmap size but as > they are textures nowadays in practice this limit will be much smaller. > >>> EGL_LARGEST_PBUFFER is used by the client. MIN2 macro is moved to >>> egldefines so that it can be shared. >>> >>> Fixes following Piglit test: >>> egl-create-largest-pbuffer-surface >>> >> With the above said, I'm not sure how much sense it makes to have >> explicit EGL_HEIGHT/WIDTH in the test, alongside EGL_LARGEST_PBUFFER >> in the mentioned test. >> >> In all fairness, fixing this properly might result in a serious >> (series of) patch(es). Which might be a bit too much for stable ? >> Better to cross that road as we reach it :-) > > > I did some investigation and it seems currently there is no way to query > maximum size of a pixmap using xlib or xcb, only way would be to try this in > a loop. Xcb uses uint16_t type so you could determine it from that but with > most (all?) drivers it would fail with max. > Yay fun times ! I wonder if the binary drivers handle this in the same way ... or perhaps they also crash ? Regardless, let's go ahead with this patch, but please add some of the above discussion/justification in the commit message and code. Adding workarounds without comprehensive description will come to bite us sooner or later. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: set correct error code if swapbuffers fails
On 02/19/2016 06:23 PM, Emil Velikov wrote: On 19 February 2016 at 05:40, Tapani Pälli wrote: Pinging Emil with this one .. Should have mentioned it beforehand - I pushed it yesterday. Hopefully others won't object :-) OK thanks, I cannot spot it in the current tree .. in case this can be consider as r-b, I can push it in? // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] egl_dri2: set correct error code if swapbuffers fails
On 19 February 2016 at 16:48, Tapani Pälli wrote: > On 02/19/2016 06:23 PM, Emil Velikov wrote: >> >> On 19 February 2016 at 05:40, Tapani Pälli wrote: >>> >>> Pinging Emil with this one .. >>> >> Should have mentioned it beforehand - I pushed it yesterday. Hopefully >> others won't object :-) > > > OK thanks, I cannot spot it in the current tree .. in case this can be > consider as r-b, I can push it in? > Had the wrong repo named as "origin" :-\ All done now. Thanks for the reminder. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: add ARB_ES3_1_compatibility support
Oddly a bunch of the features it adds are actually from ESSL 3.20. But
the spec is quite clear, oh well.
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/builtin_functions.cpp | 66 +++-
src/compiler/glsl/builtin_variables.cpp | 16
src/compiler/glsl/glcpp/glcpp-parse.y| 3 ++
src/compiler/glsl/glsl_parser_extras.cpp | 3 +-
src/compiler/glsl/glsl_parser_extras.h | 2 +
5 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_functions.cpp
index f488434..6576650 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -214,6 +214,7 @@ static bool
shader_integer_mix(const _mesa_glsl_parse_state *state)
{
return state->is_version(450, 310) ||
+ state->ARB_ES3_1_compatibility_enable ||
(v130(state) && state->EXT_shader_integer_mix_enable);
}
@@ -453,6 +454,13 @@ shader_image_atomic(const _mesa_glsl_parse_state *state)
}
static bool
+shader_image_atomic_float(const _mesa_glsl_parse_state *state)
+{
+ return (state->is_version(450, 320) ||
+ state->ARB_ES3_1_compatibility_enable);
+}
+
+static bool
shader_image_size(const _mesa_glsl_parse_state *state)
{
return state->is_version(430, 310) ||
@@ -585,7 +593,8 @@ private:
IMAGE_FUNCTION_READ_ONLY = (1 << 4),
IMAGE_FUNCTION_WRITE_ONLY = (1 << 5),
IMAGE_FUNCTION_AVAIL_ATOMIC = (1 << 6),
- IMAGE_FUNCTION_MS_ONLY = (1 << 7),
+ IMAGE_FUNCTION_AVAIL_ATOMIC_FLOAT = (1 << 7),
+ IMAGE_FUNCTION_MS_ONLY = (1 << 8),
};
/**
@@ -599,6 +608,15 @@ private:
unsigned flags);
/**
+* Same as add_image_function, but only for float formats
+*/
+ void add_float_image_function(const char *name,
+ const char *intrinsic_name,
+ image_prototype_ctr prototype,
+ unsigned num_arguments,
+ unsigned flags);
+
+ /**
* Create new functions for all known image built-ins and types.
* If \p glsl is \c true, use the GLSL built-in names and emit code
* to call into the actual compiler intrinsic. If \p glsl is
@@ -2933,6 +2951,42 @@ builtin_builder::add_image_function(const char *name,
}
void
+builtin_builder::add_float_image_function(const char *name,
+ const char *intrinsic_name,
+ image_prototype_ctr prototype,
+ unsigned num_arguments,
+ unsigned flags)
+{
+ static const glsl_type *const types[] = {
+ glsl_type::image1D_type,
+ glsl_type::image2D_type,
+ glsl_type::image3D_type,
+ glsl_type::image2DRect_type,
+ glsl_type::imageCube_type,
+ glsl_type::imageBuffer_type,
+ glsl_type::image1DArray_type,
+ glsl_type::image2DArray_type,
+ glsl_type::imageCubeArray_type,
+ glsl_type::image2DMS_type,
+ glsl_type::image2DMSArray_type,
+ };
+
+ ir_function *f = shader->symbols->get_function(name);
+ if (!f) {
+ f = new(mem_ctx) ir_function(name);
+ shader->symbols->add_function(f);
+ }
+
+ for (unsigned i = 0; i < ARRAY_SIZE(types); ++i) {
+ if ((types[i]->sampler_dimensionality == GLSL_SAMPLER_DIM_MS ||
+ !(flags & IMAGE_FUNCTION_MS_ONLY)))
+ f->add_signature(_image(prototype, types[i], intrinsic_name,
+ num_arguments, flags));
+ }
+}
+
+
+void
builtin_builder::add_image_functions(bool glsl)
{
const unsigned flags = (glsl ? IMAGE_FUNCTION_EMIT_STUB : 0);
@@ -2953,6 +3007,9 @@ builtin_builder::add_image_functions(bool glsl)
IMAGE_FUNCTION_WRITE_ONLY));
const unsigned atom_flags = flags | IMAGE_FUNCTION_AVAIL_ATOMIC;
+ const unsigned atom_float_flags = flags |
+ IMAGE_FUNCTION_AVAIL_ATOMIC_FLOAT |
+ IMAGE_FUNCTION_SUPPORTS_FLOAT_DATA_TYPE;
add_image_function(glsl ? "imageAtomicAdd" : "__intrinsic_image_atomic_add",
"__intrinsic_image_atomic_add",
@@ -2983,6 +3040,12 @@ builtin_builder::add_image_functions(bool glsl)
"__intrinsic_image_atomic_exchange",
&builtin_builder::_image_prototype, 1, atom_flags);
+ add_float_image_function((glsl ? "imageAtomicExchange" :
+ "__intrinsic_image_atomic_exchange"),
+"__intrinsic_image_atomic_exchange",
+&builtin_builder::_image_prototype, 1,
+atom_float_flags);
+
add_image_function((glsl ? "imageAtomicCompSwap" :
"__intrinsic_image_atomic_comp_swap"),
"__intrinsic_image_atomic_comp_swap",
@@ -5251,6 +5314,7 @@ builtin_builder::_image_prototyp
[Mesa-dev] [PATCH 2/3] mesa: add ES3_1_compatibility extension enable
Signed-off-by: Ilia Mirkin --- src/mesa/main/extensions_table.h | 1 + src/mesa/main/mtypes.h | 1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h index 3a90bc9..c30ce16 100644 --- a/src/mesa/main/extensions_table.h +++ b/src/mesa/main/extensions_table.h @@ -28,6 +28,7 @@ EXT(APPLE_vertex_array_object , dummy_true EXT(ARB_ES2_compatibility , ARB_ES2_compatibility , GLL, GLC, x , x , 2009) EXT(ARB_ES3_compatibility , ARB_ES3_compatibility , GLL, GLC, x , x , 2012) +EXT(ARB_ES3_1_compatibility , ARB_ES3_1_compatibility , x , GLC, x , x , 2014) EXT(ARB_arrays_of_arrays, ARB_arrays_of_arrays , GLL, GLC, x , x , 2012) EXT(ARB_base_instance , ARB_base_instance , GLL, GLC, x , x , 2011) EXT(ARB_blend_func_extended , ARB_blend_func_extended , GLL, GLC, x , x , 2009) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 844811c..50de6c4 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -3772,6 +3772,7 @@ struct gl_extensions GLboolean ANGLE_texture_compression_dxt; GLboolean ARB_ES2_compatibility; GLboolean ARB_ES3_compatibility; + GLboolean ARB_ES3_1_compatibility; GLboolean ARB_arrays_of_arrays; GLboolean ARB_base_instance; GLboolean ARB_blend_func_extended; -- 2.4.10 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: add gl_MaxSamples, new in GL 4.5 / GL ES 3.2
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/builtin_variables.cpp | 3 +++
src/compiler/glsl/glsl_parser_extras.cpp | 3 +++
src/compiler/glsl/glsl_parser_extras.h | 3 +++
3 files changed, 9 insertions(+)
diff --git a/src/compiler/glsl/builtin_variables.cpp
b/src/compiler/glsl/builtin_variables.cpp
index d20fc4a..8d41213 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -867,6 +867,9 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxTessControlUniformComponents",
state->Const.MaxTessControlUniformComponents);
add_const("gl_MaxTessEvaluationUniformComponents",
state->Const.MaxTessEvaluationUniformComponents);
}
+
+ if (state->is_version(450, 320))
+ add_const("gl_MaxSamples", state->Const.MaxSamples);
}
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index fbac836..c05668f 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -175,6 +175,9 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct
gl_context *_ctx,
this->Const.MaxTessControlUniformComponents =
ctx->Const.Program[MESA_SHADER_TESS_CTRL].MaxUniformComponents;
this->Const.MaxTessEvaluationUniformComponents =
ctx->Const.Program[MESA_SHADER_TESS_EVAL].MaxUniformComponents;
+ /* GL 4.5 / OES_sample_variables */
+ this->Const.MaxSamples = ctx->Const.MaxSamples;
+
this->current_function = NULL;
this->toplevel_ir = NULL;
this->found_return = false;
diff --git a/src/compiler/glsl/glsl_parser_extras.h
b/src/compiler/glsl/glsl_parser_extras.h
index 5f6ca6a..faf5134 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -457,6 +457,9 @@ struct _mesa_glsl_parse_state {
unsigned MaxTessControlTotalOutputComponents;
unsigned MaxTessControlUniformComponents;
unsigned MaxTessEvaluationUniformComponents;
+
+ /* GL 4.5 / OES_sample_variables */
+ unsigned MaxSamples;
} Const;
/**
--
2.4.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50: do not advertise about compute shaders
Reviewed-by: Ilia Mirkin On Fri, Feb 19, 2016 at 2:25 PM, Samuel Pitoiset wrote: > Compute shaders are totally unsupported. This avoids Clover to > report that OpenCL is supported on Tesla because it's a lie. > > Signed-off-by: Samuel Pitoiset > --- > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c > b/src/gallium/drivers/nouveau/nv50/nv50_screen.c > index 06b7bf9..8d11dd7 100644 > --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c > @@ -264,8 +264,8 @@ nv50_screen_get_shader_param(struct pipe_screen *pscreen, > unsigned shader, > case PIPE_SHADER_VERTEX: > case PIPE_SHADER_GEOMETRY: > case PIPE_SHADER_FRAGMENT: > - case PIPE_SHADER_COMPUTE: >break; > + case PIPE_SHADER_COMPUTE: > default: >return 0; > } > -- > 2.6.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: force depth mode to GL_RED for sized depth/stencil formats
On Wed, Feb 17, 2016 at 3:26 PM, Kenneth Graunke wrote: > On Wednesday, February 17, 2016 8:21:32 AM PST Ilia Mirkin wrote: >> See commit 9db2098d for the i965 version of this. >> >> This fixes depth in a bunch of dEQP EXT_texture_border_clamp tests. And >> probably other ones as well. >> >> Signed-off-by: Ilia Mirkin >> Cc: Ian Romanick >> Cc: mesa-sta...@lists.freedesktop.org >> --- >> >> This replaces my patch "mesa: default DepthMode to GL_RED on ES 3.0" which >> tried to do it at the global level. Unfortunately this needs to only apply >> to sized format, so it can't be done until the texture is complete. >> >> src/mesa/state_tracker/st_atom_texture.c | 34 ++ > +- >> 1 file changed, 25 insertions(+), 9 deletions(-) > > This looks good to me. For what it's worth, > > Reviewed-by: Kenneth Graunke Thanks. There not having been other comments on this patch, I'm going to push this later today. A later change can try to clean this up so that the driver doesn't have to care about this annoyance by reverting both this and the i965-specific handling... I think Ian had some ideas, but it all seems very sadly intertwined. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50: do not advertise about compute shaders
Compute shaders are totally unsupported. This avoids Clover to report that OpenCL is supported on Tesla because it's a lie. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 06b7bf9..8d11dd7 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -264,8 +264,8 @@ nv50_screen_get_shader_param(struct pipe_screen *pscreen, unsigned shader, case PIPE_SHADER_VERTEX: case PIPE_SHADER_GEOMETRY: case PIPE_SHADER_FRAGMENT: - case PIPE_SHADER_COMPUTE: break; + case PIPE_SHADER_COMPUTE: default: return 0; } -- 2.6.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50: do not advertise about compute shaders
Reviewed-by: Pierre Moreau On 08:25 PM - Feb 19 2016, Samuel Pitoiset wrote: > Compute shaders are totally unsupported. This avoids Clover to > report that OpenCL is supported on Tesla because it's a lie. > > Signed-off-by: Samuel Pitoiset > --- > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c > b/src/gallium/drivers/nouveau/nv50/nv50_screen.c > index 06b7bf9..8d11dd7 100644 > --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c > @@ -264,8 +264,8 @@ nv50_screen_get_shader_param(struct pipe_screen *pscreen, > unsigned shader, > case PIPE_SHADER_VERTEX: > case PIPE_SHADER_GEOMETRY: > case PIPE_SHADER_FRAGMENT: > - case PIPE_SHADER_COMPUTE: >break; > + case PIPE_SHADER_COMPUTE: > default: >return 0; > } > -- > 2.6.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] OpenSWR driver addition
On 18/02/16 23:46, Brian Paul wrote: On 02/17/2016 06:53 PM, Tim Rowley wrote: This patch series adds the OpenSWR driver, a new software rasterizer project by Intel. The goal of this project is to create a high performance, highly scalable renderer targeted towards visualization workloads. For geometry heavy workloads we see a considerable speedup over llvmpipe, which is to be expected as the geometry frontend of llvmpipe is single threaded. Our rasterizer is x86 specific and requires AVX or AVX2. The driver fits into the gallium framework, and reuses gallivm for doing the TGSI to vectorized llvm-IR conversion of the kernel of the shaders. A longer description of the project can be found in the initial introduction to the mesa-dev mailing list. Since this was written we've worked on more conformance, features, rebasing to Mesa master, cleaning up the build system, and supporting llvm 3.6 through 3.8. https://lists.freedesktop.org/archives/mesa-dev/2015-October/097816.html Nice to see this arriving. I agree with Roland's comments. Also, I'd recommend writing some documentation (docs/swr.html?) that gives a description of the driver, how to use it, etc. -Brian I went through the series, and didn't spot anything that hasn't been covered by Brian/Roland. Series is Acked-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Libva] vaPutSurface never returns
Hi, On Fri, Feb 19, 2016 at 5:04 PM, Emil Velikov wrote: > Was about to mention the same thing as Christian :-) > > Vasilis, is there any reason why you're using vdpau + the vdpau to > vaapi adapter, as opposed to the gallium vaapi target directly ? > Someone on #radeon mentioned to not use vaapi mesa driver on radeon. Is this driver supposed to work on amd GPUs? I have tried using vaapi driver from oibaf/graphics-drivers, which has mesa 11.2~git1602191930.e6f1a4~gd~t vainfo output: libva info: VA-API version 0.38.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.38 (libva 1.6.2) vainfo: Driver version: mesa gallium vaapi vainfo: Supported profile and entrypoints Using this driver, my app gets an Xerror and also segfaults using this driver (although the segfault appears to happen in a font rendering library, not in vaapi itself). X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 155 (DRI2) Minor opcode of failed request: 8 (DRI2SwapBuffers) Resource id in failed request: 0x387 Serial number of failed request: 32 Current serial number in output stream: 34 Program received signal SIGSEGV, Segmentation fault. 0x7049ab2b in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 Program received signal SIGSEGV, Segmentation fault. 0x7049ab2b in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (gdb) bt #0 0x7049ab2b in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 #1 0x704a1c24 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6 #2 0x76dddc87 in FTGlyphContainer::Render(unsigned int, unsigned int, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2 #3 0x76de395e in FTFontImpl::Render(char const*, int, FTPoint, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2 #4 0x76de7e67 in FTTextureFontImpl::Render(char const*, int, FTPoint, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2 #5 0x76de21c3 in FTFont::Render(char const*, int, FTPoint, FTPoint, int) () from /usr/lib/x86_64-linux-gnu/libftgl.so.2 #6 0x76de4868 in ftglRenderFont () from /usr/lib/x86_64-linux-gnu/libftgl.so.2 #7 0x0040e3de in font_write (L=0x8d2550) at font.c:68 Full backtrace: http://pastebin.com/VbXgdDT0 This problem does not happen with vdpau (although vdpau encounters the vdpau_putSurface problem I originally mentioned, and outputs black frames after a while) Regarding the vdpau issue, I don't see any dmesg messages about GPU lockup. Desktop and GPU keeps working fine. Also fence debug info is: sudo cat /sys/kernel/debug/dri/0/radeon_fence_info --- ring 0 --- Last signaled fence 0x00088cf4 Last emitted0x00088cf4 Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x00397e7e Last sync to ring 4 0x Last sync to ring 5 0x2a97 --- ring 1 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 2 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 3 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 3 --- Last signaled fence 0x00397e82 Last emitted0x00397e82 Last sync to ring 0 0x00088cf2 Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 4 0x Last sync to ring 5 0x2a97 --- ring 4 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 5 0x --- ring 5 --- Last signaled fence 0x2aa0 Last emitted0x2aa0 Last sync to ring 0 0x00088869 Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x00397a54 Last sync to ring 4 0x thank you, - Vasilis > > Mesa 11.0.x has the said target (toggle with --enable-va at configure > time), although there has been quite a few fixes from Christian, > Julien and others since then. As an alternative I'd suggest mesa > 11.1.x series (or mesa 11.2.0-rc1 coming out later on today). > > -Emil > > On 19 February 2016 at 09:53, Christian König > wrote: > > Questions for VDPAU should pr
Re: [Mesa-dev] [PATCH 22/22] meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve blit
Am 19.02.2016 um 11:57 schrieb Iago Toral:
> On Thu, 2016-02-18 at 16:13 -0800, Ian Romanick wrote:
>> On 02/18/2016 01:47 PM, Ian Romanick wrote:
>>> On 02/18/2016 08:44 AM, Neil Roberts wrote:
I made a pathological test case (attached) which repeatedly renders into
an MSAA FBO and then blits it to the screen and measures the framerate.
It checks it with a range of different sample counts. The rendering is
done either by rendering two triangles to fill the framebuffer or by
calling glClear.
The percentage increase in framerate after applying the patch is like
this:
With triangles to fill buffer:
16 62,27%
8 48,59%
4 27,72%
2 5,34%
0 0,58%
With glClear:
16 -5,20%
8 -7,08%
4 -2,45%
2 -20,76%
0 3,71%
>>>
>>> I find this result interesting. In the samples=0 case, the before and
>>> after shaders should be identical. I dug into this a bit, and I think
>>> the problem is the previous patch. Using do { ... } while (false) in
>>> the macro makes the compiler generate some really, really bad code.
>>> Just deleting those two lines makes a huge difference.
>>>
>>> With do { ... } while (false):
>>>
>>> SIMD8 shader: 228 instructions. 4 loops. 1554 cycles. 0:0 spills:fills.
>>> Promoted 0 constants. Compacted 3648 to 2192 bytes (40%)
>>>
>>> Without:
>>>
>>> SIMD8 shader: 159 instructions. 0 loops. 380 cycles. 0:0 spills:fills.
>>> Promoted 0 constants. Compacted 2544 to 1600 bytes (37%)
>>> SIMD16 shader: 159 instructions. 0 loops. 898 cycles. 0:0 spills:fills.
>>> Promoted 0 constants. Compacted 2544 to 1600 bytes (37%)
>>>
>>> This is for samples=16 and sampler2DMS. The cycle counts are bogus
>>> because the 4 loops have their cycle counts statically multiplied by
>>> 10... even though the loop will only execute once.
>>>
>>> So... I'll try some more experiments. I also wonder about changing the
>>> SAMPLES > 1 to SAMPLES > 2.
>>
>> This is weird, and I'm not sure what to make of it. I ran your test at
>> a bunch of commits on my branch. Getting rid of gl_FragColor was the
>> big win. The GL_EXT_shader_samples_identical patch is still the big
>> loss. I'm assuming that causes enough register pressure over the
>> previous commit to lose SIMD16. The following patch just removes the
>> "do {" and "} while (false)". That gets back some of the losses,
>> but not all of it.
>
> I don't know much about this, but using shader_samples_identical should
> only give a benefit if we actually get identical samples, otherwise it
> means more work, right? I noticed that the test renders a quad with
> random colors for each vertex that will be interpolated across the
> region, so could it be that we are hitting few cases of identical
> samples? Shouldn't the results be expected to be better if we rendered a
> flat color instead?
Unless you run that shader drawing random colors at per-sample frequency
(using per-sample interpolation), you still get identical samples (for
each pixel). Except at the edges of the quad.
(I didn't actually look at the test...)
Roland
>
>> The raw per-commit data is below.
>>
>> 5c7f974 Android: disable unused-parameter warning
>> With triangles to fill buffer:
>>
>> 8,419.603882
>> 4,633.834045
>> 2,595.628113
>> 0,795.798157
>>
>> With glClear:
>>
>> 8,450.937958
>> 4,594.000610
>> 2,641.354553
>> 0,767.400818
>>
>> 89b8c0a meta/blit: Replace the gl_FragColor write
>> With triangles to fill buffer:
>>
>> 8,597.943054
>> 4,803.083862
>> 2,942.862549
>> 0,1129.432983
>>
>> With glClear:
>>
>> 8,643.500671
>> 4,980.392151
>> 2,982.704407
>> 0,1116.569946
>>
>> 7025d43 meta/blit: Don't dynamically select the MSAA "merge" function
>> With triangles to fill buffer:
>>
>> 8,599.412598
>> 4,954.745056
>> 2,933.184021
>> 0,1129.305420
>>
>> With glClear:
>>
>> 8,582.106079
>> 4,965.810303
>> 2,975.419434
>> 0,1169.180420
>>
>> b895a4d meta/blit: Use a single, master shader template for MSAA-SS blits
>> With triangles to fill buffer:
>>
>> 8,591.786011
>> 4,932.835815
>> 2,910.498047
>> 0,1072.501099
>>
>> With glClear:
>>
>> 8,623.441406
>> 4,952.562378
>> 2,941.442261
>> 0,1081.314819
>>
>> 197e4be meta/blit: Use GL_EXT_shader_samples_identical in MSAA-SS resolve
>> blit
>> With triangles to fill buffer:
>>
>> 8,559.252869
>> 4,795.355103
>> 2,781.494202
>> 0,941.619568
>>
>> With glClear:
>>
>> 8,577.400513
>> 4,806.321533
>> 2,811.030029
>> 0,957.579224
>>
>> ec01613 fix loop nonsense derp
>> With triangles to fill buffer:
>>
>> 8,559.221558
>> 4,788.767944
>> 2,786.287170
>> 0,1078.632324
>>
>> With glClear:
>>
>> 8,575.771545
>> 4,956.205750
>> 2,813.206482
>> 0,.111084
>>
>>> I will probably also make a patch to fix the damage done by the do { ...
>>> } while (false). That's just comedy.
>>>
It seems like a pretty convincing win for the triangle case but the
clear case make
[Mesa-dev] [Bug 94195] [llvmpipe] Does not build with LLVM 3.7.x on Windows
https://bugs.freedesktop.org/show_bug.cgi?id=94195 Jose Fonseca changed: What|Removed |Added CC||emil.l.veli...@gmail.com, ||jfons...@vmware.com --- Comment #1 from Jose Fonseca --- This has been fixed in https://cgit.freedesktop.org/mesa/mesa/commit/?id=a5256012ef8ea31bc8025fc72193a9772372c9a1 We could crossport it to the 11.1 branch, but I'm not sure if there will be another patch release. There is a 11.2 coming soon. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add GL_OES_gpu_shader5 and GL_EXT_gpu_shader5 support
The two extensions are identical, and are largely taking bits of already
existing desktop functionality. We continue to do a poor job of
supporting the 'precise' keyword, just like we do on desktop.
This passes the relevant dEQP tests that I could find.
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt | 2 +-
src/compiler/glsl/ast_array_index.cpp| 20 +--
src/compiler/glsl/builtin_functions.cpp | 99 +++-
src/compiler/glsl/glcpp/glcpp-parse.y| 4 ++
src/compiler/glsl/glsl_lexer.ll | 2 +-
src/compiler/glsl/glsl_parser_extras.cpp | 2 +
src/compiler/glsl/glsl_parser_extras.h | 4 ++
src/mesa/main/extensions_table.h | 2 +
8 files changed, 88 insertions(+), 47 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 2e528d4..e7d40de 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -245,7 +245,7 @@ GLES3.2, GLSL ES 3.2
GL_OES_draw_buffers_indexed not started
GL_OES_draw_elements_base_vertex DONE (all drivers)
GL_OES_geometry_shader started (Marta)
- GL_OES_gpu_shader5 not started (based on
parts of GL_ARB_gpu_shader5, which is done for some drivers)
+ GL_OES_gpu_shader5 DONE (all drivers that
support GL_ARB_gpu_shader5)
GL_OES_primitive_bounding boxnot started
GL_OES_sample_shadingDONE (nvc0, r600,
radeonsi)
GL_OES_sample_variables DONE (nvc0, r600,
radeonsi)
diff --git a/src/compiler/glsl/ast_array_index.cpp
b/src/compiler/glsl/ast_array_index.cpp
index f5baeb9..af5e89e 100644
--- a/src/compiler/glsl/ast_array_index.cpp
+++ b/src/compiler/glsl/ast_array_index.cpp
@@ -236,13 +236,22 @@ _mesa_ast_array_index_to_hir(void *mem_ctx,
_mesa_glsl_error(&loc, state, "unsized array index must be
constant");
}
} else if (array->type->without_array()->is_interface()
- && (array->variable_referenced()->data.mode == ir_var_uniform
||
- array->variable_referenced()->data.mode ==
ir_var_shader_storage)
- && !state->is_version(400, 0) &&
!state->ARB_gpu_shader5_enable) {
+ && ((array->variable_referenced()->data.mode == ir_var_uniform
+ && !state->is_version(400, 320)
+ && !state->ARB_gpu_shader5_enable
+ && !state->EXT_gpu_shader5_enable
+ && !state->OES_gpu_shader5_enable) ||
+ (array->variable_referenced()->data.mode ==
ir_var_shader_storage
+ && !state->is_version(400, 0)
+ && !state->ARB_gpu_shader5_enable))) {
/* Page 50 in section 4.3.9 of the OpenGL ES 3.10 spec says:
*
* "All indices used to index a uniform or shader storage block
* array must be constant integral expressions."
+ *
+ * But OES_gpu_shader5 (and ESSL 3.20) relax this to allow indexing
+ * on uniform blocks but not shader storage blocks.
+ *
*/
_mesa_glsl_error(&loc, state, "%s block array index must be constant",
array->variable_referenced()->data.mode
@@ -279,7 +288,10 @@ _mesa_ast_array_index_to_hir(void *mem_ctx,
* dynamically uniform expression is undefined.
*/
if (array->type->without_array()->is_sampler()) {
- if (!state->is_version(400, 0) && !state->ARB_gpu_shader5_enable) {
+ if (!state->is_version(400, 320) &&
+ !state->ARB_gpu_shader5_enable &&
+ !state->EXT_gpu_shader5_enable &&
+ !state->OES_gpu_shader5_enable) {
if (state->is_version(130, 300))
_mesa_glsl_error(&loc, state,
"sampler arrays indexed with non-constant "
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_functions.cpp
index 6576650..b862da0 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -240,6 +240,21 @@ gpu_shader5(const _mesa_glsl_parse_state *state)
}
static bool
+gpu_shader5_es(const _mesa_glsl_parse_state *state)
+{
+ return state->is_version(400, 320) ||
+ state->ARB_gpu_shader5_enable ||
+ state->EXT_gpu_shader5_enable ||
+ state->OES_gpu_shader5_enable;
+}
+
+static bool
+es31_not_gs5(const _mesa_glsl_parse_state *state)
+{
+ return state->is_version(0, 310) && !gpu_shader5_es(state);
+}
+
+static bool
gpu_shader5_or_es31(const _mesa_glsl_parse_state *state)
{
return state->is_version(400, 310) || state->ARB_gpu_shader5_enable;
@@ -361,8 +376,10 @@ texture_gather_or_es31(const _mesa_glsl_parse_state *state)
static bool
texture_gather_only_or_es31(const _mesa_glsl_parse_state *state)
{
- ret
[Mesa-dev] [Bug 94040] clGetPlatformIDs causes futex race condition
https://bugs.freedesktop.org/show_bug.cgi?id=94040 --- Comment #10 from b...@bob131.so --- Sorry, I completely forgot you asked for those. Enjoy ;) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94040] clGetPlatformIDs causes futex race condition
https://bugs.freedesktop.org/show_bug.cgi?id=94040 --- Comment #9 from b...@bob131.so --- Created attachment 121851 --> https://bugs.freedesktop.org/attachment.cgi?id=121851&action=edit Complete Blender backtraces -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 94040] clGetPlatformIDs causes futex race condition
https://bugs.freedesktop.org/show_bug.cgi?id=94040 b...@bob131.so changed: What|Removed |Added Attachment #121851|0 |1 is obsolete|| --- Comment #11 from b...@bob131.so --- Created attachment 121852 --> https://bugs.freedesktop.org/attachment.cgi?id=121852&action=edit Complete Blender backtraces with ocl-icd debuginfos -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/mesa: add GL_ARB_shader_atomic_counter_ops support
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 4 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 60 +++---
2 files changed, 57 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 94696ce..21e108d 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -368,8 +368,10 @@ void st_init_limits(struct pipe_screen *screen,
c->Program[MESA_SHADER_FRAGMENT].MaxAtomicBuffers;
assert(c->MaxCombinedAtomicBuffers <= MAX_COMBINED_ATOMIC_BUFFERS);
- if (c->MaxCombinedAtomicBuffers > 0)
+ if (c->MaxCombinedAtomicBuffers > 0) {
extensions->ARB_shader_atomic_counters = GL_TRUE;
+ extensions->ARB_shader_atomic_counter_ops = GL_TRUE;
+ }
c->MaxCombinedShaderOutputResources = c->MaxDrawBuffers;
c->ShaderStorageBufferOffsetAlignment =
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 943582d..fe6d58b 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3163,8 +3163,8 @@ void
glsl_to_tgsi_visitor::visit_atomic_counter_intrinsic(ir_call *ir)
{
const char *callee = ir->callee->function_name();
- ir_dereference *deref = static_cast(
- ir->actual_parameters.get_head());
+ exec_node *param = ir->actual_parameters.get_head();
+ ir_dereference *deref = static_cast(param);
ir_variable *location = deref->variable_referenced();
st_src_reg buffer(
@@ -3193,17 +3193,56 @@
glsl_to_tgsi_visitor::visit_atomic_counter_intrinsic(ir_call *ir)
if (!strcmp("__intrinsic_atomic_read", callee)) {
inst = emit_asm(ir, TGSI_OPCODE_LOAD, dst, offset);
- inst->buffer = buffer;
} else if (!strcmp("__intrinsic_atomic_increment", callee)) {
inst = emit_asm(ir, TGSI_OPCODE_ATOMUADD, dst, offset,
st_src_reg_for_int(1));
- inst->buffer = buffer;
} else if (!strcmp("__intrinsic_atomic_predecrement", callee)) {
inst = emit_asm(ir, TGSI_OPCODE_ATOMUADD, dst, offset,
st_src_reg_for_int(-1));
- inst->buffer = buffer;
emit_asm(ir, TGSI_OPCODE_ADD, dst, this->result, st_src_reg_for_int(-1));
+ } else {
+ param = param->get_next();
+ ir_rvalue *val = ((ir_instruction *)param)->as_rvalue();
+ val->accept(this);
+
+ st_src_reg data = this->result, data2 = undef_src;
+ unsigned opcode;
+ if (!strcmp("__intrinsic_atomic_add", callee))
+ opcode = TGSI_OPCODE_ATOMUADD;
+ else if (!strcmp("__intrinsic_atomic_min", callee))
+ opcode = TGSI_OPCODE_ATOMIMIN;
+ else if (!strcmp("__intrinsic_atomic_max", callee))
+ opcode = TGSI_OPCODE_ATOMIMAX;
+ else if (!strcmp("__intrinsic_atomic_and", callee))
+ opcode = TGSI_OPCODE_ATOMAND;
+ else if (!strcmp("__intrinsic_atomic_or", callee))
+ opcode = TGSI_OPCODE_ATOMOR;
+ else if (!strcmp("__intrinsic_atomic_xor", callee))
+ opcode = TGSI_OPCODE_ATOMXOR;
+ else if (!strcmp("__intrinsic_atomic_exchange", callee))
+ opcode = TGSI_OPCODE_ATOMXCHG;
+ else if (!strcmp("__intrinsic_atomic_comp_swap", callee)) {
+ opcode = TGSI_OPCODE_ATOMCAS;
+ param = param->get_next();
+ val = ((ir_instruction *)param)->as_rvalue();
+ val->accept(this);
+ data2 = this->result;
+ } else if (!strcmp("__intrinsic_atomic_sub", callee)) {
+ opcode = TGSI_OPCODE_ATOMUADD;
+ st_src_reg res = get_temp(glsl_type::uvec4_type);
+ st_dst_reg dstres = st_dst_reg(res);
+ dstres.writemask = dst.writemask;
+ emit_asm(ir, TGSI_OPCODE_INEG, dstres, data);
+ data = res;
+ } else {
+ assert(!"Unexpected intrinsic");
+ return;
+ }
+
+ inst = emit_asm(ir, opcode, dst, offset, data, data2);
}
+
+ inst->buffer = buffer;
}
void
@@ -3596,7 +3635,16 @@ glsl_to_tgsi_visitor::visit(ir_call *ir)
/* Filter out intrinsics */
if (!strcmp("__intrinsic_atomic_read", callee) ||
!strcmp("__intrinsic_atomic_increment", callee) ||
- !strcmp("__intrinsic_atomic_predecrement", callee)) {
+ !strcmp("__intrinsic_atomic_predecrement", callee) ||
+ !strcmp("__intrinsic_atomic_add", callee) ||
+ !strcmp("__intrinsic_atomic_sub", callee) ||
+ !strcmp("__intrinsic_atomic_min", callee) ||
+ !strcmp("__intrinsic_atomic_max", callee) ||
+ !strcmp("__intrinsic_atomic_and", callee) ||
+ !strcmp("__intrinsic_atomic_or", callee) ||
+ !strcmp("__intrinsic_atomic_xor", callee) ||
+ !strcmp("__intrinsic_atomic_exchange", callee) ||
+ !strcmp("__intrinsic_atomic_comp_swap", callee)) {
visit_atomic_counter_intrinsic(ir);
return;
}
--
2.4.10
___
mesa-dev mailing l
[Mesa-dev] [PATCH 1/2] mesa: add GL_ARB_shader_atomic_counter_ops support
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/builtin_functions.cpp | 110 +++
src/compiler/glsl/glcpp/glcpp-parse.y| 3 +
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_parser_extras.h | 2 +
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
6 files changed, 118 insertions(+)
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_functions.cpp
index b862da0..d4dc271 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -439,6 +439,12 @@ shader_atomic_counters(const _mesa_glsl_parse_state *state)
}
static bool
+shader_atomic_counter_ops(const _mesa_glsl_parse_state *state)
+{
+ return state->ARB_shader_atomic_counter_ops_enable;
+}
+
+static bool
shader_clock(const _mesa_glsl_parse_state *state)
{
return state->ARB_shader_clock_enable;
@@ -819,8 +825,14 @@ private:
B1(interpolateAtSample)
ir_function_signature
*_atomic_counter_intrinsic(builtin_available_predicate avail);
+ ir_function_signature
*_atomic_counter_intrinsic1(builtin_available_predicate avail);
+ ir_function_signature
*_atomic_counter_intrinsic2(builtin_available_predicate avail);
ir_function_signature *_atomic_counter_op(const char *intrinsic,
builtin_available_predicate
avail);
+ ir_function_signature *_atomic_counter_op1(const char *intrinsic,
+ builtin_available_predicate
avail);
+ ir_function_signature *_atomic_counter_op2(const char *intrinsic,
+ builtin_available_predicate
avail);
ir_function_signature *_atomic_intrinsic2(builtin_available_predicate avail,
const glsl_type *type);
@@ -983,48 +995,59 @@ builtin_builder::create_intrinsics()
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
+NULL);
+ add_function("__intrinsic_atomic_sub",
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_min",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_max",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_and",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_or",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_xor",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_exchange",
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic2(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic1(shader_atomic_counter_ops),
NULL);
add_function("__intrinsic_atomic_comp_swap",
_atomic_intrinsic3(buffer_atomics_supported,
glsl_type::uint_type),
_atomic_intrinsic3(buffer_atomics_supported,
glsl_type::int_type),
+_atomic_counter_intrinsic2(shader_at
Re: [Mesa-dev] [PATCH 16/25] radeonsi: add PS prolog
On 19.02.2016 06:39, Marek Olšák wrote: On Tue, Feb 16, 2016 at 5:31 PM, Nicolai Hähnle wrote: So, patches 12-16 also look good to me except for the comments I've sent on 12-14. Does this mean I can add your Rb on those? Yes indeed. Nicolai Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
