Re: [Mesa-dev] [PATCH] ac/nir: fix txf_ms with an offset
Reviewed-by: Samuel Pitoiset
On 7/19/19 9:17 PM, Rhys Perry wrote:
Seems to fix some hair artifacts in Max Payne 3:
https://github.com/daniel-schuermann/mesa/issues/76
Signed-off-by: Rhys Perry
Fixes: f4e499ec791 ('radv: add initial non-conformant radv vulkan driver')
---
src/amd/common/ac_nir_to_llvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 96bf89a8bf9..549a26ea243 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3784,7 +3784,7 @@ static void visit_tex(struct ac_nir_context *ctx,
nir_tex_instr *instr)
goto write_result;
}
- if (args.offset && instr->op != nir_texop_txf) {
+ if (args.offset && instr->op != nir_texop_txf && instr->op !=
nir_texop_txf_ms) {
LLVMValueRef offset[3], pack;
for (unsigned chan = 0; chan < 3; ++chan)
offset[chan] = ctx->ac.i32_0;
@@ -3919,7 +3919,7 @@ static void visit_tex(struct ac_nir_context *ctx,
nir_tex_instr *instr)
args.coords[sample_chan], fmask_ptr);
}
- if (args.offset && instr->op == nir_texop_txf) {
+ if (args.offset && (instr->op == nir_texop_txf || instr->op ==
nir_texop_txf_ms)) {
int num_offsets =
instr->src[offset_src].src.ssa->num_components;
num_offsets = MIN2(num_offsets, instr->coord_components);
for (unsigned i = 0; i < num_offsets; ++i) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v6 4/5] st/dri2: Implement DRI2bufferDamageExtension
Hi Qiang,
On Sun, 21 Jul 2019 17:02:54 +0800
Qiang Yu wrote:
> On Mon, Jul 15, 2019 at 8:50 PM Boris Brezillon
> wrote:
> >
> > From: Daniel Stone
> >
> > Add a pipe_screen->set_damage_region() hook to propagate
> > set-damage-region requests to the driver, it's then up to the driver to
> > decide what to do with this piece of information.
> >
> > If the hook is left unassigned, the buffer-damage extension is
> > considered unsupported.
> >
> > Signed-off-by: Daniel Stone
> > Signed-off-by: Boris Brezillon
> > Reviewed-by: Alyssa Rosenzweig
> > ---
> > Hello Qiang,
> >
> > I intentionally dropped your R-b/T-b on this patch since the
> > ->set_damage_region() prototype has changed. Feel free to add it back.
> >
> > Regards,
> >
> > Boris
> >
> > Changes in v6:
> > * Pass pipe_box objects instead ints
> > * Document the set_damage_region() hook
> >
> > Changes in v5:
> > * Add Alyssa's R-b
> > ---
> > src/gallium/include/pipe/p_screen.h | 17 ++
> > src/gallium/state_trackers/dri/dri2.c | 34 +++
> > 2 files changed, 51 insertions(+)
> >
> > diff --git a/src/gallium/include/pipe/p_screen.h
> > b/src/gallium/include/pipe/p_screen.h
> > index 3f9bad470950..11a6aa939124 100644
> > --- a/src/gallium/include/pipe/p_screen.h
> > +++ b/src/gallium/include/pipe/p_screen.h
> > @@ -464,6 +464,23 @@ struct pipe_screen {
> > bool (*is_parallel_shader_compilation_finished)(struct pipe_screen
> > *screen,
> > void *shader,
> > unsigned shader_type);
> > +
> > + /**
> > +* Set the damage region (called when KHR_partial_update() is invoked).
> > +* This function is passed an array of rectangles encoding the damage
> > area.
> > +* rects are using the bottom-left origin convention.
> > +* nrects = 0 means 'reset the damage region'. What 'reset' implies is
> > HW
> > +* specific. For tile-based renderers, the damage extent is typically
> > set
> > +* to cover the whole resource with no damage rect (or a 0-size damage
> > +* rect). This way, the existing resource content is reloaded into the
> > +* local tile buffer for every tile thus making partial tile update
> > +* possible. For HW operating in immediate mode, this reset operation is
> > +* likely to be a NOOP.
> > +*/
> > + void (*set_damage_region)(struct pipe_screen *screen,
> > + struct pipe_resource *resource,
> > + unsigned int nrects,
> > + const struct pipe_box *rects);
> > };
> >
> >
> > diff --git a/src/gallium/state_trackers/dri/dri2.c
> > b/src/gallium/state_trackers/dri/dri2.c
> > index 5a7ec878bab0..5273b95cd5fb 100644
> > --- a/src/gallium/state_trackers/dri/dri2.c
> > +++ b/src/gallium/state_trackers/dri/dri2.c
> > @@ -1807,6 +1807,35 @@ static const __DRI2interopExtension
> > dri2InteropExtension = {
> > .export_object = dri2_interop_export_object
> > };
> >
> > +/**
> > + * \brief the DRI2bufferDamageExtension set_damage_region method
> > + */
> > +static void
> > +dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int
> > *rects)
> > +{
> > + struct dri_drawable *drawable = dri_drawable(dPriv);
> > + struct pipe_resource *resource =
> > drawable->textures[ST_ATTACHMENT_BACK_LEFT];
> > + struct pipe_screen *screen = resource->screen;
> > + struct pipe_box *boxes = NULL;
> > +
> > + if (nrects) {
> > + boxes = CALLOC(nrects, sizeof(*boxes));
> > + assert(boxes);
>
> Where does this boxes array get freed? I can't find in your patch 6 either.
Indeed, the FREE() is missing.
> In fact I prefer the v5 way which just uses `int *rects` to avoid unnecessary
> conversion.
Well, Erik suggested to pass an array of pipe_boxe objects to make
things clearer, and I can of agree with him. Moreover, I'd expect the
extra allocation + pipe_box init overhead to be negligible.
Regards,
Boris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: fix crash in vkCmdClearAttachments with unused attachment
depth_stencil_attachment and/or ds_resolve attachment can be NULL. This fixes crashes with dEQP-VK.renderpass.suballocation.unused_clear_attachments.* Cc: 19.1 Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_meta_clear.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c index dd2ba402f40..b93ba3e0b29 100644 --- a/src/amd/vulkan/radv_meta_clear.c +++ b/src/amd/vulkan/radv_meta_clear.c @@ -1688,7 +1688,7 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer, if (ds_resolve_clear) ds_att = subpass->ds_resolve_attachment; - if (ds_att->attachment == VK_ATTACHMENT_UNUSED) + if (!ds_att || ds_att->attachment == VK_ATTACHMENT_UNUSED) return; VkImageLayout image_layout = ds_att->layout; -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix crash in vkCmdClearAttachments with unused attachment
r-b On Mon, Jul 22, 2019 at 10:09 AM Samuel Pitoiset wrote: > > depth_stencil_attachment and/or ds_resolve attachment can be NULL. > > This fixes crashes with > dEQP-VK.renderpass.suballocation.unused_clear_attachments.* > > Cc: 19.1 > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_meta_clear.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/vulkan/radv_meta_clear.c > b/src/amd/vulkan/radv_meta_clear.c > index dd2ba402f40..b93ba3e0b29 100644 > --- a/src/amd/vulkan/radv_meta_clear.c > +++ b/src/amd/vulkan/radv_meta_clear.c > @@ -1688,7 +1688,7 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer, > if (ds_resolve_clear) > ds_att = subpass->ds_resolve_attachment; > > - if (ds_att->attachment == VK_ATTACHMENT_UNUSED) > + if (!ds_att || ds_att->attachment == VK_ATTACHMENT_UNUSED) > return; > > VkImageLayout image_layout = ds_att->layout; > -- > 2.22.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
[Mesa-dev] [Bug 111192] blender: ../src/gallium/drivers/svga/svga_tgsi_vgpu10.c:1738: make_immediate_reg_4: Assertion `!"Failed to find immediate register!"' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=92 Bug ID: 92 Summary: blender: ../src/gallium/drivers/svga/svga_tgsi_vgpu10.c:1738: make_immediate_reg_4: Assertion `!"Failed to find immediate register!"' failed. Product: Mesa Version: 19.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/vmwgfx Assignee: mesa-dev@lists.freedesktop.org Reporter: sch...@alpharesearch.de QA Contact: mesa-dev@lists.freedesktop.org Created attachment 144840 --> https://bugs.freedesktop.org/attachment.cgi?id=144840&action=edit system info from blender renderer: 'SVGA3D; build: RELEASE; LLVM;' vendor: 'VMware, Inc.' version:'3.3 (Core Profile) Mesa 19.1.2 - padoka PPA' When I start the new Blender 2.8RC2 and press tab to swtich to edit mode I get this: blender: ../src/gallium/drivers/svga/svga_tgsi_vgpu10.c:1738: make_immediate_reg_4: Assertion `!"Failed to find immediate register!"' failed. Aborted (core dumped) I opened a bug report for Blender: https://developer.blender.org/T67449 But it was determined that this is a driver fault. -- 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 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization
https://bugs.freedesktop.org/show_bug.cgi?id=41 --- Comment #12 from Connor Abbott --- It seems I get an error trying to download your capture, probably because it's too big, can you upload it somewhere else? Also, radv sometimes (intentionally or not) has a slightly different pass ordering or lowers things differently, which can make a NIR-level bug still only appear on radv. -- 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] radv/gfx10: correctly determine the number of vertices per primitive
For TES as NGG.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 336bae28614..6e5a283f923 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -112,6 +112,7 @@ struct radv_shader_context {
unsigned gs_max_out_vertices;
unsigned gs_output_prim;
+ unsigned tes_point_mode;
unsigned tes_primitive_mode;
uint32_t tcs_patch_outputs_read;
@@ -3304,7 +3305,6 @@ handle_ngg_outputs_post(struct radv_shader_context *ctx)
{
LLVMBuilderRef builder = ctx->ac.builder;
struct ac_build_if_state if_state;
- unsigned num_vertices = 3;
LLVMValueRef tmp;
assert((ctx->stage == MESA_SHADER_VERTEX ||
@@ -3322,6 +3322,20 @@ handle_ngg_outputs_post(struct radv_shader_context *ctx)
ac_unpack_param(&ctx->ac, ctx->gs_vtx_offset[2], 0, 16),
};
+ /* Determine the number of vertices per primitive. */
+ unsigned num_vertices;
+
+ if (ctx->stage == MESA_SHADER_VERTEX) {
+ num_vertices = 3; /* TODO: optimize for points & lines */
+ } else {
+ if (ctx->tes_point_mode)
+ num_vertices = 1;
+ else if (ctx->tes_primitive_mode == GL_LINES)
+ num_vertices = 2;
+ else
+ num_vertices = 3;
+ }
+
/* TODO: streamout */
/* Copy Primitive IDs from GS threads to the LDS address corresponding
@@ -4435,6 +4449,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
ctx.tcs_num_inputs =
util_last_bit64(shader_info->info.vs.ls_outputs_written);
ctx.tcs_num_patches = get_tcs_num_patches(&ctx);
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
+ ctx.tes_point_mode = shaders[i]->info.tess.point_mode;
ctx.tes_primitive_mode =
shaders[i]->info.tess.primitive_mode;
ctx.abi.load_tess_varyings = load_tes_input;
ctx.abi.load_tess_coord = load_tess_coord;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv/gfx10: reduce max_esverts_base to 128
Same as RadeonSI. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_pipeline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c index a7ff0e2d139..fce60a62ee9 100644 --- a/src/amd/vulkan/radv_pipeline.c +++ b/src/amd/vulkan/radv_pipeline.c @@ -1704,7 +1704,7 @@ calculate_ngg_info(const VkGraphicsPipelineCreateInfo *pCreateInfo, /* All these are per subgroup: */ bool max_vert_out_per_gs_instance = false; - unsigned max_esverts_base = 256; + unsigned max_esverts_base = 128; unsigned max_gsprims_base = 128; /* default prim group size clamp */ /* Hardware has the following non-natural restrictions on the value -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #11975 failed
Build mesa 11975 failed Commit d07c846546 by Alyssa Rosenzweig on 7/22/2019 3:34 PM: pan/decode: Disable magic divisor debugging\n\nMemory corruption (for both legitimate and illegitimate reasons) causes\nthis to hang pantrace.\n\nSigned-off-by: Alyssa Rosenzweig 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 2/2] radv/gfx10: correctly determine the number of vertices per primitive
On Mon, Jul 22, 2019 at 11:49 AM Samuel Pitoiset
wrote:
>
> For TES as NGG.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 336bae28614..6e5a283f923 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -112,6 +112,7 @@ struct radv_shader_context {
> unsigned gs_max_out_vertices;
> unsigned gs_output_prim;
>
> + unsigned tes_point_mode;
> unsigned tes_primitive_mode;
>
> uint32_t tcs_patch_outputs_read;
> @@ -3304,7 +3305,6 @@ handle_ngg_outputs_post(struct radv_shader_context *ctx)
> {
> LLVMBuilderRef builder = ctx->ac.builder;
> struct ac_build_if_state if_state;
> - unsigned num_vertices = 3;
> LLVMValueRef tmp;
>
> assert((ctx->stage == MESA_SHADER_VERTEX ||
> @@ -3322,6 +3322,20 @@ handle_ngg_outputs_post(struct radv_shader_context
> *ctx)
> ac_unpack_param(&ctx->ac, ctx->gs_vtx_offset[2], 0, 16),
> };
>
> + /* Determine the number of vertices per primitive. */
> + unsigned num_vertices;
> +
> + if (ctx->stage == MESA_SHADER_VERTEX) {
> + num_vertices = 3; /* TODO: optimize for points & lines */
> + } else {
> + if (ctx->tes_point_mode)
> + num_vertices = 1;
> + else if (ctx->tes_primitive_mode == GL_LINES)
> + num_vertices = 2;
> + else
> + num_vertices = 3;
> + }
> +
> /* TODO: streamout */
>
> /* Copy Primitive IDs from GS threads to the LDS address corresponding
> @@ -4435,6 +4449,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
> ac_llvm_compiler *ac_llvm,
> ctx.tcs_num_inputs =
> util_last_bit64(shader_info->info.vs.ls_outputs_written);
> ctx.tcs_num_patches = get_tcs_num_patches(&ctx);
> } else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
> + ctx.tes_point_mode = shaders[i]->info.tess.point_mode;
Drive-by-comment without reading the full context...
What if there's e.g. a GS which produces not-points? This bool will be
set, and the logic above will say num_vertices = 1, which presumably
is bad.
-ilia
> ctx.tes_primitive_mode =
> shaders[i]->info.tess.primitive_mode;
> ctx.abi.load_tess_varyings = load_tes_input;
> ctx.abi.load_tess_coord = load_tess_coord;
> --
> 2.22.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 2/2] radv/gfx10: correctly determine the number of vertices per primitive
On Mon, Jul 22, 2019 at 6:01 PM Ilia Mirkin wrote:
>
> On Mon, Jul 22, 2019 at 11:49 AM Samuel Pitoiset
> wrote:
> >
> > For TES as NGG.
> >
> > Signed-off-by: Samuel Pitoiset
> > ---
> > src/amd/vulkan/radv_nir_to_llvm.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> > b/src/amd/vulkan/radv_nir_to_llvm.c
> > index 336bae28614..6e5a283f923 100644
> > --- a/src/amd/vulkan/radv_nir_to_llvm.c
> > +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> > @@ -112,6 +112,7 @@ struct radv_shader_context {
> > unsigned gs_max_out_vertices;
> > unsigned gs_output_prim;
> >
> > + unsigned tes_point_mode;
> > unsigned tes_primitive_mode;
> >
> > uint32_t tcs_patch_outputs_read;
> > @@ -3304,7 +3305,6 @@ handle_ngg_outputs_post(struct radv_shader_context
> > *ctx)
> > {
> > LLVMBuilderRef builder = ctx->ac.builder;
> > struct ac_build_if_state if_state;
> > - unsigned num_vertices = 3;
> > LLVMValueRef tmp;
> >
> > assert((ctx->stage == MESA_SHADER_VERTEX ||
> > @@ -3322,6 +3322,20 @@ handle_ngg_outputs_post(struct radv_shader_context
> > *ctx)
> > ac_unpack_param(&ctx->ac, ctx->gs_vtx_offset[2], 0, 16),
> > };
> >
> > + /* Determine the number of vertices per primitive. */
> > + unsigned num_vertices;
> > +
> > + if (ctx->stage == MESA_SHADER_VERTEX) {
> > + num_vertices = 3; /* TODO: optimize for points & lines */
> > + } else {
> > + if (ctx->tes_point_mode)
> > + num_vertices = 1;
> > + else if (ctx->tes_primitive_mode == GL_LINES)
> > + num_vertices = 2;
> > + else
> > + num_vertices = 3;
> > + }
> > +
> > /* TODO: streamout */
> >
> > /* Copy Primitive IDs from GS threads to the LDS address
> > corresponding
> > @@ -4435,6 +4449,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
> > ac_llvm_compiler *ac_llvm,
> > ctx.tcs_num_inputs =
> > util_last_bit64(shader_info->info.vs.ls_outputs_written);
> > ctx.tcs_num_patches = get_tcs_num_patches(&ctx);
> > } else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL)
> > {
> > + ctx.tes_point_mode =
> > shaders[i]->info.tess.point_mode;
>
> Drive-by-comment without reading the full context...
>
> What if there's e.g. a GS which produces not-points? This bool will be
> set, and the logic above will say num_vertices = 1, which presumably
> is bad.
The invariant you're probably missing here is that
handle_ngg_outputs_post only gets called if there is no GS.
(And the gs epilogue does not care about these tessellation variables).
>
> -ilia
>
> > ctx.tes_primitive_mode =
> > shaders[i]->info.tess.primitive_mode;
> > ctx.abi.load_tess_varyings = load_tes_input;
> > ctx.abi.load_tess_coord = load_tess_coord;
> > --
> > 2.22.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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94 Bug ID: 94 Summary: [bisected] Piles of dEQP teximage tests failing Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: ja...@jlekstrand.net QA Contact: mesa-dev@lists.freedesktop.org The following CTS and dEQP tests are failing on mesa master: dEQP-GLES2.functional.negative_api.texture.compressedteximage_2d_invalid_target dEQP-GLES2.functional.negative_api.texture.teximage2d_invalid_target dEQP-GLES31.functional.debug.async.case_6_log dEQP-GLES31.functional.debug.error_filters.case_10 dEQP-GLES31.functional.debug.error_filters.case_16 dEQP-GLES31.functional.debug.error_filters.case_20 dEQP-GLES31.functional.debug.error_filters.case_3 dEQP-GLES31.functional.debug.error_groups.case_10 dEQP-GLES31.functional.debug.error_groups.case_3 dEQP-GLES31.functional.debug.negative_coverage.callbacks.texture.compressedteximage2d_invalid_target dEQP-GLES31.functional.debug.negative_coverage.callbacks.texture.compressedteximage3d dEQP-GLES31.functional.debug.negative_coverage.callbacks.texture.teximage2d dEQP-GLES31.functional.debug.negative_coverage.callbacks.texture.teximage3d dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.compressedteximage2d_invalid_target dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.compressedteximage3d dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.teximage2d dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.teximage3d dEQP-GLES31.functional.debug.negative_coverage.log.texture.compressedteximage2d_invalid_target dEQP-GLES31.functional.debug.negative_coverage.log.texture.compressedteximage3d dEQP-GLES31.functional.debug.negative_coverage.log.texture.teximage2d dEQP-GLES31.functional.debug.negative_coverage.log.texture.teximage3d dEQP-GLES3.functional.negative_api.texture.compressedteximage2d_invalid_target dEQP-GLES3.functional.negative_api.texture.compressedteximage3d dEQP-GLES3.functional.negative_api.texture.teximage2d dEQP-GLES3.functional.negative_api.texture.teximage3d KHR-GL46.direct_state_access.textures_image_query_errors KHR-GLES2.texture_3d.compressed_texture.negative_compressed_tex_image KHR-GLES2.texture_3d.filtering.combinations.negative I've bisected the failing tests to the following commit in mesa master: commit 9dd1f7cec010775d2fd378dc496b7fe7cc40e812 Author: Pierre-Eric Pelloux-Prayer Date: Tue Jul 2 11:32:06 2019 +0200 mesa: pass gl_texture_object as arg to not depend on state This will allow to use the same functions for EXT_dsa implementation. Reviewed-by: Marek Olšák -- 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 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94 Jason Ekstrand changed: What|Removed |Added CC||mar...@gmail.com Assignee|mesa-dev@lists.freedesktop. |pierre-eric.pelloux-prayer@ |org |amd.com -- 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 2/2] radv/gfx10: correctly determine the number of vertices per primitive
On 7/22/19 6:01 PM, Ilia Mirkin wrote:
On Mon, Jul 22, 2019 at 11:49 AM Samuel Pitoiset
wrote:
For TES as NGG.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 336bae28614..6e5a283f923 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -112,6 +112,7 @@ struct radv_shader_context {
unsigned gs_max_out_vertices;
unsigned gs_output_prim;
+ unsigned tes_point_mode;
unsigned tes_primitive_mode;
uint32_t tcs_patch_outputs_read;
@@ -3304,7 +3305,6 @@ handle_ngg_outputs_post(struct radv_shader_context *ctx)
{
LLVMBuilderRef builder = ctx->ac.builder;
struct ac_build_if_state if_state;
- unsigned num_vertices = 3;
LLVMValueRef tmp;
assert((ctx->stage == MESA_SHADER_VERTEX ||
@@ -3322,6 +3322,20 @@ handle_ngg_outputs_post(struct radv_shader_context *ctx)
ac_unpack_param(&ctx->ac, ctx->gs_vtx_offset[2], 0, 16),
};
+ /* Determine the number of vertices per primitive. */
+ unsigned num_vertices;
+
+ if (ctx->stage == MESA_SHADER_VERTEX) {
+ num_vertices = 3; /* TODO: optimize for points & lines */
+ } else {
+ if (ctx->tes_point_mode)
+ num_vertices = 1;
+ else if (ctx->tes_primitive_mode == GL_LINES)
+ num_vertices = 2;
+ else
+ num_vertices = 3;
+ }
+
/* TODO: streamout */
/* Copy Primitive IDs from GS threads to the LDS address corresponding
@@ -4435,6 +4449,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
ctx.tcs_num_inputs =
util_last_bit64(shader_info->info.vs.ls_outputs_written);
ctx.tcs_num_patches = get_tcs_num_patches(&ctx);
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
+ ctx.tes_point_mode = shaders[i]->info.tess.point_mode;
Drive-by-comment without reading the full context...
What if there's e.g. a GS which produces not-points? This bool will be
set, and the logic above will say num_vertices = 1, which presumably
is bad.
With GS, TES is emitted as ES and this function isn't called because
it's for NGG only.
-ilia
ctx.tes_primitive_mode =
shaders[i]->info.tess.primitive_mode;
ctx.abi.load_tess_varyings = load_tes_input;
ctx.abi.load_tess_coord = load_tess_coord;
--
2.22.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] R: [PATCH 1/2] meson: require libdrm for gallium svga or virgl
Hmm, I don't *think* the freedreno gallium driver itself should depend on libdrm. I guess I haven't tried to build without. What is the error? BR, -R On Thu, Jul 18, 2019 at 9:43 AM Francesco Ansanelli wrote: > > Dear Alyssa, > > Sorry the bothering.. > > Your patch also added the check for freedreno, but it is not mentioned in the > commit message. > Is it actually what you wanted? > > Cheers, > Francesco > ___ > 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] [Bug 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94 --- Comment #1 from Kenneth Graunke --- It looks like an assert(texObj) used to be in teximage() *after* a bunch of the error checking, and now it's in teximage_err() *before* the error checking. Note that these tests are explicitly probing error conditions. -- You are receiving this mail because: 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 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization
https://bugs.freedesktop.org/show_bug.cgi?id=41 --- Comment #13 from Steven Newbury --- I've put it on my local web server: http://www.snewbury.org.uk/before.rdc http://www.snewbury.org.uk/after.rdc -- 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 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 --- Comment #2 from Jordan Justen --- I also saw this on debian sid after upgrading from meson 0.49 to 0.51. Downgrading to 0.49 fixed it. In the meson log, it suspiciously lists the PKG_CONFIG_PATH as empty, but for several previously found libraries, PKG_CONFIG_PATH is printed as non-empty: Pkg-config binary for MachineChoice.BUILD is not cached. Pkg-config binary missing from cross or native file, or env var undefined. Trying a default pkg-config fallback at pkg-config Trying pkg-config binary pkg-config for machine MachineChoice.BUILD at ['/usr/bin/pkg-config'] Found pkg-config: /usr/bin/pkg-config (0.29) Determining dependency 'wayland-scanner' with pkg-config executable '/usr/bin/pkg-config' PKG_CONFIG_PATH: Called `/usr/bin/pkg-config --modversion wayland-scanner` -> 1 -- 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 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94 --- Comment #2 from Marek Olšák --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1420 -- You are receiving this mail because: 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 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94 --- Comment #3 from Pierre-Eric Pelloux-Prayer --- Sorry about the regression. Thanks Jason and Kenneth for the bisection / analysis! -- You are receiving this mail because: 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 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 Jordan Justen changed: What|Removed |Added CC||baker.dyla...@gmail.com, ||emil.l.veli...@gmail.com, ||fdo-b...@engestrom.ch, ||jljus...@gmail.com -- 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
[Mesa-dev] [Bug 111126] Build problem: meson build can not find wayland-scanner
https://bugs.freedesktop.org/show_bug.cgi?id=26 --- Comment #3 from Jordan Justen --- Emil, in: commit c077b74ee8187042ad3ad8001d94074e73e3e9ea meson: use dependency()+find_program() for wayland-scanner You added "native: true". How is that used? I notice that if I remove it, then mesa will configure with meson 0.51. -- 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 master #11979 failed
Build mesa 11979 failed Commit 5c5f11d1dd by Jason Ekstrand on 7/22/2019 5:51 AM: nir: Remove a bunch of large stack arrays\n\nReviewed-by: Lionel Landwerlin \nReviewed-by: Matt Turner Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111194] [bisected] Piles of dEQP teximage tests failing
https://bugs.freedesktop.org/show_bug.cgi?id=94
Kenneth Graunke changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #4 from Kenneth Graunke ---
Fixed by:
commit c37df5feaa267080b836bbcf0f2727ec9f1d288e
Author: Marek Olšák
Date: Mon Jul 22 15:28:42 2019 -0400
mesa: fix assertion failure in TexImage
Check the assertion after error checking.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94
Fixes: 9dd1f7cec01 ("mesa: pass gl_texture_object as arg to not depend on
state")
Reviewed-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Kenneth Graunke
--
You are receiving this mail because:
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] boolean usage in gallium
PSA - I've pushed the changes which flip the gallium APIs and their
direct users from boolean -> bool. I've tried to take every precaution
against breaking compilation, but it's conceivable something got
missed in the repository-wide update. However fixing it up should be
trivial - let me know if you should have trouble, I'm happy to help. I
have not updated any of the various drivers' internal usages, and
encourage gallium driver and state tracker maintainers to convert
boolean -> bool
TRUE -> true
FALSE -> false
The one caveat I'll note is that the following situation can occur with boolean:
void f(int x) { print(x); }
void g(boolean x) { f(x); }
void h() { g(123); }
This will print 123, since boolean is a char. With bool, it will print
1. IMHO any code which relies on this behavior is a bug, but bugs do
happen, so a blind conversion can be dangerous.
Cheers,
-ilia
On Sat, Jun 29, 2019 at 12:08 AM Ilia Mirkin wrote:
>
> Ken pointed out on IRC today that there was still a lot of "boolean"
> (vs bool/_Bool) usage in gallium. In fact, many interfaces are
> specified with boolean.
>
> I had it in my mind that I had at some point removed most boolean
> usage, but that is just not the case - first of all, the interfaces
> remain with it, and I could find no evidence of such a commit. I must
> have imagined it.
>
> Is there any reason to keep boolean around? I know conversions must be
> done carefully (since incorrect-but-working usage would not currently
> be caught by the compiler), but are there any practical reasons to
> avoid C99 _Bool in gallium code?
>
> If not, I may begin converting things over.
>
> Cheers,
>
> -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv/gfx10: enable CLEAR_state
It actually works. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_device.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index 992e12840f7..93b03afda22 100644 --- a/src/amd/vulkan/radv_device.c +++ b/src/amd/vulkan/radv_device.c @@ -354,8 +354,7 @@ radv_physical_device_init(struct radv_physical_device *device, /* The mere presence of CLEAR_STATE in the IB causes random GPU hangs * on GFX6. */ - device->has_clear_state = device->rad_info.chip_class >= GFX7 && - device->rad_info.chip_class <= GFX9; + device->has_clear_state = device->rad_info.chip_class >= GFX7; device->cpdma_prefetch_writes_memory = device->rad_info.chip_class <= GFX8; -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
