[Mesa-dev] boolean usage in gallium
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] [Bug 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 --- Comment #1 from Bas Nieuwenhuizen --- Forgot a hunk somehow apparently ... https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1205 should fix this. -- 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] What does WIP really mean in an MR?
I had interpreted it as literally the "block the gitlab merge button" option, ie. "I want to get feedback but it is not ready to merge and I'll drop the WIP tag when I think it is".. (comments inline) On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick wrote: > > After a conversation yesterday with a couple of the other Intel devs, > I've come to the conclusion that *everyone* interprets WIP to mean > something different. I heard no less than four interpretations. > > * This series is good. It hasn't been reviewed, so don't click "merge." isn't that the point of a MR.. doesn't seem like a reason for "WIP" > * This series has some sketchy bits. It probably isn't ready for review > unless you've been tagged for design feedback. I guess I'd also use WIP for "I want some early feedback, but it isn't ready yet".. but in this case I'd also poke people who I wanted to look at it > * This series has been reviewed. Incorporation of detailed feedback is > in progress, but it's going to take some time. I suppose also a case for "WIP".. > * This series is good, but there are some questionable patches at the end. I guess in this case, I'd reform things into multiple MR's, one with the parts ready to go, and one w/ the remaining WIP bits BR, -R > Due to this lack of common understanding, we discovered at least one MR > that was ready to go but had been ignored for months. :( This makes me > wonder if other MRs have similarly languished for no good reason. > > Can we formulate some guidelines for how people should apply WIP to > their MRs and how people should interpret WIP when they see it on an MR? > ___ > 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] What does WIP really mean in an MR?
After a conversation yesterday with a couple of the other Intel devs, I've come to the conclusion that *everyone* interprets WIP to mean something different. I heard no less than four interpretations. * This series is good. It hasn't been reviewed, so don't click "merge." * This series has some sketchy bits. It probably isn't ready for review unless you've been tagged for design feedback. * This series has been reviewed. Incorporation of detailed feedback is in progress, but it's going to take some time. * This series is good, but there are some questionable patches at the end. Due to this lack of common understanding, we discovered at least one MR that was ready to go but had been ignored for months. :( This makes me wonder if other MRs have similarly languished for no good reason. Can we formulate some guidelines for how people should apply WIP to their MRs and how people should interpret WIP when they see it on an MR? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258 --- Comment #12 from n3rdopolis --- Dang, doesn't work, even with GBM_ALWAYS_SOFTWARE EGL_NOT_INITIALIZED... -- 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] [PATCH v3] panfrost: Rewrite u-interleaving code
Rather than using a magic lookup table with no explanations, let's add
liberal comments to the code to explain what this tiling scheme is and
how to encode/decode it efficiently.
It's not so mysterious after all -- just reordering bits with some XORs
thrown in.
v2: Correct copyright identifier. Fix spelling error. Switch space_4 to
a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
generic rather than split up unaligned writes.
v3: Correct stride order (fixes crash loading). Correct coordinate
system mishap.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Vasily Khoruzhick
Cc: Andreas Baierl
Cc: Erico Nunes
---
src/panfrost/shared/pan_tiling.c | 290 ---
1 file changed, 189 insertions(+), 101 deletions(-)
diff --git a/src/panfrost/shared/pan_tiling.c b/src/panfrost/shared/pan_tiling.c
index 413cd89420b..08c9561b2ef 100644
--- a/src/panfrost/shared/pan_tiling.c
+++ b/src/panfrost/shared/pan_tiling.c
@@ -2,6 +2,7 @@
* Copyright (c) 2011-2013 Luc Verhaegen
* Copyright (c) 2018 Alyssa Rosenzweig
* Copyright (c) 2018 Vasily Khoruzhick
+ * Copyright (c) 2019 Collabora, Ltd.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -24,129 +25,212 @@
*
*/
+#include
#include "pan_tiling.h"
-uint32_t space_filler[16][16] = {
- { 0, 1, 4, 5, 16, 17, 20, 21, 64, 65, 68, 69, 80, 81, 84,
85, },
- { 3, 2, 7, 6, 19, 18, 23, 22, 67, 66, 71, 70, 83, 82, 87,
86, },
- { 12, 13, 8, 9, 28, 29, 24, 25, 76, 77, 72, 73, 92, 93, 88,
89, },
- { 15, 14, 11, 10, 31, 30, 27, 26, 79, 78, 75, 74, 95, 94, 91,
90, },
- { 48, 49, 52, 53, 32, 33, 36, 37, 112, 113, 116, 117, 96, 97,
100, 101, },
- { 51, 50, 55, 54, 35, 34, 39, 38, 115, 114, 119, 118, 99, 98,
103, 102, },
- { 60, 61, 56, 57, 44, 45, 40, 41, 124, 125, 120, 121, 108, 109,
104, 105, },
- { 63, 62, 59, 58, 47, 46, 43, 42, 127, 126, 123, 122, 111, 110,
107, 106, },
- { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145,
148, 149, },
- { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146,
151, 150, },
- { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157,
152, 153, },
- { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158,
155, 154, },
- { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161,
164, 165, },
- { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162,
167, 166, },
- { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173,
168, 169, },
- { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174,
171, 170, },
+/* This file implements software encode/decode of the tiling format used for
+ * textures and framebuffers primarily on Utgard GPUs. Names for this format
+ * include "Utgard-style tiling", "(Mali) swizzled textures", and
+ * "U-interleaved" (the former two names being used in the community
+ * Lima/Panfrost drivers; the latter name used internally at Arm).
+ * Conceptually, like any tiling scheme, the pixel reordering attempts to 2D
+ * spatial locality, to improve cache locality in both horizontal and vertical
+ * directions.
+ *
+ * This format is tiled: first, the image dimensions must be aligned to 16
+ * pixels in each axis. Once aligned, the image is divided into 16x16 tiles.
+ * This size harmonizes with other properties of the GPU; on Midgard,
+ * framebuffer tiles are logically 16x16 (this is the tile size used in
+ * Transaction Elimination and the minimum tile size used in Hierarchical
+ * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
+ * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
+ * size.
+ *
+ * Within each 16x16 block, the bits are reordered according to this pattern:
+ *
+ * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
+ *
+ * Basically, interleaving the X and Y bits, with XORs thrown in for every
+ * adjacent bit pair.
+ *
+ * This is cheap to implement both encode/decode in both hardware and software.
+ * In hardware, lines are simply rerouted to reorder and some XOR gates are
+ * thrown in. Software has to be a bit more clever.
+ *
+ * In software, the trick is to divide the pattern into two lines:
+ *
+ *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
+ * ^ | 0 | x3 | 0 | x2 | 0 | x1 | 0 | x0 |
+ *
+ * That is, duplicate the bits of the Y and space out the bits of the X. The
+ * top line is a function only of Y, so it can be calculated once per row and
+ * stored in a register. The bottom line is simply X with the bits spaced out.
+ * Spacing out the X is easy enough with a LUT, or by subtracting+ANDing the
+ * mask pattern (abusing carry bits).
+ *
+ * This format is also supported on Midgard GPUs, where it
Re: [Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code
> LGTM however I haven't tested it.
I have; there are some regressions I need to deal with. One of them was
silly (switching src_stride/dst_stride argument order in the load call).
The others are either CI fails or legitimate bugs.
Regardless, I won't push until it's green on our side :)
>
> +CC: Erico and Andreas
>
> Erico, Andreas could you test this change? I'm away from my board till July
> 2nd.
>
> Reviewed-by: Vasily Khoruzhick
>
>
> > ---
> > src/panfrost/shared/pan_tiling.c | 290 ---
> > 1 file changed, 189 insertions(+), 101 deletions(-)
> >
> > diff --git a/src/panfrost/shared/pan_tiling.c
> > b/src/panfrost/shared/pan_tiling.c
> > index 413cd89420b..c8b09887037 100644
> > --- a/src/panfrost/shared/pan_tiling.c
> > +++ b/src/panfrost/shared/pan_tiling.c
> > @@ -2,6 +2,7 @@
> > * Copyright (c) 2011-2013 Luc Verhaegen
> > * Copyright (c) 2018 Alyssa Rosenzweig
> > * Copyright (c) 2018 Vasily Khoruzhick
> > + * Copyright (c) 2019 Collabora, Ltd.
> > *
> > * Permission is hereby granted, free of charge, to any person obtaining a
> > * copy of this software and associated documentation files (the
> > "Software"),
> > @@ -24,129 +25,212 @@
> > *
> > */
> >
> > +#include
> > #include "pan_tiling.h"
> >
> > -uint32_t space_filler[16][16] = {
> > - { 0, 1, 4, 5, 16, 17, 20, 21, 64, 65, 68, 69, 80, 81,
> > 84, 85, },
> > - { 3, 2, 7, 6, 19, 18, 23, 22, 67, 66, 71, 70, 83, 82,
> > 87, 86, },
> > - { 12, 13, 8, 9, 28, 29, 24, 25, 76, 77, 72, 73, 92, 93,
> > 88, 89, },
> > - { 15, 14, 11, 10, 31, 30, 27, 26, 79, 78, 75, 74, 95, 94,
> > 91, 90, },
> > - { 48, 49, 52, 53, 32, 33, 36, 37, 112, 113, 116, 117, 96, 97,
> > 100, 101, },
> > - { 51, 50, 55, 54, 35, 34, 39, 38, 115, 114, 119, 118, 99, 98,
> > 103, 102, },
> > - { 60, 61, 56, 57, 44, 45, 40, 41, 124, 125, 120, 121, 108, 109,
> > 104, 105, },
> > - { 63, 62, 59, 58, 47, 46, 43, 42, 127, 126, 123, 122, 111, 110,
> > 107, 106, },
> > - { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145,
> > 148, 149, },
> > - { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146,
> > 151, 150, },
> > - { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157,
> > 152, 153, },
> > - { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158,
> > 155, 154, },
> > - { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161,
> > 164, 165, },
> > - { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162,
> > 167, 166, },
> > - { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173,
> > 168, 169, },
> > - { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174,
> > 171, 170, },
> > +/* This file implements software encode/decode of the tiling format used
> > for
> > + * textures and framebuffers primarily on Utgard GPUs. Names for this
> > format
> > + * include "Utgard-style tiling", "(Mali) swizzled textures", and
> > + * "U-interleaved" (the former two names being used in the community
> > + * Lima/Panfrost drivers; the latter name used internally at Arm).
> > + * Conceptually, like any tiling scheme, the pixel reordering attempts to
> > 2D
> > + * spatial locality, to improve cache locality in both horizontal and
> > vertical
> > + * directions.
> > + *
> > + * This format is tiled: first, the image dimensions must be aligned to 16
> > + * pixels in each axis. Once aligned, the image is divided into 16x16
> > tiles.
> > + * This size harmonizes with other properties of the GPU; on Midgard,
> > + * framebuffer tiles are logically 16x16 (this is the tile size used in
> > + * Transaction Elimination and the minimum tile size used in Hierarchical
> > + * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
> > + * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
> > + * size.
> > + *
> > + * Within each 16x16 block, the bits are reordered according to this
> > pattern:
> > + *
> > + * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
> > + *
> > + * Basically, interleaving the X and Y bits, with XORs thrown in for every
> > + * adjacent bit pair.
> > + *
> > + * This is cheap to implement both encode/decode in both hardware and
> > software.
> > + * In hardware, lines are simply rerouted to reorder and some XOR gates are
> > + * thrown in. Software has to be a bit more clever.
> > + *
> > + * In software, the trick is to divide the pattern into two lines:
> > + *
> > + *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
> > + * ^ | 0 | x3 | 0 | x2 | 0 | x1 | 0 | x0 |
> > + *
> > + * That is, duplicate the bits of the Y and space out the bits of the X.
> > The
> > + * top line is a function only of Y, so it can be calculated once per row
> > and
> > + * stored in a register. The
Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)
ping
On Mon, Jun 24, 2019 at 8:12 PM Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_drawpixels.c | 58 +++
> 1 file changed, 38 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index 59868d3ff1d..26d3cc33e5c 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -1508,35 +1508,35 @@ static GLboolean
> blit_copy_pixels(struct gl_context *ctx, GLint srcx, GLint srcy,
> GLsizei width, GLsizei height,
> GLint dstx, GLint dsty, GLenum type)
> {
> struct st_context *st = st_context(ctx);
> struct pipe_context *pipe = st->pipe;
> struct pipe_screen *screen = pipe->screen;
> struct gl_pixelstore_attrib pack, unpack;
> GLint readX, readY, readW, readH, drawX, drawY, drawW, drawH;
>
> - if (type == GL_COLOR &&
> - ctx->Pixel.ZoomX == 1.0 &&
> + if (ctx->Pixel.ZoomX == 1.0 &&
> ctx->Pixel.ZoomY == 1.0 &&
> - ctx->_ImageTransferState == 0x0 &&
> - !ctx->Color.BlendEnabled &&
> - !ctx->Color.AlphaEnabled &&
> - (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == GL_COPY)
> &&
> - !ctx->Depth.Test &&
> - !ctx->Fog.Enabled &&
> - !ctx->Stencil.Enabled &&
> - !ctx->FragmentProgram.Enabled &&
> - !ctx->VertexProgram.Enabled &&
> - !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
> - !_mesa_ati_fragment_shader_enabled(ctx) &&
> - ctx->DrawBuffer->_NumColorDrawBuffers == 1 &&
> + (type != GL_COLOR ||
> +(ctx->_ImageTransferState == 0x0 &&
> + !ctx->Color.BlendEnabled &&
> + !ctx->Color.AlphaEnabled &&
> + (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp ==
> GL_COPY) &&
> + !ctx->Depth.Test &&
> + !ctx->Fog.Enabled &&
> + !ctx->Stencil.Enabled &&
> + !ctx->FragmentProgram.Enabled &&
> + !ctx->VertexProgram.Enabled &&
> + !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
> + !_mesa_ati_fragment_shader_enabled(ctx) &&
> + ctx->DrawBuffer->_NumColorDrawBuffers == 1)) &&
> !ctx->Query.CondRenderQuery &&
> !ctx->Query.CurrentOcclusionObject) {
>struct st_renderbuffer *rbRead, *rbDraw;
>
>/*
> * Clip the read region against the src buffer bounds.
> * We'll still allocate a temporary buffer/texture for the original
> * src region size but we'll only read the region which is
> on-screen.
> * This may mean that we draw garbage pixels into the dest region,
> but
> * that's expected.
> @@ -1555,22 +1555,32 @@ blit_copy_pixels(struct gl_context *ctx, GLint
> srcx, GLint srcy,
>unpack = pack;
>if (!_mesa_clip_drawpixels(ctx, , , , ,
> ))
> return GL_TRUE; /* all done */
>
>readX = readX - pack.SkipPixels + unpack.SkipPixels;
>readY = readY - pack.SkipRows + unpack.SkipRows;
>
>drawW = readW;
>drawH = readH;
>
> - rbRead = st_get_color_read_renderbuffer(ctx);
> - rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
> + if (type == GL_COLOR) {
> + rbRead = st_get_color_read_renderbuffer(ctx);
> + rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
> + } else if (type == GL_DEPTH || type == GL_DEPTH_STENCIL) {
> + rbRead =
> st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
> + rbDraw =
> st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
> + } else if (type == GL_STENCIL) {
> + rbRead =
> st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
> + rbDraw =
> st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
> + } else {
> + return false;
> + }
>
>/* Flip src/dst position depending on the orientation of buffers. */
>if (st_fb_orientation(ctx->ReadBuffer) == Y_0_TOP) {
> readY = rbRead->Base.Height - readY;
> readH = -readH;
>}
>
>if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
> /* We can't flip the destination for pipe->blit, so we only
> adjust
>* its position and flip the source.
> @@ -1597,23 +1607,31 @@ blit_copy_pixels(struct gl_context *ctx, GLint
> srcx, GLint srcy,
> blit.src.box.depth = 1;
> blit.dst.resource = rbDraw->texture;
> blit.dst.level = rbDraw->surface->u.tex.level;
> blit.dst.format = rbDraw->texture->format;
> blit.dst.box.x = drawX;
> blit.dst.box.y = drawY;
> blit.dst.box.z = rbDraw->surface->u.tex.first_layer;
> blit.dst.box.width = drawW;
> blit.dst.box.height = drawH;
> blit.dst.box.depth = 1;
> - blit.mask = PIPE_MASK_RGBA;
>
[Mesa-dev] [Bug 111020] [RADV][DXVK] GPU lockup on Risk of Rain 2
https://bugs.freedesktop.org/show_bug.cgi?id=111020 Bug ID: 111020 Summary: [RADV][DXVK] GPU lockup on Risk of Rain 2 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: mayeul.can...@live.fr QA Contact: mesa-dev@lists.freedesktop.org # System specs GPU: R9 Fury Distribution: Arch Linux Mesa: 19.1.1 LLVM: 8.0.0 Application: Risk of Rain 2 via Steamplay/Proton 4.2-9 Steam store URL: https://store.steampowered.com/app/632360/Risk_of_Rain_2/ # Steps to reproduce: -Install Steam for Linux; -Join Steam Beta; -Enable Steam Play for all titles; -Install Risk of Rain 2; -Play Risk of Rain 2 to the third stage (it needs to have trees like the picture on the following page: https://steamcommunity.com/games/632360/announcements/detail/1595878665982945764 ) - The crash should happen within two minutes # Notes I encountered multiple random GPU hangs on this game before (~1 every 5 hours), but the latest update added an alternative third-stage level where I could not play longer than approximately 2 minutes without encountering a hang. Unfortunately, the GPU does not recover, and I have to force-reboot the computer. Do not hesitate to ask me additional information, with steps on how to gather it. I thought about recording an apitrace, but this probably wouldn't play well with the GPU hang. I am not sure whether the issue is in LLVM or this should be preventable at the amdgpu-level. Though GPU recovery should probably work in the first place (I saw a patch to improve this pass by, but didn't try it). Another game I'm getting random hangs in is No Man's Sky, also unrecoverable. I am reporting this one since it seems to be more reproducible. -- 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 110357] [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 Blocks||102590 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=102590 [Bug 102590] [OpenGL CTS] List of open issues -- 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 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 Bug ID: 111019 Summary: radv doesn't handle variable descriptor count properly Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: joseph.ku...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 144676 --> https://bugs.freedesktop.org/attachment.cgi?id=144676=edit Minimal reproducer When a descriptor set layout is created with VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT, descriptorCount in VkDescriptorSetLayoutBinding should be treated as an upper bound. The actual descriptor count is provided in VkDescriptorSetVariableDescriptorCountAllocateInfoEXT when vkAllocateDescriptorSets() is called. radv uses the upper limit from VkDescriptorSetLayoutBinding as descriptor count and fails to allocate descriptor sets with VK_ERROR_OUT_OF_POOL_MEMORY. The attached program reproduces the bug. -- 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 37637] unreal tournament crashes with mesa 7.11-dev
https://bugs.freedesktop.org/show_bug.cgi?id=37637 Tomas Bzatek changed: What|Removed |Added CC||b...@bzatek.net -- 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] egl: Make EGL_EXT_device_drm optional.
On 2019/06/28, mathias.froehl...@gmx.net wrote: > From: Mathias Fröhlich > > Hi, > > Ilia mentioned that there are drm rendernode only drivers out there. > To support an egl device on those platforms, make the EGL_EXT_device_drm > device extension optional. > Currently DRM core mandates that primary node is available, even for GPU only devices. A while back, we had a chat with kernel people why we do so. IIRC the conclustion was that existing userspace will just work, since it already must handle cases when you unplug your only monitor. I think Ilia was having a pretty reasonable assumption, that's why I did before digging deeper, as opposed to saying there _are_ such cases. HTH Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111016] Building Mesa GLX with Meson for macOS fails
https://bugs.freedesktop.org/show_bug.cgi?id=111016 --- Comment #4 from John Ericson --- For reference, the flags we pass today on master are at https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/mesa/default.nix#L98-L132 . Generally speaking, nixpkgs errs on the side of more explicit flags rather than leaving up to configure's defaults, but yes the first priority if making it work, even if it means making a lot more of those flags platform-specific. -- 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] [PATCH] egl: Make EGL_EXT_device_drm optional.
From: Mathias Fröhlich
Hi,
Ilia mentioned that there are drm rendernode only drivers out there.
To support an egl device on those platforms, make the EGL_EXT_device_drm
device extension optional.
Please review
best and thanks
Mathias
Relax drm device requirement to just have a render node to create
an EGLDevice. Off screen rendering is just possible with a render
node without having a master device node available.
To enable the EGL_EXT_device_drm device extension also check for
the primary node.
Signed-off-by: Mathias Fröhlich
---
src/egl/drivers/dri2/platform_device.c | 7 ++-
src/egl/main/egldevice.c | 25 +++--
src/egl/main/egldevice.h | 3 +++
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_device.c
b/src/egl/drivers/dri2/platform_device.c
index 6b80a3869b3..1213fa89337 100644
--- a/src/egl/drivers/dri2/platform_device.c
+++ b/src/egl/drivers/dri2/platform_device.c
@@ -394,15 +394,12 @@ dri2_initialize_device(_EGLDriver *drv, _EGLDisplay *disp)
disp->Device = dev;
disp->DriverData = (void *) dri2_dpy;
err = "DRI2: failed to load driver";
- if (_eglDeviceSupports(dev, _EGL_DEVICE_DRM)) {
+ if (!_eglDeviceIsSoftware(dev)) {
if (!device_probe_device(disp))
goto cleanup;
- } else if (_eglDeviceSupports(dev, _EGL_DEVICE_SOFTWARE)) {
+ } else {
if (!device_probe_device_sw(disp))
goto cleanup;
- } else {
- _eglLog(_EGL_FATAL, "Driver bug: exposed device is neither DRM nor
SOFTWARE one");
- return EGL_FALSE;
}
if (!dri2_create_screen(disp)) {
diff --git a/src/egl/main/egldevice.c b/src/egl/main/egldevice.c
index 99d8a6c1886..70b596bc8ac 100644
--- a/src/egl/main/egldevice.c
+++ b/src/egl/main/egldevice.c
@@ -45,6 +45,8 @@ struct _egl_device {
EGLBoolean MESA_device_software;
EGLBoolean EXT_device_drm;
+ EGLBoolean is_software;
+
#ifdef HAVE_LIBDRM
drmDevicePtr device;
#endif
@@ -69,8 +71,8 @@ _eglFiniDevice(void)
dev = dev_list;
dev_list = dev_list->Next;
+ assert(!_eglDeviceIsSoftware(dev));
#ifdef HAVE_LIBDRM
- assert(_eglDeviceSupports(dev, _EGL_DEVICE_DRM));
drmFreeDevice(>device);
#endif
free(dev);
@@ -98,6 +100,7 @@ _eglCheckDeviceHandle(EGLDeviceEXT device)
_EGLDevice _eglSoftwareDevice = {
.extensions = "EGL_MESA_device_software",
.MESA_device_software = EGL_TRUE,
+ .is_software = EGL_TRUE,
};
#ifdef HAVE_LIBDRM
@@ -108,9 +111,8 @@ static int
_eglAddDRMDevice(drmDevicePtr device, _EGLDevice **out_dev)
{
_EGLDevice *dev;
- const int wanted_nodes = 1 << DRM_NODE_RENDER | 1 << DRM_NODE_PRIMARY;
- if ((device->available_nodes & wanted_nodes) != wanted_nodes)
+ if ((device->available_nodes & 1 << DRM_NODE_RENDER) == 0)
return -1;
dev = _eglGlobal.DeviceList;
@@ -122,7 +124,7 @@ _eglAddDRMDevice(drmDevicePtr device, _EGLDevice **out_dev)
while (dev->Next) {
dev = dev->Next;
- assert(_eglDeviceSupports(dev, _EGL_DEVICE_DRM));
+ assert(!_eglDeviceIsSoftware(dev));
if (drmDevicesEqual(device, dev->device) != 0) {
if (out_dev)
*out_dev = dev;
@@ -138,8 +140,13 @@ _eglAddDRMDevice(drmDevicePtr device, _EGLDevice **out_dev)
}
dev = dev->Next;
- dev->extensions = "EGL_EXT_device_drm";
- dev->EXT_device_drm = EGL_TRUE;
+ if (device->available_nodes & (1 << DRM_NODE_PRIMARY)) {
+ dev->extensions = "EGL_EXT_device_drm";
+ dev->EXT_device_drm = EGL_TRUE;
+ } else {
+ dev->extensions = "";
+ dev->EXT_device_drm = EGL_FALSE;
+ }
dev->device = device;
if (out_dev)
@@ -188,6 +195,12 @@ out:
return dev;
}
+EGLBoolean
+_eglDeviceIsSoftware(_EGLDevice *dev)
+{
+ return dev->is_software;
+}
+
EGLBoolean
_eglDeviceSupports(_EGLDevice *dev, _EGLDeviceExtension ext)
{
diff --git a/src/egl/main/egldevice.h b/src/egl/main/egldevice.h
index 83a47d5eacc..b75fd3ab12e 100644
--- a/src/egl/main/egldevice.h
+++ b/src/egl/main/egldevice.h
@@ -65,6 +65,9 @@ enum _egl_device_extension {
typedef enum _egl_device_extension _EGLDeviceExtension;
+EGLBoolean
+_eglDeviceIsSoftware(_EGLDevice *dev);
+
EGLBoolean
_eglDeviceSupports(_EGLDevice *dev, _EGLDeviceExtension ext);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Only tag AFBC addresses when sampling
R-b, *blush*
On Fri, Jun 28, 2019 at 09:27:34AM +0200, Tomeu Vizoso wrote:
> Rendering to AFBC was broken, as the HW will complaint loudly if we pass
> a tagged pointer in bifrost_render_target.
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 3609b50a6443 ("panfrost: Merge AFBC slab with BO backing")
> ---
> src/gallium/drivers/panfrost/pan_context.c | 8 +++-
> src/gallium/drivers/panfrost/pan_resource.c | 7 +--
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index 967d7116c249..be800ca6ce1c 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -834,6 +834,11 @@ panfrost_upload_tex(
> unsigned first_layer = pview->u.tex.first_layer;
> unsigned last_layer = pview->u.tex.last_layer;
>
> +/* Lower-bit is set when sampling from colour AFBC */
> +bool is_afbc = rsrc->bo->layout == PAN_AFBC;
> +bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
> +unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
> +
> /* Inject the addresses in, interleaving mip levels, cube faces, and
> * strides in that order */
>
> @@ -841,8 +846,9 @@ panfrost_upload_tex(
>
> for (unsigned l = first_level; l <= last_level; ++l) {
> for (unsigned f = first_layer; f <= last_layer; ++f) {
> +
> view->hw.payload[idx++] =
> -panfrost_get_texture_address(rsrc, l, f);
> +panfrost_get_texture_address(rsrc, l, f) +
> afbc_bit;
>
> if (has_manual_stride) {
> view->hw.payload[idx++] =
> diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> b/src/gallium/drivers/panfrost/pan_resource.c
> index c5bda8093206..8db7e45af1b6 100644
> --- a/src/gallium/drivers/panfrost/pan_resource.c
> +++ b/src/gallium/drivers/panfrost/pan_resource.c
> @@ -756,12 +756,7 @@ panfrost_get_texture_address(
> unsigned level_offset = rsrc->bo->slices[level].offset;
> unsigned face_offset = face * rsrc->bo->cubemap_stride;
>
> -/* Lower-bit is set when sampling from colour AFBC */
> -bool is_afbc = rsrc->bo->layout == PAN_AFBC;
> -bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
> -unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
> -
> -return rsrc->bo->gpu + level_offset + face_offset + afbc_bit;
> +return rsrc->bo->gpu + level_offset + face_offset;
> }
>
> static void
> --
> 2.20.1
>
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/6] ac: compute the size of one DCC slice on GFX8
On Fri, Jun 28, 2019 at 9:19 AM Samuel Pitoiset
wrote:
>
> Addrlib doesn't provide this info. Because DCC is linear, at least
> on GFX8, it's easy to compute the size one slice.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_surface.c | 6 ++
> src/amd/common/ac_surface.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index f8b9d2b70f8..9e45bd44b72 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -302,6 +302,12 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
> surf_level->dcc_fast_clear_size =
> AddrDccOut->dccFastClearSize;
> else
> surf_level->dcc_fast_clear_size = 0;
> +
> + /* Compute the DCC slice size because addrlib doesn't
> +* provide this info. As DCC memory is linear (each
> +* slice is the same size) it's easy to compute.
> +*/
> + surf->dcc_slice_size = AddrDccOut->dccRamSize /
> config->info.array_size;
This will not work.
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/common/ac_surface.c#L289
/* If the DCC size of a subresource (1 mip level or 1 slice)
* is not aligned, the DCC memory layout is not contiguous for
* that subresource, which means we can't use fast clear.
*
* We only do fast clears for whole mipmap levels. If we did
* per-slice fast clears, the same restriction would apply.
* (i.e. only compute the slice size and see if it's aligned)
*
* The last level can be non-contiguous and still be clearable
* if it's interleaved with the next level that doesn't exist.
*/
For 1 level there is no guarantuee that the slice size is aligned and
the total size of the mipmap level is aligned after multiplying by
slice count (implicitly with color surface size), so we can't just
divide.
> }
> }
>
> diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
> index 31623634936..8143c9f9a0e 100644
> --- a/src/amd/common/ac_surface.h
> +++ b/src/amd/common/ac_surface.h
> @@ -212,6 +212,7 @@ struct radeon_surf {
>
> /* DCC and HTILE are very small. */
> uint32_tdcc_size;
> +uint32_tdcc_slice_size;
> uint32_tdcc_alignment;
>
> uint32_thtile_size;
> --
> 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 111018] welcome to camp nou
https://bugs.freedesktop.org/show_bug.cgi?id=111018 Bug ID: 111018 Summary: welcome to camp nou Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: EGL Assignee: mesa-dev@lists.freedesktop.org Reporter: akshayr...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org -- 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 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
https://bugs.freedesktop.org/show_bug.cgi?id=109258 --- Comment #11 from Brendan King --- I'm pretty sure I've got this to work, by removing the following block of code from function dri2_initialize_drm in platform_drm.c: /* Not supported yet */ if (disp->Options.ForceSoftware) return EGL_FALSE; and setting both GBM_ALWAYS_SOFTWARE=1 and LIBGL_ALWAYS_SOFTWARE=1 when running Weston. IIRC, the first variable is needed for the compositor to use software rendering, and the second for the other Weston processes. -- 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] XDC 2019: 10 days left to submit your talks!
Hello! Onlyh 10 days to go to submit your talks, workshops or demos for this year's X.Org Developer Conference, which will be taking place in beautiful Montréal, Canada on October 2-4, 2019! Whether it's the Linux kernel, Mesa, DRM, Wayland or X11, if it's related to the Open Source graphics stack, please send it in! Head to the XDC website to learn more: https://xdc2019.x.org/ The deadline for submissions Sunday, 7 July 2019. Best, Mark ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Only tag AFBC addresses when sampling
Rendering to AFBC was broken, as the HW will complaint loudly if we pass
a tagged pointer in bifrost_render_target.
Signed-off-by: Tomeu Vizoso
Fixes: 3609b50a6443 ("panfrost: Merge AFBC slab with BO backing")
---
src/gallium/drivers/panfrost/pan_context.c | 8 +++-
src/gallium/drivers/panfrost/pan_resource.c | 7 +--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 967d7116c249..be800ca6ce1c 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -834,6 +834,11 @@ panfrost_upload_tex(
unsigned first_layer = pview->u.tex.first_layer;
unsigned last_layer = pview->u.tex.last_layer;
+/* Lower-bit is set when sampling from colour AFBC */
+bool is_afbc = rsrc->bo->layout == PAN_AFBC;
+bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
+unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
+
/* Inject the addresses in, interleaving mip levels, cube faces, and
* strides in that order */
@@ -841,8 +846,9 @@ panfrost_upload_tex(
for (unsigned l = first_level; l <= last_level; ++l) {
for (unsigned f = first_layer; f <= last_layer; ++f) {
+
view->hw.payload[idx++] =
-panfrost_get_texture_address(rsrc, l, f);
+panfrost_get_texture_address(rsrc, l, f) +
afbc_bit;
if (has_manual_stride) {
view->hw.payload[idx++] =
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index c5bda8093206..8db7e45af1b6 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -756,12 +756,7 @@ panfrost_get_texture_address(
unsigned level_offset = rsrc->bo->slices[level].offset;
unsigned face_offset = face * rsrc->bo->cubemap_stride;
-/* Lower-bit is set when sampling from colour AFBC */
-bool is_afbc = rsrc->bo->layout == PAN_AFBC;
-bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
-unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
-
-return rsrc->bo->gpu + level_offset + face_offset + afbc_bit;
+return rsrc->bo->gpu + level_offset + face_offset;
}
static void
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] radv: add support for decompressing DCC layers with compute
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_fast_clear.c | 104 +-
1 file changed, 53 insertions(+), 51 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_fast_clear.c
b/src/amd/vulkan/radv_meta_fast_clear.c
index a642d6243d4..d601686f8f6 100644
--- a/src/amd/vulkan/radv_meta_fast_clear.c
+++ b/src/amd/vulkan/radv_meta_fast_clear.c
@@ -818,58 +818,60 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer
*cmd_buffer,
height = radv_minify(image->info.height,
subresourceRange->baseMipLevel + l);
- radv_image_view_init(, cmd_buffer->device,
-&(VkImageViewCreateInfo) {
-.sType =
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
-.image =
radv_image_to_handle(image),
-.viewType =
VK_IMAGE_VIEW_TYPE_2D,
-.format = image->vk_format,
-.subresourceRange = {
- .aspectMask =
VK_IMAGE_ASPECT_COLOR_BIT,
- .baseMipLevel =
subresourceRange->baseMipLevel + l,
- .levelCount = 1,
- .baseArrayLayer = 0,
- .layerCount = 1
-},
-});
-
- radv_meta_push_descriptor_set(cmd_buffer,
- VK_PIPELINE_BIND_POINT_COMPUTE,
-
device->meta_state.fast_clear_flush.dcc_decompress_compute_p_layout,
- 0, /* set */
- 2, /* descriptorWriteCount */
- (VkWriteDescriptorSet[]) {
- {
- .sType =
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET,
- .dstBinding = 0,
- .dstArrayElement
= 0,
- .descriptorCount
= 1,
- .descriptorType
= VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE,
- .pImageInfo =
(VkDescriptorImageInfo[]) {
- {
-
.sampler = VK_NULL_HANDLE,
-
.imageView = radv_image_view_to_handle(),
-
.imageLayout = VK_IMAGE_LAYOUT_GENERAL,
- },
- }
- },
+ for (uint32_t s = 0; s < radv_get_layerCount(image,
subresourceRange); s++) {
+ radv_image_view_init(, cmd_buffer->device,
+&(VkImageViewCreateInfo) {
+.sType =
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
+.image =
radv_image_to_handle(image),
+.viewType =
VK_IMAGE_VIEW_TYPE_2D,
+.format =
image->vk_format,
+.subresourceRange
= {
+ .aspectMask =
VK_IMAGE_ASPECT_COLOR_BIT,
+ .baseMipLevel =
subresourceRange->baseMipLevel + l,
+ .levelCount = 1,
+ .baseArrayLayer
= subresourceRange->baseArrayLayer + s,
+ .layerCount = 1
+},
+});
+
+ radv_meta_push_descriptor_set(cmd_buffer,
+
VK_PIPELINE_BIND_POINT_COMPUTE,
+
[Mesa-dev] [PATCH 4/6] radv: implement clearing DCC layers on GFX8
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
src/amd/vulkan/radv_meta_clear.c | 6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 1f3fdd1abd0..c79543a3246 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4972,7 +4972,8 @@ void radv_initialize_dcc(struct radv_cmd_buffer
*cmd_buffer,
if (!surf_level->dcc_fast_clear_size)
break;
- size = surf_level->dcc_offset +
surf_level->dcc_fast_clear_size;
+ size = surf_level->dcc_offset +
+ surf_level->dcc_fast_clear_size *
image->info.array_size;
}
/* Initialize the mipmap levels without DCC. */
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index e5181daf0f2..f12cf23660a 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1379,6 +1379,7 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
radv_update_dcc_metadata(cmd_buffer, image, range, true);
for (uint32_t l = 0; l < level_count; l++) {
+ uint32_t dcc_slice_size =
image->planes[0].surface.dcc_slice_size;
uint64_t offset = image->offset + image->dcc_offset;
uint32_t level = range->baseMipLevel + l;
uint64_t size;
@@ -1397,8 +1398,9 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
* fast clear path fallbacks to slow clears if one
* level can't be fast cleared.
*/
- offset += surf_level->dcc_offset;
- size = surf_level->dcc_fast_clear_size;
+ offset += surf_level->dcc_offset +
+ dcc_slice_size * range->baseArrayLayer;
+ size = surf_level->dcc_fast_clear_size *
radv_get_layerCount(image, range);
}
flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, offset,
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] radv: enable DCC for layers on GFX8
Still not supported on GFX9. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_image.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c index 07d89d32edf..8ac6e63a209 100644 --- a/src/amd/vulkan/radv_image.c +++ b/src/amd/vulkan/radv_image.c @@ -171,14 +171,10 @@ radv_use_dcc_for_image(struct radv_device *device, return false; /* TODO: Enable DCC for mipmaps on GFX9+. */ - if (pCreateInfo->mipLevels > 1 && + if ((pCreateInfo->arrayLayers > 1 || pCreateInfo->mipLevels > 1) && device->physical_device->rad_info.chip_class >= GFX9) return false; - /* TODO: Enable DCC for array layers. */ - if (pCreateInfo->arrayLayers > 1) - return false; - /* Do not enable DCC for mipmapped arrays because performance is worse. */ if (pCreateInfo->arrayLayers > 1 && pCreateInfo->mipLevels > 1) return false; -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] radv: do not enable DCC for mipmapped arrays because performance is worse
Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_image.c | 4 1 file changed, 4 insertions(+) diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c index 4099c57aa85..07d89d32edf 100644 --- a/src/amd/vulkan/radv_image.c +++ b/src/amd/vulkan/radv_image.c @@ -179,6 +179,10 @@ radv_use_dcc_for_image(struct radv_device *device, if (pCreateInfo->arrayLayers > 1) return false; + /* Do not enable DCC for mipmapped arrays because performance is worse. */ + if (pCreateInfo->arrayLayers > 1 && pCreateInfo->mipLevels > 1) + return false; + if (radv_surface_has_scanout(device, create_info)) return false; -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] ac: compute the size of one DCC slice on GFX8
Addrlib doesn't provide this info. Because DCC is linear, at least
on GFX8, it's easy to compute the size one slice.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_surface.c | 6 ++
src/amd/common/ac_surface.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index f8b9d2b70f8..9e45bd44b72 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -302,6 +302,12 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
surf_level->dcc_fast_clear_size =
AddrDccOut->dccFastClearSize;
else
surf_level->dcc_fast_clear_size = 0;
+
+ /* Compute the DCC slice size because addrlib doesn't
+* provide this info. As DCC memory is linear (each
+* slice is the same size) it's easy to compute.
+*/
+ surf->dcc_slice_size = AddrDccOut->dccRamSize /
config->info.array_size;
}
}
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 31623634936..8143c9f9a0e 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -212,6 +212,7 @@ struct radeon_surf {
/* DCC and HTILE are very small. */
uint32_tdcc_size;
+uint32_tdcc_slice_size;
uint32_tdcc_alignment;
uint32_thtile_size;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] ac: compute the DCC fast clear size per slice on GFX8
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_surface.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 9e45bd44b72..cc4aea5f8d9 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -308,6 +308,31 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
* slice is the same size) it's easy to compute.
*/
surf->dcc_slice_size = AddrDccOut->dccRamSize /
config->info.array_size;
+
+ /* For arrays, we have to compute the DCC info again
+* with one slice size to get a correct fast clear
+* size.
+*/
+ if (config->info.array_size > 1) {
+ AddrDccIn->colorSurfSize =
AddrSurfInfoOut->sliceSize;
+ AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
+ AddrDccIn->tileInfo =
*AddrSurfInfoOut->pTileInfo;
+ AddrDccIn->tileIndex =
AddrSurfInfoOut->tileIndex;
+ AddrDccIn->macroModeIndex =
AddrSurfInfoOut->macroModeIndex;
+
+ ret = AddrComputeDccInfo(addrlib,
+AddrDccIn, AddrDccOut);
+ if (ret == ADDR_OK) {
+ /* If the DCC memory isn't properly
+* aligned, the data are interleaved
+* accross slices.
+*/
+ if (AddrDccOut->dccRamSizeAligned)
+ surf_level->dcc_fast_clear_size
= AddrDccOut->dccFastClearSize;
+ else
+ surf_level->dcc_fast_clear_size
= 0;
+ }
+ }
}
}
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Expose support for 10-bit VP9 decode
Am 28.06.19 um 07:09 schrieb Vishwakarma, Pratik: Fix si_vid_is_format_supported to expose support for 10-bit VP9 decode using P016 format. Without this change, 10-bit decode will be exposed only for HEVC even though newer hardware support 10-bit decode for VP9. Signed-off-by: Pratik Vishwakarma Reviewed-by: Christian König --- src/gallium/drivers/radeonsi/si_get.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c index 4e23d283ab7..8cc5933f9bc 100644 --- a/src/gallium/drivers/radeonsi/si_get.c +++ b/src/gallium/drivers/radeonsi/si_get.c @@ -709,6 +709,10 @@ static boolean si_vid_is_format_supported(struct pipe_screen *screen, return (format == PIPE_FORMAT_NV12) || (format == PIPE_FORMAT_P016); + /* Vp9 profile 2 supports 10 bit decoding using P016 */ + if (profile == PIPE_VIDEO_PROFILE_VP9_PROFILE2) + return format == PIPE_FORMAT_P016; + /* we can only handle this one with UVD */ if (profile != PIPE_VIDEO_PROFILE_UNKNOWN) return format == PIPE_FORMAT_NV12; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
