[Mesa-dev] [RFC] panfrost/midgard: Hack some bits to get things working on T720

2019-06-12 Thread Tomeu Vizoso
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Michel Dänzer
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

2019-06-12 Thread Juan A. Suarez Romero
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

2019-06-12 Thread Alex Smith
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?

2019-06-12 Thread Erik Faye-Lund
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?

2019-06-12 Thread Erik Faye-Lund
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 ?

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Samuel Pitoiset


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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread Samuel Pitoiset
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
---
 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"

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
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

2019-06-12 Thread Rohan Garg
---
 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

2019-06-12 Thread Bas Nieuwenhuizen
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Alyssa Rosenzweig
> 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"

2019-06-12 Thread Samuel Pitoiset

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

2019-06-12 Thread Alyssa Rosenzweig
> +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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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 ?

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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?

2019-06-12 Thread Adam Jackson
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 ?

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Marek Olšák
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 ?

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Marek Olšák
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

2019-06-12 Thread bugzilla-daemon
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

2019-06-12 Thread Samuel Pitoiset

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