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

The input lag is maxframes*1000/fps ms. For 10 fps and 2 frames, the lag is 200 ms. You might also say that it's the amount of time it will take the GPU to catch up with the CPU after fence_finish returns. Hopefully that clears up performance concerns. Marek On Sat, Apr 27, 2019, 4:07 PM Axel

[Mesa-dev] [MR] Gallium nine fixes and improvements for Mesa 19.1

Hi, I usually send my patch series via mail, but as this one was rather long, and as people seem to find gitlab easier to work with for long patch series, this time I used the merge request system. Don't hesitate to take a look: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/748

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

On 27/04/2019 21:02, Rob Clark wrote: On Sat, Apr 27, 2019 at 9:52 AM Axel Davy wrote: On 27/04/2019 18:13, Rob Clark wrote: On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: From: Marek Olšák It's done by: - decrease the number of frames in flight by 1 - flush before throttling in

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

On Sat, Apr 27, 2019 at 9:52 AM Axel Davy wrote: > > On 27/04/2019 18:13, Rob Clark wrote: > > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: > >> From: Marek Olšák > >> > >> It's done by: > >> - decrease the number of frames in flight by 1 > >> - flush before throttling in SwapBuffers > >>

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

On 27/04/2019 18:13, Rob Clark wrote: On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: From: Marek Olšák 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

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

On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: > > From: Marek Olšák > > 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. > >

Re: [Mesa-dev] [PATCH 1/3] mesa: rework error handling in glDrawBuffers

Hi Marek, one comment/failure inline: On Saturday, 27 April 2019 05:31:45 CEST Marek Olšák wrote: > From: Marek Olšák > > It's needed by the next pbuffer fix, which changes the behavior of > draw_buffer_enum_to_bitmask, so it can't be used to help with error > checking. > --- >

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

Those are all valid reasons, but I don't wanna expose swrast for AMD's customers. Marek On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich wrote: > Hi Marek, > > On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > > Adam, did you notice my original suggestion "If there is at least 1 drm

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

On 26/04/2019 20:40, Marek Olšák wrote: On Fri, Apr 26, 2019 at 12:56 PM Axel Davy > wrote: On 26/04/2019 10:08, Michel Dänzer wrote: > On 2019-04-26 4:06 a.m., Marek Olšák wrote: >> From: Marek Olšák mailto:marek.ol...@amd.com>> >> >> It's done

[Mesa-dev] [PATCH] radv: add missing VEGA20 chip in radv_get_device_name()

Otherwise it returns "AMD RADV unknown". Cc: 19.0 Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index b7f991fce72..8340bf52c11 100644 ---

[Mesa-dev] [PATCH v3] radv: fix set_output_usage_mask() with composite and 64-bit types

It previously used var->type instead of deref_instr->type and didn't handle 64-bit outputs. This fixes lots of transform feedback CTS tests involving transform feedback and geometry shaders (mostly dEQP-VK.transform_feedback.fuzz.random_geometry.*) v2: fix writemask widening when comp != 0 v3:

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

Hi Marek, On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > Adam, did you notice my original suggestion "If there is at least 1 drm > device, swrast won't be in the list."? which means swrast would be in the > list for your "dumb" GPUs. Imagine a box with a low end drm capable

[Mesa-dev] [PATCH v2] radv: fix set_output_usage_mask() with composite and 64-bit types

It previously used var->type instead of deref_instr->type and didn't handle 64-bit outputs. This fixes lots of transform feedback CTS tests involving transform feedback and geometry shaders (mostly dEQP-VK.transform_feedback.fuzz.random_geometry.*) v2: fix writemask widening when comp != 0

[Mesa-dev] [PATCH] radv: fix set_output_usage_mask() with composite and 64-bit types

It previously used var->type instead of deref_instr->type and didn't handle 64-bit outputs. This fixes lots of transform feedback CTS tests involving transform feedback and geometry shaders (mostly dEQP-VK.transform_feedback.fuzz.random_geometry.*) Signed-off-by: Rhys Perry Cc: 19.0 ---