themaister / granite Goto Github PK

I'm able to run the command from the @cyanreg blogpost here successfully on a NVidia hardware on linux. But I get this error with Granite:

[ERROR]: Failed to create swapchain (code: -3)

Perhaps VK_IMAGE_USAGE_TRANSFER_SRC_BIT should be used here instead of VK_IMAGE_USAGE_TRANSFER_DST_BIT.

I have a question about synchronization when it comes to uploading images with initial data.

I've built my own Vulkan implementation very similar to Granite's, using Vulkan.hpp instead, but mostly the same functionally. I'm not sure if I've missed something or if this is a use-case you've simply never covered.

The asset manager in my program loads textures asynchronously on worker threads. This means that images can be created, uploaded, and have mipmaps generated in one frame, but not actually be used that frame in a shader. As far as I can tell, there doesn't appear to be any synchronization for this situation, because I would get errors that command pools are being reset before the image is fully uploaded. This makes sense, since there are no barriers or semaphores keeping the command buffer alive until the image is uploaded.

But I'm not sure where the best place to put such synchronization would be. Would I increment the queue's timeline value and insert a signal on that? Would I create a semaphore for each image upload? Or does this synchronization already exist in Granite and I'm simply misusing it?

cmake configuration done but when running ninja it failed with:

ninja: error: 'third_party/shaderc/third_party/glslang/OGLCompilersDLL/libOGLCompiler.a', needed by 'compiler/libgranite-compiler.a', missing and no known rule to make it

In renderer/render_graph.hpp:251 is the declaration of the following member:

VkPipelineStageFlags used_queues = 0;

Which compiles because it is implicitly converted where used, but judging by the usage it should be of type RenderGraphQueueFlagBits

Which version of GLTF are you using ？ Version of rapidjson could also be a problem , Failed to read JSON .

I noticed texture-decoder-test is not passing for me with astc formats but fails on "4 x 4 UNORM". I modified test to not exit on first failure and I see there are more failures if I let it continue. I wanted to ask do you think this could be a platform specific issue or Granite issue? Is there a known 'good point' where tests passed?

I've attached here log where I've commented out all but astc test run and force all the sub-tests to run:
granite.log

Fossilize link to https://github.com/Themaister/Fossilize instead of https://github.com/ValveSoftware/Fossilize

Hi,
just testing Granite for first time.. built on Linux..
clone repo and did git submodule update --init
but still lots of samples error about assets:
./pcf-test

[ERROR]: open(), error: No such file or directory
[ERROR]: OSFilesystem::open(): MMapFile failed to open file
[ERROR]: Failed to open file: assets://pipelines.json

[ERROR]: open(), error: No such file or directory
[ERROR]: OSFilesystem::open(): MMapFile failed to open file
[ERROR]: Failed to open file: assets://shader_cache.json
[ERROR]: Failed to load shader cache assets://shader_cache.json from disk. Skipping ...

etc..
also
./gltf-viewer
[ERROR]: open(), error: No such file or directory
[ERROR]: OSFilesystem::open(): MMapFile failed to open file
[ERROR]: Failed to open file: assets://scene.glb
[ERROR]: application_create() threw exception: Failed to load GLTF file.

where to obtain this assets?
thanks..

is possible using on IOS? using Molten VK.

would you please answer my question why you use half the table defined by Vulkan spec for ETC2/EAC modifiler table? and I've notice there is no SIGNED EAC format support in you eac path, is it related?
https://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html#Table-etc2eac-modifiers

Hey Themaister, I recently read your blog in https://themaister.net/blog/2019/04/20/a-tour-of-granites-vulkan-backend-part-3/ about the descriptor set management in Granite. In the blog you talked about the driver implementation of descriptor pool.

On certain GPUs, allocating descriptor sets is, or at least used to be very costly. The descriptor pools might not be implemented as true pools (sigh …), so every vkAllocateDescriptorSets would mean a global heap allocation, absolutely horrible for performance.

I would like to know if mainstream PC/console platforms use this mechanism, and I would appreciate it if you could provide some documents or implementation detail about that.

It looks like push constants aren't needed in assets/shaders/decode/*.comp.

The two changes needed for this are:

1. Replacing registers.resolution with imageSize(OutputImage) in

    if (any(greaterThanEqual(coord.xy, registers.resolution)))                                 
        return; 

2. Replacing registers.error_color with DECODE_8BIT ? uvec4(0xff, 0, 0xff, 0xff) : uvec4(0xffff) in

    imageStore(OutputImage, coord, registers.error_color);

compile with the latest code,error come with some unkown member in ffmpeg hwcontext_vulkan.h:

/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:892:9: error: no member named 'lock_queue' in 'AVVulkanDeviceContext'
vk->lock_queue = [](AVHWDeviceContext *ctx, int, int) {
~~ ^
/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:897:9: error: no member named 'unlock_queue' in 'AVVulkanDeviceContext'
vk->unlock_queue = [](AVHWDeviceContext *ctx, int, int) {
~~ ^
/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:949:11: error: no member named 'img_flags' in 'AVVulkanFramesContext'
vk->img_flags |= VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT;
~~ ^
/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:1192:34: error: no member named 'lock_frame' in 'AVVulkanFramesContext'
inline void lock() const { vk->lock_frame(frames, vk_frame); }
~~ ^
/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:1193:36: error: no member named 'unlock_frame' in 'AVVulkanFramesContext'
inline void unlock() const { vk->unlock_frame(frames, vk_frame); }
~~ ^
/Users/xxx/workspace/Granite/video/ffmpeg_decode.cpp:1207:19: error: no member named 'img_flags' in 'AVVulkanFramesContext'
info.flags = vk->img_flags;
~~ ^
/Users/panbin/workspace/Granite/video/ffmpeg_decode.cpp:1241:16: error: no member named 'queue_family' in 'AVVkFrame'
if (vk_frame->queue_family[0] != VK_QUEUE_FAMILY_IGNORED)

-- Configuring Shaderc to avoid building tests.
-- asciidoctor was not found - no documentation will be generated
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find PythonInterp: Found unsuitable version "2.7.18", but
required is at least "3" (found /usr/bin/python)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:391 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.16/Modules/FindPythonInterp.cmake:169 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
third_party/shaderc/cmake/setup_build.cmake:38 (find_package)
third_party/shaderc/CMakeLists.txt:44 (include)

Of course python3 is installed.

cheers,

neshume

Hello!

I am tring to build using Visual Studio 2015 Update 3, however following happens:

application_glfw.cpp(52): error C2664: 'bool Vulkan::Context::init_loader(PFN_vkGetInstanceProcAddr)': cannot convert argument 1 from 'GLFWvkproc (__cdecl *)(VkInstance,const char *)' to 'PFN_vkGetInstanceProcAddr'

This is because call convention is incompatible here: seems GLFW is __cdecl, while Vulkan function pointers are __stdcall.

I'm opening issue as there are no discussions tab.

I was wondering how does the renderer behave with D3D11 like logic where you create pipeline before draw/dispatch?

I saw you use fossilize to prewarm pipelines, in my engine I'm using VkPipelineCache, should I expect speed up?
How big would get the cache in real game for example?

Thanks in advance

https://github.com/Themaister/Granite/blob/3e4b24dab7e0a0f9ca7496da44cc5aa62a1d60e5/vulkan/shader.cpp#L194..L196

This fragment of code assumes, that only used (active) push constants need to be placed in the pipeline layout range.

However, the Vulkan spec says:

Similarly, the push constant block declared in each shader (if present) must only place variables at offsets that are each included in a push constant range (...)

So all declared variables should be backed by the range.

Following disabled chunk of code is more correct. It seems this is not pessimization of layers :) - this fixes crashing on at least one Vulkan implementation:

// The validation layers are too conservative here, but this is just a performance pessimization.
		size_t size =
		    compiler.get_declared_struct_size(compiler.get_type(resources.push_constant_buffers.front().base_type_id));
		layout.push_constant_offset = 0;
		layout.push_constant_range = size;

Fix:

buffer_info == other.buffer_info

Btw: Good work.