[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20

2019-05-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=110760

Timothy Arceri  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
 CC||t_arc...@yahoo.com.au
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #1 from Timothy Arceri  ---
Thanks for the report. Just something to note, in future you should report
issues you suspect are related to DXVK and the driver to RADV rather than
radeonsi. DXVK runs on the RADV Vulkan driver not the radeonsi OpenGL driver.

I just tried to run this on my Vega 64 with Mesa master and hit:

../src/amd/vulkan/radv_cmd_buffer.c:4839: write_event: Assertion
`cmd_buffer->cs->cdw <= cdw_max' failed.

-- 
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 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus

2019-05-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=39017

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #12 from Timothy Arceri  ---
No reply and no additional reports since 2012 so assuming fixed and closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: add drirc workaround for American Truck Simulator

2019-05-26 Thread Timothy Arceri 
Cc: "19.0" "19.1" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110711
---
 src/util/00-mesa-defaults.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index 3c459f3dec4..e36190f61c8 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -471,6 +471,9 @@ TODO: document the other workarounds.
 
 
 
+
+
+
 
 
 
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600: Cleanup "nir" debug option.

2019-05-26 Thread Bas Nieuwenhuizen 
r600g does not have a nir compiler, and radeonsi does not use the
option either.
---
 src/gallium/drivers/r600/r600_pipe_common.c | 1 -
 src/gallium/drivers/r600/r600_pipe_common.h | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_pipe_common.c 
b/src/gallium/drivers/r600/r600_pipe_common.c
index 5177ff4e1c6..b1ad0d7d23b 100644
--- a/src/gallium/drivers/r600/r600_pipe_common.c
+++ b/src/gallium/drivers/r600/r600_pipe_common.c
@@ -741,7 +741,6 @@ void r600_common_context_cleanup(struct r600_common_context 
*rctx)
 static const struct debug_named_value common_debug_options[] = {
/* logging */
{ "tex", DBG_TEX, "Print texture info" },
-   { "nir", DBG_NIR, "Enable experimental NIR shaders" },
{ "compute", DBG_COMPUTE, "Print compute info" },
{ "vm", DBG_VM, "Print virtual addresses when creating resources" },
{ "info", DBG_INFO, "Print driver information" },
diff --git a/src/gallium/drivers/r600/r600_pipe_common.h 
b/src/gallium/drivers/r600/r600_pipe_common.h
index b43b7eecd10..4136ba5b565 100644
--- a/src/gallium/drivers/r600/r600_pipe_common.h
+++ b/src/gallium/drivers/r600/r600_pipe_common.h
@@ -78,7 +78,7 @@ struct u_log_context;
 #define DBG_ALL_SHADERS(DBG_FS - 1)
 #define DBG_FS (1 << 6) /* fetch shader */
 #define DBG_TEX(1 << 7)
-#define DBG_NIR(1 << 8)
+/* gap */
 #define DBG_COMPUTE(1 << 9)
 /* gap */
 #define DBG_VM (1 << 11)
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: rs: choose clear format based on block size

2019-05-26 Thread Christian Gmeiner 
Fixes following piglit and does not introduce any regressions.
  spec@ext_packed_depth_stencil@fbo-depth-gl_depth24_stencil8-blit

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_rs.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index e64babfdd0a..8c85f329f76 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -254,7 +254,19 @@ etna_rs_gen_clear_surface(struct etna_context *ctx, struct 
etna_surface *surf,
   uint32_t clear_value)
 {
struct etna_resource *dst = etna_resource(surf->base.texture);
-   uint32_t format = translate_rs_format(surf->base.format);
+   uint32_t format;
+
+   switch (util_format_get_blocksizebits(surf->base.format)) {
+   case 16:
+  format = RS_FORMAT_A4R4G4B4;
+  break;
+   case 32:
+  format = RS_FORMAT_A8R8G8B8;
+  break;
+   default:
+  format = ETNA_NO_MATCH;
+  break;
+   }
 
if (format == ETNA_NO_MATCH) {
   BUG("etna_rs_gen_clear_surface: Unhandled clear fmt %s", 
util_format_name(surf->base.format));
-- 
2.21.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

2019-05-26 Thread Axel Davy 

hi,

I haven't done enough testing to have a full understanding of the issue, 
but it seems there could be a regression with gallium nine.


One user is reporting on irc huge slowdowns with d3d8 games (using the 
d3d8to9 wrapper) when using vsync. Reverting fixes the issues.


I don't know exactly why vsync would have issues.

Another thing though is that many d3d9 games do their own throttling, 
and if our throttling is stricter, maybe the game multithreading could 
be perturbed.

All in all, this needs more testing with gallium nine.

To prevent possible regression for next release, I'll force 
PIPE_CAP_MAX_FRAMES_IN_FLIGHT to be clamped to 2 at least for gallium nine.



Might be worth trying to see if gl could be affected.

Yours,

Axel

On 02/05/2019 03:19, Marek Olšák wrote:

If there is no other feedback, I'll push this tomorrow.

Marek

On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák > wrote:


This patch might improve performance, because less submitted
unfinished work means less used memory by the unfinished work.

Marek

On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer mailto:mic...@daenzer.net>> wrote:

On 2019-04-27 6:13 p.m., Rob Clark wrote:
> On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák
mailto:mar...@gmail.com>> wrote:
>>
>> From: Marek Olšák mailto:marek.ol...@amd.com>>
>>
>> It's done by:
>> - decrease the number of frames in flight by 1
>> - flush before throttling in SwapBuffers
>>   (instead of wait-then-flush, do flush-then-wait)
>>
>> The improvement is apparent with Unigine Heaven.
>>
>> Previously:
>>     draw frame 2
>>     wait frame 0
>>     flush frame 2
>>     present frame 2
>>
>>     The input lag is 2 frames.
>>
>> Now:
>>     draw frame 2
>>     flush frame 2
>>     wait frame 1
>>     present frame 2
>>
>>     The input lag is 1 frame. Flushing is done before
waiting, because
>>     otherwise the device would be idle after waiting.
>>
>> Nine is affected because it also uses the pipe cap.
>> ---
>>  src/gallium/auxiliary/util/u_screen.c         | 2 +-
>>  src/gallium/state_trackers/dri/dri_drawable.c | 20
+--
>>  2 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_screen.c
b/src/gallium/auxiliary/util/u_screen.c
>> index 27f51e0898e..410f17421e6 100644
>> --- a/src/gallium/auxiliary/util/u_screen.c
>> +++ b/src/gallium/auxiliary/util/u_screen.c
>> @@ -349,21 +349,21 @@
u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,
>>     case PIPE_CAP_MAX_VARYINGS:
>>        return 8;
>>
>>     case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
>>        return 0;
>>
>>     case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
>>        return 0;
>>
>>     case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
>> -      return 2;
>> +      return 1;
>
> would it be safer to leave the current default and let
drivers opt-in
> to the lower # individually?  I guess triple buffering would
still be
> better for some of the smaller gpu's?

This patch doesn't prevent triple buffering. The application
can still
prepare up to one frame worth of GPU commands before the GPU has
finished processing the commands of the previous frame (while the
pre-previous frame is being displayed).

I just think the term "in flight" should maybe be defined a
bit better,
but it's not a blocker and could be done in a follow-up patch.


-- 
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



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110761] Huge problems between Mesa and Electron engine apps

2019-05-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=110761

--- Comment #1 from tele4...@hotmail.com ---
Hello Sergey, this sounds like the regression being discussed at
https://lists.freedesktop.org/archives/mesa-dev/2019-May/219546.html and
https://bugs.freedesktop.org/show_bug.cgi?id=110721#c17.

-- 
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] radv: tidy up GetQueryPoolResults for occlusion queries

2019-05-26 Thread Bas Nieuwenhuizen 
r-b

On Wed, May 22, 2019 at 5:43 PM Samuel Pitoiset
 wrote:
>
> Just move the block that checks the availability bit into the
> switch like other query types.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_query.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 0bc7f8390b6..c0f470da888 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1121,13 +1121,6 @@ VkResult radv_GetQueryPoolResults(
> char *src = pool->ptr + query * pool->stride;
> uint32_t available;
>
> -   if (pool->type == VK_QUERY_TYPE_PIPELINE_STATISTICS) {
> -   if (flags & VK_QUERY_RESULT_WAIT_BIT)
> -   while(!*(volatile uint32_t*)(pool->ptr + 
> pool->availability_offset + 4 * query))
> -   ;
> -   available = *(uint32_t*)(pool->ptr + 
> pool->availability_offset + 4 * query);
> -   }
> -
> switch (pool->type) {
> case VK_QUERY_TYPE_TIMESTAMP: {
> available = *(uint64_t *)src != TIMESTAMP_NOT_READY;
> @@ -1187,6 +1180,11 @@ VkResult radv_GetQueryPoolResults(
> break;
> }
> case VK_QUERY_TYPE_PIPELINE_STATISTICS: {
> +   if (flags & VK_QUERY_RESULT_WAIT_BIT)
> +   while(!*(volatile uint32_t*)(pool->ptr + 
> pool->availability_offset + 4 * query))
> +   ;
> +   available = *(uint32_t*)(pool->ptr + 
> pool->availability_offset + 4 * query);
> +
> if (!available && !(flags & 
> VK_QUERY_RESULT_PARTIAL_BIT))
> result = VK_NOT_READY;
>
> --
> 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

[Mesa-dev] [Bug 110761] Huge problems between Mesa and Electron engine apps

2019-05-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=110761

Bug ID: 110761
   Summary: Huge problems between Mesa and Electron engine apps
   Product: Mesa
   Version: 19.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/X11
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pavly...@protonmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 144347
  --> https://bugs.freedesktop.org/attachment.cgi?id=144347=edit
Example in Spotify app

After updating to 19.0.5, all programs that works on electron engine have huge
visual artefacts on amd cards (flashing, elements blinking and appears in the
new place every second). Non-electron apps works normal. Downgrading to 19.0.4
fixes all problems. This bug also persist on wayland session. 100% affected
apps: Skype (little bit), Spotify (huge artefacts, impossible to see
something), Discord (little bit). What i was tried: change videocard to
another, disable compositor, disable vsync, change DE. Nothing helped. Don't
know if this bug exist on nvidia cards.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: ignore the loadOp if the first use of an attachment is a resolve

2019-05-26 Thread Bas Nieuwenhuizen 
On Sun, May 26, 2019 at 2:50 PM Bas Nieuwenhuizen
 wrote:
>
> On Wed, May 22, 2019 at 11:20 AM Samuel Pitoiset
>  wrote:
> >
> > Based on ANV.
> >
> > Signed-off-by: Samuel Pitoiset 
> > ---
> >  src/amd/vulkan/radv_meta_resolve.c | 21 -
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_meta_resolve.c 
> > b/src/amd/vulkan/radv_meta_resolve.c
> > index ade5d438438..6a8abce1ddb 100644
> > --- a/src/amd/vulkan/radv_meta_resolve.c
> > +++ b/src/amd/vulkan/radv_meta_resolve.c
> > @@ -618,15 +618,6 @@ 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;
> >
> > -   /* FINISHME(perf): Skip clears for resolve attachments.
> > -*
> > -* From the Vulkan 1.0 spec:
> > -*
> > -*If the first use of an attachment in a render pass is as a 
> > resolve
> > -*attachment, then the loadOp is effectively ignored as the 
> > resolve is
> > -*guaranteed to overwrite all pixels in the render area.
> > -*/
> > -
> > if (!subpass->has_resolve)
> > return;
> >
> > @@ -637,6 +628,18 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer 
> > *cmd_buffer)
> > if (dest_att.attachment == VK_ATTACHMENT_UNUSED)
> > continue;
> >
> > +   if 
> > (cmd_buffer->state.attachments[dest_att.attachment].pending_clear_aspects) {
> > +   /* From the Vulkan 1.0 spec:
> > +*
> > +*If the first use of an attachment in a render
> > +*pass is as a resolve attachment, then the 
> > loadOp
> > +*is effectively ignored as the resolve is
> > +*guaranteed to overwrite all pixels in the 
> > render
> > +*area.
> > +   */
> > +   
> > cmd_buffer->state.attachments[dest_att.attachment].pending_clear_aspects = 
> > 0;
> > +   }
> > +
>
> You can drop the if statement. Also this seems like a correctness
> issue, as we only cleared the first time it was used as a color
> attachment, which might happen after a resolve?

Forgot to say, r-b with the if removed, and maybe want to cc stable?
>
> > struct radv_image *dst_img = 
> > cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
> > struct radv_image *src_img = 
> > cmd_buffer->state.framebuffer->attachments[src_att.attachment].attachment->image;
> >
> > --
> > 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] [PATCH] radv: ignore the loadOp if the first use of an attachment is a resolve

2019-05-26 Thread Bas Nieuwenhuizen 
On Wed, May 22, 2019 at 11:20 AM Samuel Pitoiset
 wrote:
>
> Based on ANV.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_resolve.c | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c 
> b/src/amd/vulkan/radv_meta_resolve.c
> index ade5d438438..6a8abce1ddb 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -618,15 +618,6 @@ 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;
>
> -   /* FINISHME(perf): Skip clears for resolve attachments.
> -*
> -* From the Vulkan 1.0 spec:
> -*
> -*If the first use of an attachment in a render pass is as a 
> resolve
> -*attachment, then the loadOp is effectively ignored as the 
> resolve is
> -*guaranteed to overwrite all pixels in the render area.
> -*/
> -
> if (!subpass->has_resolve)
> return;
>
> @@ -637,6 +628,18 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer 
> *cmd_buffer)
> if (dest_att.attachment == VK_ATTACHMENT_UNUSED)
> continue;
>
> +   if 
> (cmd_buffer->state.attachments[dest_att.attachment].pending_clear_aspects) {
> +   /* From the Vulkan 1.0 spec:
> +*
> +*If the first use of an attachment in a render
> +*pass is as a resolve attachment, then the loadOp
> +*is effectively ignored as the resolve is
> +*guaranteed to overwrite all pixels in the render
> +*area.
> +   */
> +   
> cmd_buffer->state.attachments[dest_att.attachment].pending_clear_aspects = 0;
> +   }
> +

You can drop the if statement. Also this seems like a correctness
issue, as we only cleared the first time it was used as a color
attachment, which might happen after a resolve?

> struct radv_image *dst_img = 
> cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
> struct radv_image *src_img = 
> cmd_buffer->state.framebuffer->attachments[src_att.attachment].attachment->image;
>
> --
> 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