Re: [Mesa-dev] [PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension

2018-02-13 Thread Keith Packard 
Lionel Landwerlin  writes:

> I'm assuming the correlation is done outside the vulkan driver? With a 
> clock_gettime() maybe?
>
> If that's the case, I'm afraid this will be highly inaccurate.
> The kernel might execute other tasks when the ioctl() happens and that 
> might introduce (in my experience) a few milliseconds of delay.

Yes, I agree. The trouble is that the window system layer works in one
time base while the rendering layer works in the other, so there's no
one driver which has access to both values, at least in Mesa.

> I think if you want to do something like that, this has to be 
> implemented in the kernel, making sure you disable interruptions while 
> doing the correlation.

That was my thinking originally, until I realized that there wasn't a
single place which knew of the two clocks.

Suggestions are welcome; I just don't know how the rendering driver is
supposed to know what timebase the window system is running in?

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension

2018-02-13 Thread Lionel Landwerlin 

On 13/02/18 00:20, Dylan Baker wrote:

Quoting Keith Packard (2018-02-09 20:45:15)

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.


I'm assuming the correlation is done outside the vulkan driver? With a 
clock_gettime() maybe?


If that's the case, I'm afraid this will be highly inaccurate.
The kernel might execute other tasks when the ioctl() happens and that 
might introduce (in my experience) a few milliseconds of delay.


I think if you want to do something like that, this has to be 
implemented in the kernel, making sure you disable interruptions while 
doing the correlation.




Signed-off-by: Keith Packard 
---
  include/vulkan/vulkan.h |  6 ++
  src/Makefile.am |  1 +
  src/amd/vulkan/Makefile.am  |  3 +++
  src/amd/vulkan/meson.build  |  8 
  src/amd/vulkan/radv_device.c|  8 
  src/amd/vulkan/radv_extensions.py   |  1 +
  src/intel/Makefile.vulkan.am|  7 +++
  src/intel/vulkan/anv_extensions.py  |  1 +
  src/intel/vulkan/anv_gem.c  | 13 +
  src/intel/vulkan/anv_private.h  |  1 +
  src/intel/vulkan/genX_query.c   | 15 +++
  src/intel/vulkan/meson.build| 12 ++--
  src/vulkan/meson.build  |  1 +
  src/vulkan/registry/vk_mesa_query_timestamp.xml | 22 ++
  14 files changed, 89 insertions(+), 10 deletions(-)
  create mode 100644 src/vulkan/registry/vk_mesa_query_timestamp.xml

diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index d3e2e246cf3..5523eb7586f 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -7025,6 +7025,12 @@ VKAPI_ATTR VkResult VKAPI_CALL 
vkGetMemoryHostPointerPropertiesEXT(
  VkMemoryHostPointerPropertiesEXT*   pMemoryHostPointerProperties);
  #endif
  
+typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(VkDevice device, uint64_t *timestamp);

+
+VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
+VkDevice_device,
+uint64_t*timestamp);
+
  #ifdef __cplusplus
  }
  #endif
diff --git a/src/Makefile.am b/src/Makefile.am
index 014ffaf3e29..74ff305d7c6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -68,6 +68,7 @@ endif
  
  EXTRA_DIST += vulkan/registry/vk.xml

  EXTRA_DIST += vulkan/registry/vk_android_native_buffer.xml
+EXTRA_DIST += vulkan/registry/vk_mesa_query_timestamp.xml
  
  if HAVE_AMD_DRIVERS

  SUBDIRS += amd
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 94ece06e99e..0626fa2b3b3 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -129,12 +129,14 @@ libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
  
  vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml

  vk_android_native_buffer_xml = 
$(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
+vk_mesa_query_timestamp_xml = 
$(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamps.xml
  
  radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py $(vulkan_api_xml)

 $(MKDIR_GEN)
 $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
 --xml $(vulkan_api_xml) \
 --xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
 --outdir $(builddir)
  radv_entrypoints.h: radv_entrypoints.c
  
@@ -144,6 +146,7 @@ radv_extensions.c: radv_extensions.py \

 $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
 --xml $(vulkan_api_xml) \
 --xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
 --out $@
  
  vk_format_table.c: vk_format_table.py \

diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index 0b92a1763a1..34f578476c0 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -20,10 +20,10 @@
  
  radv_entrypoints = custom_target(

'radv_entrypoints.[ch]',
-  input : ['radv_entrypoints_gen.py', vk_api_xml],
+  input : ['radv_entrypoints_gen.py', vk_api_xml, 
vk_android_native_buffer_xml, vk_mesa_query_timestamp_xml],

some of these lines look a little long,
input : [
 'radv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml,
 vk_mesa_query_timestamp_xml,
],


output : ['radv_entrypoints.h', 'radv_entrypoints.c'],
command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--outdir',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--xml', '@INPUT3@', '--outdir',