[Mesa-dev] Crash in iris_bufmgr.c
Hi Kenneth, since your recent changes, I get a zero pointer dereference in alloc_bo_from_cache on one workload here: What I get is Thread 2 "" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffef776700 (LWP 20924)] list_del (item=0x7fffe8ae4020) at ../src/util/list.h:91 91 item->prev->next = item->next; (gdb) p item->prev $1 = (struct list_head *) 0x0 (gdb) where #0 list_del (item=0x7fffe8ae4020) at ../src/util/list.h:91 #1 0x7469072f in alloc_bo_from_cache (bufmgr=0x4d8370, bucket=0x4d8418, memzone=IRIS_MEMZONE_OTHER, flags=0, match_zone=true) at ../src/gallium/drivers/iris/iris_bufmgr.c:387 [...] I think the reason is that you use list_for_each_entry_safe in alloc_bo_from_cache in the outer loop and store a pointer to the next list entry. But when you call into iris_bo_cache_purge_bucket from inside that loop the function body there may walk the same list node than __next from list_for_each_entry_safe in alloc_bo_from_cache points to and may zero the list pointers out. You may know best how to fix that. best and thanks Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] radv: implement VK_EXT_sample_locations
R-b, assuming you disable the ext and add todos for the htile stuff.
On Fri, May 24, 2019, 9:28 AM Samuel Pitoiset
wrote:
> It's a bit difficult and invasive to support variable sample locations
> during layout transitions actually.
>
> So for now, I disabled HTILE for depth/stencil images that might require
> sample locations.
> On 5/22/19 10:20 PM, Marek Olšák wrote:
>
> The depth decompress pass needs to know the sample locations.
>
> If shader loads read from compressed depth, the texture hardware will
> always use the standard locations for decompression.
>
> Marek
>
> On Tue, May 21, 2019 at 8:17 PM Bas Nieuwenhuizen
> wrote:
>
>> So this does not seem to use the sample locations during layout
>> transitions?
>>
>> AFAIK those are needed for e.g. HTILE decompression as it is based on
>> equations somehow.
>>
>> On Thu, May 16, 2019 at 11:51 AM Samuel Pitoiset
>> wrote:
>> >
>> > Basically, this extension allows applications to use custom
>> > sample locations. It doesn't support variable sample locations
>> > during subpass. Note that we don't have to upload the user
>> > sample locations because the spec doesn't allow this.
>> >
>> > Only enabled on VI+ because it's untested on older chips.
>> >
>> > v2: - change sampleLocationCoordinateRange[1] to 0.9375
>> > - compute and emit PA_SC_CENTROID_PRIORITY_{0,1}
>> > - rebased on top of master
>> > - some cleanups
>> >
>> > Signed-off-by: Samuel Pitoiset
>> > ---
>> > src/amd/vulkan/radv_cmd_buffer.c | 223 ++
>> > src/amd/vulkan/radv_device.c | 27
>> > src/amd/vulkan/radv_extensions.py | 1 +
>> > src/amd/vulkan/radv_pipeline.c| 30
>> > src/amd/vulkan/radv_private.h | 26 +++-
>> > 5 files changed, 300 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/src/amd/vulkan/radv_cmd_buffer.c
>> b/src/amd/vulkan/radv_cmd_buffer.c
>> > index 4f592bc7f68..fb79c1c6713 100644
>> > --- a/src/amd/vulkan/radv_cmd_buffer.c
>> > +++ b/src/amd/vulkan/radv_cmd_buffer.c
>> > @@ -105,6 +105,7 @@ radv_bind_dynamic_state(struct radv_cmd_buffer
>> *cmd_buffer,
>> > dest->viewport.count = src->viewport.count;
>> > dest->scissor.count = src->scissor.count;
>> > dest->discard_rectangle.count = src->discard_rectangle.count;
>> > + dest->sample_location.count = src->sample_location.count;
>> >
>> > if (copy_mask & RADV_DYNAMIC_VIEWPORT) {
>> > if (memcmp(>viewport.viewports,
>> >viewport.viewports,
>> > @@ -192,6 +193,22 @@ radv_bind_dynamic_state(struct radv_cmd_buffer
>> *cmd_buffer,
>> > }
>> > }
>> >
>> > + if (copy_mask & RADV_DYNAMIC_SAMPLE_LOCATIONS) {
>> > + if (dest->sample_location.per_pixel !=
>> src->sample_location.per_pixel ||
>> > + dest->sample_location.grid_size.width !=
>> src->sample_location.grid_size.width ||
>> > + dest->sample_location.grid_size.height !=
>> src->sample_location.grid_size.height ||
>> > + memcmp(>sample_location.locations,
>> > + >sample_location.locations,
>> > + src->sample_location.count *
>> sizeof(VkSampleLocationEXT))) {
>> > + dest->sample_location.per_pixel =
>> src->sample_location.per_pixel;
>> > + dest->sample_location.grid_size =
>> src->sample_location.grid_size;
>> > + typed_memcpy(dest->sample_location.locations,
>> > +src->sample_location.locations,
>> > +src->sample_location.count);
>> > + dest_mask |= RADV_DYNAMIC_SAMPLE_LOCATIONS;
>> > + }
>> > + }
>> > +
>> > cmd_buffer->state.dirty |= dest_mask;
>> > }
>> >
>> > @@ -632,6 +649,190 @@ radv_emit_descriptor_pointers(struct
>> radv_cmd_buffer *cmd_buffer,
>> > }
>> > }
>> >
>> > +/**
>> > + * Convert the user sample locations to hardware sample locations (the
>> values
>> > + * that will be emitted by PA_SC_AA_SAMPLE_LOCS_PIXEL_*).
>> > + */
>> > +static void
>> > +radv_convert_user_sample_locs(struct radv_sample_locations_state
>> *state,
>> > + uint32_t x, uint32_t y, VkOffset2D
>> *sample_locs)
>> > +{
>> > + uint32_t x_offset = x % state->grid_size.width;
>> > + uint32_t y_offset = y % state->grid_size.height;
>> > + uint32_t num_samples = (uint32_t)state->per_pixel;
>> > + VkSampleLocationEXT *user_locs;
>> > + uint32_t pixel_offset;
>> > +
>> > + pixel_offset = (x_offset + y_offset * state->grid_size.width) *
>> num_samples;
>> > +
>> > + assert(pixel_offset <= MAX_SAMPLE_LOCATIONS);
>> > + user_locs = >locations[pixel_offset];
>> > +
>> > + for (uint32_t i = 0; i < num_samples; i++) {
>> > + float shifted_pos_x = user_locs[i].x - 0.5;
>> > + float shifted_pos_y = user_locs[i].y - 0.5;
>>
Re: [Mesa-dev] [PATCH v3 03/18] intel/blorp: Use the hardware op for CCS ambiguate on gen10+
On Wed, Feb 14, 2018 at 12:19 PM Jason Ekstrand wrote:
>
> Cannonlake hardware adds a new resolve type in 3DSTATE_PS called
> FAST_CLEAR_0 which does an ambiguate. Now that the hardware can do it
> directly, we should use that instead of binding the CCS as a render
> target and doing it manually. This was tested with a full Vulkan CTS
> run on Cannonlake.
> ---
> src/intel/blorp/blorp_clear.c | 12 +++-
> src/intel/blorp/blorp_genX_exec.h | 6 ++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
This patch is
Reviewed-by: Nanley Chery
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index 421a6c5..4ba65d0 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -758,7 +758,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
> params.x1 = ALIGN(params.x1, x_scaledown) / x_scaledown;
> params.y1 = ALIGN(params.y1, y_scaledown) / y_scaledown;
>
> - if (batch->blorp->isl_dev->info->gen >= 9) {
> + if (batch->blorp->isl_dev->info->gen >= 10) {
> + assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
> + resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE ||
> + resolve_op == ISL_AUX_OP_AMBIGUATE);
> + } else if (batch->blorp->isl_dev->info->gen >= 9) {
>assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
> resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE);
> } else {
> @@ -893,6 +897,12 @@ blorp_ccs_ambiguate(struct blorp_batch *batch,
> struct blorp_surf *surf,
> uint32_t level, uint32_t layer)
> {
> + if (ISL_DEV_GEN(batch->blorp->isl_dev) >= 10) {
> + /* On gen10 and above, we have a hardware resolve op for this */
> + return blorp_ccs_resolve(batch, surf, level, layer, 1,
> + surf->surf->format, ISL_AUX_OP_AMBIGUATE);
> + }
> +
> struct blorp_params params;
> blorp_params_init();
>
> diff --git a/src/intel/blorp/blorp_genX_exec.h
> b/src/intel/blorp/blorp_genX_exec.h
> index 5e1312a..85abf6b 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -752,6 +752,12 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>switch (params->fast_clear_op) {
>case ISL_AUX_OP_NONE:
> break;
> +#if GEN_GEN >= 10
> + case ISL_AUX_OP_AMBIGUATE:
> + ps.RenderTargetFastClearEnable = true;
> + ps.RenderTargetResolveType = FAST_CLEAR_0;
> + break;
> +#endif
> #if GEN_GEN >= 9
>case ISL_AUX_OP_PARTIAL_RESOLVE:
> ps.RenderTargetResolveType = RESOLVE_PARTIAL;
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] radeon/vcn: fix poc for hevc encode
These 2 patches are:
Acked-by: Leo Liu
On 5/29/19 2:41 PM, boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang
>
> MaxPicOrderCntLsb should be at least 16 according to the spec,
> therefore add minimum value check.
>
> Also use poc value passed from st instead of calculation
> in slice header encoding.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
>
> V2: Fix typo
>
> V3: Use MAX2 macro instead of coding. Also MaxPicOrderCntLsb
> should be power of 2 according to spec.
>
> Signed-off-by: Boyuan Zhang
> ---
> src/gallium/drivers/radeon/radeon_vcn_enc.c | 3 ++-
> src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> index 8f9af73c66..3651d8a86b 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
> @@ -72,7 +72,8 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder
> *enc, struct pipe_pic
> enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
> enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
> enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
> - enc->enc_pic.max_poc = pic->seq.intra_period;
> + enc->enc_pic.max_poc =
> + MAX2(16, util_next_power_of_two(pic->seq.intra_period));
> enc->enc_pic.log2_max_poc = 0;
> for (int i = enc->enc_pic.max_poc; i != 0;
> enc->enc_pic.log2_max_poc++)
>i = (i >> 1);
> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> index 7f5b190934..3302ed7524 100644
> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
> @@ -988,7 +988,7 @@ static void radeon_enc_slice_header_hevc(struct
> radeon_encoder *enc)
> }
>
> if ((enc->enc_pic.nal_unit_type != 19) && (enc->enc_pic.nal_unit_type
> != 20)) {
> - radeon_enc_code_fixed_bits(enc, enc->enc_pic.frame_num %
> enc->enc_pic.max_poc, enc->enc_pic.log2_max_poc);
> + radeon_enc_code_fixed_bits(enc, enc->enc_pic.pic_order_cnt,
> enc->enc_pic.log2_max_poc);
> if (enc->enc_pic.picture_type == PIPE_H264_ENC_PICTURE_TYPE_P)
> radeon_enc_code_fixed_bits(enc, 0x1, 1);
> else {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
From: Boyuan Zhang
MaxPicOrderCntLsb should be at least 16 according to the spec,
therefore add minimum value check.
Also use poc value passed from st instead of calculation
in slice header encoding.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
Cc: mesa-sta...@lists.freedesktop.org
V2: Fix typo
V3: Use MAX2 macro instead of coding. Also MaxPicOrderCntLsb
should be power of 2 according to spec.
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_uvd_enc.c | 3 ++-
src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 3 +--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c
b/src/gallium/drivers/radeon/radeon_uvd_enc.c
index 521d08f304..3bceaccb70 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
@@ -73,7 +73,8 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
- enc->enc_pic.max_poc = pic->seq.intra_period;
+ enc->enc_pic.max_poc =
+ MAX2(16, util_next_power_of_two(pic->seq.intra_period));
enc->enc_pic.log2_max_poc = 0;
for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
i = (i >> 1);
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
index ddb219792a..8f0e0099e7 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
@@ -768,8 +768,7 @@ radeon_uvd_enc_slice_header_hevc(struct radeon_uvd_encoder
*enc)
if ((enc->enc_pic.nal_unit_type != 19)
&& (enc->enc_pic.nal_unit_type != 20)) {
radeon_uvd_enc_code_fixed_bits(enc,
- enc->enc_pic.frame_num %
- enc->enc_pic.max_poc,
+ enc->enc_pic.pic_order_cnt,
enc->enc_pic.log2_max_poc);
if (enc->enc_pic.picture_type == PIPE_H265_ENC_PICTURE_TYPE_P)
radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/vcn: fix poc for hevc encode
From: Boyuan Zhang
MaxPicOrderCntLsb should be at least 16 according to the spec,
therefore add minimum value check.
Also use poc value passed from st instead of calculation
in slice header encoding.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
Cc: mesa-sta...@lists.freedesktop.org
V2: Fix typo
V3: Use MAX2 macro instead of coding. Also MaxPicOrderCntLsb
should be power of 2 according to spec.
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vcn_enc.c | 3 ++-
src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index 8f9af73c66..3651d8a86b 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -72,7 +72,8 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder
*enc, struct pipe_pic
enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
- enc->enc_pic.max_poc = pic->seq.intra_period;
+ enc->enc_pic.max_poc =
+ MAX2(16, util_next_power_of_two(pic->seq.intra_period));
enc->enc_pic.log2_max_poc = 0;
for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
i = (i >> 1);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
index 7f5b190934..3302ed7524 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -988,7 +988,7 @@ static void radeon_enc_slice_header_hevc(struct
radeon_encoder *enc)
}
if ((enc->enc_pic.nal_unit_type != 19) && (enc->enc_pic.nal_unit_type
!= 20)) {
- radeon_enc_code_fixed_bits(enc, enc->enc_pic.frame_num %
enc->enc_pic.max_poc, enc->enc_pic.log2_max_poc);
+ radeon_enc_code_fixed_bits(enc, enc->enc_pic.pic_order_cnt,
enc->enc_pic.log2_max_poc);
if (enc->enc_pic.picture_type == PIPE_H264_ENC_PICTURE_TYPE_P)
radeon_enc_code_fixed_bits(enc, 0x1, 1);
else {
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37471] Website with information about maintainers/developers
https://bugs.freedesktop.org/show_bug.cgi?id=37471 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Adam Jackson --- https://gitlab.freedesktop.org/mesa/mesa/blob/master/REVIEWERS -- You are receiving this mail because: You are on the CC list 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] panfrost: Reload framebuffer contents if there's no clear
On Wed, 29 May 2019 at 17:37, Alyssa Rosenzweig wrote: > > > Have never tested those, tbh. Do you know if I should be able to test > > those with whatever is packaged for Debian? > > I don't think sway isn't packaged in testing yet (I think it's in > experimental)? mpv is definitely packaged; you can run it onto DRM as > > mpv --vo gpu --gpu-context=drm --drm-connector=1.eDP-1 [video > here] > > Pressing the "m" key should cause a "Mute: yes/no" to toggle on-screen, > overlayed on the video. It should not make the video itself go black. > (mpv does a flush in between with no clear.) > > It should not cause a crash from u_blitter recursion or anything ;) Some dEQP tests triggered that, but should be fine now. In any case, will test with mpv tomorrow. Cheers, Tomeu > > I have tested glmark2 on both Wayland and DRM, and we have deqp test > > runs on both Veyron and Kevin: > > > > https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323413 > > https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323414 > > Oh, wonderful! the functional.texture.wrap.* tests should be legitimately > fixed by this commit (they did a flush-no-clear pattern as well). Some > other parts of texture.* ought to be, but the balls in my court now :) > > The FBO stuff looks like noise since those are mostly all broken anyway. > > Not sure what to make of the shader bits -- possibly I regressed > something in the compiler upstream while CI was down. > > > Doesn't address it, but I haven't been able to find any failures due to > > this. > > Good to know, alright! :) > ___ > 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] panfrost: Reload framebuffer contents if there's no clear
> Have never tested those, tbh. Do you know if I should be able to test > those with whatever is packaged for Debian? I don't think sway isn't packaged in testing yet (I think it's in experimental)? mpv is definitely packaged; you can run it onto DRM as mpv --vo gpu --gpu-context=drm --drm-connector=1.eDP-1 [video here] Pressing the "m" key should cause a "Mute: yes/no" to toggle on-screen, overlayed on the video. It should not make the video itself go black. (mpv does a flush in between with no clear.) It should not cause a crash from u_blitter recursion or anything ;) > I have tested glmark2 on both Wayland and DRM, and we have deqp test > runs on both Veyron and Kevin: > > https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323413 > https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323414 Oh, wonderful! the functional.texture.wrap.* tests should be legitimately fixed by this commit (they did a flush-no-clear pattern as well). Some other parts of texture.* ought to be, but the balls in my court now :) The FBO stuff looks like noise since those are mostly all broken anyway. Not sure what to make of the shader bits -- possibly I regressed something in the compiler upstream while CI was down. > Doesn't address it, but I haven't been able to find any failures due to this. Good to know, alright! :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] panfrost: Reload framebuffer contents if there's no clear
On Wed, 29 May 2019 at 17:10, Alyssa Rosenzweig wrote: > > Does this address the issues with the previous version raised on IRC? In > particular: > > Does mpv work? (Including the on-screen display) > Does sway work? Have never tested those, tbh. Do you know if I should be able to test those with whatever is packaged for Debian? I have tested glmark2 on both Wayland and DRM, and we have deqp test runs on both Veyron and Kevin: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323413 https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/323414 There's quite some noise, caused by our CI infrastructure being flaky atm. Once things stabilize, I will check every discrepancy and update the list of expected failures. > I suspect this will also fix many tests in dEQP-GLES2, but that's on me; > as long as nothing *regresses* there, it's all good. > > > + if (!job->clear) > > + panfrost_draw_wallpaper(>base); > > Does the commit address setting/clearing job->clear? I remember this was > buggy (and I'm wondering if there might be erratic behaviour related..?) Doesn't address it, but I haven't been able to find any failures due to this. Cheers, Tomeu > ___ > 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] panfrost: Reload framebuffer contents if there's no clear
Does this address the issues with the previous version raised on IRC? In particular: Does mpv work? (Including the on-screen display) Does sway work? I suspect this will also fix many tests in dEQP-GLES2, but that's on me; as long as nothing *regresses* there, it's all good. > + if (!job->clear) > + panfrost_draw_wallpaper(>base); Does the commit address setting/clearing job->clear? I remember this was buggy (and I'm wondering if there might be erratic behaviour related..?) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Andrés Gómez García changed: What|Removed |Added CC||ago...@igalia.com, ||clayton.a.cr...@intel.com, ||kenn...@whitecape.org --- Comment #6 from Andrés Gómez García --- Clayton, in the MR the general feeling is that this shouldn't be a blocker for a release. It is not causing prevously passing tests to fail but enabling new ones which need to be fixed but this is not a regression. Can we drop the block and, so, the MR? -- 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 1/2] panfrost: Remove link stage for jobs
> -.job_index = 1 + (2 * ctx->draw_count), > +.job_index = 1, FWIW, the blob has this the "1 + (2*ctx->draw_count)" way for reasons I never figured out. -- Can't test right now, but if this is still working (passing tests/glmark/etc), then R-b as discussed on IRC :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 19.1.0-rc4
Hello, list. The fourth release candidate for Mesa 19.1.0 is now available. Remind that right now there are two bugs blocking the final release: #110302 - [bisected][regression] piglit egl-create-pbuffer-surface and egl-gl-colorspace regressions #110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration Chenglei Ren (1): anv/android: fix missing dependencies issue during parallel build Christian Gmeiner (1): etnaviv: use the correct uniform dirty bits Danylo Piliaiev (1): anv: Do not emulate texture swizzle for INPUT_ATTACHMENT, STORAGE_IMAGE Dave Airlie (1): Revert "mesa: unreference current winsys buffers when unbinding winsys buffers" Greg V (1): gallium: enable dmabuf on BSD as well Juan A. Suarez Romero (1): Update version to 19.1.0-rc4 Lionel Landwerlin (3): vulkan/overlay: fix timestamp query emission with no pipeline stats vulkan: fix build dependency issue with generated files anv: fix apply_pipeline_layout pass for arrays of YCbCr descriptors Marek Olšák (2): radeonsi: update buffer descriptors in all contexts after buffer invalidation radeonsi: fix a regression in si_rebind_buffer Philipp Zabel (1): etnaviv: fill missing offset in etna_resource_get_handle Qiang Yu (2): lima: fix lima_blit with non-zero level source resource lima: fix render to non-zero level texture Timothy Arceri (1): Revert "st/mesa: expose 0 shader binary formats for compat profiles for Qt" git tag: mesa-19.1.0-rc4 https://mesa.freedesktop.org/archive/mesa-19.1.0-rc4.tar.xz MD5: b95104cfa0edcd5877f3d58197e145bb mesa-19.1.0-rc4.tar.xz SHA1: 11203b0bfb44c77410795067f3ce8b6eed2afdae mesa-19.1.0-rc4.tar.xz SHA256: 3ca81ca19f4f76eae397e98a3e20772ae53d04cd8038370696fe4f9bd4ab489c mesa-19.1.0-rc4.tar.xz SHA512: 04cc5a537d803359b9eb3207f7b7ab1357126fe78ae0a0ba24df51d2fbbf4e0cf1815a60f99a10b33c822c08af0c84adef44849e73c883f5ce30fdae142c5b61 mesa-19.1.0-rc4.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-19.1.0-rc4.tar.xz.sig 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
[Mesa-dev] [PATCH] svga: Remove unnecessary check for the pre flush bit for setting vertex buffers
From: Charmaine Lee This fixes the missing rebind when the can_pre_flush bit is not set and the vertex buffers are the same as what have been sent. Cc: mesa-sta...@lists.freedesktop.org Reviewed-by: Neha Bhende Signed-off-by: Charmaine Lee Signed-off-by: Thomas Hellstrom --- src/gallium/drivers/svga/svga_draw.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/svga/svga_draw.c b/src/gallium/drivers/svga/svga_draw.c index 9e13ee8ce6d..b6c21a866fe 100644 --- a/src/gallium/drivers/svga/svga_draw.c +++ b/src/gallium/drivers/svga/svga_draw.c @@ -568,11 +568,11 @@ validate_vertex_buffers(struct svga_hwtnl *hwtnl) vbuffer_attrs[i].sid = 0; } - /* If we haven't yet emitted a drawing command or if any - * vertex buffer state is changing, issue that state now. + /* If any of the vertex buffer state has changed, issue + * the SetVertexBuffers command. Otherwise, we will just + * need to rebind the resources. */ - if (((hwtnl->cmd.swc->hints & SVGA_HINT_FLAG_CAN_PRE_FLUSH) == 0) || - vbuf_count != svga->state.hw_draw.num_vbuffers || + if (vbuf_count != svga->state.hw_draw.num_vbuffers || !vertex_buffers_equal(vbuf_count, vbuffer_attrs, vbuffers, -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/svga/drm: Fix 32-bit RPCI send message
From: Deepak Rawat
Depending on whether compiled with frame-pointer or not, the temporary
memory location used for the bp parameter in these macros are referenced
relative to the stack pointer or the frame pointer.
Hence we can never reference that parameter when we've modified either
the stack pointer or the frame pointer, because then the compiler would
generate an incorrect stack reference.
Fix this by pushing the temporary memory parameter on a known location on
the stack before modifying the stack- and frame pointers.
Also in case of failuire RPCI channel is not closed which lead to vmx
running out of channels.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmw_msg.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_msg.c
b/src/gallium/winsys/svga/drm/vmw_msg.c
index 8cce2241f36..3e8ed2a0fb5 100644
--- a/src/gallium/winsys/svga/drm/vmw_msg.c
+++ b/src/gallium/winsys/svga/drm/vmw_msg.c
@@ -177,17 +177,23 @@ typedef uint64_t VMW_REG;
typedef uint32_t VMW_REG;
-/* In the 32-bit version of this macro, we use "m" because there is no
- * more register left for bp
+/* In the 32-bit version of this macro, we store bp in a memory location
+ * because we've ran out of registers.
+ * Now we can't reference that memory location while we've modified
+ * %esp or %ebp, so we first push it on the stack, just before we push
+ * %ebp, and then when we need it we read it from the stack where we
+ * just pushed it.
*/
#define VMW_PORT_HB_OUT(cmd, in_cx, in_si, in_di, \
port_num, magic, bp, \
ax, bx, cx, dx, si, di) \
({\
- __asm__ volatile ("push %%ebp;"\
- "mov %12, %%ebp;" \
+ __asm__ volatile ("push %12;" \
+ "push %%ebp;" \
+ "mov 0x04(%%esp), %%ebp;" \
"rep outsb;"\
- "pop %%ebp;" : \
+ "pop %%ebp;"\
+ "add $0x04, %%esp;" : \
"=a"(ax), \
"=b"(bx), \
"=c"(cx), \
@@ -209,10 +215,12 @@ typedef uint32_t VMW_REG;
port_num, magic, bp, \
ax, bx, cx, dx, si, di) \
({\
- __asm__ volatile ("push %%ebp;"\
- "mov %12, %%ebp;" \
+ __asm__ volatile ("push %12;" \
+ "push %%ebp;" \
+ "mov 0x04(%%esp), %%ebp;" \
"rep insb;" \
- "pop %%ebp" : \
+ "pop %%ebp;"\
+ "add $0x04, %%esp;" : \
"=a"(ax), \
"=b"(bx), \
"=c"(cx), \
@@ -418,6 +426,7 @@ vmw_svga_winsys_host_log(struct svga_winsys_screen *sws,
const char *log)
struct rpc_channel channel;
char *msg;
int msg_len;
+ int ret;
#ifdef MSG_NOT_IMPLEMENTED
return;
@@ -435,12 +444,14 @@ vmw_svga_winsys_host_log(struct svga_winsys_screen *sws,
const char *log)
util_sprintf(msg, "log %s", log);
- if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
- vmw_send_msg(, msg) ||
- vmw_close_channel()) {
- debug_printf("Failed to send log\n");
+ if (!(ret = vmw_open_channel(, RPCI_PROTOCOL_NUM))) {
+ ret = vmw_send_msg(, msg);
+ vmw_close_channel();
}
+ if (ret)
+ debug_printf("Failed to send log\n");
+
FREE(msg);
return;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
Ok, that sounds like it makes sense but I'm not so deeply into this handling
anyway.
One more comment: Please use the MIN2 or MAX2 macro here instead of open coding
it.
Apart from that looks good to me,
Christian.
Am 29.05.2019 12:53 schrieb "Zhang, Boyuan" :
Yes, I agree that all interface defined value check should be done in state
tracker. However, this value is NOT defined by vaapi interface, so it's like a
radeon specific implementation based on the known values we got.
Regards,
Boyuan
-Original Message-
From: Christian König
Sent: May 28, 2019 3:27 AM
To: Zhang, Boyuan ; mesa-dev@lists.freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
It would be better to have those checks in the state tracker than in the
backend code.
Christian.
Am 27.05.19 um 20:41 schrieb boyuan.zh...@amd.com:
> From: Boyuan Zhang
>
> MaxPicOrderCntLsb should be at 16 according to the spec, therefore add
> minimum value check.
>
> Also use poc value passed from st instead of calculation in slice
> header encoding.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
>
> Signed-off-by: Boyuan Zhang
> ---
> src/gallium/drivers/radeon/radeon_uvd_enc.c | 3 ++-
> src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 3 +--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c
> b/src/gallium/drivers/radeon/radeon_uvd_enc.c
> index 521d08f304..9256e43a08 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
> @@ -73,7 +73,8 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
> enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
> enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
> enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
> - enc->enc_pic.max_poc = pic->seq.intra_period;
> + enc->enc_pic.max_poc =
> + (pic->seq.intra_period >= 16) ? pic->seq.intra_period : 16;
> enc->enc_pic.log2_max_poc = 0;
> for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
> i = (i >> 1);
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> index ddb219792a..8f0e0099e7 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> @@ -768,8 +768,7 @@ radeon_uvd_enc_slice_header_hevc(struct
> radeon_uvd_encoder *enc)
> if ((enc->enc_pic.nal_unit_type != 19)
> && (enc->enc_pic.nal_unit_type != 20)) {
> radeon_uvd_enc_code_fixed_bits(enc,
> - enc->enc_pic.frame_num %
> - enc->enc_pic.max_poc,
> + enc->enc_pic.pic_order_cnt,
>enc->enc_pic.log2_max_poc);
> if (enc->enc_pic.picture_type == PIPE_H265_ENC_PICTURE_TYPE_P)
>radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
Yes, I agree that all interface defined value check should be done in state
tracker. However, this value is NOT defined by vaapi interface, so it's like a
radeon specific implementation based on the known values we got.
Regards,
Boyuan
-Original Message-
From: Christian König
Sent: May 28, 2019 3:27 AM
To: Zhang, Boyuan ; mesa-dev@lists.freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
It would be better to have those checks in the state tracker than in the
backend code.
Christian.
Am 27.05.19 um 20:41 schrieb boyuan.zh...@amd.com:
> From: Boyuan Zhang
>
> MaxPicOrderCntLsb should be at 16 according to the spec, therefore add
> minimum value check.
>
> Also use poc value passed from st instead of calculation in slice
> header encoding.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
>
> Signed-off-by: Boyuan Zhang
> ---
> src/gallium/drivers/radeon/radeon_uvd_enc.c | 3 ++-
> src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 3 +--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c
> b/src/gallium/drivers/radeon/radeon_uvd_enc.c
> index 521d08f304..9256e43a08 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
> @@ -73,7 +73,8 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
> enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
> enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
> enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
> - enc->enc_pic.max_poc = pic->seq.intra_period;
> + enc->enc_pic.max_poc =
> + (pic->seq.intra_period >= 16) ? pic->seq.intra_period : 16;
> enc->enc_pic.log2_max_poc = 0;
> for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
> i = (i >> 1);
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> index ddb219792a..8f0e0099e7 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> @@ -768,8 +768,7 @@ radeon_uvd_enc_slice_header_hevc(struct
> radeon_uvd_encoder *enc)
> if ((enc->enc_pic.nal_unit_type != 19)
> && (enc->enc_pic.nal_unit_type != 20)) {
> radeon_uvd_enc_code_fixed_bits(enc,
> - enc->enc_pic.frame_num %
> - enc->enc_pic.max_poc,
> + enc->enc_pic.pic_order_cnt,
>enc->enc_pic.log2_max_poc);
> if (enc->enc_pic.picture_type == PIPE_H265_ENC_PICTURE_TYPE_P)
>radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH libdrm] etnaviv: drop etna_bo_from_handle symbol
On Wed, 2019-05-29 at 12:08 +0200, Lucas Stach wrote: > There is no implementation and also no users, so there is no point > in keeping it in the API. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel This makes https://patchwork.kernel.org/patch/9912089/ obsolete. regards Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm] etnaviv: drop etna_bo_from_handle symbol
There is no implementation and also no users, so there is no point in keeping it in the API. Signed-off-by: Lucas Stach --- etnaviv/etnaviv-symbol-check | 1 - etnaviv/etnaviv_drmif.h | 2 -- 2 files changed, 3 deletions(-) diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check index 0e2030e4672f..965870236111 100755 --- a/etnaviv/etnaviv-symbol-check +++ b/etnaviv/etnaviv-symbol-check @@ -23,7 +23,6 @@ etna_pipe_del etna_pipe_wait etna_pipe_wait_ns etna_bo_new -etna_bo_from_handle etna_bo_from_name etna_bo_from_dmabuf etna_bo_ref diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h index 87704acd3469..198bb429ada2 100644 --- a/etnaviv/etnaviv_drmif.h +++ b/etnaviv/etnaviv_drmif.h @@ -112,8 +112,6 @@ int etna_pipe_wait_ns(struct etna_pipe *pipe, uint32_t timestamp, uint64_t ns); struct etna_bo *etna_bo_new(struct etna_device *dev, uint32_t size, uint32_t flags); -struct etna_bo *etna_bo_from_handle(struct etna_device *dev, - uint32_t handle, uint32_t size); struct etna_bo *etna_bo_from_name(struct etna_device *dev, uint32_t name); struct etna_bo *etna_bo_from_dmabuf(struct etna_device *dev, int fd); struct etna_bo *etna_bo_ref(struct etna_bo *bo); -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] panfrost: Reload framebuffer contents if there's no clear
If by flush time the client hasn't submitted a clear, add jobs for
reloading the framebuffer contents as the first draw in the frame.
This is required by programs such as Weston which don't do clears and
rely on the previous contents of the framebuffer being there.
Reloading the whole framebuffer on every frame without regards to what
is needed or what is going to be covered is very inefficient, but future
work will introduce support for damage regions and partial updates so we
know what needs to be actually reloaded.
Fixes quite a few tests in dEQP-EGL.functional.buffer_age.*.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/meson.build | 1 -
src/gallium/drivers/panfrost/pan_context.c | 91 +-
src/gallium/drivers/panfrost/pan_wallpaper.c | 274 ---
src/gallium/drivers/panfrost/pan_wallpaper.h | 33 ---
4 files changed, 88 insertions(+), 311 deletions(-)
delete mode 100644 src/gallium/drivers/panfrost/pan_wallpaper.c
delete mode 100644 src/gallium/drivers/panfrost/pan_wallpaper.h
diff --git a/src/gallium/drivers/panfrost/meson.build
b/src/gallium/drivers/panfrost/meson.build
index fb92954854a1..e81094fe3090 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -48,7 +48,6 @@ files_panfrost = files(
'pan_swizzle.c',
'pan_blending.c',
'pan_blend_shaders.c',
- 'pan_wallpaper.c',
'pan_pretty_print.c',
'pan_fragment.c',
'pan_sfbd.c',
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 337faaca0f73..b15cf5f38a49 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -46,7 +46,6 @@
#include "pan_blending.h"
#include "pan_blend_shaders.h"
#include "pan_util.h"
-#include "pan_wallpaper.h"
static int performance_counter_number = 0;
extern const char *pan_counters_base;
@@ -1373,6 +1372,87 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool
flush_immediate,
#endif
}
+static void
+panfrost_draw_wallpaper(struct pipe_context *pipe)
+{
+ struct panfrost_context *ctx = pan_context(pipe);
+ struct pipe_blit_info binfo = { };
+
+ /* Nothing to reload? */
+ if (ctx->pipe_framebuffer.cbufs[0] == NULL)
+ return;
+
+util_blitter_save_vertex_buffer_slot(ctx->blitter,
ctx->vertex_buffers);
+util_blitter_save_vertex_elements(ctx->blitter, ctx->vertex);
+util_blitter_save_vertex_shader(ctx->blitter, ctx->vs);
+util_blitter_save_rasterizer(ctx->blitter, ctx->rasterizer);
+util_blitter_save_viewport(ctx->blitter, >pipe_viewport);
+util_blitter_save_scissor(ctx->blitter, >scissor);
+util_blitter_save_fragment_shader(ctx->blitter, ctx->fs);
+util_blitter_save_blend(ctx->blitter, ctx->blend);
+util_blitter_save_depth_stencil_alpha(ctx->blitter,
ctx->depth_stencil);
+util_blitter_save_stencil_ref(ctx->blitter, >stencil_ref);
+ util_blitter_save_so_targets(ctx->blitter, 0, NULL);
+
+ /* For later */
+//util_blitter_save_sample_mask(ctx->blitter, vc4->sample_mask);
+
+util_blitter_save_framebuffer(ctx->blitter, >pipe_framebuffer);
+util_blitter_save_fragment_sampler_states(ctx->blitter,
+
ctx->sampler_count[PIPE_SHADER_FRAGMENT],
+ (void
**)(>samplers[PIPE_SHADER_FRAGMENT]));
+util_blitter_save_fragment_sampler_views(ctx->blitter,
+
ctx->sampler_view_count[PIPE_SHADER_FRAGMENT],
+(struct pipe_sampler_view
**)>sampler_views[PIPE_SHADER_FRAGMENT]);
+
+
+ binfo.src.resource = binfo.dst.resource =
ctx->pipe_framebuffer.cbufs[0]->texture;
+ binfo.src.level = binfo.dst.level = 0;
+ binfo.src.box.x = binfo.dst.box.x = 0;
+ binfo.src.box.y = binfo.dst.box.y = 0;
+ binfo.src.box.width = binfo.dst.box.width = ctx->pipe_framebuffer.width;
+ binfo.src.box.height = binfo.dst.box.height =
ctx->pipe_framebuffer.height;
+
+ /* This avoids an assert due to missing nir_texop_txb support */
+ //binfo.src.box.depth = binfo.dst.box.depth = 1;
+
+ binfo.src.format = binfo.dst.format =
ctx->pipe_framebuffer.cbufs[0]->texture->format;
+
+ assert(ctx->pipe_framebuffer.nr_cbufs == 1);
+ binfo.mask = PIPE_MASK_RGBA;
+ binfo.filter = PIPE_TEX_FILTER_LINEAR;
+ binfo.scissor_enable = FALSE;
+
+ util_blitter_blit(ctx->blitter, );
+
+/* We are flushing all queued draws and we know that no more jobs will
+ * be added until the next frame.
+ * We also know that the last jobs are the wallpaper jobs, and they
+ * need to be linked so they execute right after the set_value job.
+ */
+
+/* set_value job to wallpaper vertex job */
+
[Mesa-dev] [PATCH 1/2] panfrost: Remove link stage for jobs
And instead, link them as they are added.
Makes things a bit clearer and prepares future work such as FB reload
jobs.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 120 +
src/gallium/drivers/panfrost/pan_context.h | 2 +-
2 files changed, 54 insertions(+), 68 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 80623df251d2..337faaca0f73 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -384,6 +384,11 @@ panfrost_invalidate_frame(struct panfrost_context *ctx)
/* XXX */
ctx->dirty |= PAN_DIRTY_SAMPLERS | PAN_DIRTY_TEXTURES;
+
+/* Reset job counters */
+ctx->draw_count = 0;
+ctx->vertex_job_count = 0;
+ctx->tiler_job_count = 0;
}
/* In practice, every field of these payloads should be configurable
@@ -610,6 +615,15 @@ panfrost_default_shader_backend(struct panfrost_context
*ctx)
memcpy(>fragment_shader_core, , sizeof(shader));
}
+static void
+panfrost_link_job_pair(struct mali_job_descriptor_header *first, mali_ptr next)
+{
+if (first->job_descriptor_size)
+first->next_job_64 = (u64) (uintptr_t) next;
+else
+first->next_job_32 = (u32) (uintptr_t) next;
+}
+
/* Generates a vertex/tiler job. This is, in some sense, the heart of the
* graphics command stream. It should be called once per draw, accordding to
* presentations. Set is_tiler for "tiler" jobs (fragment shader jobs, but in
@@ -617,10 +631,10 @@ panfrost_default_shader_backend(struct panfrost_context
*ctx)
* vertex jobs. */
struct panfrost_transfer
-panfrost_vertex_tiler_job(struct panfrost_context *ctx, bool is_tiler, bool
is_elided_tiler)
+panfrost_vertex_tiler_job(struct panfrost_context *ctx, bool is_tiler)
{
-/* Each draw call corresponds to two jobs, and we want to offset to
leave room for the set-value job */
-int draw_job_index = 1 + (2 * ctx->draw_count);
+/* Each draw call corresponds to two jobs, and the set-value job is
first */
+int draw_job_index = 1 + (2 * ctx->draw_count) + 1;
struct mali_job_descriptor_header job = {
.job_type = is_tiler ? JOB_TYPE_TILER : JOB_TYPE_VERTEX,
@@ -630,19 +644,6 @@ panfrost_vertex_tiler_job(struct panfrost_context *ctx,
bool is_tiler, bool is_e
#endif
};
-/* Only non-elided tiler jobs have dependencies which are known at
this point */
-
-if (is_tiler && !is_elided_tiler) {
-/* Tiler jobs depend on vertex jobs */
-
-job.job_dependency_index_1 = draw_job_index;
-
-/* Tiler jobs also depend on the previous tiler job */
-
-if (ctx->draw_count)
-job.job_dependency_index_2 = draw_job_index - 1;
-}
-
struct midgard_payload_vertex_tiler *payload = is_tiler ?
>payload_tiler : >payload_vertex;
/* There's some padding hacks on 32-bit */
@@ -653,6 +654,36 @@ panfrost_vertex_tiler_job(struct panfrost_context *ctx,
bool is_tiler, bool is_e
int offset = 4;
#endif
struct panfrost_transfer transfer = panfrost_allocate_transient(ctx,
sizeof(job) + sizeof(*payload));
+
+if (is_tiler) {
+/* Tiler jobs depend on vertex jobs */
+
+job.job_dependency_index_1 = draw_job_index;
+
+/* Tiler jobs also depend on the previous tiler job */
+
+if (ctx->draw_count) {
+job.job_dependency_index_2 = draw_job_index - 1;
+/* Previous tiler job points to this tiler job */
+
panfrost_link_job_pair(ctx->u_tiler_jobs[ctx->draw_count - 1], transfer.gpu);
+} else {
+/* The only vertex job so far points to first tiler
job */
+panfrost_link_job_pair(ctx->u_vertex_jobs[0],
transfer.gpu);
+}
+} else {
+if (ctx->draw_count) {
+/* Previous vertex job points to this vertex job */
+
panfrost_link_job_pair(ctx->u_vertex_jobs[ctx->draw_count - 1], transfer.gpu);
+
+/* Last vertex job points to first tiler job */
+panfrost_link_job_pair(, ctx->tiler_jobs[0]);
+} else {
+/* Have the first vertex job depend on the set value
job */
+job.job_dependency_index_1 =
ctx->u_set_value_job->job_index;
+panfrost_link_job_pair(ctx->u_set_value_job,
transfer.gpu);
+}
+}
+
memcpy(transfer.cpu, , sizeof(job));
memcpy(transfer.cpu + sizeof(job) - offset, payload, sizeof(*payload));
return transfer;
@@ -667,7 +698,7 @@ panfrost_set_value_job(struct panfrost_context
[Mesa-dev] [Bug 110348] radv: Resolve attachments do not work if view format differs from image format
https://bugs.freedesktop.org/show_bug.cgi?id=110348 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Samuel Pitoiset --- No need to ask for a spec clarification actually. I think it's pretty clear that we should use the view formats for subpass resolves. Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=017170a7859ab1a5c82e8cb5991b2bbb83d70c10 -- 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 1/2] radv: always use view format when performing subpass resolves
On 5/29/19 2:00 AM, Bas Nieuwenhuizen wrote:
Don't you also need to change it in the pipeline selection? (e.g. your
newly added radv_get_resolve_pipeline())
Good catch.
I will update radv_get_resolve_pipeline() and push, thanks!
Otherwise r-b for the eries.
On Tue, May 28, 2019 at 11:02 AM Samuel Pitoiset
wrote:
It makes sense to use the image view formats when resolving
inside subpasses, while we have to use the image formats for
normal resolves.
Original patch by Philip Rebohle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110348
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta.h| 2 ++
src/amd/vulkan/radv_meta_resolve.c| 9 ++---
src/amd/vulkan/radv_meta_resolve_cs.c | 8 ++--
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 0bd75d6c207..4a7c37be9b3 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -183,8 +183,10 @@ void radv_expand_fmask_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *src_image,
+VkFormat src_format,
VkImageLayout src_image_layout,
struct radv_image *dest_image,
+VkFormat dest_format,
VkImageLayout dest_image_layout,
uint32_t region_count,
const VkImageResolve *regions);
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 1544513a9bc..b4551a98637 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -439,8 +439,10 @@ void radv_CmdResolveImage(
if (resolve_method == RESOLVE_COMPUTE) {
radv_meta_resolve_compute_image(cmd_buffer,
src_image,
+ src_image->vk_format,
src_image_layout,
dest_image,
+ dest_image->vk_format,
dest_image_layout,
region_count, regions);
return;
@@ -658,7 +660,8 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
if (dest_att.attachment == VK_ATTACHMENT_UNUSED)
continue;
- struct radv_image *dst_img =
cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
+ struct radv_image_view *dest_iview =
cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment;
+ struct radv_image *dst_img = dest_iview->image;
if (radv_image_has_dcc(dst_img)) {
radv_initialize_dcc(cmd_buffer, dst_img, 0x);
@@ -673,14 +676,14 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
radv_cmd_buffer_set_subpass(cmd_buffer, _subpass);
- VkResult ret = build_resolve_pipeline(cmd_buffer->device,
radv_format_meta_fs_key(dst_img->vk_format));
+ VkResult ret = build_resolve_pipeline(cmd_buffer->device,
radv_format_meta_fs_key(dest_iview->vk_format));
if (ret != VK_SUCCESS) {
cmd_buffer->record_result = ret;
continue;
}
emit_resolve(cmd_buffer,
-dst_img->vk_format,
+dest_iview->vk_format,
&(VkOffset2D) { 0, 0 },
&(VkExtent2D) { fb->width, fb->height });
}
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
b/src/amd/vulkan/radv_meta_resolve_cs.c
index 67df4800023..506e4139e93 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -413,8 +413,10 @@ emit_resolve(struct radv_cmd_buffer *cmd_buffer,
void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *src_image,
+VkFormat src_format,
VkImageLayout src_image_layout,
struct radv_image *dest_image,
+VkFormat dest_format,
VkImageLayout dest_image_layout,
uint32_t region_count,
const VkImageResolve *regions)
@@ -460,7 +462,7 @@ void radv_meta_resolve_compute_image(struct radv_cmd_buffer
