Re: [Mesa-dev] [PATCH v2 1/2] etnaviv: enable full overwrite in a few more cases
Am Mi., 19. Dez. 2018 um 16:27 Uhr schrieb Lucas Stach : > > Take into account the render target format when checking if the color > mask affects all channels of the RT. This allows to enable full > override in a few cases where a non-alpha format is used. > > Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner > --- > v2: clarify comment > --- > src/gallium/drivers/etnaviv/etnaviv_blend.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_blend.c > b/src/gallium/drivers/etnaviv/etnaviv_blend.c > index 0e2299a50b30..061c9af5247f 100644 > --- a/src/gallium/drivers/etnaviv/etnaviv_blend.c > +++ b/src/gallium/drivers/etnaviv/etnaviv_blend.c > @@ -114,6 +114,7 @@ etna_update_blend(struct etna_context *ctx) > struct pipe_blend_state *pblend = ctx->blend; > struct etna_blend_state *blend = etna_blend_state(pblend); > const struct pipe_rt_blend_state *rt0 = &pblend->rt[0]; > + const struct util_format_description *desc; > uint32_t colormask; > > if (pfb->cbufs[0] && > @@ -128,11 +129,13 @@ etna_update_blend(struct etna_context *ctx) > } > > /* If the complete render target is written, set full_overwrite: > -* - The color mask is > -* - No blending is used > +* - The color mask covers all channels of the render target > +* - No blending or logicop is used > */ > - bool full_overwrite = ((rt0->colormask == 0xf) && blend->fo_allowed) || > - !pfb->cbufs[0]; > + if (pfb->cbufs[0]) > + desc = util_format_description(pfb->cbufs[0]->format); > + bool full_overwrite = !pfb->cbufs[0] || ((blend->fo_allowed && > + util_format_colormask_full(desc, colormask))); > blend->PE_COLOR_FORMAT = > VIVS_PE_COLOR_FORMAT_COMPONENTS(colormask) | > COND(full_overwrite, VIVS_PE_COLOR_FORMAT_OVERWRITE); > -- > 2.19.1 > > ___ > etnaviv mailing list > etna...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/etnaviv -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] etnaviv: annotate variables only used in debug build
Am Mi., 19. Dez. 2018 um 16:27 Uhr schrieb Lucas Stach :
>
> Some of the status variables in the compiler are only used in asserts
> and thus may be unused in release builds. Annotate them accordingly
> to avoid 'unused but set' warnings from the compiler.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> v2: get rid of superfluous variable initialization
> ---
> src/gallium/drivers/etnaviv/etnaviv_compiler.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> index bbc61a59fc67..ceca5b8af997 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
> @@ -477,8 +477,7 @@ static void
> etna_compile_parse_declarations(struct etna_compile *c)
> {
> struct tgsi_parse_context ctx = { };
> - unsigned status = TGSI_PARSE_OK;
> - status = tgsi_parse_init(&ctx, c->tokens);
> + MAYBE_UNUSED unsigned status = tgsi_parse_init(&ctx, c->tokens);
> assert(status == TGSI_PARSE_OK);
>
> while (!tgsi_parse_end_of_tokens(&ctx)) {
> @@ -530,8 +529,7 @@ static void
> etna_compile_pass_check_usage(struct etna_compile *c)
> {
> struct tgsi_parse_context ctx = { };
> - unsigned status = TGSI_PARSE_OK;
> - status = tgsi_parse_init(&ctx, c->tokens);
> + MAYBE_UNUSED unsigned status = tgsi_parse_init(&ctx, c->tokens);
> assert(status == TGSI_PARSE_OK);
>
> for (int idx = 0; idx < c->total_decls; ++idx) {
> @@ -662,8 +660,7 @@ etna_compile_pass_optimize_outputs(struct etna_compile *c)
> {
> struct tgsi_parse_context ctx = { };
> int inst_idx = 0;
> - unsigned status = TGSI_PARSE_OK;
> - status = tgsi_parse_init(&ctx, c->tokens);
> + MAYBE_UNUSED unsigned status = tgsi_parse_init(&ctx, c->tokens);
> assert(status == TGSI_PARSE_OK);
>
> while (!tgsi_parse_end_of_tokens(&ctx)) {
> @@ -1812,7 +1809,7 @@ static void
> etna_compile_pass_generate_code(struct etna_compile *c)
> {
> struct tgsi_parse_context ctx = { };
> - unsigned status = tgsi_parse_init(&ctx, c->tokens);
> + MAYBE_UNUSED unsigned status = tgsi_parse_init(&ctx, c->tokens);
> assert(status == TGSI_PARSE_OK);
>
> int inst_idx = 0;
> --
> 2.19.1
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] etnaviv: implement check_resource_capability
Am Di., 18. Dez. 2018 um 19:09 Uhr schrieb Lucas Stach :
>
> We try to avoid sharing all resources with KMS side of renderonly, as this
> adds some overhead that isn't really needed for most resources. If
> someone tries to validate a resource for scanout, this is a good indication
> that the sharing with the KMS side is actually needed.
>
> Signed-off-by: Lucas Stach
> ---
> .../drivers/etnaviv/etnaviv_resource.c| 22 +++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index c00912880309..cd846e3ae36e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -624,6 +624,27 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
> }
> }
>
> +static bool
> +etna_check_resource_capability(struct pipe_screen *pscreen,
> + struct pipe_resource *prsc,
> + unsigned bind)
> +{
> + struct etna_screen *screen = etna_screen(pscreen);
> + struct etna_resource *rsc = etna_resource(prsc);
> +
> + if ((bind & PIPE_BIND_LINEAR) && rsc->layout != ETNA_LAYOUT_LINEAR)
> + return false;
> +
> + if ((bind & PIPE_BIND_SCANOUT) && !rsc->scanout) {
> + rsc->scanout = renderonly_create_gpu_import_for_resource(prsc,
> screen->ro,
> + NULL);
Can you explain me why the
renderonly_create_gpu_import_for_resource(..) call ends up here? Are
there really any cases where !rsc->scanout? I looked at the relevant
code parts and I have the feeling
the renderonly_create_gpu_import_for_resource(..) call happens much
earlier in the call chain. I could be
wrong as I am running out of coffee right now :)
> + if (!rsc->scanout)
> + return false;
> + }
> +
> + return true;
> +}
> +
> void
> etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
> enum etna_resource_status status)
> @@ -667,4 +688,5 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
> pscreen->resource_get_handle = etna_resource_get_handle;
> pscreen->resource_changed = etna_resource_changed;
> pscreen->resource_destroy = etna_resource_destroy;
> + pscreen->check_resource_capability = etna_check_resource_capability;
> }
> --
> 2.19.1
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 100960] Special block from Minecraft mod rendered out of place
https://bugs.freedesktop.org/show_bug.cgi?id=100960 Sergii Romantsov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- 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
