[Mesa-dev] [RFC] panfrost/midgard: Hack some bits to get things working on T720
Any ideas on why these two changes get kmscube working on T720? Signed-off-by: Tomeu Vizoso --- src/gallium/drivers/panfrost/pan_context.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/panfrost/pan_context.c b/src/gallium/drivers/panfrost/pan_context.c index e20e8e8d5923..a1423c22e1fb 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -95,11 +95,14 @@ panfrost_emit_sfbd(struct panfrost_context *ctx) .unknown_address_0 = ctx->scratchpad.gpu, .unknown_address_1 = ctx->misc_0.gpu, .unknown_address_2 = ctx->misc_0.gpu + 40960, -.tiler_flags = 0xf0, +.tiler_flags = 0xfff, .tiler_heap_free = ctx->tiler_heap.gpu, .tiler_heap_end = ctx->tiler_heap.gpu + ctx->tiler_heap.size, }; +uint32_t *known_unknown = ((void*)ctx->misc_0.cpu + 40960); +*known_unknown = 0xa000; + panfrost_set_framebuffer_resolution(&framebuffer, ctx->pipe_framebuffer.width, ctx->pipe_framebuffer.height); return framebuffer; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available
On VegaM, the visible VRAM size is equal to the VRAM size, which
means only two heaps are exposed.
This fixes dEQP-VK.api.info.device.memory_budget.
v2: - use heapIndex
Cc: 19.0 19.1
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 60
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 358fc7cb30a..3b69e457496 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1502,40 +1502,46 @@ radv_get_memory_budget_properties(VkPhysicalDevice
physicalDevice,
* Note that the application heap usages are not really accurate (eg.
* in presence of shared buffers).
*/
- if (vram_size) {
- heap_usage = device->ws->query_value(device->ws,
-RADEON_ALLOCATED_VRAM);
+ for (int i = 0; i < device->memory_properties.memoryTypeCount; i++) {
+ uint32_t heap_index =
device->memory_properties.memoryTypes[i].heapIndex;
- heap_budget = vram_size -
- device->ws->query_value(device->ws, RADEON_VRAM_USAGE) +
- heap_usage;
+ switch (device->mem_type_indices[i]) {
+ case RADV_MEM_TYPE_VRAM:
+ heap_usage = device->ws->query_value(device->ws,
+
RADEON_ALLOCATED_VRAM);
- memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
- memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
- }
-
- if (visible_vram_size) {
- heap_usage = device->ws->query_value(device->ws,
-RADEON_ALLOCATED_VRAM_VIS);
+ heap_budget = vram_size -
+ device->ws->query_value(device->ws,
RADEON_VRAM_USAGE) +
+ heap_usage;
- heap_budget = visible_vram_size -
- device->ws->query_value(device->ws,
RADEON_VRAM_VIS_USAGE) +
- heap_usage;
+ memoryBudget->heapBudget[heap_index] = heap_budget;
+ memoryBudget->heapUsage[heap_index] = heap_usage;
+ break;
+ case RADV_MEM_TYPE_VRAM_CPU_ACCESS:
+ heap_usage = device->ws->query_value(device->ws,
+
RADEON_ALLOCATED_VRAM_VIS);
- memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
heap_budget;
- memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
heap_usage;
- }
+ heap_budget = visible_vram_size -
+ device->ws->query_value(device->ws,
RADEON_VRAM_VIS_USAGE) +
+ heap_usage;
- if (gtt_size) {
- heap_usage = device->ws->query_value(device->ws,
-RADEON_ALLOCATED_GTT);
+ memoryBudget->heapBudget[heap_index] = heap_budget;
+ memoryBudget->heapUsage[heap_index] = heap_usage;
+ break;
+ case RADV_MEM_TYPE_GTT_WRITE_COMBINE:
+ heap_usage = device->ws->query_value(device->ws,
+
RADEON_ALLOCATED_GTT);
- heap_budget = gtt_size -
- device->ws->query_value(device->ws, RADEON_GTT_USAGE) +
- heap_usage;
+ heap_budget = gtt_size -
+ device->ws->query_value(device->ws,
RADEON_GTT_USAGE) +
+ heap_usage;
- memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
- memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
+ memoryBudget->heapBudget[heap_index] = heap_budget;
+ memoryBudget->heapUsage[heap_index] = heap_usage;
+ break;
+ default:
+ break;
+ }
}
/* The heapBudget and heapUsage values must be zero for array elements
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available
On 2019-06-11 5:03 p.m., Samuel Pitoiset wrote: > On 6/11/19 4:56 PM, Alex Deucher wrote: >> On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset >> wrote: >>> On VegaM, the visible VRAM size is equal to the VRAM size, which >>> means only two heaps are exposed. >> FWIW, this is not VegaM specific. The vram size could be equal to the >> visible vram size on any asic depending on whether the platform >> supports large or resizeable BARs or not. > Yeah, not saying it's specific to VegaM. It's just the first time I hit > this, so I included that patch in the VegaM series. :-) I think Alex's point (which I agree with) is that the commit log is inaccurate and misleading. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 19.1.0
On Tue, 2019-06-11 at 20:28 +0300, Thomas Backlund wrote:
> Den 11.6.2019 kl. 19:00, skrev Juan A. Suarez Romero:
> > Mesa 19.1.0 is now available.
> >
> > Emil Velikov (3):
> >mapi: add static_date offset to MaxShaderCompilerThreadsKHR
> >mapi: correctly handle the full offset table
> >
>
> Question...
>
> Wasn't "mapi: add static_date offset to EXT_dsa"
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=497de977bdfe79469638e351d1363275c5954ea6
>
> also supposed to be part of the fix for:
> https://bugs.freedesktop.org/show_bug.cgi?id=110302
>
It is required to fix the issue with master branch, but not with 19.1 stable
branch.
The reason is that this commit is required due commit d2906293c43 ("mesa:
EXT_dsa add selectorless matrix stackfunctions"), which is not part of the 19.1
stable release.
J.A.
> --
> Thomas
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Change memory type order for GPUs without dedicated VRAM
On Tue, 11 Jun 2019 at 14:32, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 10.06.19 um 15:56 schrieb Bas Nieuwenhuizen:
> > On Sat, Jun 8, 2019 at 3:36 PM Alex Smith
> wrote:
> >> On Mon, 3 Jun 2019 at 13:27, Koenig, Christian <
> christian.koe...@amd.com> wrote:
> >>> Am 03.06.19 um 14:21 schrieb Alex Smith:
> >>>
> >>> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian <
> christian.koe...@amd.com> wrote:
> Am 02.06.19 um 12:32 schrieb Alex Smith:
> > Put the uncached GTT type at a higher index than the visible VRAM
> type,
> > rather than having GTT first.
> >
> > When we don't have dedicated VRAM, we don't have a non-visible VRAM
> > type, and the property flags for GTT and visible VRAM are identical.
> > According to the spec, for types with identical flags, we should give
> > the one with better performance a lower index.
> >
> > Previously, apps which follow the spec guidance for choosing a memory
> > type would have picked the GTT type in preference to visible VRAM
> (all
> > Feral games will do this), and end up with lower performance.
> >
> > On a Ryzen 5 2500U laptop (Raven Ridge), this improves average FPS in
> > the Rise of the Tomb Raider benchmark by up to ~30%. Tested a couple
> of
> > other (Feral) games and saw similar improvement on those as well.
> Well that patch doesn't looks like a good idea to me.
>
> Using VRAM over uncached GTT should have something between no and only
> minimal performance difference on APU.
>
> To make things even worse VRAM is still needed for scanout and newer
> laptops have only a very very low default setting (32 or 16MB). So you
> can end up in VRAM clashing on those systems.
>
> Can you check some kernel statistics to figure out what exactly is
> going
> on here?
> >>>
> >>> What statistics should I look at?
> >>>
> >>>
> >>> First of all take a look at amdgpu_gem_info file in the debugfs
> directory while using GTT and match that to using VRAM. You should see a
> lot more of GTT ... CPU_GTT_USWC entries with the GTT variant. If the
> CPU_GTT_USWC flag is missing we have found the problem.
> >>>
> >>> If that looks ok, then take a look at the ttm_page_pool or
> ttm_dma_page_pool file and see how many wc/uc and wc/uc huge pages you got.
> Huge pages should be used for anything larger than 2MB, if not we have
> found the problem.
> >>>
> >>> If that still isn't the issue I need to take a look at the VM code
> again and see if we still map VRAM/GTT differently on APUs.
> >>
> >> OK, got around to looking at this. amdgpu_gem_info does have more USWC
> entries when using GTT. I've attached the output from VRAM vs GTT in case
> you can spot anything else in there.
> >>
> >> ttm_page_pool has 9806 wc, 238 wc huge, no uc or uc huge.
> > To add to this, I tried rounding up the size all application GTT
> > allocations to a multiple of 2 megabytes (+ a suballocator for buffers
> > < 2M). This increased performance a bit but not nearly what going from
> > GTT->"VRAM" brings.
>
> I need to dig deeper when I have a bit more time.
>
> The logs Alex provided didn't showed anything obviously wrong, so no
> idea what's the actual problem here.
>
> Anyway feel free to go ahead with this approach, but please keep in mind
> that this might cause problems on some systems.
>
Thanks Christian.
Bas, Samuel - what do you think to going ahead with this change in the
meantime? Perhaps we could add some threshold on minimum "VRAM" size
(256MB?) required to change the order, to avoid issues on systems where
that heap is really small?
Alex
>
> Christian.
>
> >
> >> FWIW this was from kernel 5.0.10, I just upgraded to 5.1.6 and still
> the same perf difference there.
> >>
> >> Thanks,
> >> Alex
> >>
> >>>
> >>> Thanks,
> >>> Christian.
> >>>
> >>>
> >>> Thanks,
> >>> Alex
> >>>
>
> Regards,
> Christian.
>
> > Signed-off-by: Alex Smith
> > ---
> > I noticed that the memory types advertised on my Raven laptop looked
> a
> > bit odd so played around with it and found this. I'm not sure if it
> is
> > actually expected that the performance difference between visible
> VRAM
> > and GTT is so large, seeing as it's not dedicated VRAM, but the
> results
> > are clear (and consistent, tested multiple times).
> > ---
> >src/amd/vulkan/radv_device.c | 18 +++---
> >1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_device.c
> b/src/amd/vulkan/radv_device.c
> > index 3cf050ed220..d36ee226ebd 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -171,12 +171,11 @@ radv_physical_device_init_mem_types(struct
> radv_physical_device *device)
> >.heapIndex = vram_index,
> >};
> >}
> > - if (gart_index >= 0) {
> > +
Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?
On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote: > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > > > So here's the question: How does people feel about hosting this > > under > > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK > > with > > this, I will make that happen, and send out a patch to update the > > link > > we have in our FAQ once that's done. > > Sounds fine to me. I've needed to refer to the SI more than once, I'd > be happy to have it in a well-known location. > > Vaguely related: Old-timers may remember that DRI used to have its > own > CVS repo on dri.sourceforge.net. If you want a git import of that > tree, > you can find it here: > > https://gitlab.freedesktop.org/ajax/dri Hmm, for some reason I can't see the repo here, just the (empty) issue tracker. Even though the project is listed as public... Strange. > I'd be happy to move this under mesa/ too if we want. I think that'd be nice, yeah. I think it would be nice to keep things like this in some central location. One could also imagine that the SGI GLX realease in it's original form would be interesting to preserve in case other mirrors go down as well. Just for the heck of it, I've archived that as well, even though it's just a single tarball, so it ends up as just a single commit: https://gitlab.freedesktop.org/kusma/glx This could also be a candidate for moving under the mesa-group. > > I would further propose we mark the repo as archived, which would > > clearly mark that we're not maintaining it and also prevent it from > > appearing in searches. > > Enh. Less sold on this, though if it's linked from the FAQ I guess > it's > okay. I find that gitlab's archive makes things a little too hard to > find, I would often prefer to see archived results in searches. But > there's not really a better way to make a repo read-only, so I won't > object too strongly. > Yeah, I was kinda left a bit disappointed when I read that archived projects don't show up in searches as well. But I guess it makes sense for most uses of archived projects. It would be nice if there was a separate switch for searchability, just so code-historians can find things like this easily ;) And just to be clear, they would show up here, together with other no- longer-in-use projects: https://gitlab.freedesktop.org/groups/mesa/-/archived I don't really feel strongly about archived or not. We should make sure nobody thinks this is somewhere they can contribute fixes. Perhaps it's enough to just state this in the project description, disable merge- requests, and protect all branches. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?
On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote: > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote: > > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > > > > > So here's the question: How does people feel about hosting this > > > under > > > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK > > > with > > > this, I will make that happen, and send out a patch to update the > > > link > > > we have in our FAQ once that's done. > > > > Sounds fine to me. I've needed to refer to the SI more than once, > > I'd > > be happy to have it in a well-known location. > > > > Vaguely related: Old-timers may remember that DRI used to have its > > own > > CVS repo on dri.sourceforge.net. If you want a git import of that > > tree, > > you can find it here: > > > > https://gitlab.freedesktop.org/ajax/dri > > Hmm, for some reason I can't see the repo here, just the (empty) > issue > tracker. Even though the project is listed as public... Strange. > > > I'd be happy to move this under mesa/ too if we want. > > I think that'd be nice, yeah. I think it would be nice to keep things > like this in some central location. > > One could also imagine that the SGI GLX realease in it's original > form > would be interesting to preserve in case other mirrors go down as > well. > Just for the heck of it, I've archived that as well, even though it's > just a single tarball, so it ends up as just a single commit: > > https://gitlab.freedesktop.org/kusma/glx > > This could also be a candidate for moving under the mesa-group. > Actually, perhaps this one belongs under the xorg-group instead of the mesa-group... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110901] mesa-19.1.0/src/util/futex.h:82: use of out of scope variable ?
https://bugs.freedesktop.org/show_bug.cgi?id=110901
Bug ID: 110901
Summary: mesa-19.1.0/src/util/futex.h:82: use of out of scope
variable ?
Product: Mesa
Version: 19.1
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
Assignee: mesa-dev@lists.freedesktop.org
Reporter: dcb...@hotmail.com
QA Contact: mesa-dev@lists.freedesktop.org
mesa-19.1.0/src/util/futex.h:82] -> [mesa-19.1.0/src/util/futex.h:76] ->
[mesa-19.1.0/src/util/futex.h:85]: (error) Using pointer to local variable
'tmo' that is out of scope.
Source code is
if (timeout != NULL) {
const struct _umtx_time tmo = {
._timeout = *timeout,
._flags = UMTX_ABSTIME,
._clockid = CLOCK_MONOTONIC
};
uaddr = (void *)(uintptr_t)sizeof(tmo);
uaddr2 = (void *)&tmo;
}
return _umtx_op(addr, UMTX_OP_WAIT_UINT, (uint32_t)value, uaddr, uaddr2) ==
-1 ? errno : 0;
--
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 110902] mesa-19.1.0/src/broadcom/compiler/vir_opt_redundant_flags.c:104]: (style) Same expression
https://bugs.freedesktop.org/show_bug.cgi?id=110902
Bug ID: 110902
Summary: mesa-19.1.0/src/broadcom/compiler/vir_opt_redundant_fl
ags.c:104]: (style) Same expression
Product: Mesa
Version: 19.1
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
Assignee: mesa-dev@lists.freedesktop.org
Reporter: dcb...@hotmail.com
QA Contact: mesa-dev@lists.freedesktop.org
mesa-19.1.0/src/broadcom/compiler/vir_opt_redundant_flags.c:104]: (style) Same
expression on both sides of '||'.
Source code is
if (inst->qpu.type != V3D_QPU_INSTR_TYPE_ALU ||
inst->qpu.flags.auf != V3D_QPU_UF_NONE ||
inst->qpu.flags.auf != V3D_QPU_UF_NONE) {
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available
On 6/12/19 9:58 AM, Michel Dänzer wrote: On 2019-06-11 5:03 p.m., Samuel Pitoiset wrote: On 6/11/19 4:56 PM, Alex Deucher wrote: On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset wrote: On VegaM, the visible VRAM size is equal to the VRAM size, which means only two heaps are exposed. FWIW, this is not VegaM specific. The vram size could be equal to the visible vram size on any asic depending on whether the platform supports large or resizeable BARs or not. Yeah, not saying it's specific to VegaM. It's just the first time I hit this, so I included that patch in the VegaM series. :-) I think Alex's point (which I agree with) is that the commit log is inaccurate and misleading. I will update the commit log before pushing. Forgot to do that for v2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 9/9] radv: add support for VK_KHR_depth_stencil_resolve
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 21 +
src/amd/vulkan/radv_extensions.py | 1 +
2 files changed, 22 insertions(+)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 358fc7cb30a..b6a86796927 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1379,6 +1379,27 @@ void radv_GetPhysicalDeviceProperties2(
properties->variableSampleLocations = VK_FALSE;
break;
}
+ case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR: {
+ VkPhysicalDeviceDepthStencilResolvePropertiesKHR
*properties =
+
(VkPhysicalDeviceDepthStencilResolvePropertiesKHR *)ext;
+
+ /* We support all of the depth resolve modes */
+ properties->supportedDepthResolveModes =
+ VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR |
+ VK_RESOLVE_MODE_AVERAGE_BIT_KHR |
+ VK_RESOLVE_MODE_MIN_BIT_KHR |
+ VK_RESOLVE_MODE_MAX_BIT_KHR;
+
+ /* Average doesn't make sense for stencil so we don't
support that */
+ properties->supportedStencilResolveModes =
+ VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR |
+ VK_RESOLVE_MODE_MIN_BIT_KHR |
+ VK_RESOLVE_MODE_MAX_BIT_KHR;
+
+ properties->independentResolveNone = VK_TRUE;
+ properties->independentResolve = VK_TRUE;
+ break;
+ }
default:
break;
}
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index b14bd990e5f..e080c62cec8 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -55,6 +55,7 @@ EXTENSIONS = [
Extension('VK_KHR_bind_memory2', 1, True),
Extension('VK_KHR_create_renderpass2',1, True),
Extension('VK_KHR_dedicated_allocation', 1, True),
+Extension('VK_KHR_depth_stencil_resolve', 1, True),
Extension('VK_KHR_descriptor_update_template',1, True),
Extension('VK_KHR_device_group', 1, True),
Extension('VK_KHR_device_group_creation', 1, True),
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 5/9] radv: select the depth/stencil resolve method based on some conditions
Only fallback to the compute path for layers.
v2: - move the check for color resolves after ds resolves
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 78 +-
1 file changed, 65 insertions(+), 13 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 5027bfdb93b..7cadf937ee6 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -342,20 +342,28 @@ static void radv_pick_resolve_method_images(struct
radv_image *src_image,
cmd_buffer->queue_family_index,
cmd_buffer->queue_family_index);
- if (src_format == VK_FORMAT_R16G16_UNORM ||
- src_format == VK_FORMAT_R16G16_SNORM)
- *method = RESOLVE_COMPUTE;
- else if (vk_format_is_int(src_format))
- *method = RESOLVE_COMPUTE;
- else if (src_image->info.array_size > 1 ||
-dest_image->info.array_size > 1)
- *method = RESOLVE_COMPUTE;
+ if (vk_format_is_color(src_format)) {
+ if (src_format == VK_FORMAT_R16G16_UNORM ||
+ src_format == VK_FORMAT_R16G16_SNORM)
+ *method = RESOLVE_COMPUTE;
+ else if (vk_format_is_int(src_format))
+ *method = RESOLVE_COMPUTE;
+ else if (src_image->info.array_size > 1 ||
+dest_image->info.array_size > 1)
+ *method = RESOLVE_COMPUTE;
- if (radv_layout_dcc_compressed(dest_image, dest_image_layout,
queue_mask)) {
- *method = RESOLVE_FRAGMENT;
- } else if (dest_image->planes[0].surface.micro_tile_mode !=
- src_image->planes[0].surface.micro_tile_mode) {
- *method = RESOLVE_COMPUTE;
+ if (radv_layout_dcc_compressed(dest_image, dest_image_layout,
queue_mask)) {
+ *method = RESOLVE_FRAGMENT;
+ } else if (dest_image->planes[0].surface.micro_tile_mode !=
+ src_image->planes[0].surface.micro_tile_mode) {
+ *method = RESOLVE_COMPUTE;
+ }
+ } else {
+ if (src_image->info.array_size > 1 ||
+ dest_image->info.array_size > 1)
+ *method = RESOLVE_COMPUTE;
+ else
+ *method = RESOLVE_FRAGMENT;
}
}
@@ -621,6 +629,50 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
struct radv_meta_saved_state saved_state;
enum radv_resolve_method resolve_method = RESOLVE_HW;
+ if (subpass->ds_resolve_attachment) {
+ struct radv_subpass_attachment src_att =
*subpass->depth_stencil_attachment;
+ struct radv_subpass_attachment dst_att =
*subpass->ds_resolve_attachment;
+ struct radv_image_view *src_iview =
+
cmd_buffer->state.framebuffer->attachments[src_att.attachment].attachment;
+ struct radv_image_view *dst_iview =
+
cmd_buffer->state.framebuffer->attachments[dst_att.attachment].attachment;
+
+ radv_pick_resolve_method_images(src_iview->image,
+ src_iview->vk_format,
+ dst_iview->image,
+ dst_att.layout,
+ cmd_buffer,
+ &resolve_method);
+
+ if ((src_iview->aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT) &&
+ subpass->depth_resolve_mode != VK_RESOLVE_MODE_NONE_KHR) {
+ if (resolve_method == RESOLVE_FRAGMENT) {
+
radv_depth_stencil_resolve_subpass_fs(cmd_buffer,
+
VK_IMAGE_ASPECT_DEPTH_BIT,
+
subpass->depth_resolve_mode);
+ } else {
+ assert(resolve_method == RESOLVE_COMPUTE);
+
radv_depth_stencil_resolve_subpass_cs(cmd_buffer,
+
VK_IMAGE_ASPECT_DEPTH_BIT,
+
subpass->depth_resolve_mode);
+ }
+ }
+
+ if ((src_iview->aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT) &&
+ subpass->stencil_resolve_mode != VK_RESOLVE_MODE_NONE_KHR) {
+ if (resolve_method == RESOLVE_FRAGMENT) {
+
radv_depth_stencil_resolve_subpass_fs(cmd_buffer,
+
[Mesa-dev] [PATCH v2 1/9] radv: rename has_resolve to has_resolve_color
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 2 +-
src/amd/vulkan/radv_pass.c | 4 ++--
src/amd/vulkan/radv_private.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 8c4bfa63ac7..5027bfdb93b 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -621,7 +621,7 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
struct radv_meta_saved_state saved_state;
enum radv_resolve_method resolve_method = RESOLVE_HW;
- if (!subpass->has_resolve)
+ if (!subpass->has_color_resolve)
return;
for (uint32_t i = 0; i < subpass->color_count; ++i) {
diff --git a/src/amd/vulkan/radv_pass.c b/src/amd/vulkan/radv_pass.c
index 8fa098eaac8..728b6113206 100644
--- a/src/amd/vulkan/radv_pass.c
+++ b/src/amd/vulkan/radv_pass.c
@@ -132,7 +132,7 @@ radv_render_pass_compile(struct radv_render_pass *pass)
depth_sample_count);
/* We have to handle resolve attachments specially */
- subpass->has_resolve = false;
+ subpass->has_color_resolve = false;
if (subpass->resolve_attachments) {
for (uint32_t j = 0; j < subpass->color_count; j++) {
struct radv_subpass_attachment *resolve_att =
@@ -141,7 +141,7 @@ radv_render_pass_compile(struct radv_render_pass *pass)
if (resolve_att->attachment ==
VK_ATTACHMENT_UNUSED)
continue;
- subpass->has_resolve = true;
+ subpass->has_color_resolve = true;
}
}
}
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 8f2e80b3017..848fd427ef0 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1910,8 +1910,8 @@ struct radv_subpass {
struct radv_subpass_attachment * resolve_attachments;
struct radv_subpass_attachment * depth_stencil_attachment;
- /** Subpass has at least one resolve attachment */
- bool has_resolve;
+ /** Subpass has at least one color resolve attachment */
+ bool has_color_resolve;
/** Subpass has at least one color attachment */
bool has_color_att;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 6/9] radv: decompress HTILE if the resolve src image is compressed
It's required to decompress HTILE before resolving with the
compute path.
v2: - do proper layout transitions
- account for the framebuffer layers
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 7cadf937ee6..48ebbd1fc10 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -784,6 +784,22 @@ radv_decompress_resolve_subpass_src(struct radv_cmd_buffer
*cmd_buffer)
radv_decompress_resolve_src(cmd_buffer, src_image,
src_att.layout, 1, ®ion);
}
+
+ if (subpass->ds_resolve_attachment) {
+ struct radv_subpass_attachment src_att =
*subpass->depth_stencil_attachment;
+ struct radv_image_view *src_iview =
+ fb->attachments[src_att.attachment].attachment;
+ struct radv_image *src_image = src_iview->image;
+
+ VkImageResolve region = {};
+ region.srcSubresource.aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT;
+ region.srcSubresource.mipLevel = 0;
+ region.srcSubresource.baseArrayLayer = src_iview->base_layer;
+ region.srcSubresource.layerCount = layer_count;
+
+ radv_decompress_resolve_src(cmd_buffer, src_image,
+ src_att.layout, 1, ®ion);
+ }
}
/**
@@ -809,7 +825,7 @@ radv_decompress_resolve_src(struct radv_cmd_buffer
*cmd_buffer,
barrier.newLayout = VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL;
barrier.image = radv_image_to_handle(src_image);
barrier.subresourceRange = (VkImageSubresourceRange) {
- .aspectMask = VK_IMAGE_ASPECT_COLOR_BIT,
+ .aspectMask = region->srcSubresource.aspectMask,
.baseMipLevel = region->srcSubresource.mipLevel,
.levelCount = 1,
.baseArrayLayer = src_base_layer,
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/9] radv: implement all depth/stencil resolve modes using graphics
When using graphics, the driver doesn't need to decompress HTILE
before resolving. This path currently doesn't support layers
so we have to fallback to the compute path.
v2: - use image view format
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_fs.c | 596 ++
src/amd/vulkan/radv_private.h | 18 +
2 files changed, 614 insertions(+)
diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
b/src/amd/vulkan/radv_meta_resolve_fs.c
index d059760edf1..8ee3cc07f12 100644
--- a/src/amd/vulkan/radv_meta_resolve_fs.c
+++ b/src/amd/vulkan/radv_meta_resolve_fs.c
@@ -316,6 +316,356 @@ create_resolve_pipeline(struct radv_device *device,
return result;
}
+enum {
+ DEPTH_RESOLVE,
+ STENCIL_RESOLVE
+};
+
+static const char *
+get_resolve_mode_str(VkResolveModeFlagBitsKHR resolve_mode)
+{
+ switch (resolve_mode) {
+ case VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR:
+ return "zero";
+ case VK_RESOLVE_MODE_AVERAGE_BIT_KHR:
+ return "average";
+ case VK_RESOLVE_MODE_MIN_BIT_KHR:
+ return "min";
+ case VK_RESOLVE_MODE_MAX_BIT_KHR:
+ return "max";
+ default:
+ unreachable("invalid resolve mode");
+ }
+}
+
+static nir_shader *
+build_depth_stencil_resolve_fragment_shader(struct radv_device *dev, int
samples,
+ int index,
+ VkResolveModeFlagBitsKHR
resolve_mode)
+{
+ nir_builder b;
+ char name[64];
+ const struct glsl_type *vec2 = glsl_vector_type(GLSL_TYPE_FLOAT, 2);
+ const struct glsl_type *vec4 = glsl_vec4_type();
+ const struct glsl_type *sampler_type =
glsl_sampler_type(GLSL_SAMPLER_DIM_2D,
+false,
+false,
+
GLSL_TYPE_FLOAT);
+
+ snprintf(name, 64, "meta_resolve_fs_%s-%s-%d",
+index == DEPTH_RESOLVE ? "depth" : "stencil",
+get_resolve_mode_str(resolve_mode), samples);
+
+ nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_FRAGMENT, NULL);
+ b.shader->info.name = ralloc_strdup(b.shader, name);
+
+ nir_variable *input_img = nir_variable_create(b.shader, nir_var_uniform,
+ sampler_type, "s_tex");
+ input_img->data.descriptor_set = 0;
+ input_img->data.binding = 0;
+
+ nir_variable *fs_pos_in = nir_variable_create(b.shader,
nir_var_shader_in, vec2, "fs_pos_in");
+ fs_pos_in->data.location = VARYING_SLOT_POS;
+
+ nir_variable *fs_out = nir_variable_create(b.shader,
+ nir_var_shader_out, vec4,
+ "f_out");
+ fs_out->data.location =
+ index == DEPTH_RESOLVE ? FRAG_RESULT_DEPTH :
FRAG_RESULT_STENCIL;
+
+ nir_ssa_def *pos_in = nir_load_var(&b, fs_pos_in);
+
+ nir_intrinsic_instr *src_offset = nir_intrinsic_instr_create(b.shader,
nir_intrinsic_load_push_constant);
+ nir_intrinsic_set_base(src_offset, 0);
+ nir_intrinsic_set_range(src_offset, 8);
+ src_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 0));
+ src_offset->num_components = 2;
+ nir_ssa_dest_init(&src_offset->instr, &src_offset->dest, 2, 32,
"src_offset");
+ nir_builder_instr_insert(&b, &src_offset->instr);
+
+ nir_ssa_def *pos_int = nir_f2i32(&b, pos_in);
+
+ nir_ssa_def *img_coord = nir_channels(&b, nir_iadd(&b, pos_int,
&src_offset->dest.ssa), 0x3);
+
+ nir_ssa_def *input_img_deref = &nir_build_deref_var(&b,
input_img)->dest.ssa;
+
+ nir_alu_type type = index == DEPTH_RESOLVE ? nir_type_float :
nir_type_uint;
+
+ nir_tex_instr *tex = nir_tex_instr_create(b.shader, 3);
+ tex->sampler_dim = GLSL_SAMPLER_DIM_MS;
+ tex->op = nir_texop_txf_ms;
+ tex->src[0].src_type = nir_tex_src_coord;
+ tex->src[0].src = nir_src_for_ssa(img_coord);
+ tex->src[1].src_type = nir_tex_src_ms_index;
+ tex->src[1].src = nir_src_for_ssa(nir_imm_int(&b, 0));
+ tex->src[2].src_type = nir_tex_src_texture_deref;
+ tex->src[2].src = nir_src_for_ssa(input_img_deref);
+ tex->dest_type = type;
+ tex->is_array = false;
+ tex->coord_components = 2;
+
+ nir_ssa_dest_init(&tex->instr, &tex->dest, 4, 32, "tex");
+ nir_builder_instr_insert(&b, &tex->instr);
+
+ nir_ssa_def *outval = &tex->dest.ssa;
+
+ if (resolve_mode != VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR) {
+ for (int i = 1; i < samples; i++) {
+ nir_tex_instr *tex_add = nir_tex_instr_create(b.shader,
3);
+ tex_add->sampler_dim = GLSL_SAMPLER_DIM_MS;
+ tex_add->op = nir_texop
[Mesa-dev] [PATCH v2 2/9] radv: record if a render pass has depth/stencil resolve attachments
Only supported with vkCreateRenderPass2().
v2: - do not set has_resolve (now has_color_resolve) for ds resolves
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pass.c| 27 ++-
src/amd/vulkan/radv_private.h | 3 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pass.c b/src/amd/vulkan/radv_pass.c
index 728b6113206..688a17919bd 100644
--- a/src/amd/vulkan/radv_pass.c
+++ b/src/amd/vulkan/radv_pass.c
@@ -91,6 +91,10 @@ radv_render_pass_compile(struct radv_render_pass *pass)
subpass->depth_stencil_attachment->attachment ==
VK_ATTACHMENT_UNUSED)
subpass->depth_stencil_attachment = NULL;
+ if (subpass->ds_resolve_attachment &&
+ subpass->ds_resolve_attachment->attachment ==
VK_ATTACHMENT_UNUSED)
+ subpass->ds_resolve_attachment = NULL;
+
for (uint32_t j = 0; j < subpass->attachment_count; j++) {
struct radv_subpass_attachment *subpass_att =
&subpass->attachments[j];
@@ -309,10 +313,15 @@ VkResult radv_CreateRenderPass(
static unsigned
radv_num_subpass_attachments2(const VkSubpassDescription2KHR *desc)
{
+ const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
+ vk_find_struct_const(desc->pNext,
+
SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
+
return desc->inputAttachmentCount +
desc->colorAttachmentCount +
(desc->pResolveAttachments ? desc->colorAttachmentCount : 0) +
- (desc->pDepthStencilAttachment != NULL);
+ (desc->pDepthStencilAttachment != NULL) +
+ (ds_resolve && ds_resolve->pDepthStencilResolveAttachment);
}
VkResult radv_CreateRenderPass2KHR(
@@ -429,6 +438,22 @@ VkResult radv_CreateRenderPass2KHR(
.layout = desc->pDepthStencilAttachment->layout,
};
}
+
+ const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
+ vk_find_struct_const(desc->pNext,
+
SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
+
+ if (ds_resolve && ds_resolve->pDepthStencilResolveAttachment) {
+ subpass->ds_resolve_attachment = p++;
+
+ *subpass->ds_resolve_attachment = (struct
radv_subpass_attachment) {
+ .attachment =
ds_resolve->pDepthStencilResolveAttachment->attachment,
+ .layout =
ds_resolve->pDepthStencilResolveAttachment->layout,
+ };
+
+ subpass->depth_resolve_mode =
ds_resolve->depthResolveMode;
+ subpass->stencil_resolve_mode =
ds_resolve->stencilResolveMode;
+ }
}
for (unsigned i = 0; i < pCreateInfo->dependencyCount; ++i) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 848fd427ef0..af7e90140a4 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1909,6 +1909,9 @@ struct radv_subpass {
struct radv_subpass_attachment * color_attachments;
struct radv_subpass_attachment * resolve_attachments;
struct radv_subpass_attachment * depth_stencil_attachment;
+ struct radv_subpass_attachment * ds_resolve_attachment;
+ VkResolveModeFlagBitsKHR depth_resolve_mode;
+ VkResolveModeFlagBitsKHR stencil_resolve_mode;
/** Subpass has at least one color resolve attachment */
bool has_color_resolve;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 7/9] radv: clear the depth/stencil resolve attachment if necessary
The driver might need to clear one aspect of the depth/stencil
resolve attachment before performing the resolve itself.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 73
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 44aaf92f53d..b5824c68fe2 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -715,13 +715,14 @@ static void
emit_depthstencil_clear(struct radv_cmd_buffer *cmd_buffer,
const VkClearAttachment *clear_att,
const VkClearRect *clear_rect,
+ struct radv_subpass_attachment *ds_att,
uint32_t view_mask)
{
struct radv_device *device = cmd_buffer->device;
struct radv_meta_state *meta_state = &device->meta_state;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
const struct radv_framebuffer *fb = cmd_buffer->state.framebuffer;
- const uint32_t pass_att = subpass->depth_stencil_attachment->attachment;
+ const uint32_t pass_att = ds_att->attachment;
VkClearDepthStencilValue clear_value =
clear_att->clearValue.depthStencil;
VkImageAspectFlags aspects = clear_att->aspectMask;
const struct radv_image_view *iview = fb ?
fb->attachments[pass_att].attachment : NULL;
@@ -761,18 +762,25 @@ emit_depthstencil_clear(struct radv_cmd_buffer
*cmd_buffer,
iview,
samples_log2,
aspects,
-
subpass->depth_stencil_attachment->layout,
+ds_att->layout,
clear_rect,
clear_value);
if (!pipeline)
return;
+ struct radv_subpass clear_subpass = {
+ .color_count = 0,
+ .color_attachments = NULL,
+ .depth_stencil_attachment = ds_att,
+ };
+
+ radv_cmd_buffer_set_subpass(cmd_buffer, &clear_subpass);
+
radv_CmdBindPipeline(cmd_buffer_h, VK_PIPELINE_BIND_POINT_GRAPHICS,
pipeline);
if (depth_view_can_fast_clear(cmd_buffer, iview, aspects,
- subpass->depth_stencil_attachment->layout,
- clear_rect, clear_value))
+ ds_att->layout, clear_rect, clear_value))
radv_update_ds_clear_metadata(cmd_buffer, iview->image,
clear_value, aspects);
@@ -799,6 +807,8 @@ emit_depthstencil_clear(struct radv_cmd_buffer *cmd_buffer,
radv_CmdSetStencilReference(cmd_buffer_h,
VK_STENCIL_FACE_FRONT_BIT,
prev_reference);
}
+
+ radv_cmd_buffer_set_subpass(cmd_buffer, subpass);
}
static uint32_t
@@ -1562,7 +1572,8 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer,
const VkClearRect *clear_rect,
enum radv_cmd_flush_bits *pre_flush,
enum radv_cmd_flush_bits *post_flush,
- uint32_t view_mask)
+ uint32_t view_mask,
+ bool ds_resolve_clear)
{
const struct radv_framebuffer *fb = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
@@ -1588,12 +1599,16 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer,
emit_color_clear(cmd_buffer, clear_att, clear_rect,
view_mask);
}
} else {
- const uint32_t pass_att =
subpass->depth_stencil_attachment->attachment;
- if (pass_att == VK_ATTACHMENT_UNUSED)
+ struct radv_subpass_attachment *ds_att =
subpass->depth_stencil_attachment;
+
+ if (ds_resolve_clear)
+ ds_att = subpass->ds_resolve_attachment;
+
+ if (ds_att->attachment == VK_ATTACHMENT_UNUSED)
return;
- VkImageLayout image_layout =
subpass->depth_stencil_attachment->layout;
- const struct radv_image_view *iview = fb ?
fb->attachments[pass_att].attachment : NULL;
+ VkImageLayout image_layout = ds_att->layout;
+ const struct radv_image_view *iview = fb ?
fb->attachments[ds_att->attachment].attachment : NULL;
VkClearDepthStencilValue clear_value =
clear_att->clearValue.depthStencil;
assert(aspects & (VK_IMAGE_ASPECT_DEPTH_BIT |
@@ -1606,7 +1621,7 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer,
pre_flush, post_flush);
[Mesa-dev] [PATCH v2 8/9] radv: pass sample locations for transitions before depth/stencil resolves
HTILE decompressions need the user sample locations if specified
in the current subpass.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 +-
src/amd/vulkan/radv_meta_resolve.c | 30 ++
src/amd/vulkan/radv_private.h | 3 +++
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index d69bec60bb8..b08e5829723 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2644,7 +2644,7 @@ void radv_subpass_barrier(struct radv_cmd_buffer
*cmd_buffer,
NULL);
}
-static uint32_t
+uint32_t
radv_get_subpass_id(struct radv_cmd_buffer *cmd_buffer)
{
struct radv_cmd_state *state = &cmd_buffer->state;
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 48ebbd1fc10..ea1b3a6781c 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -802,6 +802,20 @@ radv_decompress_resolve_subpass_src(struct radv_cmd_buffer
*cmd_buffer)
}
}
+static struct radv_sample_locations_state *
+radv_get_resolve_sample_locations(struct radv_cmd_buffer *cmd_buffer)
+{
+ struct radv_cmd_state *state = &cmd_buffer->state;
+ uint32_t subpass_id = radv_get_subpass_id(cmd_buffer);
+
+ for (uint32_t i = 0; i < state->num_subpass_sample_locs; i++) {
+ if (state->subpass_sample_locs[i].subpass_idx == subpass_id)
+ return &state->subpass_sample_locs[i].sample_location;
+ }
+
+ return NULL;
+}
+
/**
* Decompress CMask/FMask before resolving a multisampled source image.
*/
@@ -832,6 +846,22 @@ radv_decompress_resolve_src(struct radv_cmd_buffer
*cmd_buffer,
.layerCount = region->srcSubresource.layerCount,
};
+ if (src_image->flags &
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT) {
+ /* If the depth/stencil image uses different sample
+* locations, we need them during HTILE decompressions.
+*/
+ struct radv_sample_locations_state *sample_locs =
+ radv_get_resolve_sample_locations(cmd_buffer);
+
+ barrier.pNext = &(VkSampleLocationsInfoEXT) {
+ .sType =
VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT,
+ .sampleLocationsPerPixel =
sample_locs->per_pixel,
+ .sampleLocationGridSize =
sample_locs->grid_size,
+ .sampleLocationsCount = sample_locs->count,
+ .pSampleLocations = sample_locs->locations,
+ };
+ }
+
radv_CmdPipelineBarrier(radv_cmd_buffer_to_handle(cmd_buffer),
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 5c42f4f418a..3133c44f79d 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1959,6 +1959,9 @@ struct radv_subpass {
VkSampleCountFlagBitsmax_sample_count;
};
+uint32_t
+radv_get_subpass_id(struct radv_cmd_buffer *cmd_buffer);
+
struct radv_render_pass_attachment {
VkFormat format;
uint32_t samples;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/9] radv: VK_KHR_depth_stencil_resolve
Hi, Second version of VK_KHR_depth_stencil_resolve which should handle interations with VK_EXT_sample_locations correctly. All CTS tests now pass on Polaris10/Vega10. Please review, Thanks! Samuel Pitoiset (9): radv: rename has_resolve to has_resolve_color radv: record if a render pass has depth/stencil resolve attachments radv: implement all depth/stencil resolve modes using graphics radv: implement all depth/stencil resolve modes using compute radv: select the depth/stencil resolve method based on some conditions radv: decompress HTILE if the resolve src image is compressed radv: clear the depth/stencil resolve attachment if necessary radv: pass sample locations for transitions before depth/stencil resolves radv: add support for VK_KHR_depth_stencil_resolve src/amd/vulkan/radv_cmd_buffer.c | 2 +- src/amd/vulkan/radv_device.c | 21 + src/amd/vulkan/radv_extensions.py | 1 + src/amd/vulkan/radv_meta_clear.c | 73 +++- src/amd/vulkan/radv_meta_resolve.c| 128 +- src/amd/vulkan/radv_meta_resolve_cs.c | 506 ++ src/amd/vulkan/radv_meta_resolve_fs.c | 596 ++ src/amd/vulkan/radv_pass.c| 31 +- src/amd/vulkan/radv_private.h | 44 +- 9 files changed, 1363 insertions(+), 39 deletions(-) -- 2.22.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/9] radv: implement all depth/stencil resolve modes using compute
This path supports layers but it requires to decompress HTILE
before resolving. The driver also needs to fixup HTILE after
the resolve. This path is probably slower than the graphics one.
v2: - use image view format
- make HTILE uncompressed after resolving
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_cs.c | 506 ++
src/amd/vulkan/radv_private.h | 16 +
2 files changed, 522 insertions(+)
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
b/src/amd/vulkan/radv_meta_resolve_cs.c
index fc4bcf27bb9..c06f0f2c5ce 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -139,6 +139,165 @@ build_resolve_compute_shader(struct radv_device *dev,
bool is_integer, bool is_s
return b.shader;
}
+enum {
+ DEPTH_RESOLVE,
+ STENCIL_RESOLVE,
+};
+
+static const char *
+get_resolve_mode_str(VkResolveModeFlagBitsKHR resolve_mode)
+{
+ switch (resolve_mode) {
+ case VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR:
+ return "zero";
+ case VK_RESOLVE_MODE_AVERAGE_BIT_KHR:
+ return "average";
+ case VK_RESOLVE_MODE_MIN_BIT_KHR:
+ return "min";
+ case VK_RESOLVE_MODE_MAX_BIT_KHR:
+ return "max";
+ default:
+ unreachable("invalid resolve mode");
+ }
+}
+
+static nir_shader *
+build_depth_stencil_resolve_compute_shader(struct radv_device *dev, int
samples,
+ int index,
+ VkResolveModeFlagBitsKHR
resolve_mode)
+{
+ nir_builder b;
+ char name[64];
+ const struct glsl_type *sampler_type =
glsl_sampler_type(GLSL_SAMPLER_DIM_MS,
+false,
+false,
+
GLSL_TYPE_FLOAT);
+ const struct glsl_type *img_type =
glsl_sampler_type(GLSL_SAMPLER_DIM_2D,
+false,
+false,
+GLSL_TYPE_FLOAT);
+ snprintf(name, 64, "meta_resolve_cs_%s-%s-%d",
+index == DEPTH_RESOLVE ? "depth" : "stencil",
+get_resolve_mode_str(resolve_mode), samples);
+
+ nir_builder_init_simple_shader(&b, NULL, MESA_SHADER_COMPUTE, NULL);
+ b.shader->info.name = ralloc_strdup(b.shader, name);
+ b.shader->info.cs.local_size[0] = 16;
+ b.shader->info.cs.local_size[1] = 16;
+ b.shader->info.cs.local_size[2] = 1;
+
+ nir_variable *input_img = nir_variable_create(b.shader, nir_var_uniform,
+ sampler_type, "s_tex");
+ input_img->data.descriptor_set = 0;
+ input_img->data.binding = 0;
+
+ nir_variable *output_img = nir_variable_create(b.shader,
nir_var_uniform,
+ img_type, "out_img");
+ output_img->data.descriptor_set = 0;
+ output_img->data.binding = 1;
+ nir_ssa_def *invoc_id = nir_load_local_invocation_id(&b);
+ nir_ssa_def *wg_id = nir_load_work_group_id(&b);
+ nir_ssa_def *block_size = nir_imm_ivec4(&b,
+ b.shader->info.cs.local_size[0],
+ b.shader->info.cs.local_size[1],
+
b.shader->info.cs.local_size[2], 0);
+
+ nir_ssa_def *global_id = nir_iadd(&b, nir_imul(&b, wg_id, block_size),
invoc_id);
+
+ nir_intrinsic_instr *src_offset = nir_intrinsic_instr_create(b.shader,
nir_intrinsic_load_push_constant);
+ nir_intrinsic_set_base(src_offset, 0);
+ nir_intrinsic_set_range(src_offset, 16);
+ src_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 0));
+ src_offset->num_components = 2;
+ nir_ssa_dest_init(&src_offset->instr, &src_offset->dest, 2, 32,
"src_offset");
+ nir_builder_instr_insert(&b, &src_offset->instr);
+
+ nir_intrinsic_instr *dst_offset = nir_intrinsic_instr_create(b.shader,
nir_intrinsic_load_push_constant);
+ nir_intrinsic_set_base(dst_offset, 0);
+ nir_intrinsic_set_range(dst_offset, 16);
+ dst_offset->src[0] = nir_src_for_ssa(nir_imm_int(&b, 8));
+ dst_offset->num_components = 2;
+ nir_ssa_dest_init(&dst_offset->instr, &dst_offset->dest, 2, 32,
"dst_offset");
+ nir_builder_instr_insert(&b, &dst_offset->instr);
+
+ nir_ssa_def *img_coord = nir_channels(&b, nir_iadd(&b, global_id,
&src_offset->dest.ssa), 0x3);
+
+ nir_ssa_def *input_img_deref = &nir_build_deref_var(&b,
input_img)->dest.ssa;
+
+ nir_alu_type type = index == DEPTH_RESOLVE ? nir_type_float :
nir_type_uint;
+
+ nir_tex_instr *tex = nir_tex_instr
[Mesa-dev] [Bug 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 Bug ID: 110903 Summary: Can't start mutter or GDM with wayland Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: pierre-eric.pelloux-pra...@amd.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 144518 --> https://bugs.freedesktop.org/attachment.cgi?id=144518&action=edit dmesg (kernel options used: drm.debug=0x7) Since d6edccee8da38d4802020d5aa4d9e11bb7aae801 GDM + wayland won't start on my machines. The cursor appears but I can't move it and the background stays black. Observations: * mutter --wayland -r --no-x11 fails in the same way * GDM with x11 still works correctly. * using master and reverting a7ecf78b900c28aafdc1cd1e1a4117feb30a66c9, 4e3297f7d4d87618bf896ac503e1f036a7b6befb and d6edccee8da38d4802020d5aa4d9e11bb7aae801 fixes the problem (the 2 first commits doesn't cause the problem but depends on the problematic one). Versions: * mutter: 3.30.2-7 (from Debian) * mesa / drm : master * linux: 40cc64619a2580b (from amd-staging-drm-next) -- 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 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 --- Comment #1 from Pierre-Eric Pelloux-Prayer --- Created attachment 144519 --> https://bugs.freedesktop.org/attachment.cgi?id=144519&action=edit The content of /sys/kernel/debug/dri/0/amdgpu_gem_info while mutter is running -- 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 104166] swr: Scons build - Add support for AVX512 configuration
https://bugs.freedesktop.org/show_bug.cgi?id=104166 pal1000 changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #2 from pal1000 --- This will be available in Meson build as soon as this lands https://gitlab.freedesktop.org/mesa/mesa/merge_requests/986 -- 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 110468] using swrAVX renders incorrectly at particular resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=110468 --- Comment #9 from ayan...@outlook.com --- That has only seemed to fix swrAVX, swrAVX2 is still a black screen. -- 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 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 Michel Dänzer changed: What|Removed |Added Attachment #144518|text/x-log |text/plain mime type|| -- 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 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 Michel Dänzer changed: What|Removed |Added CC||emil.l.veli...@gmail.com Component|Other |EGL --- Comment #2 from Michel Dänzer --- I just ran into this as well yesterday. The problem seems to be that mutter ends up using a DRM render node FD for GBM/drawing, so the GEM BOs created with that do not exist in the DRM card node FD used for KMS, so mutter ends up unable to display anything. mutter does pass in the KMS FD via the EGL_DRM_MASTER_FD_EXT attribute. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 3/9] panfrost/midgard: Figure out job requirements in pan_job.c
Requirements for a job should be figured out in pan_job.c
---
src/gallium/drivers/panfrost/pan_context.c | 8 +---
src/gallium/drivers/panfrost/pan_job.c | 11 +++
src/gallium/drivers/panfrost/pan_job.h | 4
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index d6a54f9a9f5..4c53b2d58f5 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -921,13 +921,7 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
SET_BIT(ctx->fragment_shader_core.unknown2_4, MALI_NO_MSAA,
!msaa);
}
-/* Enable job requirements at draw-time */
-
-if (msaa)
-job->requirements |= PAN_REQ_MSAA;
-
-if (ctx->depth_stencil->depth.writemask)
-job->requirements |= PAN_REQ_DEPTH_WRITE;
+panfrost_job_set_requirements(ctx, job);
if (ctx->occlusion_query) {
ctx->payload_tiler.gl_enables |= MALI_OCCLUSION_QUERY |
MALI_OCCLUSION_PRECISE;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 333c9f1f147..0083ca6499e 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -164,6 +164,17 @@ panfrost_job_submit(struct panfrost_context *ctx, struct
panfrost_job *job)
ctx->tiler_job_count = 0;
}
+void
+panfrost_job_set_requirements(struct panfrost_context *ctx,
+ struct panfrost_job *job)
+{
+if (ctx->rasterizer->base.multisample)
+job->requirements |= PAN_REQ_MSAA;
+
+if (ctx->depth_stencil->depth.writemask)
+job->requirements |= PAN_REQ_DEPTH_WRITE;
+}
+
void
panfrost_flush_jobs_reading_resource(struct panfrost_context *panfrost,
struct pipe_resource *prsc)
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index afc9ac4e58f..cbfd6cb0c7f 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -90,4 +90,8 @@ panfrost_flush_jobs_reading_resource(struct panfrost_context
*panfrost,
void
panfrost_job_submit(struct panfrost_context *ctx, struct panfrost_job *job);
+
+void
+panfrost_job_set_requirements(struct panfrost_context *ctx,
+ struct panfrost_job *job);
#endif
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 0/9] panfrost/midgard: Refactor pan_context
Refactor pan_context to separate out responsibilities between pan_context and pan_job. Rohan Garg (9): panfrost/midgard: Initial implementation of panfrost_job_submit panfrost/midgard: Reset job counters once the job is submitted panfrost/midgard: Figure out job requirements in pan_job.c panfrost/midgard: Move clearing logic into pan_job panfrost/midgard: Remove unnecessary variables panfrost/midgard: Remove duplicated header panfrost/midgard: Move draw_count into panfrost_job panfrost/midgard: Move requirement setting into panfrost_job Fixes 88ae2f5870c: "panfrost/midgard: Remove unnecessary variables" src/gallium/drivers/panfrost/pan_context.c | 104 --- src/gallium/drivers/panfrost/pan_context.h | 4 - src/gallium/drivers/panfrost/pan_job.c | 95 + src/gallium/drivers/panfrost/pan_job.h | 16 +++ src/gallium/drivers/panfrost/pan_wallpaper.c | 1 - 5 files changed, 134 insertions(+), 86 deletions(-) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 2/9] panfrost/midgard: Reset job counters once the job is submitted
Move the reset out of frame invalidation into job submission --- src/gallium/drivers/panfrost/pan_context.c | 5 - src/gallium/drivers/panfrost/pan_job.c | 4 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_context.c b/src/gallium/drivers/panfrost/pan_context.c index 4680dd2ff8c..d6a54f9a9f5 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -384,11 +384,6 @@ 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 diff --git a/src/gallium/drivers/panfrost/pan_job.c b/src/gallium/drivers/panfrost/pan_job.c index 1e09760871c..333c9f1f147 100644 --- a/src/gallium/drivers/panfrost/pan_job.c +++ b/src/gallium/drivers/panfrost/pan_job.c @@ -158,6 +158,10 @@ panfrost_job_submit(struct panfrost_context *ctx, struct panfrost_job *job) if (ret) fprintf(stderr, "panfrost_job_submit failed: %d\n", ret); +/* Reset job counters */ +ctx->draw_count = 0; +ctx->vertex_job_count = 0; +ctx->tiler_job_count = 0; } void -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 1/9] panfrost/midgard: Initial implementation of panfrost_job_submit
Start fleshing out panfrost_job
---
src/gallium/drivers/panfrost/pan_context.c | 3 +--
src/gallium/drivers/panfrost/pan_job.c | 20
src/gallium/drivers/panfrost/pan_job.h | 2 ++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 6dab13de1f2..4680dd2ff8c 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1350,8 +1350,7 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool
flush_immediate,
#ifndef DRY_RUN
-bool is_scanout = panfrost_is_scanout(ctx);
-screen->driver->submit_vs_fs_job(ctx, has_draws, is_scanout);
+panfrost_job_submit(ctx, job);
/* If visual, we can stall a frame */
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 6e913ac3374..1e09760871c 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -140,6 +140,26 @@ panfrost_flush_jobs_writing_resource(struct
panfrost_context *panfrost,
/* TODO stub */
}
+void
+panfrost_job_submit(struct panfrost_context *ctx, struct panfrost_job *job)
+{
+struct pipe_context *gallium = (struct pipe_context *) ctx;
+struct panfrost_screen *screen = pan_screen(gallium->screen);
+int ret;
+
+bool has_draws = ctx->draw_count > 0;
+bool is_scanout = panfrost_is_scanout(ctx);
+
+if (!job)
+return;
+
+ret = screen->driver->submit_vs_fs_job(ctx, has_draws, is_scanout);
+
+if (ret)
+fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
+
+}
+
void
panfrost_flush_jobs_reading_resource(struct panfrost_context *panfrost,
struct pipe_resource *prsc)
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index 1b28084c599..afc9ac4e58f 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -88,4 +88,6 @@ void
panfrost_flush_jobs_reading_resource(struct panfrost_context *panfrost,
struct pipe_resource *prsc);
+void
+panfrost_job_submit(struct panfrost_context *ctx, struct panfrost_job *job);
#endif
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 8/9] panfrost/midgard: Move requirement setting into panfrost_job
Move panfrost_job_set_requirements into panfrost_get_job_for_fbo,
requirements should be set when acquiring a job from a context.
---
src/gallium/drivers/panfrost/pan_context.c | 2 --
src/gallium/drivers/panfrost/pan_job.c | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index ced25cf4b82..00acb464bc6 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -872,8 +872,6 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
SET_BIT(ctx->fragment_shader_core.unknown2_4, MALI_NO_MSAA,
!msaa);
}
-panfrost_job_set_requirements(ctx, job);
-
if (ctx->occlusion_query) {
ctx->payload_tiler.gl_enables |= MALI_OCCLUSION_QUERY |
MALI_OCCLUSION_PRECISE;
ctx->payload_tiler.postfix.occlusion_counter =
ctx->occlusion_query->transfer.gpu;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 3ae7450c189..86fb24a119b 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -109,6 +109,7 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
struct pipe_surface **cbufs = ctx->pipe_framebuffer.cbufs;
struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
+panfrost_job_set_requirements(ctx, job);
return job;
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 4/9] panfrost/midgard: Move clearing logic into pan_job
---
src/gallium/drivers/panfrost/pan_context.c | 49 +-
src/gallium/drivers/panfrost/pan_job.c | 59 ++
src/gallium/drivers/panfrost/pan_job.h | 8 +++
3 files changed, 68 insertions(+), 48 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 4c53b2d58f5..d372f295979 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -245,40 +245,6 @@ panfrost_is_scanout(struct panfrost_context *ctx)
ctx->pipe_framebuffer.cbufs[0]->texture->bind &
PIPE_BIND_SHARED;
}
-static uint32_t
-pan_pack_color(const union pipe_color_union *color, enum pipe_format format)
-{
-/* Alpha magicked to 1.0 if there is no alpha */
-
-bool has_alpha = util_format_has_alpha(format);
-float clear_alpha = has_alpha ? color->f[3] : 1.0f;
-
-/* Packed color depends on the framebuffer format */
-
-const struct util_format_description *desc =
-util_format_description(format);
-
-if (util_format_is_rgba8_variant(desc)) {
-return (float_to_ubyte(clear_alpha) << 24) |
- (float_to_ubyte(color->f[2]) << 16) |
- (float_to_ubyte(color->f[1]) << 8) |
- (float_to_ubyte(color->f[0]) << 0);
-} else if (format == PIPE_FORMAT_B5G6R5_UNORM) {
-/* First, we convert the components to R5, G6, B5 separately */
-unsigned r5 = CLAMP(color->f[0], 0.0, 1.0) * 31.0;
-unsigned g6 = CLAMP(color->f[1], 0.0, 1.0) * 63.0;
-unsigned b5 = CLAMP(color->f[2], 0.0, 1.0) * 31.0;
-
-/* Then we pack into a sparse u32. TODO: Why these shifts? */
-return (b5 << 25) | (g6 << 14) | (r5 << 5);
-} else {
-/* Unknown format */
-assert(0);
-}
-
-return 0;
-}
-
static void
panfrost_clear(
struct pipe_context *pipe,
@@ -289,20 +255,7 @@ panfrost_clear(
struct panfrost_context *ctx = pan_context(pipe);
struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
-if (buffers & PIPE_CLEAR_COLOR) {
-enum pipe_format format =
ctx->pipe_framebuffer.cbufs[0]->format;
-job->clear_color = pan_pack_color(color, format);
-}
-
-if (buffers & PIPE_CLEAR_DEPTH) {
-job->clear_depth = depth;
-}
-
-if (buffers & PIPE_CLEAR_STENCIL) {
-job->clear_stencil = stencil;
-}
-
-job->clear |= buffers;
+panfrost_job_clear(ctx, job, buffers, color, depth, stencil);
}
static mali_ptr
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 0083ca6499e..be2742a0dc5 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -26,6 +26,7 @@
#include "pan_context.h"
#include "util/hash_table.h"
#include "util/ralloc.h"
+#include "util/u_format.h"
struct panfrost_job *
panfrost_create_job(struct panfrost_context *ctx)
@@ -175,6 +176,64 @@ panfrost_job_set_requirements(struct panfrost_context *ctx,
job->requirements |= PAN_REQ_DEPTH_WRITE;
}
+static uint32_t
+pan_pack_color(const union pipe_color_union *color, enum pipe_format format)
+{
+/* Alpha magicked to 1.0 if there is no alpha */
+
+bool has_alpha = util_format_has_alpha(format);
+float clear_alpha = has_alpha ? color->f[3] : 1.0f;
+
+/* Packed color depends on the framebuffer format */
+
+const struct util_format_description *desc =
+util_format_description(format);
+
+if (util_format_is_rgba8_variant(desc)) {
+return (float_to_ubyte(clear_alpha) << 24) |
+ (float_to_ubyte(color->f[2]) << 16) |
+ (float_to_ubyte(color->f[1]) << 8) |
+ (float_to_ubyte(color->f[0]) << 0);
+} else if (format == PIPE_FORMAT_B5G6R5_UNORM) {
+/* First, we convert the components to R5, G6, B5 separately */
+unsigned r5 = CLAMP(color->f[0], 0.0, 1.0) * 31.0;
+unsigned g6 = CLAMP(color->f[1], 0.0, 1.0) * 63.0;
+unsigned b5 = CLAMP(color->f[2], 0.0, 1.0) * 31.0;
+
+/* Then we pack into a sparse u32. TODO: Why these shifts? */
+return (b5 << 25) | (g6 << 14) | (r5 << 5);
+} else {
+/* Unknown format */
+assert(0);
+}
+
+return 0;
+}
+
+void
+panfrost_job_clear(struct panfrost_context *ctx,
+struct panfrost_job *job,
+unsigned buffers,
+const union pipe_color_union *color,
+double depth, unsigned stencil)
+
+{
+if (buffers & PIPE_CLEAR_COLOR) {
+enum pip
[Mesa-dev] [PATCH libdrm 9/9] Fixes 88ae2f5870c: "panfrost/midgard: Remove unnecessary variables"
Make sure we link the last vertex job to the first tiler job.
---
src/gallium/drivers/panfrost/pan_context.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 00acb464bc6..caa914e33cb 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -581,6 +581,7 @@ struct panfrost_transfer
panfrost_vertex_tiler_job(struct panfrost_context *ctx, bool is_tiler)
{
struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+static mali_ptr first_tiler_job = 0;
/* Each draw call corresponds to two jobs, and the set-value job is
first */
int draw_job_index = 1 + (2 * job->draw_count) + 1;
@@ -623,6 +624,11 @@ panfrost_vertex_tiler_job(struct panfrost_context *ctx,
bool is_tiler)
if (job->draw_count) {
/* Previous vertex job points to this vertex job */
panfrost_link_job_pair(ctx->u_vertex_jobs[job->draw_count - 1], transfer.gpu);
+
+/* Last vertex job points to first tiler job */
+if (!first_tiler_job)
+first_tiler_job = transfer.gpu;
+panfrost_link_job_pair(&next_job, first_tiler_job);
} else {
/* Have the first vertex job depend on the set value
job */
next_job.job_dependency_index_1 =
ctx->u_set_value_job->job_index;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 7/9] panfrost/midgard: Move draw_count into panfrost_job
Refactor code to use draw_counts from a panfrost_job
---
src/gallium/drivers/panfrost/pan_context.c | 31 --
src/gallium/drivers/panfrost/pan_context.h | 2 --
src/gallium/drivers/panfrost/pan_job.c | 4 +--
src/gallium/drivers/panfrost/pan_job.h | 2 ++
4 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index eaceaa8725e..ced25cf4b82 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -580,10 +580,12 @@ panfrost_link_job_pair(struct mali_job_descriptor_header
*first, mali_ptr next)
struct panfrost_transfer
panfrost_vertex_tiler_job(struct panfrost_context *ctx, bool is_tiler)
{
+struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+
/* Each draw call corresponds to two jobs, and the set-value job is
first */
-int draw_job_index = 1 + (2 * ctx->draw_count) + 1;
+int draw_job_index = 1 + (2 * job->draw_count) + 1;
-struct mali_job_descriptor_header job = {
+struct mali_job_descriptor_header next_job = {
.job_type = is_tiler ? JOB_TYPE_TILER : JOB_TYPE_VERTEX,
.job_index = draw_job_index + (is_tiler ? 1 : 0),
#ifdef __LP64__
@@ -605,25 +607,25 @@ panfrost_vertex_tiler_job(struct panfrost_context *ctx,
bool is_tiler)
if (is_tiler) {
/* Tiler jobs depend on vertex jobs */
-job.job_dependency_index_1 = draw_job_index;
+next_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;
+if (job->draw_count) {
+next_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);
+
panfrost_link_job_pair(ctx->u_tiler_jobs[job->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) {
+if (job->draw_count) {
/* Previous vertex job points to this vertex job */
-
panfrost_link_job_pair(ctx->u_vertex_jobs[ctx->draw_count - 1], transfer.gpu);
+
panfrost_link_job_pair(ctx->u_vertex_jobs[job->draw_count - 1], transfer.gpu);
} else {
/* Have the first vertex job depend on the set value
job */
-job.job_dependency_index_1 =
ctx->u_set_value_job->job_index;
+next_job.job_dependency_index_1 =
ctx->u_set_value_job->job_index;
panfrost_link_job_pair(ctx->u_set_value_job,
transfer.gpu);
}
}
@@ -1245,8 +1247,9 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
static void
panfrost_queue_draw(struct panfrost_context *ctx)
{
+struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
/* TODO: Expand the array? */
-if (ctx->draw_count >= MAX_DRAW_CALLS) {
+if (job->draw_count >= MAX_DRAW_CALLS) {
DBG("Job buffer overflow, ignoring draw\n");
assert(0);
}
@@ -1255,7 +1258,7 @@ panfrost_queue_draw(struct panfrost_context *ctx)
panfrost_emit_for_draw(ctx, true);
/* We need a set_value job before any other draw jobs */
-if (ctx->draw_count == 0)
+if (job->draw_count == 0)
panfrost_set_value_job(ctx);
struct panfrost_transfer vertex = panfrost_vertex_tiler_job(ctx,
false);
@@ -1264,7 +1267,7 @@ panfrost_queue_draw(struct panfrost_context *ctx)
struct panfrost_transfer tiler = panfrost_vertex_tiler_job(ctx, true);
ctx->u_tiler_jobs[ctx->tiler_job_count] = (struct
mali_job_descriptor_header *) tiler.cpu;
-ctx->draw_count++;
+job->draw_count++;
}
/* The entire frame is in memory -- send it off to the kernel! */
@@ -1278,7 +1281,7 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool
flush_immediate,
struct panfrost_screen *screen = pan_screen(gallium->screen);
/* Edge case if screen is cleared and nothing else */
-bool has_draws = ctx->draw_count > 0;
+bool has_draws = job->draw_count > 0;
/* Workaround a bizarre lockup (a hardware errata?) */
if (!has_draws)
@@ -1323,7 +1326,7 @@ panfrost_flush(
struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
[Mesa-dev] [PATCH libdrm 5/9] panfrost/midgard: Remove unnecessary variables
These are not required anymore since mali jobs are
now linked lists i.e. u_vertex_jobs and u_tiler_jobs
---
src/gallium/drivers/panfrost/pan_context.c | 5 -
src/gallium/drivers/panfrost/pan_context.h | 2 --
src/gallium/drivers/panfrost/pan_wallpaper.c | 1 -
3 files changed, 8 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index d372f295979..66762a010f8 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -622,9 +622,6 @@ panfrost_vertex_tiler_job(struct panfrost_context *ctx,
bool is_tiler)
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(&job, 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;
@@ -1264,11 +1261,9 @@ panfrost_queue_draw(struct panfrost_context *ctx)
struct panfrost_transfer vertex = panfrost_vertex_tiler_job(ctx,
false);
ctx->u_vertex_jobs[ctx->vertex_job_count] = (struct
mali_job_descriptor_header *) vertex.cpu;
-ctx->vertex_jobs[ctx->vertex_job_count++] = vertex.gpu;
struct panfrost_transfer tiler = panfrost_vertex_tiler_job(ctx, true);
ctx->u_tiler_jobs[ctx->tiler_job_count] = (struct
mali_job_descriptor_header *) tiler.cpu;
-ctx->tiler_jobs[ctx->tiler_job_count++] = tiler.gpu;
ctx->draw_count++;
}
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index e3dc07059b5..27bb92b8330 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -156,8 +156,6 @@ struct panfrost_context {
unsigned draw_count;
mali_ptr set_value_job;
-mali_ptr vertex_jobs[MAX_DRAW_CALLS];
-mali_ptr tiler_jobs[MAX_DRAW_CALLS];
struct mali_job_descriptor_header *u_set_value_job;
struct mali_job_descriptor_header *u_vertex_jobs[MAX_DRAW_CALLS];
diff --git a/src/gallium/drivers/panfrost/pan_wallpaper.c
b/src/gallium/drivers/panfrost/pan_wallpaper.c
index ac77ad089bc..963ab608ab7 100644
--- a/src/gallium/drivers/panfrost/pan_wallpaper.c
+++ b/src/gallium/drivers/panfrost/pan_wallpaper.c
@@ -250,7 +250,6 @@ panfrost_draw_wallpaper(struct pipe_context *pipe)
struct panfrost_transfer tiler = panfrost_vertex_tiler_job(ctx, true,
true);
struct mali_job_descriptor_header *jd = (struct
mali_job_descriptor_header *) tiler.cpu;
ctx->u_tiler_jobs[ctx->tiler_job_count] = jd;
-ctx->tiler_jobs[ctx->tiler_job_count++] = tiler.gpu;
ctx->draw_count++;
/* Okay, so we have the tiler job emitted. Since we set elided_tiler
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH libdrm 6/9] panfrost/midgard: Remove duplicated header
--- src/gallium/drivers/panfrost/pan_context.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/drivers/panfrost/pan_context.c b/src/gallium/drivers/panfrost/pan_context.c index 66762a010f8..eaceaa8725e 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -30,7 +30,6 @@ #include "pan_format.h" #include "util/macros.h" -#include "util/u_format.h" #include "util/u_inlines.h" #include "util/u_upload_mgr.h" #include "util/u_memory.h" -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available
r-b with the vega m ref changed in the commit message. On Wed, Jun 12, 2019 at 11:18 AM Samuel Pitoiset wrote: > > > On 6/12/19 9:58 AM, Michel Dänzer wrote: > > On 2019-06-11 5:03 p.m., Samuel Pitoiset wrote: > >> On 6/11/19 4:56 PM, Alex Deucher wrote: > >>> On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset > >>> wrote: > On VegaM, the visible VRAM size is equal to the VRAM size, which > means only two heaps are exposed. > >>> FWIW, this is not VegaM specific. The vram size could be equal to the > >>> visible vram size on any asic depending on whether the platform > >>> supports large or resizeable BARs or not. > >> Yeah, not saying it's specific to VegaM. It's just the first time I hit > >> this, so I included that patch in the VegaM series. :-) > > I think Alex's point (which I agree with) is that the commit log is > > inaccurate and misleading. > I will update the commit log before pushing. Forgot to do that for v2. > > > > > ___ > 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 110902] mesa-19.1.0/src/broadcom/compiler/vir_opt_redundant_flags.c:104]: (style) Same expression
https://bugs.freedesktop.org/show_bug.cgi?id=110902 Alejandro Piñeiro (freenode IRC: apinheiro) changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Alejandro Piñeiro (freenode IRC: apinheiro) --- Will take a look to this one. -- 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 110902] mesa-19.1.0/src/broadcom/compiler/vir_opt_redundant_flags.c:104]: (style) Same expression
https://bugs.freedesktop.org/show_bug.cgi?id=110902 --- Comment #2 from Alejandro Piñeiro (freenode IRC: apinheiro) --- Following MR includes a patch that should fix this: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1082 -- 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 110468] using swrAVX renders incorrectly at particular resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=110468 --- Comment #10 from pal1000 --- I think that requires another issue report as I don't know if it is caused by VS2019. Also I'll be a bystander to that one because my system doesn't meet the requirements to run swrAVX2. -- 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] [RFC] panfrost/midgard: Hack some bits to get things working on T720
> Any ideas on why these two changes get kmscube working on T720? ...No, absolutely none. You're positive the known_unknown thing is needed? If that's so, I'm really concerned because I was under the impression those were magic structures we didn't need to deal with ourself. If that assumption is... yeesh, this could explain a whole slew of issues on T860 as well that I don't want to dive into... 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] Revert "radv: fix color conversions for normalized uint/sint formats"
Please ignore this patch.
See
https://github.com/doitsujin/dxvk/commit/3b1e03f9887fc7b540c90e9e34e32b46612281bb
On 6/5/19 2:45 PM, Bas Nieuwenhuizen wrote:
r-b
On Wed, Jun 5, 2019 at 12:02 PM Samuel Pitoiset
wrote:
For some reasons, this actually introduced rendering issues with
Far Cry 3 (and probably Far Cry 4). I'm reverting it for now
until I figure out the right fix.
See the following link for reference:
https://github.com/ValveSoftware/Proton/issues/727#issuecomment-498638025
Cc: 19.0 19.1
This reverts commit e03e7c510f571a8867ab7a8604058c075c601a70.
---
src/amd/vulkan/radv_formats.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index d7b560082f6..0434c0641d8 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1034,22 +1034,10 @@ bool radv_format_pack_clear_color(VkFormat format,
assert(channel->size == 8);
v =
util_format_linear_float_to_srgb_8unorm(value->float32[c]);
- } else {
- float f = MIN2(value->float32[c], 1.0f);
-
- if (channel->type == VK_FORMAT_TYPE_UNSIGNED) {
- f = MAX2(f, 0.0f) * ((1ULL <<
channel->size) - 1);
- } else {
- f = MAX2(f, -1.0f) * ((1ULL <<
(channel->size - 1)) - 1);
- }
-
- /* The hardware rounds before conversion. */
- if (f > 0)
- f += 0.5f;
- else
- f -= 0.5f;
-
- v = (uint64_t)f;
+ } else if (channel->type == VK_FORMAT_TYPE_UNSIGNED) {
+ v = MAX2(MIN2(value->float32[c], 1.0f), 0.0f) * ((1ULL
<< channel->size) - 1);
+ } else {
+ v = MAX2(MIN2(value->float32[c], 1.0f), -1.0f) * ((1ULL
<< (channel->size - 1)) - 1);
}
} else if (channel->type == VK_FORMAT_TYPE_FLOAT) {
if (channel->size == 32) {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] panfrost/midgard: Hack some bits to get things working on T720
> +uint32_t *known_unknown = ((void*)ctx->misc_0.cpu + 40960); > +*known_unknown = 0xa000; > + This is doubly scary, since misc_0 is marked INVISIBLE/GROWABLE. Rob has been coding under the assumption growable must never be accessed CPU-side. If this is strictly necessary (and not just covering up a different bug), this would potentially require kernel side assistance. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 Emil Velikov changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |emil.l.veli...@gmail.com |org | Status|NEW |ASSIGNED --- Comment #3 from Emil Velikov --- Seems like mutter checks the EGLDevice codepath - eglGetPlatformDisplay + eglInitialize and then checks the required extensions. On case they're not found, eglTerminate is not called. Thus as the GBM codepath is hit, due to the libdrm_amdgpu amdgpu_device cache, we end up using the EGLDevice (EGL_EXT_platform_device) amdgpu_device. Which seemingly does not work. I'm working on a mutter MR and will add the links shortly. Including backports all the way back to 3.30. -- 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 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 --- Comment #4 from Michel Dänzer --- Created attachment 144522 --> https://bugs.freedesktop.org/attachment.cgi?id=144522&action=edit amdgpu: Compare DRM node type as well in fd_compare -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110903] Can't start mutter or GDM with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110903 Michel Dänzer changed: What|Removed |Added QA Contact|mesa-dev@lists.freedesktop. | |org | Product|Mesa|DRI CC||ckoenig.leichtzumerken@gmai ||l.com Component|EGL |libdrm Version|git |unspecified --- Comment #5 from Michel Dänzer --- It breaks because the cached amdgpu_device unavoidably uses a different DRM file descriptor from the one mutter uses for KMS (which it gets independently from libdrm(_amdgpu)/EGL/GBM), so GEM objects created in the former aren't visible in the latter. The libdrm_amdgpu patch I attached makes this particular case work, because the two file descriptors are for different DRM node types (render vs. card). But it could still break if the cached amdgpu_device is for the same node type as the new file descriptor passed in. Christian, can you remind us in what cases re-using a cached admgpu_device is required? -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110901] mesa-19.1.0/src/util/futex.h:82: use of out of scope variable ?
https://bugs.freedesktop.org/show_bug.cgi?id=110901 --- Comment #1 from Eric Engestrom --- Indeed, that's a dangling pointer to data that should not exist anymore, good catch! I just posted an MR with a fix, can you compile-test it for me? I don't have a FreeBSD machine available. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1086 How did you find this btw? The error message doesn't look familiar to me and looking it up doesn't return many results. I'd love to be able to find these myself :) -- 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 110884] can't start GDM when building mesa master branch with LTO
https://bugs.freedesktop.org/show_bug.cgi?id=110884 Caio Marcelo de Oliveira Filho changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |caio.olive...@intel.com |org | --- Comment #5 from Caio Marcelo de Oliveira Filho --- I had a conversation with Thiago, and we need the patch needs an update. I'll create an MR in GitLab with those. -- 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 110884] can't start GDM when building mesa master branch with LTO
https://bugs.freedesktop.org/show_bug.cgi?id=110884 --- Comment #6 from Caio Marcelo de Oliveira Filho --- (In reply to Caio Marcelo de Oliveira Filho from comment #5) > I had a conversation with Thiago, and we need the patch needs an update. > I'll create an MR in GitLab with those. I meant: "We think the patch needs an update" -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?
On Wed, 2019-06-12 at 10:29 +0200, Erik Faye-Lund wrote: > On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote: > > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote: > > > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote: > > > > > > > So here's the question: How does people feel about hosting this under > > > > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with > > > > this, I will make that happen, and send out a patch to update the link > > > > we have in our FAQ once that's done. > > > > > > Sounds fine to me. I've needed to refer to the SI more than once, I'd > > > be happy to have it in a well-known location. > > > > > > Vaguely related: Old-timers may remember that DRI used to have its own > > > CVS repo on dri.sourceforge.net. If you want a git import of that tree, > > > you can find it here: > > > > > > https://gitlab.freedesktop.org/ajax/dri > > > > Hmm, for some reason I can't see the repo here, just the (empty) issue > > tracker. Even though the project is listed as public... Strange. Weirdly there are separate controls for project and repository visibility, and the latter was set to "Only project members" for some reason. Fixed, thanks! > > > I'd be happy to move this under mesa/ too if we want. > > > > I think that'd be nice, yeah. I think it would be nice to keep things > > like this in some central location. > > > > One could also imagine that the SGI GLX realease in it's original form > > would be interesting to preserve in case other mirrors go down as well. > > Just for the heck of it, I've archived that as well, even though it's > > just a single tarball, so it ends up as just a single commit: > > > > https://gitlab.freedesktop.org/kusma/glx > > > > This could also be a candidate for moving under the mesa-group. > > Actually, perhaps this one belongs under the xorg-group instead of the > mesa-group... Yeah, toss-up really. The glx code drop has both the client library and server support, so it's not entirely one or the other. libGL used to live only in the X11 monolith, and (iirc) we moved it to Mesa during m12n so it lived near the DRI drivers since that interface kept growing. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110901] mesa-19.1.0/src/util/futex.h:82: use of out of scope variable ?
https://bugs.freedesktop.org/show_bug.cgi?id=110901 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Engestrom --- Fixed by: commit 9996ddbb27c9eb39cd234a4abce6c3742572c770 Author: Eric Engestrom Date: Wed Jun 12 17:23:27 2019 +0100 util/futex: fix dangling pointer use I'm still curious how you found this though ;) -- 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] ac: add radeon_info::is_amdgpu instead of checking drm_major == 3
From: Marek Olšák
and clean up
---
src/amd/common/ac_gpu_info.c | 13 --
src/amd/common/ac_gpu_info.h | 1 +
src/amd/vulkan/radv_debug.c | 5 +-
src/gallium/drivers/r600/r600_buffer_common.c | 6 +--
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe_common.c | 46 ++-
src/gallium/drivers/r600/r600_query.c | 2 +-
src/gallium/drivers/r600/r600_texture.c | 2 +-
src/gallium/drivers/r600/radeon_uvd.c | 3 +-
src/gallium/drivers/r600/radeon_vce.c | 5 +-
src/gallium/drivers/radeon/radeon_uvd.c | 2 +-
src/gallium/drivers/radeon/radeon_vce.c | 6 +--
src/gallium/drivers/radeonsi/si_buffer.c | 2 +-
src/gallium/drivers/radeonsi/si_debug.c | 2 +-
src/gallium/drivers/radeonsi/si_get.c | 4 +-
src/gallium/drivers/radeonsi/si_pipe.c| 4 +-
src/gallium/drivers/radeonsi/si_query.c | 2 +-
src/gallium/drivers/radeonsi/si_state.c | 2 +-
.../winsys/radeon/drm/radeon_drm_winsys.c | 1 +
19 files changed, 33 insertions(+), 77 deletions(-)
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 13fba8df047..4de6882f15e 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -110,20 +110,23 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
if (r) {
fprintf(stderr, "amdgpu: drmGetDevice2 failed.\n");
return false;
}
info->pci_domain = devinfo->businfo.pci->domain;
info->pci_bus = devinfo->businfo.pci->bus;
info->pci_dev = devinfo->businfo.pci->dev;
info->pci_func = devinfo->businfo.pci->func;
drmFreeDevice(&devinfo);
+ assert(info->drm_major == 3);
+ info->is_amdgpu = true;
+
/* Query hardware and driver information. */
r = amdgpu_query_gpu_info(dev, amdinfo);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_gpu_info failed.\n");
return false;
}
r = amdgpu_query_info(dev, AMDGPU_INFO_DEV_INFO, sizeof(device_info),
&device_info);
if (r) {
@@ -154,45 +157,45 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(compute)
failed.\n");
return false;
}
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD, 0, &uvd);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(uvd)
failed.\n");
return false;
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD_ENC, 0,
&uvd_enc);
if (r) {
fprintf(stderr, "amdgpu:
amdgpu_query_hw_ip_info(uvd_enc) failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_DEC, 0,
&vcn_dec);
if (r) {
fprintf(stderr, "amdgpu:
amdgpu_query_hw_ip_info(vcn_dec) failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_ENC, 0,
&vcn_enc);
if (r) {
fprintf(stderr, "amdgpu:
amdgpu_query_hw_ip_info(vcn_enc) failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 27) {
+ if (info->drm_minor >= 27) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_JPEG, 0,
&vcn_jpeg);
if (r) {
fprintf(stderr, "amdgpu:
amdgpu_query_hw_ip_info(vcn_jpeg) failed.\n");
return false;
}
}
r = amdgpu_query_firmware_version(dev, AMDGPU_INFO_FW_GFX_ME, 0, 0,
&info->me_fw_version,
&info->me_fw_feature);
@@ -737,21 +740,21 @@ ac_get_raster_config(struct radeon_info *info,
fprintf(stderr,
"ac: Unknown GPU, using 0 for raster_config\n");
raster_config = 0x;
raster_config_1 = 0x;
break;
}
/* drm/radeon on Kaveri is buggy, so disable 1 RB to work around it.
* This decreases performance by up to 50% when the RB is the
bottleneck.
*/
- if (info->family == CHIP_KAVERI && info->drm_major == 2)
+ if (info->family == CHIP_KAVERI && !info->is_amdgpu)
raster_config = 0x;
[Mesa-dev] [Bug 110901] mesa-19.1.0/src/util/futex.h:82: use of out of scope variable ?
https://bugs.freedesktop.org/show_bug.cgi?id=110901 --- Comment #3 from dcb...@hotmail.com --- I found this by using a static analysis tool called cppcheck. I strongly recommend it for all C and C++ code. Not everything it mentions is worth fixing, but it does a deeper code analysis than almost all compilers. I have no FreeBSD machine here either. -- 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 04/10] radeonsi: use ac_shader_config
On Wed, May 8, 2019 at 1:52 AM Marek Olšák wrote:
> On Fri, May 3, 2019 at 7:19 AM Nicolai Hähnle wrote:
>
>> From: Nicolai Hähnle
>>
>> ---
>> src/amd/common/ac_binary.c| 2 +
>> src/gallium/drivers/radeonsi/si_compute.c | 14 +--
>> src/gallium/drivers/radeonsi/si_shader.c | 112 +++---
>> src/gallium/drivers/radeonsi/si_shader.h | 25 +
>> 4 files changed, 27 insertions(+), 126 deletions(-)
>>
>> diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
>> index 44251886b5f..d0ca55e0e0d 100644
>> --- a/src/amd/common/ac_binary.c
>> +++ b/src/amd/common/ac_binary.c
>> @@ -218,26 +218,28 @@ void ac_parse_shader_binary_config(const char
>> *data, size_t nbytes,
>> unsigned value = util_le32_to_cpu(*(uint32_t*)(data + i +
>> 4));
>> switch (reg) {
>> case R_00B028_SPI_SHADER_PGM_RSRC1_PS:
>> case R_00B128_SPI_SHADER_PGM_RSRC1_VS:
>> case R_00B228_SPI_SHADER_PGM_RSRC1_GS:
>> case R_00B848_COMPUTE_PGM_RSRC1:
>> case R_00B428_SPI_SHADER_PGM_RSRC1_HS:
>> conf->num_sgprs = MAX2(conf->num_sgprs,
>> (G_00B028_SGPRS(value) + 1) * 8);
>> conf->num_vgprs = MAX2(conf->num_vgprs,
>> (G_00B028_VGPRS(value) + 1) * 4);
>> conf->float_mode = G_00B028_FLOAT_MODE(value);
>> + conf->rsrc1 = value;
>> break;
>> case R_00B02C_SPI_SHADER_PGM_RSRC2_PS:
>> conf->lds_size = MAX2(conf->lds_size,
>> G_00B02C_EXTRA_LDS_SIZE(value));
>> break;
>> case R_00B84C_COMPUTE_PGM_RSRC2:
>> conf->lds_size = MAX2(conf->lds_size,
>> G_00B84C_LDS_SIZE(value));
>> + conf->rsrc2 = value;
>> break;
>> case R_0286CC_SPI_PS_INPUT_ENA:
>> conf->spi_ps_input_ena = value;
>> break;
>> case R_0286D0_SPI_PS_INPUT_ADDR:
>> conf->spi_ps_input_addr = value;
>> break;
>> case R_0286E8_SPI_TMPRING_SIZE:
>> case R_00B860_COMPUTE_TMPRING_SIZE:
>> /* WAVESIZE is in units of 256 dwords. */
>> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> b/src/gallium/drivers/radeonsi/si_compute.c
>> index 541d7e6f118..02d7bac406a 100644
>> --- a/src/gallium/drivers/radeonsi/si_compute.c
>> +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> @@ -59,21 +59,21 @@ static const amd_kernel_code_t
>> *si_compute_get_code_object(
>> uint64_t symbol_offset)
>> {
>> if (!program->use_code_object_v2) {
>> return NULL;
>> }
>> return (const amd_kernel_code_t*)
>> (program->shader.binary.code + symbol_offset);
>> }
>>
>> static void code_object_to_config(const amd_kernel_code_t *code_object,
>> - struct si_shader_config *out_config) {
>> + struct ac_shader_config *out_config) {
>>
>> uint32_t rsrc1 = code_object->compute_pgm_resource_registers;
>> uint32_t rsrc2 = code_object->compute_pgm_resource_registers >>
>> 32;
>> out_config->num_sgprs = code_object->wavefront_sgpr_count;
>> out_config->num_vgprs = code_object->workitem_vgpr_count;
>> out_config->float_mode = G_00B028_FLOAT_MODE(rsrc1);
>> out_config->rsrc1 = rsrc1;
>> out_config->lds_size = MAX2(out_config->lds_size,
>> G_00B84C_LDS_SIZE(rsrc2));
>> out_config->rsrc2 = rsrc2;
>> out_config->scratch_bytes_per_wave =
>> @@ -241,22 +241,22 @@ static void *si_create_compute_state(
>> const amd_kernel_code_t *code_object =
>> si_compute_get_code_object(program, 0);
>> code_object_to_config(code_object,
>> &program->shader.config);
>> if (program->shader.binary.reloc_count != 0) {
>> fprintf(stderr, "Error: %d unsupported
>> relocations\n",
>>
>> program->shader.binary.reloc_count);
>> FREE(program);
>> return NULL;
>> }
>> } else {
>> -
>> si_shader_binary_read_config(&program->shader.binary,
>> -&program->shader.config, 0);
>> +
>> ac_shader_binary_read_config(&program->shader.binary,
>> +&program->shader.config, 0, false);
>> }
>> si_shader_dump(sctx->screen, &program->shader,
>> &sctx->debug,
>>PIPE_SHADER_COMPUTE, stderr, true);
>> if (si_shader_binary_upload(sctx->screen,
>> &program->shader) < 0) {
>> fpri
[Mesa-dev] [Bug 110884] can't start GDM when building mesa master branch with LTO
https://bugs.freedesktop.org/show_bug.cgi?id=110884 --- Comment #7 from Caio Marcelo de Oliveira Filho --- Candidate MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1090 -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] ac/rtld: check correct LDS max size
From: Marek Olšák
---
src/amd/common/ac_rtld.c | 8 +++-
src/amd/common/ac_rtld.h | 2 ++
src/gallium/drivers/radeonsi/si_shader.c | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_rtld.c b/src/amd/common/ac_rtld.c
index c750dbfa9cb..18f198f8af2 100644
--- a/src/amd/common/ac_rtld.c
+++ b/src/amd/common/ac_rtld.c
@@ -273,21 +273,27 @@ bool ac_rtld_open(struct ac_rtld_binary *binary,
if (!util_dynarray_resize(&binary->lds_symbols, struct
ac_rtld_symbol,
i.num_shared_lds_symbols))
goto fail;
memcpy(binary->lds_symbols.data, i.shared_lds_symbols,
binary->lds_symbols.size);
}
util_dynarray_foreach(&binary->lds_symbols, struct ac_rtld_symbol,
symbol)
symbol->part_idx = ~0u;
- unsigned max_lds_size = i.info->chip_class >= GFX7 ? 64 * 1024 : 32 *
1024;
+ unsigned max_lds_size = 64 * 1024;
+
+ if (i.info->chip_class == GFX6 ||
+ (i.shader_type != MESA_SHADER_COMPUTE &&
+i.shader_type != MESA_SHADER_FRAGMENT))
+ max_lds_size = 32 * 1024;
+
uint64_t shared_lds_size = 0;
if (!layout_symbols(binary->lds_symbols.data, i.num_shared_lds_symbols,
&shared_lds_size))
goto fail;
report_if(shared_lds_size > max_lds_size);
binary->lds_size = shared_lds_size;
/* First pass over all parts: open ELFs, pre-determine the placement of
* sections in the memory image, and collect and layout private LDS
symbols. */
uint32_t lds_end_align = 0;
diff --git a/src/amd/common/ac_rtld.h b/src/amd/common/ac_rtld.h
index b13270b181d..3f60444f85e 100644
--- a/src/amd/common/ac_rtld.h
+++ b/src/amd/common/ac_rtld.h
@@ -22,20 +22,21 @@
*/
#ifndef AC_RTLD_H
#define AC_RTLD_H
#include
#include
#include
#include "util/u_dynarray.h"
+#include "compiler/shader_enums.h"
struct ac_rtld_part;
struct ac_shader_config;
struct radeon_info;
struct ac_rtld_symbol {
const char *name;
uint32_t size;
uint32_t align;
uint64_t offset; /* filled in by ac_rtld_open */
@@ -77,20 +78,21 @@ typedef bool (*ac_rtld_get_external_symbol_cb)(
void *cb_data, const char *symbol, uint64_t *value);
/**
* Lifetimes of \ref info, in-memory ELF objects, and the names of
* \ref shared_lds_symbols must extend until \ref ac_rtld_close is called on
* the opened binary.
*/
struct ac_rtld_open_info {
const struct radeon_info *info;
struct ac_rtld_options options;
+ gl_shader_stage shader_type;
unsigned num_parts;
const char * const *elf_ptrs; /* in-memory ELF objects of each part */
const size_t *elf_sizes; /* sizes of corresponding in-memory ELF
objects in bytes */
/* Shared LDS symbols are layouted such that they are accessible from
* all shader parts. Non-shared (private) LDS symbols of one part may
* overlap private LDS symbols of another shader part.
*/
unsigned num_shared_lds_symbols;
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 3c3d74ce7af..88d32582799 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -21,20 +21,21 @@
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include "util/u_memory.h"
#include "util/u_string.h"
#include "tgsi/tgsi_build.h"
#include "tgsi/tgsi_strings.h"
#include "tgsi/tgsi_util.h"
#include "tgsi/tgsi_dump.h"
+#include "tgsi/tgsi_from_mesa.h"
#include "ac_binary.h"
#include "ac_exp_param.h"
#include "ac_shader_util.h"
#include "ac_rtld.h"
#include "ac_llvm_util.h"
#include "si_shader_internal.h"
#include "si_pipe.h"
#include "sid.h"
@@ -5091,20 +5092,21 @@ static void si_llvm_emit_polygon_stipple(struct
si_shader_context *ctx,
/* For the UMR disassembler. */
#define DEBUGGER_END_OF_CODE_MARKER0xbf9f /* invalid instruction */
#define DEBUGGER_NUM_MARKERS 5
static bool si_shader_binary_open(struct si_screen *screen,
struct si_shader *shader,
struct ac_rtld_binary *rtld)
{
const struct si_shader_selector *sel = shader->selector;
+ enum pipe_shader_type shader_type = sel ? sel->type :
PIPE_SHADER_COMPUTE;
const char *part_elfs[5];
size_t part_sizes[5];
unsigned num_parts = 0;
#define add_part(shader_or_part) \
if (shader_or_part) { \
part_elfs[num_parts] = (shader_or_part)->binary.elf_buffer; \
part_sizes[num_parts] = (shader_or_part)->binary.elf_size; \
num_parts++; \
}
@@ -5129,20 +5131,21 @@ static bool si_shader_binary_open(struct si_screen
[Mesa-dev] [PATCH 4/7] radeonsi: add s_sethalt to shaders for debugging
From: Nicolai Hähnle
---
src/amd/common/ac_rtld.c| 9 +
src/amd/common/ac_rtld.h| 9 +
src/gallium/drivers/radeonsi/si_debug_options.h | 1 +
src/gallium/drivers/radeonsi/si_shader.c| 3 +++
4 files changed, 22 insertions(+)
diff --git a/src/amd/common/ac_rtld.c b/src/amd/common/ac_rtld.c
index 92020c5f0dd..c750dbfa9cb 100644
--- a/src/amd/common/ac_rtld.c
+++ b/src/amd/common/ac_rtld.c
@@ -236,20 +236,21 @@ static bool read_private_lds_symbols(struct
ac_rtld_binary *binary,
bool ac_rtld_open(struct ac_rtld_binary *binary,
struct ac_rtld_open_info i)
{
/* One of the libelf implementations
* (http://www.mr511.de/software/english.htm) requires calling
* elf_version() before elf_memory().
*/
elf_version(EV_CURRENT);
memset(binary, 0, sizeof(*binary));
+ memcpy(&binary->options, &i.options, sizeof(binary->options));
binary->num_parts = i.num_parts;
binary->parts = calloc(sizeof(*binary->parts), i.num_parts);
if (!binary->parts)
return false;
uint64_t pasted_text_size = 0;
uint64_t rx_align = 1;
uint64_t rx_size = 0;
#define report_if(cond) \
@@ -283,20 +284,23 @@ bool ac_rtld_open(struct ac_rtld_binary *binary,
uint64_t shared_lds_size = 0;
if (!layout_symbols(binary->lds_symbols.data, i.num_shared_lds_symbols,
&shared_lds_size))
goto fail;
report_if(shared_lds_size > max_lds_size);
binary->lds_size = shared_lds_size;
/* First pass over all parts: open ELFs, pre-determine the placement of
* sections in the memory image, and collect and layout private LDS
symbols. */
uint32_t lds_end_align = 0;
+ if (binary->options.halt_at_entry)
+ pasted_text_size += 4;
+
for (unsigned part_idx = 0; part_idx < i.num_parts; ++part_idx) {
struct ac_rtld_part *part = &binary->parts[part_idx];
unsigned part_lds_symbols_begin =
util_dynarray_num_elements(&binary->lds_symbols, struct
ac_rtld_symbol);
part->elf = elf_memory((char *)i.elf_ptrs[part_idx],
i.elf_sizes[part_idx]);
report_elf_if(!part->elf);
const Elf64_Ehdr *ehdr = elf64_getehdr(part->elf);
report_elf_if(!ehdr);
@@ -685,20 +689,25 @@ bool ac_rtld_upload(struct ac_rtld_upload_info *u)
} \
} while (false)
#define report_elf_if(cond) \
do { \
if ((cond)) { \
report_errorf(#cond); \
return false; \
} \
} while (false)
+ if (u->binary->options.halt_at_entry) {
+ /* s_sethalt 1 */
+ *(uint32_t *)u->rx_ptr = util_cpu_to_le32(0xbf8d0001);
+ }
+
/* First pass: upload raw section data and lay out private LDS symbols.
*/
for (unsigned i = 0; i < u->binary->num_parts; ++i) {
struct ac_rtld_part *part = &u->binary->parts[i];
Elf_Scn *section = NULL;
while ((section = elf_nextscn(part->elf, section))) {
Elf64_Shdr *shdr = elf64_getshdr(section);
struct ac_rtld_section *s =
&part->sections[elf_ndxscn(section)];
if (!s->is_rx)
diff --git a/src/amd/common/ac_rtld.h b/src/amd/common/ac_rtld.h
index 01c29b50817..b13270b181d 100644
--- a/src/amd/common/ac_rtld.h
+++ b/src/amd/common/ac_rtld.h
@@ -35,22 +35,30 @@ struct ac_shader_config;
struct radeon_info;
struct ac_rtld_symbol {
const char *name;
uint32_t size;
uint32_t align;
uint64_t offset; /* filled in by ac_rtld_open */
unsigned part_idx; /* shader part in which this symbol appears */
};
+struct ac_rtld_options {
+ /* Loader will insert an s_sethalt 1 instruction as the
+* first instruction. */
+ bool halt_at_entry:1;
+};
+
/* Lightweight wrapper around underlying ELF objects. */
struct ac_rtld_binary {
+ struct ac_rtld_options options;
+
/* Required buffer sizes, currently read/executable only. */
uint64_t rx_size;
uint64_t rx_end_markers;
unsigned num_parts;
struct ac_rtld_part *parts;
struct util_dynarray lds_symbols;
uint32_t lds_size;
@@ -68,20 +76,21 @@ struct ac_rtld_binary {
typedef bool (*ac_rtld_get_external_symbol_cb)(
void *cb_data, const char *symbol, uint64_t *value);
/**
* Lifetimes of \ref info, in-memory ELF objects, and the names of
* \ref shared_lds_symbols must extend until \ref ac_rtld_close is called on
* the opened binary.
*/
struct ac_rtld_open_info {
const struct radeon_info *info;
+ struct ac_rtld_options options;
unsigned num_parts;
const char * const *elf_ptrs; /* in-memo
[Mesa-dev] [PATCH 6/7] ac/rtld: report better error messages for LDS overallocation
From: Nicolai Hähnle
---
src/amd/common/ac_rtld.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_rtld.c b/src/amd/common/ac_rtld.c
index 18f198f8af2..57d6b0151b4 100644
--- a/src/amd/common/ac_rtld.c
+++ b/src/amd/common/ac_rtld.c
@@ -283,21 +283,26 @@ bool ac_rtld_open(struct ac_rtld_binary *binary,
unsigned max_lds_size = 64 * 1024;
if (i.info->chip_class == GFX6 ||
(i.shader_type != MESA_SHADER_COMPUTE &&
i.shader_type != MESA_SHADER_FRAGMENT))
max_lds_size = 32 * 1024;
uint64_t shared_lds_size = 0;
if (!layout_symbols(binary->lds_symbols.data, i.num_shared_lds_symbols,
&shared_lds_size))
goto fail;
- report_if(shared_lds_size > max_lds_size);
+
+ if (shared_lds_size > max_lds_size) {
+ fprintf(stderr, "ac_rtld error(1): too much LDS (used = %u, max
= %u)\n",
+ (unsigned)shared_lds_size, max_lds_size);
+ goto fail;
+ }
binary->lds_size = shared_lds_size;
/* First pass over all parts: open ELFs, pre-determine the placement of
* sections in the memory image, and collect and layout private LDS
symbols. */
uint32_t lds_end_align = 0;
if (binary->options.halt_at_entry)
pasted_text_size += 4;
for (unsigned part_idx = 0; part_idx < i.num_parts; ++part_idx) {
@@ -384,21 +389,25 @@ bool ac_rtld_open(struct ac_rtld_binary *binary,
struct ac_rtld_symbol *lds_end =
util_dynarray_grow(&binary->lds_symbols, struct
ac_rtld_symbol, 1);
lds_end->name = "__lds_end";
lds_end->size = 0;
lds_end->align = lds_end_align;
lds_end->offset = binary->lds_size;
lds_end->part_idx = ~0u;
}
- report_elf_if(binary->lds_size > max_lds_size);
+ if (binary->lds_size > max_lds_size) {
+ fprintf(stderr, "ac_rtld error(2): too much LDS (used = %u, max
= %u)\n",
+ (unsigned)binary->lds_size, max_lds_size);
+ goto fail;
+ }
/* Second pass: Adjust offsets of non-pasted text sections. */
binary->rx_size = pasted_text_size;
binary->rx_size = align(binary->rx_size, rx_align);
for (unsigned part_idx = 0; part_idx < i.num_parts; ++part_idx) {
struct ac_rtld_part *part = &binary->parts[part_idx];
size_t num_shdrs;
elf_getshdrnum(part->elf, &num_shdrs);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] ac/registers: use better names for disambiguated definitions
From: Marek Olšák --- src/amd/registers/makeregheader.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/amd/registers/makeregheader.py b/src/amd/registers/makeregheader.py index 859a59b9f3e..1d73cb47bdf 100644 --- a/src/amd/registers/makeregheader.py +++ b/src/amd/registers/makeregheader.py @@ -37,24 +37,24 @@ import re import sys from regdb import Object, RegisterDatabase, deduplicate_enums, deduplicate_register_types # BEGIN HARDCODED CONFIGURATION # Chips are sorted chronologically CHIPS = [ Object(name='gfx6', disambiguation='GFX6'), -Object(name='gfx7', disambiguation='GFX6'), -Object(name='gfx8', disambiguation='GFX6'), -Object(name='fiji', disambiguation='GFX6'), -Object(name='stoney', disambiguation='GFX6'), +Object(name='gfx7', disambiguation='GFX7'), +Object(name='gfx8', disambiguation='GFX8'), +Object(name='fiji', disambiguation='GFX8'), +Object(name='stoney', disambiguation='GFX8'), Object(name='gfx9', disambiguation='GFX9'), ] # END HARDCODED CONFIGURATION def get_chip_index(chip): """ Given a chip name, return its index in the global CHIPS list. """ return next(idx for idx, obj in enumerate(CHIPS) if obj.name == chip) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] radeonsi: don't use the low-optimizing compiler on LLVM 9
From: Marek Olšák
The compilation is faster on LLVM 9.
---
src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 8527999645b..d2fd058f2cd 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -115,21 +115,22 @@ static const struct debug_named_value debug_options[] = {
DEBUG_NAMED_VALUE_END /* must be last */
};
static void si_init_compiler(struct si_screen *sscreen,
struct ac_llvm_compiler *compiler)
{
/* Only create the less-optimizing version of the compiler on APUs
* predating Ryzen (Raven). */
bool create_low_opt_compiler = !sscreen->info.has_dedicated_vram &&
- sscreen->info.chip_class <= GFX8;
+ sscreen->info.chip_class <= GFX8 &&
+ HAVE_LLVM < 0x0900;
enum ac_target_machine_options tm_options =
(sscreen->debug_flags & DBG(SI_SCHED) ? AC_TM_SISCHED : 0) |
(sscreen->debug_flags & DBG(GISEL) ? AC_TM_ENABLE_GLOBAL_ISEL :
0) |
(sscreen->info.chip_class >= GFX9 ? AC_TM_FORCE_ENABLE_XNACK :
0) |
(sscreen->info.chip_class < GFX9 ? AC_TM_FORCE_DISABLE_XNACK :
0) |
(!sscreen->llvm_has_working_vgpr_indexing ?
AC_TM_PROMOTE_ALLOCA_TO_SCRATCH : 0) |
(sscreen->debug_flags & DBG(CHECK_IR) ? AC_TM_CHECK_IR : 0) |
(create_low_opt_compiler ? AC_TM_CREATE_LOW_OPT : 0);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] ac/registers: remove deprecated/inapplicable definitions
From: Marek Olšák
---
src/amd/registers/amdgfxregs.json | 180 --
1 file changed, 180 deletions(-)
diff --git a/src/amd/registers/amdgfxregs.json
b/src/amd/registers/amdgfxregs.json
index 371efef7201..23643c3dc7b 100644
--- a/src/amd/registers/amdgfxregs.json
+++ b/src/amd/registers/amdgfxregs.json
@@ -706,26 +706,20 @@
{"name": "IMG_DATA_FORMAT_BC2", "value": 36},
{"name": "IMG_DATA_FORMAT_BC3", "value": 37},
{"name": "IMG_DATA_FORMAT_BC4", "value": 38},
{"name": "IMG_DATA_FORMAT_BC5", "value": 39},
{"name": "IMG_DATA_FORMAT_BC6", "value": 40},
{"name": "IMG_DATA_FORMAT_BC7", "value": 41},
{"name": "IMG_DATA_FORMAT_16_AS_32_32", "value": 42},
{"name": "IMG_DATA_FORMAT_16_AS_16_16_16_16", "value": 43},
{"name": "IMG_DATA_FORMAT_16_AS_32_32_32_32", "value": 44},
{"comment": "NUM_FORMAT selects the format", "name":
"IMG_DATA_FORMAT_FMASK", "value": 45},
-{"comment": "NUM_FORMAT selects the block size", "name":
"IMG_DATA_FORMAT_ASTC_2D_LDR", "value": 46},
-{"comment": "ditto", "name": "IMG_DATA_FORMAT_ASTC_2D_HDR", "value": 47},
-{"comment": "ditto", "name": "IMG_DATA_FORMAT_ASTC_2D_LDR_SRGB", "value":
48},
-{"comment": "ditto", "name": "IMG_DATA_FORMAT_ASTC_3D_LDR", "value": 49},
-{"comment": "ditto", "name": "IMG_DATA_FORMAT_ASTC_3D_HDR", "value": 50},
-{"comment": "ditto", "name": "IMG_DATA_FORMAT_ASTC_3D_LDR_SRGB", "value":
51},
{"name": "IMG_DATA_FORMAT_N_IN_16", "value": 52},
{"name": "IMG_DATA_FORMAT_N_IN_16_16", "value": 53},
{"name": "IMG_DATA_FORMAT_N_IN_16_16_16_16", "value": 54},
{"name": "IMG_DATA_FORMAT_N_IN_16_AS_16_16_16_16", "value": 55},
{"name": "IMG_DATA_FORMAT_RESERVED_56", "value": 56},
{"name": "IMG_DATA_FORMAT_4_4", "value": 57},
{"name": "IMG_DATA_FORMAT_6_5_5", "value": 58},
{"name": "IMG_DATA_FORMAT_S8_16", "value": 59},
{"name": "IMG_DATA_FORMAT_S8_32", "value": 60},
{"name": "IMG_DATA_FORMAT_8_AS_32", "value": 61},
@@ -1359,64 +1353,20 @@
{"name": "THREAD_TRACE_MARKER", "value": 53},
{"name": "THREAD_TRACE_FLUSH", "value": 54},
{"name": "THREAD_TRACE_FINISH", "value": 55},
{"name": "PIXEL_PIPE_STAT_CONTROL", "value": 56},
{"name": "PIXEL_PIPE_STAT_DUMP", "value": 57},
{"name": "PIXEL_PIPE_STAT_RESET", "value": 58},
{"comment": "new", "name": "ENABLE_NGG_PIPELINE", "value": 61},
{"comment": "new", "name": "ENABLE_LEGACY_PIPELINE", "value": 62}
]
},
- "VGT_GROUP_PRIM_TYPE__PRIM_ORDER": {
- "entries": [
-{"name": "VGT_GRP_LIST", "value": 0},
-{"name": "VGT_GRP_STRIP", "value": 1},
-{"name": "VGT_GRP_FAN", "value": 2},
-{"name": "VGT_GRP_LOOP", "value": 3},
-{"name": "VGT_GRP_POLYGON", "value": 4}
- ]
- },
- "VGT_GROUP_VECT_0_FMT_CNTL__X_CONV": {
- "entries": [
-{"name": "VGT_GRP_INDEX_16", "value": 0},
-{"name": "VGT_GRP_INDEX_32", "value": 1},
-{"name": "VGT_GRP_UINT_16", "value": 2},
-{"name": "VGT_GRP_UINT_32", "value": 3},
-{"name": "VGT_GRP_SINT_16", "value": 4},
-{"name": "VGT_GRP_SINT_32", "value": 5},
-{"name": "VGT_GRP_FLOAT_32", "value": 6},
-{"name": "VGT_GRP_AUTO_PRIM", "value": 7},
-{"name": "VGT_GRP_FIX_1_23_TO_FLOAT", "value": 8}
- ]
- },
- "VGT_GRP_PRIM_TYPE": {
- "entries": [
-{"name": "VGT_GRP_3D_POINT", "value": 0},
-{"name": "VGT_GRP_3D_LINE", "value": 1},
-{"name": "VGT_GRP_3D_TRI", "value": 2},
-{"name": "VGT_GRP_3D_RECT", "value": 3},
-{"name": "VGT_GRP_3D_QUAD", "value": 4},
-{"name": "VGT_GRP_2D_COPY_RECT_V0", "value": 5},
-{"name": "VGT_GRP_2D_COPY_RECT_V1", "value": 6},
-{"name": "VGT_GRP_2D_COPY_RECT_V2", "value": 7},
-{"name": "VGT_GRP_2D_COPY_RECT_V3", "value": 8},
-{"name": "VGT_GRP_2D_FILL_RECT", "value": 9},
-{"name": "VGT_GRP_2D_LINE", "value": 10},
-{"name": "VGT_GRP_2D_TRI", "value": 11},
-{"name": "VGT_GRP_PRIM_INDEX_LINE", "value": 12},
-{"name": "VGT_GRP_PRIM_INDEX_TRI", "value": 13},
-{"name": "VGT_GRP_PRIM_INDEX_QUAD", "value": 14},
-{"name": "VGT_GRP_3D_LINE_ADJ", "value": 15},
-{"name": "VGT_GRP_3D_TRI_ADJ", "value": 16},
-{"name": "VGT_GRP_3D_PATCH", "value": 17}
- ]
- },
"VGT_GS_CUT_MODE": {
"entries": [
{"name": "GS_CUT_1024", "value": 0},
{"name": "GS_CUT_512", "value": 1},
{"name": "GS_CUT_256", "value": 2},
{"name": "GS_CUT_128", "value": 3}
]
},
"VGT_GS_MODE_TYPE": {
"entries": [
@@ -6047,32 +5997,20 @@
"map": {"at": 164400, "to": "mm"},
"name": "PA_SC_EDGERULE",
"type_ref": "PA_SC_EDGERULE"
},
{
"chips": ["gfx7", "fiji", "gfx6", "stoney", "gfx8"],
"map": {"at": 35824, "to": "mm"},
"name": "PA_SC_ENHANCE",
"type_ref": "PA_SC_ENHANCE"
},
- {
- "chips": ["gfx9"],
- "map": {"at": 164780, "to": "mm"},
- "name": "PA_SC_FOV_WINDOW_LR",
- "type_ref": "PA_SC_FOV_WINDOW_LR"
- },
- {
- "chips": ["gfx9"],
-
[Mesa-dev] [PATCH 3/7] amd/rtld: fix sorting of LDS symbols by alignment
From: Nicolai Hähnle
---
src/amd/common/ac_rtld.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_rtld.c b/src/amd/common/ac_rtld.c
index dc9cc04705b..92020c5f0dd 100644
--- a/src/amd/common/ac_rtld.c
+++ b/src/amd/common/ac_rtld.c
@@ -123,23 +123,23 @@ static const struct ac_rtld_symbol *find_symbol(const
struct util_dynarray *symb
return symbol;
}
return 0;
}
static int compare_symbol_by_align(const void *lhsp, const void *rhsp)
{
const struct ac_rtld_symbol *lhs = lhsp;
const struct ac_rtld_symbol *rhs = rhsp;
if (rhs->align > lhs->align)
- return -1;
- if (rhs->align < lhs->align)
return 1;
+ if (rhs->align < lhs->align)
+ return -1;
return 0;
}
/**
* Sort the given symbol list by decreasing alignment and assign offsets.
*/
static bool layout_symbols(struct ac_rtld_symbol *symbols, unsigned
num_symbols,
uint64_t *ptotal_size)
{
qsort(symbols, num_symbols, sizeof(*symbols), compare_symbol_by_align);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 QwertyChouskie changed: What|Removed |Added CC||acc12345...@gmail.com --- Comment #10 from QwertyChouskie --- (In reply to Michel Dänzer from comment #9) > (In reply to QwertyChouskie from comment #8) > > I think this was worked around in the current release of kwin-lowlatency in > > this commit: > > https://github.com/tildearrow/kwin-lowlatency/commit/ > > 73f09f6e11ce806064d0360bef1383e0779d9fa4 > > I've tried the commit before that one as well now, still unable to reproduce. tildearrow, can you give detailed repro steps? -- 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 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 --- Comment #11 from QwertyChouskie --- (In reply to QwertyChouskie from comment #10) > (In reply to Michel Dänzer from comment #9) > > (In reply to QwertyChouskie from comment #8) > > > I think this was worked around in the current release of kwin-lowlatency > > > in > > > this commit: > > > https://github.com/tildearrow/kwin-lowlatency/commit/ > > > 73f09f6e11ce806064d0360bef1383e0779d9fa4 > > > > I've tried the commit before that one as well now, still unable to > > reproduce. > > tildearrow, can you give detailed repro steps? Whoops, missed that they were posted in a comment further down. Here they are again for reference: > The test case has been mentioned already. However I forgot to include > reproduction steps: > 1. Compile kwin-lowlatency (mkdir build && cd build && cmake .. && make) > 2. Launch it with `QT_PLUGIN_PATH="$PWD/bin" ./bin/kwin_x11 --replace` > 3. Move a window to the top left corner as quick as possible and then shake > it horizontally > 4. Keep trying until it freezes (it usually does on the first or second try) (Just make sure to use the older commit for all testing :) -- 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 110709] g_glxglvnddispatchfuncs.c and glxglvnd.c fail to build with clang 8.0
https://bugs.freedesktop.org/show_bug.cgi?id=110709 Sergey Kondakov changed: What|Removed |Added CC||virtuous...@gmail.com --- Comment #2 from Sergey Kondakov --- Thanks for the patch, it helped me to build with clang 7.0.1 too. Why is this not in the release ? Do they not read their bug-tracker any more ? -- 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] [Mesa-stable] [PATCH 3/3] amd: Apply elf relocations and allow code with relocations
FYI, I just pushed the new linker.
Marek
On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely wrote:
> Fixes piglits:
> call.cl
> calls-larget-struct.cl
> calls-struct.cl
> calls-workitem-id.cl
> realign-stack.cl
> tail-calls.cl
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Jan Vesely
> ---
> The piglit test now pass using llvm-7,8,git.
> ImageMagick works on my raven, but some test still fail on
> carrizo/iceland.
> Other workloads (like shoc) that used function calls also work ok.
> ocltoys work after removing static keyword from .cl files.
> src/amd/common/ac_binary.c| 30 +++
> src/gallium/drivers/radeonsi/si_compute.c | 6 -
> 2 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
> index 18dc72c61f0..4d152fcf1be 100644
> --- a/src/amd/common/ac_binary.c
> +++ b/src/amd/common/ac_binary.c
> @@ -178,6 +178,36 @@ bool ac_elf_read(const char *elf_data, unsigned
> elf_size,
>
> parse_relocs(elf, relocs, symbols, symbol_sh_link, binary);
>
> + // Apply relocations
> + for (int i = 0; i < binary->reloc_count; ++i) {
> + struct ac_shader_reloc *r = &binary->relocs[i];
> + uint32_t *loc = (uint32_t*)(binary->code + r->offset);
> + /* Section target relocations store symbol offsets as
> +* values in reloc location. We're expected to adjust it
> for
> +* start of the section. However, R_AMDGPU_REL32 are
> +* PC relative relocations, so we need to recompute the
> +* delta between reloc locatin and the target adress.
> +*/
> + if (r->target_type == 0x3) { // section relocation
> + uint32_t target_offset = *loc; // already adjusted
> + int64_t diff = target_offset - r->offset;
> + if (r->type == 0xa) { // R_AMDGPU_REL32_LO
> + // address of the 'lo' instruction is 4B
> below
> + // the relocation point, but the target has
> + // alredy been adjusted.
> + *loc = (diff & 0x);
> + } else if (r->type == 0xb) { // R_AMDGPU_REL32_HI
> + // 'hi' relocation is 8B above 'lo'
> relocation
> + *loc = ((diff - 8) >> 32);
> + } else {
> + success = false;
> + fprintf(stderr, "Unsupported section
> relocation: type: %d, offset: %lx, value: %x\n",
> + r->type, r->offset, *loc);
> + }
> + } else
> + success = false;
> + }
> +
> if (elf){
> elf_end(elf);
> }
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index b9cea00eeeb..88631369a62 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -246,12 +246,6 @@ static void *si_create_compute_state(
> const amd_kernel_code_t *code_object =
> si_compute_get_code_object(program, 0);
> code_object_to_config(code_object,
> &program->shader.config);
> - if (program->shader.binary.reloc_count != 0) {
> - fprintf(stderr, "Error: %d unsupported
> relocations\n",
> -
> program->shader.binary.reloc_count);
> - FREE(program);
> - return NULL;
> - }
> } else {
>
> si_shader_binary_read_config(&program->shader.binary,
> &program->shader.config, 0);
> --
> 2.21.0
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110849] Flickering triangles in OpenGL apps on Radeon KAVERI
https://bugs.freedesktop.org/show_bug.cgi?id=110849 Heiko Schäfer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Heiko Schäfer --- Either the latest git version or my - very rare - cold reboot solved it. I don't know, but the errors are away :-) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: add radeon_info::is_amdgpu instead of checking drm_major == 3
Why do you need that?
On 6/12/19 11:31 PM, Marek Olšák wrote:
From: Marek Olšák
and clean up
---
src/amd/common/ac_gpu_info.c | 13 --
src/amd/common/ac_gpu_info.h | 1 +
src/amd/vulkan/radv_debug.c | 5 +-
src/gallium/drivers/r600/r600_buffer_common.c | 6 +--
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe_common.c | 46 ++-
src/gallium/drivers/r600/r600_query.c | 2 +-
src/gallium/drivers/r600/r600_texture.c | 2 +-
src/gallium/drivers/r600/radeon_uvd.c | 3 +-
src/gallium/drivers/r600/radeon_vce.c | 5 +-
src/gallium/drivers/radeon/radeon_uvd.c | 2 +-
src/gallium/drivers/radeon/radeon_vce.c | 6 +--
src/gallium/drivers/radeonsi/si_buffer.c | 2 +-
src/gallium/drivers/radeonsi/si_debug.c | 2 +-
src/gallium/drivers/radeonsi/si_get.c | 4 +-
src/gallium/drivers/radeonsi/si_pipe.c| 4 +-
src/gallium/drivers/radeonsi/si_query.c | 2 +-
src/gallium/drivers/radeonsi/si_state.c | 2 +-
.../winsys/radeon/drm/radeon_drm_winsys.c | 1 +
19 files changed, 33 insertions(+), 77 deletions(-)
diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 13fba8df047..4de6882f15e 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -110,20 +110,23 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
if (r) {
fprintf(stderr, "amdgpu: drmGetDevice2 failed.\n");
return false;
}
info->pci_domain = devinfo->businfo.pci->domain;
info->pci_bus = devinfo->businfo.pci->bus;
info->pci_dev = devinfo->businfo.pci->dev;
info->pci_func = devinfo->businfo.pci->func;
drmFreeDevice(&devinfo);
+ assert(info->drm_major == 3);
+ info->is_amdgpu = true;
+
/* Query hardware and driver information. */
r = amdgpu_query_gpu_info(dev, amdinfo);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_gpu_info failed.\n");
return false;
}
r = amdgpu_query_info(dev, AMDGPU_INFO_DEV_INFO, sizeof(device_info),
&device_info);
if (r) {
@@ -154,45 +157,45 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(compute)
failed.\n");
return false;
}
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD, 0, &uvd);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(uvd)
failed.\n");
return false;
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD_ENC, 0,
&uvd_enc);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(uvd_enc)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_DEC, 0,
&vcn_dec);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_dec)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 17) {
+ if (info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_ENC, 0,
&vcn_enc);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_enc)
failed.\n");
return false;
}
}
- if (info->drm_major == 3 && info->drm_minor >= 27) {
+ if (info->drm_minor >= 27) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_JPEG, 0,
&vcn_jpeg);
if (r) {
fprintf(stderr, "amdgpu: amdgpu_query_hw_ip_info(vcn_jpeg)
failed.\n");
return false;
}
}
r = amdgpu_query_firmware_version(dev, AMDGPU_INFO_FW_GFX_ME, 0, 0,
&info->me_fw_version,
&info->me_fw_feature);
@@ -737,21 +740,21 @@ ac_get_raster_config(struct radeon_info *info,
fprintf(stderr,
"ac: Unknown GPU, using 0 for raster_config\n");
raster_config = 0x;
raster_config_1 = 0x;
break;
}
/* drm/radeon on Kaveri is buggy, so disable 1 RB to work around it.
* This decreases performance by up to 50% when the RB is the
bottleneck.
*/
- if (info->family == CHIP_KAVERI && info->drm_major == 2)
+ if (info->family == CHIP_KAVERI && !info->is_am
