profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/NeilBickford-NV/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Neil Bickford NeilBickford-NV NVIDIA neilbickford.com Developer Technology engineer at NVIDIA.

NVIDIA/gvdb-voxels 515

Sparse volume compute and rendering on NVIDIA GPUs

issue closednvpro-samples/vk_raytracing_tutorial_KHR

Incorrect vulkan object name was mentioned in the tutorial

It should be VkPipelineShaderStageCreateInfo instead of VkPipelineStageCreateInfo

It also occured in 3 other places in the text

https://github.com/nvpro-samples/vk_raytracing_tutorial_KHR/blob/d66243800cf497a16dce555684e750917cbb7307/docs/vkrt_tutorial.md.html#L1070

closed time in 7 days

Erfan-Ahmadi

issue commentnvpro-samples/vk_raytracing_tutorial_KHR

Incorrect vulkan object name was mentioned in the tutorial

Looks like this is fixed now in 3e399a - line 1110 now says

At this point, the shader groups reference individual shaders by their index in the above `VkPipelineShaderStageCreateInfo`

Thanks again!

Erfan-Ahmadi

comment created time in 7 days

issue closednvpro-samples/vk_raytracing_tutorial_KHR

Invalid comment regarding the type of vertex data

Hi,

I think it should be vec4 since we are defining a VK_FORMAT_R32G32B32A32_SFLOAT with 4 components. And because of that the comment is somewhat misleading.

https://github.com/nvpro-samples/vk_raytracing_tutorial_KHR/blob/d66243800cf497a16dce555684e750917cbb7307/docs/vkrt_tutorial.md.html#L299

closed time in 7 days

m-radomski

issue commentnvpro-samples/vk_raytracing_tutorial_KHR

Invalid comment regarding the type of vertex data

Looks like this was fixed in d90ce7 - thanks again! https://github.com/nvpro-samples/vk_raytracing_tutorial_KHR/blame/master/docs/vkrt_tutorial.md.html#L296

m-radomski

comment created time in 7 days

issue commentjkuhlmann/cgltf

cgltf_parse_file can crash with custom file_open, should not call memory_free

Oh, yep, looks like that is indeed the same issue!

Also, I can confirm that PR #160 fixes the cgltf_parse_file() issue with custom file callbacks and invalid glTF files - thank you, Johannes!

pixeljetstream

comment created time in 18 days

issue commentjkuhlmann/cgltf

cgltf_parse_file can crash with custom file_open, should not call memory_free

To help out with this, I looked through all the occurrences of options->file.release and options->memory.free in cgltf.h. Assuming file.release and memory.free are not intended to be interchangeable (based on the issue #94 discussion here), then there may be two issues:

  • cgltf_parse_file() gets a file_data pointer using file.read above. But this pointer is later passed to either memory_free here if the parse fails, or passed to file.release in cgltf_free() here. (Looks like Johannes posted a fix right as I was writing this - I'll test it out!)
  • When reading buffers, buffers stored in files are read using file.read here, but Base64 buffers are decoded to a buffer allocated using memory.alloc[here](https://github.com/jkuhlmann/cgltf/blob/master/cgltf.h#L1209). Both of these appear to be released usingfile.releaseincgltf_free()` here (there's a special case for the .glb binary section which gets handled correctly!)

Also - thanks very much; I'll test out the PR and hopefully it should fix the cgltf_parse_file() issue!

pixeljetstream

comment created time in 18 days

issue closednvpro-samples/nvpro_core

raytraceKHR_vk.cpp instances buffer validation error

When building vk_mini_path_tracer, the following validation layer error is output during runtime:

ERROR: VUID-vkCmdBuildAccelerationStructuresKHR-geometry-03673
 --> Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-geometry-03673 ] Object 0: handle = 0x10d1641d488, type = VK_OBJECT_TYPE_DEVICE; Object 1: handle = 0xd175b40000000013, name = nvvk::RaytracingBuilderKHR::m_instBuffer.buffer ( in raytraceKHR_vk.cpp:262), type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x8a7de95d | vkCmdBuildAccelerationStructuresKHR(): The buffer associated with pInfos[0].pGeometries[0].geometry.instances.data was not created with VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR. The Vulkan spec states: The buffers from which the buffer device addresses for all of the geometry.triangles.vertexData, geometry.triangles.indexData, geometry.triangles.transformData, geometry.aabbs.data, and geometry.instances.data members of all pInfos[i].pGeometries and pInfos[i].ppGeometries are queried must have been created with the VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR usage flag

I was able to resolve this error by changing line 261 of raytraceKHR_vk.cpp to this: m_instBuffer = m_alloc->createBuffer(cmdBuf, geometryInstances, VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT | VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR); but I do not have much experience with Vulkan so I'm not sure if this is the ideal/correct solution.

closed time in 21 days

Jebbly

issue commentnvpro-samples/nvpro_core

raytraceKHR_vk.cpp instances buffer validation error

Okay - the fixed TLAS scratch buffer usage flags have been fixed in the latest bulk update - see https://github.com/nvpro-samples/nvpro_core/commit/fd6f14c4ddcb6b2ec1e79462d372b32f3838b016#diff-1481edec8577c4d7009c08b60447a6e183e0639022beb5019a5eaa1f40476d12R354 .

Thanks again!

Jebbly

comment created time in 21 days

startedNVIDIAGameWorks/nvrhi

started time in a month

issue commentnvpro-samples/nvpro_core

raytraceKHR_vk.cpp instances buffer validation error

Hi Jeffrey - thanks for the quick report! It looks like Martin-Karl fixed this a few hours ago with commit 81b3271, but this also turned up an issue with the TLAS scratch buffer usage flags that only appears when using the latest main branch of the Vulkan Validation Layers. I've just made a commit to fix this in the upstream repository, and I'll close this issue when that's merged into the public repository.

Thanks again!

Jebbly

comment created time in a month

push eventnvpro-samples/nvpro_core

joshuafc

commit sha 93ef686c3d49e32163de06c589536d35cf2b3e99

fix: error msg not match if condition VK_KHR_acceleration_structure vs VK_KHR_ray_tracing Signed-off-by: joshuafc <joshuafc@foxmail.com>

view details

Neil Bickford

commit sha 449add36fd4bd2414f08ddad12337589bf0d1305

Merge pull request #26 from joshuafc/patch-1 fix: error msg not match if condition

view details

push time in a month

PR merged nvpro-samples/nvpro_core

fix: error msg not match if condition

fix: error msg not match if condition, VK_KHR_acceleration_structure vs VK_KHR_ray_tracing

#if **VK_KHR_acceleration_structure**
...
#else
    #error This include requires **VK_KHR_ray_tracing** support in the Vulkan SDK.
...
+1 -1

3 comments

1 changed file

joshuafc

pr closed time in a month

pull request commentnvpro-samples/nvpro_core

fix: error msg not match if condition

Thanks! Merging now.

joshuafc

comment created time in a month

issue closednvpro-samples/vk_mini_path_tracer

Issues with underscore in "_edit" dir name on Linux

I'm trying to do the tutorial on Linux, but I've run into a problem when compiling the first shader file. The shader compiler is not run for the _edit project and no spv file is generated. It appears that this is caused by the underscore in the name of the directory. I was able to fix the issue by renaming the directory, or alternatively, by adding the keyword VERBATIM to the add_custom_command call in the _compile_GLSL_flags macro in nvpro_core/cmake/setup.cmake.

closed time in a month

timo-oster

issue commentnvpro-samples/vk_mini_path_tracer

Issues with underscore in "_edit" dir name on Linux

Okay, the improvement mentioned in the last comment has now been integrated in commit 5cf2ea9! This should help avoid some issues with creating shaders in the _edit directory. Thanks again!

timo-oster

comment created time in a month

issue closednvpro-samples/vk_mini_path_tracer

triangles.maxVertex seems to get a wrong value

In https://github.com/nvpro-samples/vk_mini_path_tracer/blob/6095e1d4bc57e6f3010709868931d9cbb16207bf/vk_mini_path_tracer/main.cpp#L143 objVertices.size() - 1 is assigned to triangles.maxVertex. Since objVertices is a vector of floats instead of a vector of vertices, the size of objVertices indicates total number of floats (3x number of vertices).

In Vulkan specs

maxVertex is the highest index of a vertex that will be addressed by a build command using this structure.

So objVertices.size() / 3 - 1 should be the correct value if I got it right.

BTW, it is also confusing that Vulkan uses highest index of a vertex instead of number of vertices, while the DirectX API uses VertexCount in D3D12_RAYTRACING_GEOMETRY_TRIANGLES_DESC struct. Does anyone know why?

closed time in a month

shiuang

issue commentnvpro-samples/vk_mini_path_tracer

triangles.maxVertex seems to get a wrong value

Alright, this has been fixed in commit 5cf2ea9 - thanks again!

shiuang

comment created time in a month

issue openedKhronosGroup/Vulkan-ValidationLayers

Between-stage interface validation produces incorrect errors when fragment shaders use pervertexNV attributes

Describe the Issue Hi Vulkan Validation Layer team,

Here's an issue I just ran into - briefly, it looks like when a fragment shader uses a pervertexNV input block (which requires the GL_NV_fragment_shader_barycentric extension), CoreChecks::ValidateInterfaceBetweenStages will incorrectly produce three UNASSIGNED-CoreValidation-Shader-InputNotProduced errors.

This issue includes a repro and a short trace pointing to where the root cause might be.

Repro Steps

Here's a relatively quick way to reproduce this by modifying the Vulkan-Samples Hello Triangle sample and using a GPU that supports VK_NV_fragment_shader_barycentric.

First, set up the environment so that VKB_VALIDATION_LAYERS is defined (or manually include VK_LAYER_KHRONOS_validation).

Then replace Vulkan-Samples\shaders\triangle.vert with

#version 460
// (license information omitted)

layout(location = 0) out PerVertex {
  vec3 vtxPos;
} outputs;

vec2 triangle_positions[3] = vec2[](
    vec2(0.5, -0.5),
    vec2(0.5, 0.5),
    vec2(-0.5, 0.5)
);

void main()
{
    gl_Position = vec4(triangle_positions[gl_VertexIndex], 0.0, 1.0);
    
    outputs.vtxPos = gl_Position.xyz;
}

and Vulkan-Samples\shaders\triangle.frag with

#version 460
// (license information omitted)

#extension GL_NV_fragment_shader_barycentric : enable

layout(location = 0) in pervertexNV PerVertex {
  vec3 vtxPos;
} inputs[3];

layout(location = 0) out vec4 out_color;

void main()
{
  // The purpose of this is only to do something with the barycentric inputs;
  // the exact operations don't matter.
  vec3 b = gl_BaryCoordNV;
  if(b.x > b.y && b.x > b.z)
  {
    out_color = vec4(inputs[0].vtxPos, 1.0);
  }
  else if(b.y > b.z)
  {
    out_color = vec4(inputs[1].vtxPos, 1.0);
  }
  else
  {
    out_color = vec4(inputs[2].vtxPos, 1.0);
  }
}

In hello_triangle.cpp, in HelloTriangle::prepare(), add the VK_NV_fragment_shader_barycentric device extension:

	init_device(context, {"VK_KHR_swapchain", VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME});

Finally, enable the fragment shader barycentric feature in HelloTriangle::init_device():

...
	device_info.ppEnabledExtensionNames = required_device_extensions.data();

	// Check and enable fragment-shader barycentric features
	VkPhysicalDeviceFeatures2 features2{ VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2 };
	VkPhysicalDeviceFragmentShaderBarycentricFeaturesNV baryFeatures{ VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV };
	features2.pNext = &baryFeatures;
	vkGetPhysicalDeviceFeatures2(context.gpu, &features2);
	if(baryFeatures.fragmentShaderBarycentric != VK_TRUE){
		throw new std::runtime_error("Fragment shader barycentric features NV was enabled as an extension, but could not enable the Vulkan feature!");
	}
	device_info.pNext = &features2;

	VK_CHECK(vkCreateDevice(context.gpu, &device_info, nullptr, &context.device));
...

This will cause the console window to print out three InputNotProduced errors, even though the vertex shader writes to these inputs and the graphical window displays the expected result:

[info] Logger initialized
...
[info] Initializing vulkan device.
[error] [samples\api\hello_triangle\hello_triangle.cpp:34] Validation Layer: Error: Validation: Validation Error: [ UNASSIGNED-CoreValidation-Shader-InputNotProduced ] Object 0: handle = 0x9fde6b0000000014, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x23e43bb7 | fragment shader consumes input location 0.0 which is not written by vertex shader
[error] [samples\api\hello_triangle\hello_triangle.cpp:34] Validation Layer: Error: Validation: Validation Error: [ UNASSIGNED-CoreValidation-Shader-InputNotProduced ] Object 0: handle = 0x9fde6b0000000014, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x23e43bb7 | fragment shader consumes input location 1.0 which is not written by vertex shader
[error] [samples\api\hello_triangle\hello_triangle.cpp:34] Validation Layer: Error: Validation: Validation Error: [ UNASSIGNED-CoreValidation-Shader-InputNotProduced ] Object 0: handle = 0x9fde6b0000000014, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x23e43bb7 | fragment shader consumes input location 2.0 which is not written by vertex shader

image

Analysis

I stepped through the code that handles this, and I think the root cause might be because the code assumes that fragment shaders can't take an array of vertices as input. pervertexNV inputs break that assumption, because they have one input for each of the triangle vertices. More specifically,

  • vkCreateGraphicsPipeline calls CoreChecks::ValidateInterfaceBetweenStages with the vertex producer_stage and fragment consumer_stage. This function calls consumer->CollectInterfaceByLocation(). consumer_stage->arrayed_input is false, which will ultimately cause the issue.
  • consumer->CollectInterfaceByLocation() calls CollectInterfaceBlockMembers() several times. The important thing here is whether it returns true or false.
  • CollectInterfaceBlockMembers() starts by calling GetStructType() to ensure the input is an interface block:
spirv_inst_iter SHADER_MODULE_STATE::GetStructType(spirv_inst_iter def, bool is_array_of_verts) const {
    while (true) {
        if (def.opcode() == spv::OpTypePointer) {
            def = get_def(def.word(3));
        } else if (def.opcode() == spv::OpTypeArray && is_array_of_verts) {
            def = get_def(def.word(2));
            is_array_of_verts = false;
        } else if (def.opcode() == spv::OpTypeStruct) {
            return def;
        } else {
            return end();
        }
    }
}
  • In the SPIR-V code, interface blocks between vertex and fragment shaders are typically OpTypePointers to OpTypeStructs. But this perVertexNV input is an OpTypePointer to an OpTypeArray of OpTypeStructs.
  • So because is_array_of_verts is false, GetStructType doesn't step through the OpTypeArray layer of the pervertexNV variable, and returns end(). This makes CollectInterfaceBlockMembers() think that it isn't a block.
  • As a result, for the VS/FS pair above in ValidateInterfaceBetweenStages(), outputs is empty, while inputs has 3 members - one for each element of the array. This causes the subsequent code to think that the inputs and outputs are mismatched.

I'm not sure how to fix this.

Valid Usage ID All UNASSIGNED-CoreValidation-Shader-InputNotProduced; please see output above.

Environment:

  • OS: Windows Version 20H2 (OS Build 19042.1110)
  • GPU: Any GPU supporting VK_NV_fragment_shader_barycentric. This repro was made on an RTX 2080 Ti.
  • SDK or header version if building from repo: Encountered with both the 1.2.176.1 SDK and the top of tree (as of commit b3f17dc5).
  • Options enabled (synchronization, best practices, etc.): Default options as used in Vulkan-Samples. Issue appears to arise in CoreChecks.

Additional context Please see above description.

Thanks!

created time in a month

pull request commentnvpro-samples/nvpro_core

Update nvmath_glsltypes.h

Looks like a member of our team independently added the mat3 typedef, so this should be in main with the next bulk update - thanks!

3d4m-vladimir

comment created time in a month

pull request commentnvpro-samples/nvpro_core

fix: error msg not match if condition

Hi joshuafc - thanks for the pull request! Could you sign off on your Git commit so that we're able to integrate it? DCO-Bot has the required action here: https://github.com/nvpro-samples/nvpro_core/pull/26/checks?check_run_id=3336936192

Thanks again!

joshuafc

comment created time in a month

pull request commentnvpro-samples/nvpro_core

Add missing include in imgui_helper.h (<limits>)

Hi Stephan - thanks for the pull request! Could you sign off on your Git commit so that we're able to integrate it? DCO-Bot has the required action here: https://github.com/nvpro-samples/nvpro_core/pull/25/checks?check_run_id=3303789963

Thanks again!

theHamsta

comment created time in a month

issue commentnvpro-samples/vk_mini_path_tracer

Issues with underscore in "_edit" dir name on Linux

Hi again Timo,

Thanks, that's good to hear! I just added something upstream (which should be arriving with the next bulk-update) that might address a similar thing - since the _edit project doesn't include the shaders directory by default (as it's empty), it's easy to create a .glsl file in _edit directly, instead of creating an _edit/shaders directory and then creating the .glsl file there. I added some additional CMake code to detect when this happens and automatically move files and create the needed folder structure.

Thanks again!

timo-oster

comment created time in a month

issue commentnvpro-samples/vk_mini_path_tracer

triangles.maxVertex seems to get a wrong value

Hi shiuang! I think you're correct - I've fixed this upstream, and this should be included in the next nvpro-samples bulk update (I'll close the issue then). I don't know about the VertexCount difference, unfortunately!

shiuang

comment created time in a month

startedApress/Ray-Tracing-Gems-II

started time in 2 months

issue commentnvpro-samples/vk_mini_path_tracer

Issues with underscore in "_edit" dir name on Linux

Hi timo-oster,

Thanks, that looks like a bug, and it sounds like adding VERBATIM is the fix! I'm trying to understand the root cause of why the underscore is causing issues, though, so that we can check if there are similar issues elsewhere and avoid this in the future - do you happen to know why this might be?

On a fresh Ubuntu 20.04 running in WSL using the Makefiles generator (I haven't tested ninja on the latest version yet), it seems to create the .spv file:

[ 95%] Built target nvpro_core
[ 97%] Generating /home/nbickford/nvpro-samples/vk_mini_path_tracer/_edit/shaders/raytrace.comp.glsl.spv
/usr/bin/glslangValidator --target-env vulkan1.2 -o shaders/raytrace.comp.glsl.spv -g /home/nbickford/nvpro-samples/vk_mini_path_tracer/_edit/shaders/raytrace.comp.glsl
/home/nbickford/nvpro-samples/vk_mini_path_tracer/_edit/shaders/raytrace.comp.glsl
Scanning dependencies of target vk_mini_path_tracer__edit
[100%] Building CXX object _edit/CMakeFiles/vk_mini_path_tracer__edit.dir/main.cpp.o
[100%] Linking CXX executable /home/nbickford/nvpro-samples/bin_x64/Release/vk_mini_path_tracer__edit.exe
[100%] Built target vk_mini_path_tracer__edit

The generated Makefile appears to have the correct syntax - I can definitely spot an issue with spaces here that VERBATIM would fix, but that doesn't match up with how renaming _edit would fix it:

cd /home/nbickford/nvpro-samples/vk_mini_path_tracer/_edit && /usr/bin/glslangValidator --target-env vulkan1.2 -o shaders/raytrace.comp.glsl.spv -g /home/nbickford/nvpro-samples/vk_mini_path_tracer/_edit/shaders/raytrace.comp.glsl

I could imagine an issue with backslashes and escape sequences, but these are forward slashes; apparently some Linux GUIs display underscores as spaces, but that is probably not the problem here.

Thanks!

--Neil

timo-oster

comment created time in 2 months

startednvpro-samples/vk_compute_mipmaps

started time in 2 months

issue closedNVIDIA/gvdb-voxels

Hardware Requirement

I need a little help with hardware selection, all test systems we have done was done on systems with GTX 1070 GPUs. We have a number of systems using GDVB to roll out soon, hardware selection on the machines now quite a priority

Only requirement listed in the documentation I could find "NVIDIA Kepler generation or later GPU" Tests on Quadro M2000 don't work even for some of the small sample that ships with GVDB. The M2000 is Maxwell based which is successor to Kepler and should work or am I missing something?
Will RTX 2070 & RTX 3070 do the trick? What about Quadro RTX 4000? What Nvidia CPU to use in laptops?

closed time in 2 months

jacquesvaneeden

issue commentNVIDIA/gvdb-voxels

Hardware Requirement

Hi Jacques! We should support the M2000; could you share what error you're getting when running the GVDB sample?

jacquesvaneeden

comment created time in 2 months