lunarg / vulkantools Goto Github PK
View Code? Open in Web Editor NEWTools to aid in Vulkan development
License: Other
Tools to aid in Vulkan development
License: Other
Trace files can be very large. There should be a way to collect a trace for only a portion of the entire execution, because the user may be interested only in a few frames.
So the path line would turn out to be
vulkan -> SPRIV -> AMDGPU/NVPTX/IntelGPU/OtherGPU
The SPRIV are translated at the runtime.
According to the specs v1.0.17, a subresource's layerCount
parameter can be VK_REMAINING_ARRAY_LAYERS
to use all layers of a resource (i.e. image). If the image is created with a single layer, setting the parameter to VK_REMAINING_ARRAY_LAYERS
should therefore be equivalent to setting it to 1.
However, the parameter validation layer complains that:
ParameterValidation(ERROR): object: 0x0 type: 0 location: 2529 msgCode: 1: vkCreateImageView: if pCreateInfo->viewType is VK_IMAGE_TYPE_2D, pCreateInfo->subresourceRange.layerCount must be 1
Let me know if this is clear enough, or you would need a small code snippet.
Some arm vfp load instructions, e.g. vldr, requires the address of the source to align to 4 bytes.
But sometimes, the address decomposed from the packet is not 4 bytes alignment, e.g., the 4 float type members in the VkPipelineRasterizationStateCreateInfo structure, that is causing the vldr instruction fail.
Specifically:
The instancing sample will trace, but nothing is drawn on replay
The raytracing sample gets this assert while tracing:
"vktrace_trace_packet_utils.c:147: vktrace_trace_packet_get_new_buffer_address: Assertion `pHeader->size >= pHeader->next_buffers_offset + byteCount' failed".
The shadowmappingomni sample traces ok, replays ok, but segfaults when replayed with validation. Running the sample with validation gets errors but no seg fault
I've seen all three of these on both Linux+Mesa and Windows+Nvidia
On 16.04 Mesa a0d9279e3b31ce5e5bb2baf857134bd5f48dbf65 it crashes in the driver on a call to GetPhysicalDeviceXcbPresentationSupportKHRn during replay (a cube trace replays fine using the same call) and on 15.10 Nvidia vktrace hangs.
During SDK 1.0.17 testing, I generated a Holgram trace on my Haswell system using the Mesa driver and when playing it back, the window height was bigger than the content being drawn. This also happens with some of the Sascha Willems samples.
I'm using vkreplay on arm+android platform and it crashed in trace files containing "vkUpdateDescriptorSets" calls:
--------- beginning of crash
01-01 17:27:36.791 3356 3394 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x98b8010c in tid 3394 (Thread-266)
01-01 17:27:36.842 169 169 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-01 17:27:36.842 169 169 F DEBUG : Build fingerprint: 'Android/firefly/firefly:6.0/MRA58K/jefyan0106081402:eng/test-keys'
01-01 17:27:36.842 169 169 F DEBUG : Revision: '0'
01-01 17:27:36.842 169 169 F DEBUG : ABI: 'arm'
01-01 17:27:36.842 169 169 F DEBUG : pid: 3356, tid: 3394, name: Thread-266 >>> com.arm.vktrace.vktrace_replay <<<
01-01 17:27:36.842 169 169 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x98b8010c
01-01 17:27:36.851 169 169 F DEBUG : r0 00000002 r1 00000036 r2 ffffffd0 r3 b6d992f0
01-01 17:27:36.851 169 169 F DEBUG : r4 b6d992e8 r5 98bb8670 r6 9eef0000 r7 98b80000
01-01 17:27:36.851 169 169 F DEBUG : r8 a0c92048 r9 b6d8c594 sl 00000001 fp 9ee40191
01-01 17:27:36.851 169 169 F DEBUG : ip 98b800d8 sp 9edede48 lr b6d6e613 pc b6d6b692 cpsr 200f0030
01-01 17:27:36.857 169 169 F DEBUG :
01-01 17:27:36.857 169 169 F DEBUG : backtrace:
01-01 17:27:36.857 169 169 F DEBUG : #00 pc 00055692 /system/lib/libc.so (ifree+49)
01-01 17:27:36.857 169 169 F DEBUG : #01 pc 0005860f /system/lib/libc.so (je_free+374)
01-01 17:27:36.857 169 169 F DEBUG : #02 pc 000592a3 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so
01-01 17:27:36.857 169 169 F DEBUG : #03 pc 00061413 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vkReplay::manually_replay_vkUpdateDescriptorSets(packet_vkUpdateDescriptorSets*)+2474)
01-01 17:27:36.857 169 169 F DEBUG : #04 pc 0008d003 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vkReplay::replay(vktrace_trace_packet_header*)+16642)
01-01 17:27:36.857 169 169 F DEBUG : #05 pc 0007f059 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (VkReplayReplay(vktrace_trace_packet_header*)+36)
01-01 17:27:36.857 169 169 F DEBUG : #06 pc 00091a4b /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vktrace_replay::main_loop(vktrace_replay::Sequencer&, vktrace_replay::vktrace_trace_packet_replay_library**, vkreplayer_settings)+266)
01-01 17:27:36.857 169 169 F DEBUG : #07 pc 000921dd /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (android_main+1168)
01-01 17:27:36.857 169 169 F DEBUG : #08 pc 00051233 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so
01-01 17:27:36.857 169 169 F DEBUG : #09 pc 0003f817 /system/lib/libc.so (__pthread_start(void*)+30)
01-01 17:27:36.857 169 169 F DEBUG : #10 pc 00019f73 /system/lib/libc.so (__start_thread+6)
01-01 17:27:37.157 1009 3408 W ActivityManager: Force finishing activity com.arm.vktrace.vktrace_replay/android.app.NativeActivity
01-01 17:27:37.157 169 169 F DEBUG :
01-01 17:27:37.157 169 169 F DEBUG : Tombstone written to: /data/tombstones/tombstone_03
01-01 17:27:37.157 169 169 E DEBUG : AM write failed: Broken pipe
The problem may be the memory free part of manually_replay_vkUpdateDescriptorSets, I read the source code and
pRemappedWrites[d].pImageInfo != NULL
pRemappedWrites[d].pBufferInfo != NULL
pRemappedWrites[d].pTexelBufferView != NULL
are suspicious because it seems that these pointers are not initialized after malloc.
I've tried Examples 4-6 (Linux + Mesa) and they all trace but they all playback only background color. They call vkFlushMappedMemoryRanges so it's probably not the persistently mapped memory issue.
I received the above error message from the validation layer during the call to vkCreateGraphicsPipelines with the following parameters to the DebugReport callback:
objType: DeviceExt
obj: 0
location: 0x655
messageCode: 3
layerPrefix: "SC"
message "VS consumes input at location 0 but not provided"
As someone who is new to Vulkan, I found it less then helpful.
Is "VS" VertexShader?
I would like to see more detail as to what test failed or possibly an action to take. The VkGraphicsPipelineCreateInfo is very complex and narrowing down the issue would make it easier to track down the error. In this case, I wasn't setting the pVertexInputState structure fields, leaving the values null. So adding something like "pVertexInputState.pVertexBindingDescriptions must not be null" would have pointed me in the right direction.
I'm on Ubuntu 15.10 x86_64, nvidia driver 355.00.29 and Vulkan SDK 1.0.5.
In my experiments with Vulkan, I came to experience a crash when using VK_LAYER_LUNARG_param_checker
, whether I enable the layer from code, or by setting the respective environment variables. The crash is in validateDeviceCreateInfo
from libVkLayer_param_checker.so
. Here is a sample program (main.c
):
#include <stdlib.h>
#include <stdio.h>
#include <vulkan/vulkan.h>
int main(int argc, char **argv)
{
VkResult res;
/* create instance */
VkApplicationInfo app_info = {
.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO,
.pApplicationName = "Vulkan Layer Bug",
.pEngineName = "Vulkan Layer Bug",
.apiVersion = VK_MAKE_VERSION(1, 0, 3),
};
VkInstanceCreateInfo instance_info = {
.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
.pApplicationInfo = &app_info,
};
VkInstance vk;
res = vkCreateInstance(&instance_info, NULL, &vk);
if (res)
return EXIT_FAILURE;
/* get physical device */
VkPhysicalDevice phy_dev;
VkPhysicalDeviceFeatures dev_features;
uint32_t phy_dev_count = 1;
res = vkEnumeratePhysicalDevices(vk, &phy_dev_count, &phy_dev);
if (res < 0 || phy_dev_count < 1)
return EXIT_FAILURE;
vkGetPhysicalDeviceFeatures(phy_dev, &dev_features);
/* create device */
VkDeviceQueueCreateInfo queue_info = {
.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO,
.queueFamilyIndex = 0,
.queueCount = 1,
};
VkDeviceCreateInfo dev_info = {
.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
.queueCreateInfoCount = 1,
.pQueueCreateInfos = &queue_info,
.pEnabledFeatures = &dev_features,
};
VkDevice dev;
res = vkCreateDevice(phy_dev, &dev_info, NULL, &dev);
if (res)
return EXIT_FAILURE;
fprintf(stderr, "Initialization successful\n");
/* cleanup */
vkDeviceWaitIdle(dev);
vkDestroyDevice(dev, NULL);
vkDestroyInstance(vk, NULL);
fprintf(stderr, "Cleanup successful\n");
return 0;
}
You can build this with:
$ gcc -o layerbug main.c -lvulkan
And try with:
$ ./layerbug
which works fine, and:
$ export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_param_checker
$ export VK_DEVICE_LAYERS=VK_LAYER_LUNARG_param_checker
$ ./layerbug
which results in segmentation fault. I can verify that enabling the layer from code has the same behavior.
gdb stack trace:
#0 0x00007ffff4159f31 in validateDeviceCreateInfo(VkPhysicalDevice_T*, VkDeviceCreateInfo const*, std::vector<VkQueueFamilyProperties, std::allocator<VkQueueFamilyProperties> >) ()
from /usr/lib/x86_64-linux-gnu/libVkLayer_param_checker.so
#1 0x00007ffff415ab8d in vkCreateDevice () from /usr/lib/x86_64-linux-gnu/libVkLayer_param_checker.so
#2 0x00007ffff7bbebee in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
#3 0x00007ffff7bc402a in vkCreateDevice () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
#4 0x0000000000400b84 in main ()
Registers:
rax 0x0 0
rbx 0x0 0
rcx 0x7fffffffdc40 140737488346176
rdx 0x0 0
rsi 0xb 11
rdi 0x7fffffffd860 140737488345184
rbp 0x7fffffffdc40 0x7fffffffdc40
rsp 0x7fffffffd800 0x7fffffffd800
r8 0x0 0
r9 0x7ffff7baac68 140737349594216
r10 0x0 0
r11 0x7ffff797cfb0 140737347309488
r12 0x0 0
r13 0x0 0
r14 0x7fffffffdab0 140737488345776
r15 0x640b10 6556432
rip 0x7ffff4159f31 0x7ffff4159f31 <validateDeviceCreateInfo(VkPhysicalDevice_T*, VkDeviceCreateInfo const*, std::vector<VkQueueFamilyProperties, std::allocator<VkQueueFamilyProperties> >)+465>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
I'm trying to build this repo with debugging symbols to debug further. However, if there is any glaring errors in my code, please let me know. Otherwise, it would be interesting to know if you can reproduce this issue.
Error message:
CMake Error at CMakeLists.txt:52 (string):
string sub-command REPLACE requires at least four arguments.
I'm using:
cmake version 3.5.2
Exception thrown: read access violation.
this->m_pController-> was 0xFFFFFFFFFFFFFF7F.
If there is a handler for this exception, the program may be safely continued.
vktraceviewer.exe!vktraceviewer::close_trace_file() Line 698 C++
@ the line "m_pController->UnloadTraceFile();"
void vktraceviewer::close_trace_file()
{
if (m_pController != NULL)
{
ui->bottomTabWidget->removeTab(ui->bottomTabWidget->indexOf(m_pTraceStatsTab));
m_pController->UnloadTraceFile();
#ifndef USE_STATIC_CONTROLLER_LIBRARY
m_controllerFactory.Unload(&m_pController);
#else
vtvDeleteQController(m_pController);
#endif
}
It looks now the trace file captured from the win32 platform only can be replayed on win32 platform, right?
Can we make the trace file more platform independent? So the trace file can be replayed on different platforms.
When Vulkan Application uses persistently mapped memory, vktrace cannot track updates within this memory.
...
git clone -o khronos [email protected]:vulkan/LoaderAndValidationLayers.git
Cloning into 'LoaderAndValidationLayers'...
The authenticity of host 'gitlab.khronos.org (45.55.52.146)' can't be established.
...
Warning: Permanently added 'gitlab.khronos.org,45.55.52.146' (ECDSA) to the list of known hosts.
[email protected]'s password:
Permission denied, please try again.
...
From backtrace of my (buggy) application:
(gdb) bt
#0 intel_dev_log (dev=dev@entry=0x625740, msg_flags=msg_flags@entry=8, src_object=src_object@entry=0x0, location=location@entry=0, msg_code=msg_code@entry=0,
format=format@entry=0x7ffff75283e0 "invalid presentable image format") at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/dev.c:206
#1 0x00007ffff6ee02a8 in x11_swap_chain_create (sc_ret=0x7fffec1fdee8, info=0x7fffec1fde40, dev=0x625740)
at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:887
#2 vkCreateSwapchainKHR (device=0x625740, pCreateInfo=0x7fffec1fde40, pAllocator=<optimized out>, pSwapchain=0x7fffec1fdee8)
at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:1204
[...]
(gdb) list
201 {
202 va_list ap;
203
204 va_start(ap, format);
205 intel_logv(dev, msg_flags,
206 (src_object->dbg ? src_object->dbg->type : 0),
207 (uint64_t) src_object,
208 location, msg_code,
209 format, ap);
210 va_end(ap);
(gdb) up
#1 0x00007ffff6ee02a8 in x11_swap_chain_create (sc_ret=0x7fffec1fdee8, info=0x7fffec1fde40, dev=0x625740)
at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:887
887 intel_dev_log(dev, VK_DEBUG_REPORT_ERROR_BIT_EXT,
(gdb) list
882 struct intel_x11_swap_chain *sc;
883 int fd;
884
885 /* TODOVV: Add test to validation layer */
886 if (!x11_is_format_presentable(dev, info->imageFormat)) {
887 intel_dev_log(dev, VK_DEBUG_REPORT_ERROR_BIT_EXT,
888 VK_NULL_HANDLE, 0, 0, "invalid presentable image format");
889 // return VK_ERROR_INVALID_VALUE;
890 return VK_ERROR_VALIDATION_FAILED_EXT;
891 }
intel_dev_log
is called with src_object= VK_NULL_HANDLE
, but then it is dereferenced with src_object->dbg
.
The specification v1.0.17 for the vkDestroyX
functions seem to allow VK_NULL_HANDLE
to be given to these functions. For example vkDestroyBufferView
says:
If
bufferView
is notVK_NULL_HANDLE
,bufferView
must be a validVkBufferView
handle
Which implies that bufferView
could be VK_NULL_HANDLE
. This is actually nice, similar to how C's free(NULL)
is correct and useful.
However, the object tracker validation layer complains that:
OBJTRACK(ERROR): object: 0x0 type: 13 location: 1456 msgCode: 4: Invalid VkBufferView Object 0x0
OBJTRACK(ERROR): object: 0x0 type: 0 location: 690 msgCode: 1: Unable to remove obj 0x0. Was it created? Has it already been destroyed?
I noticed the nvidia driver (under Linux if it makes any difference) crashing when given VK_NULL_HANDLE
in these cases as well. Perhaps this is already the established behavior, but the specifications need to be updated to disallow VK_NULL_HANDLE
?
The size of packet_vkApiVersion is different from 32bit system to 64bit system so the data packet generated on 32bit system should not be compatible with 64bit traceviewer.
It may be a problem, if the 32bit trace file cannot be replayed on 64 bit system,vice versa.
I'm on Ubuntu 15.10 x86_64 with nvidia driver 355.00.29.
With the latest LunarGLASS, building the ICD fails on this assertion:
// If this fails during compilation, it means LunarGlass has added new sampler types
// We must react to. Also, see comment above ersatz_static_assert.
ersatz_static_assert<NumSamplerTypes == gla::EMsCount &&
NumSamplerBaseTypes == gla::EMsbCount &&
NumSamplerDims == gla::EMsdCount> SamplerTypeMismatchWithLunarGlass;
I followed the Win32 build instructions in vktrace/ReadMe.md, changing the target for cmake to
"Visual Studio 14 2015 Win64". I open vktrace/_out64/vktrace_project.sln in Visual Studio 2015 and select Build on the ALL_BUILD projects. It fails when it is not able to find vk-generate.py. A partial build log is posted here:
1>------ Build started: Project: vktrace_common, Configuration: Debug x64 ------
2>------ Build started: Project: generate_vktrace_layer_helpers, Configuration: Debug x64 ------
3>------ Build started: Project: vktrace_layer-json, Configuration: Debug x64 ------
2> Building Custom Rule C:/VulkanSDK/VulkanTools/vktrace/src/vktrace_layer/CMakeLists.txt
3> 1 file(s) copied.
2> CMake does not need to re-run because C:\VulkanSDK\VulkanTools\vktrace\_out64\src\vktrace_layer\CMakeFiles\generate.stamp is up-to-date.
2> Generating vk_dispatch_table_helper.h
2> '..\..\..\vk-generate.py' is not recognized as an internal or external command,
2> operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 9009.
This is the same type of issue as #64, in that QueueFamilies selected are record time will need to have their properties recorded and mapped to QueueFamilies that have the same properties at playback time
Right now, screenshot only supports 2 image formats, (neither of which are the default mesa image format) and it would be nice to use a blit to copy from the source image, converting to one of the two formats that lend themselves to easy ppm file generation. If the incoming format has VK_FORMAT_FEATURE_BLIT_SRC_BIT in its features for whatever tiling its using, writePPM could use vkCmdBlitImage instead of vkCopyImage to both copy and convert the format.
Attempting to trace a Vulkan application where VkInstanceCreateInfo.pApplicationInfo == NULL
causes a segfault. Valgrind indicates the issue comes from __HOOKED_vkCreateInstance
.
Vulkaninfo makes really poor choices about what is displayed as hex values and what is displayed as decimal values. For instance, the Vulkan API verson is reported as a decimal value, even though it's only readable in hex, while device limits are reported as hex, even though decimal would be much more readable.
Furthermore, memory type flags are reported as decimal values rather than a list of flags as with image formats.
It would be nice if vkreplay could know what OS it was running on and translate WSI calls from the trace to WSI calls appropriate for the system it was replaying on.
Thanks.
https://github.com/LunarG/VulkanTools/blob/master/vktrace/src/vktrace_layer/vktrace_lib_trace.cpp traces data written to mapped memory in __HOOKED_vkUnmapMemory and __HOOKED_vkFlushMappedMemoryRanges . However, allocations made with VK_MEMORY_PROPERTY_HOST_COHERENT_BIT may be written by the host and read by the device with no synchronization other than the implicit synchronization of vkQueueSubmit, and without vkUnmapMemory'ing the vkDeviceMemory . This could allow writes that affect the rendered result (for example, to a uniform buffer) to not be captured by the tracing layer .
One way to solve this would be for the layer to prevent heaps from allowing allocations with VK_MEMORY_PROPERTY_HOST_COHERENT_BIT ?
Various improvements suggested by Tony B .
My workaround for this problem (Ubuntu cmake package is 3.5.1):
diff --git a/icd/intel/kmd/CMakeLists.txt b/icd/intel/kmd/CMakeLists.txt
index baeb3e6..a0214f3 100644
--- a/icd/intel/kmd/CMakeLists.txt
+++ b/icd/intel/kmd/CMakeLists.txt
@@ -29,7 +29,11 @@ if(UNIX)
set_source_files_properties(${libdrm_sources} PROPERTIES COMPILE_FLAGS
"-std=gnu99 -Wno-type-limits -Wno-unused-variable")
- find_package(PthreadStubs REQUIRED)
+
+set(THREADS_PREFER_PTHREAD_FLAG ON)
+find_package(Threads REQUIRED)
+# find_package(PthreadStubs REQUIRED)
+
list(APPEND include_dirs ${PTHREADSTUBS_INCLUDE_DIRS})
list(APPEND libraries ${PTHREADSTUBS_LIBRARIES})
I noticed my machine was churning heavily while I had 2 instances of vktraceviewer running; each one was causing 17-20% CPU utililization.
Suspecting the timeline to be the culprit, I commented out its creation, and confirmed that the CPU utilization goes down to ~0%.
On deeper dive, looks like viewport()->update() is being called within the paintEvent, which would cause another paint event to be signaled. We're continually repainting the timeline... yeah, that's bad.
vktrace dies immediately when trying to trace on Win7/32.
vktrace on Win 10/64 using 32 bit libraries seems to work.
Haven't tried vktrace on other 32-bit Windows systems, but they probably don't work either.
Using vktrace to trace the bloom demo (and many other demos), the trace file generates without issue, but when playing back the trace, I get an exception calling free() in GetPhysicalDeviceQueueFamilyProperties (the 5th call) and it looks like the data in .queueFamilyProperties is uninitialized (0xdddddddd)
Maybe it needs to exit on other errors too?
The formula in the "Controlling the Viewport" section (specifications v1.0.17) says:
xf = px/2 * xd + ox
yf = py/2 * yd + oy
zf = pz * zd + oz
Is the above formula correct? First of all, it is inconsistent with OpenGL which has:
xf = px/2 * (xd + 1) + ox
yf = py/2 * (yd + 1) + oy
In other words, with OpenGL, if you have a viewport with origin (0, 0) and extent (width, height), then normalized coordinates (0, 0) map to the middle of the screen. With the Vulkan formulas, the same viewport would map normalized coordinates (0, 0) to the corner of the screen.
The nvidia driver on Linux actually maps normalized coordinate (0, 0) to the middle screen with such a viewport, which is either a bug in the driver, or a hint at an incorrect formula in the specifications. Or perhaps I'm missing something?
Interesting series of bugs. This first part is not a VulkanTools bug:
$ cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBUILD_WSI_XLIB_SUPPORT=On
$ grep XLIB build/CMakeCache.txt
BUILD_WSI_XLIB_SUPPORT:BOOL=On
$ cd build && make
The error I am getting is an interaction between XLib and Qt5:
[ 93%] Building CXX object vktrace/src/vktrace_viewer/CMakeFiles/vktraceviewer.dir/main.cpp.o
In file included from /usr/include/X11/Xlib.h:44:0,
from VulkanTools/include/vulkan/vk_platform.h:113,
from VulkanTools/include/vulkan/vulkan.h:31,
from VulkanTools/include/vulkan/vk_icd.h:26,
from VulkanTools/vktrace/src/vktrace_common/vktrace_multiplatform.h:28,
from VulkanTools/vktrace/src/vktrace_common/vktrace_trace_packet_utils.h:24,
from VulkanTools/vktrace/src/vktrace_viewer/vktraceviewer.h:30,
from VulkanTools/vktrace/src/vktrace_viewer/main.cpp:24:
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected identifier before numeric constant
None = 0x0,
^
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected ‘}’ before numeric constant
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected unqualified-id before numeric constant
The Xlib.h header is maybe #included in the wrong place. I'm not sure.
Ok, so punt on that since I don't plan to use XLib anyway.
$ rm -rf build; cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBUILD_WSI_XLIB_SUPPORT=Off
$ grep XLIB build/CMakeCache.txt
BUILD_WSI_XLIB_SUPPORT:BOOL=Off
$ cd build && make
Now this is interesting:
[ 3%] Building C object icd/nulldrv/CMakeFiles/VK_nulldrv.dir/nulldrv_gpa.c.o
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c: In function ‘vk_icdGetInstanceProcAddr’:
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:333:37: error: ‘vkCreateXlibSurfaceKHR’ undeclared (first use in this function)
return (PFN_vkVoidFunction) vkCreateXlibSurfaceKHR;
^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:333:37: note: each undeclared identifier is reported only once for each function it appears in
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:335:37: error: ‘vkGetPhysicalDeviceXlibPresentationSupportKHR’ undeclared (first use in this function)
return (PFN_vkVoidFunction) vkGetPhysicalDeviceXlibPresentationSupportKHR;
^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c: In function ‘vkGetDeviceProcAddr’:
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:647:37: error: ‘vkCreateXlibSurfaceKHR’ undeclared (first use in this function)
return (PFN_vkVoidFunction) vkCreateXlibSurfaceKHR;
^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:649:37: error: ‘vkGetPhysicalDeviceXlibPresentationSupportKHR’ undeclared (first use in this function)
return (PFN_vkVoidFunction) vkGetPhysicalDeviceXlibPresentationSupportKHR;
nulldrv_gpa.c is an auto-generated file. I'm looking at the python scripts since it seems that's where it comes from. If I figure out how to disable Xlib functions, I'll send in a pull request.
In update_external_sources.sh this step:
svn checkout -r $LUNARGLASS_REVISION_R32 --force https://cvs.khronos.org/svn/repos/SPIRV/trunk/LunarGLASS/ .
requires passworkd and login which I don't have..
being all opensourced by now doesn't make sense,right?
can update script to fetch from public repos?
thanks..
I have the api_dump layer enabled in both the instance and the VkDeviceCreateInfo enabled layers, however the call is not reported. Other calls make prior to the vkCreateDevice call are dumped correctly. When I fix the issue with vkCreateDevice so that it returns success, it is dumped correctly.
"wget" is a necessary dependency.
"autotools" is a necessary dependency.
Prüfe Konnektivität ... Fertig.
./update_external_sources.sh: Zeile 67: wget: Kommando nicht gefunden.
Windows 7, SDK 1.0.21.2, Nvidia GTX 660 ti, driver 372.54 vktrace the cube.exe in the SDK bin directory then replay and I get no rendering and a stream of VK_ERROR_DEVICE_LOST messages. Going back to the commit before "vktrace: map memory types on replay" 7d5b2e9 and everything works fine.
The driver is a key component to reproducing the failure.
Running screenshot layer with standard_validation results in some errors reported. Probably, screenshot layer is not quite correct in it's api usage.
From Dan Ginsburg:
I’m trying to use vktrace in Vulkan SDK 1.0.13 on Win7 to capture a tough to reproduce flickering bug on NVIDIA GTX 760. Unfortunately, when I load into the map it seems to get stuck and eventually crash during recording. If I disable scaleform I can get it to record, so it seems like maybe something scaleform does that is not working in vktrace?
Building from here: https://github.com/nvpro-samples/gl_vk_bk3dthreaded, using sdk-1.0.24 build of VulkanTools, I can trace the demo, but when I try to replay the trace, I get 2 ERROR_DEVICE_LOST errors fro VkQueueSubmit calls and the replay hangs
Using vktrace to trace the atw sample at https://github.com/KhronosGroup/Vulkan-Samples results in an assert - vktrace...utils.c line 147: Expression pHeader->size >= pHeader->next_buffer_offset + byteCount
Most of Sascha Willems' Vulkan samples have a text overlay in the top left corner, however after trace & replay of these samples, the text overlay is missing during the replay.
Oddly enough, when using RenderDoc to launch vkreplay with the same trace file as above, the text overlay is visible!
Using vktrace on cube --validate will produce the following fatal errors on replay:
vktrace -p cube.exe -a --validate -o fred.vktrace vkreplay -t fred.vktrace
Verbose: Enumerated 1 physical devices in the system.
Error: MsgFlags 8 with object 0x7ff94efb9e60, location 1995 returned msgCode 8 and msg vkCreateSwapchainKHR() called with pCreateInfo->imageExtent = (500,500), which is not equal to the currentExtent = (1008,729) returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR().
Error: MsgFlags 8 with object 0x7ff94efb9e60, location 1995 returned msgCode 8 and msg vkCreateSwapchainKHR() called with pCreateInfo->imageExtent = (500,500), which is not equal to the currentExtent = (1008,729) returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR().
Error: Return value VK_ERROR_VALIDATION_FAILED_EXT from API call (vkCreateSwapchainKHR) does not match return value from trace file
VK_SUCCESS.
Error: Failed to replay packet_id 149.
The swapchain layer is logging an error becasue the extents do not match (between trace and replay, on Windows) which causes the vkCreateSwapchain call to fail.
In working through the code and reading about VkUpdateDescriptorSets, I see that VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT should be handled similar to other descriptor types that reference the pImageInfo member, but it is not included among the switch case statements.
I don't immediately have a sample which uses it, so I can't provide a test/repro case, but since I know there are issues with trace & replay of several applications, I wanted to raise this issue as a potential cause of error. Should be a simple fix, but since I can't test & confirm it, I'll leave it to someone else to resolve.
Currently on vkUnmapMemory, vktrace either serializes the entire memory range or nothing if the memory has had a FlushMappedMemoryRange on it. For non-coherent memory this is correct. For coherent memory the app doesn't necessarily need to use FlushMappedMemoryRange but it might. In this case vktrace should probably still serialize the entire range at Unmap even if it has seen some FlushMappedMemoryRange since these aren't strictly required for coherent memory so the app may be relying on the Unmap.
vkGetPhysicalDeviceSurfaceFormatsKHR()
and GetPhysicalDeviceSurfacePresentModesKHR()
functions can have their pXCount
and pXs
arguments as NULL
or not (where X
is either SurfaceFormat
or PresentMode
). The specifications v1.0.17+wsi, in short says:
pXs
is not provided, only the count is returnedpXs
is provided, the minimum of pXCount
and the supported number of X
s are written to the pXs
.Which is nice and clear. However, the swapchain validation layer complains that:
Swapchain(ERROR): object: 0x7fd2a3725d68 type: 2 location: 0 msgCode: 25: GetPhysicalDeviceSurfaceFormatsKHR() called with non-NULL pSurfaceFormatCount; but no prior positive value has been seen for pSurfaceFormats.
Swapchain(ERROR): object: 0x7fd2a3725d8c type: 2 location: 0 msgCode: 25: GetPhysicalDeviceSurfacePresentModesKHR() called with non-NULL pPresentModeCount; but no prior positive value has been seen for pPresentModes.
Digging into why this error is popped, I found this comment in swapchain.cpp
:
// Since we haven't recorded a preliminary value of
// *pSurfaceFormatCount, that likely means that the application
// didn't previously call this function with a NULL value of
// pSurfaceFormats:
The specifications don't seem to require that the function should be called with pXs
once NULL, and then another time not NULL.
Memory types and properties have been changing from driver to driver, so a trace that blindly uses memory type 2 on playback could be getting memory with different properties than it got when the trace was recorded. I think the replayer will need to map memory types with properties on record to memory types with the same properties on playback for all allocations.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.