Re: [Mesa-dev] [PATCH 5/5] softpipe: add support for vertex streams
As long as there's no regressions in llvmpipe, looks great to me. Am 29.03.19 um 06:48 schrieb Dave Airlie: > This enables the ARB_gpu_shader5 vertex streams on softpipe. > > Signed-off-by: Dave Airlie > --- > src/gallium/drivers/softpipe/sp_screen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/softpipe/sp_screen.c > b/src/gallium/drivers/softpipe/sp_screen.c > index 438557e146a..d2c31b8935d 100644 > --- a/src/gallium/drivers/softpipe/sp_screen.c > +++ b/src/gallium/drivers/softpipe/sp_screen.c > @@ -122,7 +122,7 @@ softpipe_get_param(struct pipe_screen *screen, enum > pipe_cap param) > case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS: >return 1024; > case PIPE_CAP_MAX_VERTEX_STREAMS: > - return 1; > + return PIPE_MAX_VERTEX_STREAMS; I think technically you should make this dependent on !sp_screen->use_llvm (unless you want to fix the llvm paths :-)). For the series: Reviewed-by: Roland Scheidegger > case PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE: >return 2048; > case PIPE_CAP_PRIMITIVE_RESTART: > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
On 3/29/19 1:54 PM, Brian Paul wrote:
> On 03/29/2019 12:58 PM, Ian Romanick wrote:
>> On 3/29/19 9:57 AM, Brian Paul wrote:
>>> __builtin_types_compatible_p() is GCC-specific and breaks the
>>> MSVC build.
>>>
>>> This intrinsic has been in u_vector_foreach() for a long time, but
>>> that macro has only recently been used in code
>>> (nir/nir_opt_comparison_pre.c) that's built with MSVC.
>>>
>>> Fixes: 2cf59861a ("nir: Add partial redundancy elimination for
>>> compares")
>>> ---
>>> src/util/u_vector.h | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/src/util/u_vector.h b/src/util/u_vector.h
>>> index cd8a95d..6807748 100644
>>> --- a/src/util/u_vector.h
>>> +++ b/src/util/u_vector.h
>>> @@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
>>> free(queue->data);
>>> }
>>> +#ifndef __GNUC__
>>> +#define __builtin_types_compatible_p(x) 1
>>> +#endif
>>> +
>>> #define u_vector_foreach(elem,
>>> queue) \
>>> STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue),
>>> struct u_vector *)); \
>>
>> The way this is GCC builtin is used here, this should be fine. However,
>> in case it's begin used elsewhere, we should #undef it afterwards.
>
> That doesn't seem to work. When u_vector_foreach() is instantiated
> later, __builtin_types_compatible_p is undefined and we error out.
Ah, right. u_vector_foreach is itself a macro, so the
__builtin_type_compatible_p macro isn't evaluated until u_vector_foreach
is evaluated. By that point __builtin_type_compatible_p would be undefined.
This should be fine as-is, then. Hopefully this won't result in a
weird, hard to debug compile failure later on.
Reviewed-by: Ian Romanick
> -Brian
>
>
> I'd
>> hate to mask some other kind of bug that may be introduced later.
>>
>>> for (uint32_t __u_vector_offset =
>>> (queue)->tail; \
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
On 03/29/2019 12:58 PM, Ian Romanick wrote:
On 3/29/19 9:57 AM, Brian Paul wrote:
__builtin_types_compatible_p() is GCC-specific and breaks the
MSVC build.
This intrinsic has been in u_vector_foreach() for a long time, but
that macro has only recently been used in code
(nir/nir_opt_comparison_pre.c) that's built with MSVC.
Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares")
---
src/util/u_vector.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/util/u_vector.h b/src/util/u_vector.h
index cd8a95d..6807748 100644
--- a/src/util/u_vector.h
+++ b/src/util/u_vector.h
@@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
free(queue->data);
}
+#ifndef __GNUC__
+#define __builtin_types_compatible_p(x) 1
+#endif
+
#define u_vector_foreach(elem, queue) \
STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct
u_vector *)); \
The way this is GCC builtin is used here, this should be fine. However,
in case it's begin used elsewhere, we should #undef it afterwards.
That doesn't seem to work. When u_vector_foreach() is instantiated
later, __builtin_types_compatible_p is undefined and we error out.
-Brian
I'd
hate to mask some other kind of bug that may be introduced later.
for (uint32_t __u_vector_offset = (queue)->tail;
\
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109646] New video compositor compute shader render glitches mpv
https://bugs.freedesktop.org/show_bug.cgi?id=109646 bmil...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from bmil...@gmail.com --- (In reply to jam...@amd.com from comment #9) > Hi Bruno, > > Please help verify the two new patches to address the issues that you found > during Chromium hardware acceleration enabled playback. > > Thanks! > James Zhu Done, those two issues are fixed with the patch. I'll close this as resolved and open another ticket if I find more issues but the two main va-api applications I use are working fine (mpv and chrome/ium). -- 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 109646] New video compositor compute shader render glitches mpv
https://bugs.freedesktop.org/show_bug.cgi?id=109646 --- Comment #9 from jam...@amd.com --- Hi Bruno, Please help verify the two new patches to address the issues that you found during Chromium hardware acceleration enabled playback. Thanks! James Zhu -- 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 109646] New video compositor compute shader render glitches mpv
https://bugs.freedesktop.org/show_bug.cgi?id=109646 --- Comment #8 from jam...@amd.com --- Created attachment 143810 --> https://bugs.freedesktop.org/attachment.cgi?id=143810=edit patch for blank issue fix -- 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 109646] New video compositor compute shader render glitches mpv
https://bugs.freedesktop.org/show_bug.cgi?id=109646 jam...@amd.com changed: What|Removed |Added CC||jam...@amd.com --- Comment #7 from jam...@amd.com --- Created attachment 143809 --> https://bugs.freedesktop.org/attachment.cgi?id=143809=edit patch for blur issue fix -- 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] [AppVeyor] mesa staging/19.0 #10592 completed
Build mesa 10592 completed
Commit 9987a3d448 by Karol Herbst on 3/28/2019 10:50 PM:
nir/print: fix printing the image_array intrinsic index\n\nFixes: 0de003be0363 ("nir: Add handle/index-based image intrinsics")\n\nSigned-off-by: Karol Herbst \nReviewed-by: Jason Ekstrand \n(cherry picked from commit 6ffc72472cc15368f95b18c1362298dd651bc7f1)
Configure your notification preferences
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
On 3/29/19 9:57 AM, Brian Paul wrote:
> __builtin_types_compatible_p() is GCC-specific and breaks the
> MSVC build.
>
> This intrinsic has been in u_vector_foreach() for a long time, but
> that macro has only recently been used in code
> (nir/nir_opt_comparison_pre.c) that's built with MSVC.
>
> Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares")
> ---
> src/util/u_vector.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/util/u_vector.h b/src/util/u_vector.h
> index cd8a95d..6807748 100644
> --- a/src/util/u_vector.h
> +++ b/src/util/u_vector.h
> @@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
> free(queue->data);
> }
>
> +#ifndef __GNUC__
> +#define __builtin_types_compatible_p(x) 1
> +#endif
> +
> #define u_vector_foreach(elem, queue) \
> STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct
> u_vector *)); \
The way this is GCC builtin is used here, this should be fine. However,
in case it's begin used elsewhere, we should #undef it afterwards. I'd
hate to mask some other kind of bug that may be introduced later.
> for (uint32_t __u_vector_offset = (queue)->tail;
> \
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
Looks good
Reviewed-by: Jose Fonseca
From: Brian Paul
Sent: Friday, March 29, 2019 16:57
To: mesa-dev@lists.freedesktop.org
Cc: Ian Romanick; Jose Fonseca; Neha Bhende
Subject: [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC
compilers
__builtin_types_compatible_p() is GCC-specific and breaks the
MSVC build.
This intrinsic has been in u_vector_foreach() for a long time, but
that macro has only recently been used in code
(nir/nir_opt_comparison_pre.c) that's built with MSVC.
Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares")
---
src/util/u_vector.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/util/u_vector.h b/src/util/u_vector.h
index cd8a95d..6807748 100644
--- a/src/util/u_vector.h
+++ b/src/util/u_vector.h
@@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
free(queue->data);
}
+#ifndef __GNUC__
+#define __builtin_types_compatible_p(x) 1
+#endif
+
#define u_vector_foreach(elem, queue) \
STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct
u_vector *)); \
for (uint32_t __u_vector_offset = (queue)->tail;
\
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
__builtin_types_compatible_p() is GCC-specific and breaks the
MSVC build.
This intrinsic has been in u_vector_foreach() for a long time, but
that macro has only recently been used in code
(nir/nir_opt_comparison_pre.c) that's built with MSVC.
Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares")
---
src/util/u_vector.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/util/u_vector.h b/src/util/u_vector.h
index cd8a95d..6807748 100644
--- a/src/util/u_vector.h
+++ b/src/util/u_vector.h
@@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue)
free(queue->data);
}
+#ifndef __GNUC__
+#define __builtin_types_compatible_p(x) 1
+#endif
+
#define u_vector_foreach(elem, queue) \
STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct
u_vector *)); \
for (uint32_t __u_vector_offset = (queue)->tail;
\
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: trace: Add missing fence related wrappers
Without that kmscube with GALLIUM_TRACE would segfault like:
#0 0x in ()
#1 0x8f311760 in dri2_create_fence_fd (_ctx=0xe266b8b0, fd=10)
at ../src/gallium/state_trackers/dri/dri_helpers.c:122
#2 0x90788670 in dri2_create_sync (drv=0xe2667910,
disp=0xe26691f0, type=12612, attrib_list=0xe26b9290) at
../src/egl/drivers/dri2/egl_dri2.c:2993
#3 0x90776a9c in _eglCreateSync (disp=0xe26691f0, type=12612,
attrib_list=0xe26b9290, orig_is_EGLAttrib=0, invalid_type_error=12292) at
../src/egl/main/eglapi.c:1823
#4 0x90776be4 in eglCreateSyncKHR (dpy=0xe26691f0, type=12612,
int_list=0xf662e828) at ../src/egl/main/eglapi.c:1848
Signed-off-by: Guido Günther
---
.../auxiliary/driver_trace/tr_context.c | 44 +++
.../auxiliary/driver_trace/tr_screen.c| 24 ++
2 files changed, 68 insertions(+)
diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c
b/src/gallium/auxiliary/driver_trace/tr_context.c
index 7859a3395ca..9f3926a32a4 100644
--- a/src/gallium/auxiliary/driver_trace/tr_context.c
+++ b/src/gallium/auxiliary/driver_trace/tr_context.c
@@ -1314,6 +1314,48 @@ trace_context_flush(struct pipe_context *_pipe,
}
+static void
+trace_context_create_fence_fd(struct pipe_context *_pipe,
+ struct pipe_fence_handle **fence,
+ int fd,
+ enum pipe_fd_type type)
+{
+ struct trace_context *tr_ctx = trace_context(_pipe);
+ struct pipe_context *pipe = tr_ctx->pipe;
+
+ trace_dump_call_begin("pipe_context", "create_fence_fd");
+
+ trace_dump_arg(ptr, pipe);
+ trace_dump_arg(int, fd);
+ trace_dump_arg(uint, type);
+
+ pipe->create_fence_fd(pipe, fence, fd, type);
+
+ if (fence)
+ trace_dump_ret(ptr, *fence);
+
+ trace_dump_call_end();
+}
+
+
+static void
+trace_context_fence_server_sync(struct pipe_context *_pipe,
+struct pipe_fence_handle *fence)
+{
+ struct trace_context *tr_ctx = trace_context(_pipe);
+ struct pipe_context *pipe = tr_ctx->pipe;
+
+ trace_dump_call_begin("pipe_context", "fence_server_sync");
+
+ trace_dump_arg(ptr, pipe);
+ trace_dump_arg(ptr, fence);
+
+ pipe->fence_server_sync(pipe, fence);
+
+ trace_dump_call_end();
+}
+
+
static inline boolean
trace_context_generate_mipmap(struct pipe_context *_pipe,
struct pipe_resource *res,
@@ -1946,6 +1988,8 @@ trace_context_create(struct trace_screen *tr_scr,
TR_CTX_INIT(clear_depth_stencil);
TR_CTX_INIT(clear_texture);
TR_CTX_INIT(flush);
+ TR_CTX_INIT(create_fence_fd);
+ TR_CTX_INIT(fence_server_sync);
TR_CTX_INIT(generate_mipmap);
TR_CTX_INIT(texture_barrier);
TR_CTX_INIT(memory_barrier);
diff --git a/src/gallium/auxiliary/driver_trace/tr_screen.c
b/src/gallium/auxiliary/driver_trace/tr_screen.c
index b5bd3e11c46..e42aef63552 100644
--- a/src/gallium/auxiliary/driver_trace/tr_screen.c
+++ b/src/gallium/auxiliary/driver_trace/tr_screen.c
@@ -495,6 +495,29 @@ trace_screen_fence_reference(struct pipe_screen *_screen,
}
+static int
+trace_screen_fence_get_fd(struct pipe_screen *_screen,
+ struct pipe_fence_handle *fence)
+{
+ struct trace_screen *tr_scr = trace_screen(_screen);
+ struct pipe_screen *screen = tr_scr->screen;
+ int result;
+
+ trace_dump_call_begin("pipe_screen", "fence_get_fd");
+
+ trace_dump_arg(ptr, screen);
+ trace_dump_arg(ptr, fence);
+
+ result = screen->fence_get_fd(screen, fence);
+
+ trace_dump_ret(int, result);
+
+ trace_dump_call_end();
+
+ return result;
+}
+
+
static boolean
trace_screen_fence_finish(struct pipe_screen *_screen,
struct pipe_context *_ctx,
@@ -654,6 +677,7 @@ trace_screen_create(struct pipe_screen *screen)
SCR_INIT(resource_changed);
tr_scr->base.resource_destroy = trace_screen_resource_destroy;
tr_scr->base.fence_reference = trace_screen_fence_reference;
+ SCR_INIT(fence_get_fd);
tr_scr->base.fence_finish = trace_screen_fence_finish;
SCR_INIT(memobj_create_from_handle);
SCR_INIT(memobj_destroy);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/vcn/vp9: search the render target from the whole list
This Patch is Acked-by: James Zhu
On 2019-03-28 9:08 a.m., Liu, Leo wrote:
> The number of render targets could be more than max of references,
> so we search the full list of the render pictures for the current
> render target index
>
> https://bugs.freedesktop.org/show_bug.cgi?id=109648
>
> Signed-off-by: Leo Liu
> Cc:
> ---
> src/gallium/drivers/radeon/radeon_vcn_dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c
> b/src/gallium/drivers/radeon/radeon_vcn_dec.c
> index d165c55f835..688cef90103 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
> @@ -491,7 +491,7 @@ static rvcn_dec_message_vp9_t get_vp9_msg(struct
> radeon_decoder *dec,
>
> assert(dec->base.max_references + 1 <= 16);
>
> - for (i = 0 ; i < dec->base.max_references + 1 ; ++i) {
> + for (i = 0 ; i < 16 ; ++i) {
> if (dec->render_pic_list[i] && dec->render_pic_list[i] ==
> target) {
> result.curr_pic_idx =
>
> (uintptr_t)vl_video_buffer_get_associated_data(target, >base);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] etnaviv: don't flush own context when updating resource use
Hi, On Wed, Mar 27, 2019 at 12:22:57PM +0100, Lucas Stach wrote: > The context is self synchronizing at the GPU side, as commands are > executed in order. We must not flush our own context when updating the > resource use, as that leads to excessive flushing on effectively every > draw call, causing huge CPU overhead. > > Fixes: 64813541d575 (etnaviv: fix resource usage tracking across > different pipe_context's) > Signed-off-by: Lucas Stach > --- > src/gallium/drivers/etnaviv/etnaviv_resource.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c > b/src/gallium/drivers/etnaviv/etnaviv_resource.c > index ab40414fbe2c..c7eedab74187 100644 > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c > @@ -666,9 +666,18 @@ etna_resource_used(struct etna_context *ctx, struct > pipe_resource *prsc, > struct etna_context *extctx = (struct etna_context *)entry->key; > struct pipe_context *pctx = >base; > > + if (extctx == ctx) > +continue; > + > pctx->flush(pctx, NULL, 0); > + /* It's safe to clear the status here. If we need to flush it means > + * either another context had the resource in exclusive (write) use, > + * or we transition the resource to exclusive use in our context. > + * In both cases the new status accurately reflects the resource use > + * after the flush. > + */ > + rsc->status = 0; >} > - rsc->status = 0; > } > > rsc->status |= status; Reviewed-By: Guido Günther ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS
https://bugs.freedesktop.org/show_bug.cgi?id=109805 --- Comment #14 from rainbowsforthe...@gmail.com --- (In reply to Samuel Pitoiset from comment #13) > Are you able to reproduce the VM faults with mesa 19.0? With Mesa 19.0.1, LLVM 8.0.0, Kernel 5.0.5 and Proton 4.2-1, it seems as though The Witcher 3 is stable now. I've been playing for well over an hour without any special kernel parameters or environment variables. No error messages or instability to report. -- 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
Re: [Mesa-dev] [PATCH 01/10] panfrost: Fix vertex buffer corruption
On Fri, 29 Mar 2019 at 02:48, Alyssa Rosenzweig wrote:
>
> Fixes crash in dEQP-GLES2.functional.buffer.*
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/pan_context.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index d242c3f90ce..5139a33d0fc 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -772,12 +772,14 @@ panfrost_emit_vertex_data(struct panfrost_context *ctx)
> * rsrc->gpu. However, attribute buffers must be 64 aligned.
> If
> * it is not, for now we have to duplicate the buffer. */
>
> -mali_ptr effective_address = (rsrc->bo->gpu +
> buf->buffer_offset);
> +mali_ptr effective_address = rsrc ? (rsrc->bo->gpu +
> buf->buffer_offset) : 0;
>
> -if (effective_address & 0x3F) {
> -attrs[i].elements = panfrost_upload_transient(ctx,
> rsrc->bo->cpu + buf->buffer_offset, attrs[i].size) | 1;
> +if (effective_address) {
> +attrs[i].elements = panfrost_upload_transient(ctx,
> rsrc->bo->cpu + buf->buffer_offset, attrs[i].size) | MALI_ATTR_LINEAR;
> +} else if (effective_address) {
Guess the two conditions above weren't supposed to be the same?
Regards,
Tomeu
> +attrs[i].elements = effective_address |
> MALI_ATTR_LINEAR;
> } else {
> -attrs[i].elements = effective_address | 1;
> +/* Leave unset? */
> }
> }
>
> --
> 2.20.1
>
> ___
> 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
[Mesa-dev] [PATCH v5 1/6] glsl/linker: location aliasing requires types to have the same width
From the OpenGL 4.60.5 spec, section 4.4.1 Input Layout Qualifiers,
Page 67, (Location aliasing):
" Further, when location aliasing, the aliases sharing the location
must have the same underlying numerical type and bit
width (floating-point or integer, 32-bit versus 64-bit, etc.) and
the same auxiliary storage and interpolation qualification."
Additionally, we have improved the linker error descriptions.
Specifically, when taking structs into account we were producing a
linker error because we assumed that all components in each location
were used and that would cause component aliasing. This is not
accurate of the actual problem. Now, the failure specifies that the
underlying numerical type incompatibility is the cause for the
failure.
Fixes the following piglit test:
tests/spec/arb_enhanced_layouts/linker/component-layout/vs-to-fs-width-mismatch-double-float.shader_test
v2:
- Do not assert if we see invalid numerical types. These come
straight from shader code, so we should produce linker errors if
shaders attempt to do location aliasing on variables that are not
numerical such as records.
- While we are at it, improve error reporting for the case of
numerical type mismatch to include the shader stage.
v3:
- Allow location aliasing of images and samplers. If we get these
it means bindless support is active and they should be handled
as 64-bit integers (Ilia)
- Make sure we produce link errors for any non-numerical type
for which we attempt location aliasing, not just structs.
v4:
- Rebased with minor fixes (Andres).
- Added fixing tag to the commit log (Andres).
v5:
- Remove the helper function and check individually for the
underlying numerical type and bit width (Timothy).
- Implicitly, assume that any non-treated type which is checked for
its underlying numerical type is either integer or
float and has a defined bit width (Timothy).
- Implicitly, assume that structs are the only non-treated
non-numerical type (Timothy).
- Improve the linker error descriptions and commit log (Andres).
Fixes: 13652e7516a ("glsl/linker: Fix type checks for location aliasing")
Cc: Ilia Mirkin
Cc: Timothy Arceri
Cc: Iago Toral Quiroga
Signed-off-by: Andres Gomez
---
src/compiler/glsl/link_varyings.cpp | 115 ++--
1 file changed, 76 insertions(+), 39 deletions(-)
diff --git a/src/compiler/glsl/link_varyings.cpp
b/src/compiler/glsl/link_varyings.cpp
index 352cd7e522b..4d4df8dc2e7 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -424,28 +424,14 @@ compute_variable_location_slot(ir_variable *var,
gl_shader_stage stage)
struct explicit_location_info {
ir_variable *var;
- unsigned numerical_type;
+ bool base_type_is_integer;
+ unsigned base_type_bit_size;
unsigned interpolation;
bool centroid;
bool sample;
bool patch;
};
-static inline unsigned
-get_numerical_type(const glsl_type *type)
-{
- /* From the OpenGL 4.6 spec, section 4.4.1 Input Layout Qualifiers, Page 68,
-* (Location aliasing):
-*
-*"Further, when location aliasing, the aliases sharing the location
-* must have the same underlying numerical type (floating-point or
-* integer)
-*/
- if (type->is_float() || type->is_double())
- return GLSL_TYPE_FLOAT;
- return GLSL_TYPE_INT;
-}
-
static bool
check_location_aliasing(struct explicit_location_info explicit_locations[][4],
ir_variable *var,
@@ -461,14 +447,23 @@ check_location_aliasing(struct explicit_location_info
explicit_locations[][4],
gl_shader_stage stage)
{
unsigned last_comp;
- if (type->without_array()->is_struct()) {
- /* The component qualifier can't be used on structs so just treat
- * all component slots as used.
+ unsigned base_type_bit_size;
+ const glsl_type *type_without_array = type->without_array();
+ const bool base_type_is_integer =
+ glsl_base_type_is_integer(type_without_array->base_type);
+ const bool is_struct = type_without_array->is_struct();
+ if (is_struct) {
+ /* structs don't have a defined underlying base type so just treat all
+ * component slots as used and set the bit size to 0. If there is
+ * location aliasing, we'll fail anyway later.
*/
last_comp = 4;
+ base_type_bit_size = 0;
} else {
- unsigned dmul = type->without_array()->is_64bit() ? 2 : 1;
- last_comp = component + type->without_array()->vector_elements * dmul;
+ unsigned dmul = type_without_array->is_64bit() ? 2 : 1;
+ last_comp = component + type_without_array->vector_elements * dmul;
+ base_type_bit_size =
+ glsl_base_type_get_bit_size(type_without_array->base_type);
}
while (location < location_limit) {
@@ -478,8 +473,22 @@ check_location_aliasing(struct explicit_location_info
explicit_locations[][4],
[Mesa-dev] [Bug 110261] Segmentation fault when using vulkaninfo on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=110261 --- Comment #3 from Denis --- hi, I am able to reproduce this issue on Manjaro OS and intel (CFL CPU), with system (18.3.4) and built from git mesa versions. Can I provide some additional information for you to help in debugging? Core was generated by `vulkaninfo'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fa3451b50f7 in XGetXCBConnection () from /usr/lib/libX11-xcb.so.1 [Current thread is 1 (Thread 0x7fa34945c740 (LWP 7380))] (gdb) bt #0 0x7fa3451b50f7 in XGetXCBConnection () from /usr/lib/libX11-xcb.so.1 #1 0x7fa342a267c1 in ?? () from /usr/lib/libvulkan_intel.so #2 0x561d0b6e0693 in ?? () #3 0x561d0b6d5f72 in ?? () #4 0x7fa349852223 in __libc_start_main () from /usr/lib/libc.so.6 #5 0x561d0b6d67be in ?? () that's my core dump. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: write availability status vkGetQueryPoolResults() when the data is not available
On Thu, 2019-03-28 at 16:21 +0100, Samuel Pitoiset wrote:
> On 3/25/19 8:16 AM, Samuel Iglesias Gonsálvez wrote:
> > On Fri, 2019-03-22 at 17:21 +0100, Samuel Pitoiset wrote:
> > > Does this fix anything known?
> > >
> > I am writing CTS tests for VK_EXT_host_query_reset extension and I
> > found this bug while testing them on RADV.
> >
> > > Does that rule also apply for CmdCopyQueryPoolResults()? If so,
> > > we
> > > might
> > > need to fix it (I haven't looked yet).
> > >
> > The rule is slightly different on CmdCopyQueryPoolResults():
> >
> > "Similarly, if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set and
> > VK_QUERY_RESULT_WAIT_BIT is not set, the availability is guaranteed
> > to
> > reflect the most recent use of the query on the same queue,
> > assuming
> > that the query is not being simultaneously used by other queues. As
> > with vkGetQueryPoolResults, implementations must guarantee that if
> > they
> > return a non-zero availability value, then the numerical results
> > are
> > valid."
> >
> > So if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT we need to still set
> > the
> > availability state.
> >
> > I skimmed the implementation of this function on RADV, it seems it
> > is
> > missing setting the availability value for all the queries except
> > for
> > VK_QUERY_TYPE_TIMESTAMP.
> >
> > Could you take care of this?
> Yes, do you have tests for CmdCopyQueryPoolResults()?
There are no tests for this case on CTS. I modified manually one test
and it seems I was wrong: RADV is setting the availability value. So
you don't need to do anything for the moment.
I'm going to add in my TODO list to add tests for this in CTS when time
allows, as it is not fully covered right now.
Thanks,
Sam
> > > With the comment on patch 1, series is:
> > >
> > > Reviewed-by: Samuel Pitoiset
> > >
> > OK, thanks! It seems I did a wrong squash of patches on patch 1. I
> > will
> > fix it and push both patches to master.
> >
> > Sam
> >
> > > On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
> > > > If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
> > > > VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
> > > > both
> > > > not
> > > > set, we need return to VK_NOT_READY only and set the
> > > > availability
> > > > status field for each query.
> > > >
> > > > From Vulkan spec:
> > > >
> > > > "If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT
> > > > are
> > > > both
> > > > not set then no result values are written to pData for queries
> > > > that
> > > > are
> > > > in the unavailable state at the time of the call, and
> > > > vkGetQueryPoolResults returns VK_NOT_READY. However,
> > > > availability
> > > > state
> > > > is still written to pData for those queries if
> > > > VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
> > > >
> > > > Signed-off-by: Samuel Iglesias Gonsálvez
> > > > ---
> > > >src/amd/vulkan/radv_query.c | 15 +++
> > > >1 file changed, 3 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/src/amd/vulkan/radv_query.c
> > > > b/src/amd/vulkan/radv_query.c
> > > > index 8578680f09d..63a2ab773a8 100644
> > > > --- a/src/amd/vulkan/radv_query.c
> > > > +++ b/src/amd/vulkan/radv_query.c
> > > > @@ -1141,11 +1141,8 @@ VkResult radv_GetQueryPoolResults(
> > > > available = *(uint64_t *)src !=
> > > > TIMESTAMP_NOT_READY;
> > > > }
> > > >
> > > > - if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > > > + if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> > > > result = VK_NOT_READY;
> > > > - break;
> > > > -
> > > > - }
> > > >
> > > > if (flags & VK_QUERY_RESULT_64_BIT) {
> > > > if (available || (flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> > > > @@ -1178,11 +1175,8 @@ VkResult radv_GetQueryPoolResults(
> > > > }
> > > > }
> > > >
> > > > - if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > > > + if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> > > > result = VK_NOT_READY;
> > > > - break;
> > > > -
> > > > - }
> > > >
> > > > if (flags & VK_QUERY_RESULT_64_BIT) {
> > > > if (available || (flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> > > > @@ -1196,11 +1190,8 @@ VkResult radv_GetQueryPoolResults(
> > > > break;
> > > > }
> > > > case VK_QUERY_TYPE_PIPELINE_STATISTICS: {
> > > > - if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > > > + if
[Mesa-dev] [Bug 110268] enable storageBuffer16BitAccess feature in radv for SI and CIK
https://bugs.freedesktop.org/show_bug.cgi?id=110268 --- Comment #3 from Samuel Pitoiset --- We should be able to enable it but I have to deal with some failures first. -- 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
Re: [Mesa-dev] [PATCH] ac: fix return type for llvm.amdgcn.frexp.exp.i32.64
Reviewed-by: Timothy Arceri
On 29/3/19 6:39 pm, Samuel Pitoiset wrote:
This fixes the following piglit with RadeonSI
tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-frexp-dvec4.shader_test
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 5572b244720..eb9e4504248 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -3942,7 +3942,7 @@ ac_build_frexp_exp(struct ac_llvm_context *ctx,
LLVMValueRef src0,
type = ctx->i32;
} else {
intr = "llvm.amdgcn.frexp.exp.i32.f64";
- type = ctx->i64;
+ type = ctx->i32;
}
LLVMValueRef params[] = {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac: fix return type for llvm.amdgcn.frexp.exp.i32.64
This fixes the following piglit with RadeonSI
tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-frexp-dvec4.shader_test
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 5572b244720..eb9e4504248 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -3942,7 +3942,7 @@ ac_build_frexp_exp(struct ac_llvm_context *ctx,
LLVMValueRef src0,
type = ctx->i32;
} else {
intr = "llvm.amdgcn.frexp.exp.i32.f64";
- type = ctx->i64;
+ type = ctx->i32;
}
LLVMValueRef params[] = {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110259] radv: Sampling depth-stencil image in GENERAL layout returns nothing but zero (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=110259 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Samuel Pitoiset --- Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=62a9d757e6074215c145c9637014d9acb16d865d -- 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
