You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Once uniform buffers in Vulkan get larger than a specific size (around 256 floats in total) the fragment shader stops to render/blend correctly.
In the linked repro repo below there are two shader pairs that only differ in two ways:
bad.frag.glsl has one more function than good.frag.glsl
bad.frag.glsl has a total uniform buffer of 259 floats, while good.frag.glsl has 255
To show that bad.frag.glsl actually renders almost correctly, just fails to set the proper alpha value, one can add a line to the main function setting the alpha of frag_color to 1 and see that every fragment actually has the correct color value, just a wrong alpha value of 0.
Changing the value of this define does not help with the issue.
Compile the project using the Vulkan graphics backend
Run the repro binary
Compile using the Direct3D12 graphics backend
Expected behavior
Same result from these two draw calls, regardless of total uniform buffer size and (G5) backend. Otherwise possibly a warning/error if the uniform buffer is too large to handle.
Screenshots
With Vulkan the output looks like this:
If compiled using Direct3D12 the correct output looks like this:
Execution Environment:
Host system (where you compile your code): Win 10 and Linux x64
Target system (where you run your code): Win 10 and Linux x64
Executing task: C:\code\vulkannodrawrepro/Kinc/make.bat -g vulkan --compile --debug
Using Kinc (cb50ced0) from C:\code\vulkannodrawrepro\Kinc
kfile found.
Creating Windows project files.
Compiling shader 1 of 7 (bad.frag).
Compiling shader 2 of 7 (bad.vert).
Compiling shader 3 of 7 (good.frag).
Compiling shader 4 of 7 (good.vert).
Compiling shader 5 of 7 (tex.frag).
Compiling shader 6 of 7 (g1.frag).
Compiling shader 7 of 7 (g1.vert).
Compiling...
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.5.5
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
MSBuild version 17.5.1+f6fdcf537 for .NET Framework
Build time: 0m 7s
Done.
Application output (if it runs):
When running on Windows
-------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code
with Visual Studio Code, Visual Studio or Visual Studio for Mac
software to help you develop and test your applications.
-------------------------------------------------------------------
Running with Vulkan validation layers enabled.
[OBS] Failed to open pipe
[OBS] graphics-hook.dll loaded against process: ShaderTest.exe
[OBS] (half life scientist) everything.. seems to be in order
The program '[26544] ShaderTest.exe' has exited with code 0 (0x0).
Additional context
Since uniform buffer size is a limiting factor on OpenGL/GLES backends regardless, I currently use a texture instead of a uniform buffer to successfully work around this issue. But the behavior difference is interesting and if this can be fixed I would probably switch back to using uniform buffers instead.
The text was updated successfully, but these errors were encountered:
Describe the bug
Once uniform buffers in Vulkan get larger than a specific size (around 256 floats in total) the fragment shader stops to render/blend correctly.
In the linked repro repo below there are two shader pairs that only differ in two ways:
bad.frag.glsl
has one more function thangood.frag.glsl
bad.frag.glsl
has a total uniform buffer of 259 floats, whilegood.frag.glsl
has 255To show that
bad.frag.glsl
actually renders almost correctly, just fails to set the proper alpha value, one can add a line to themain
function setting the alpha offrag_color
to 1 and see that every fragment actually has the correct color value, just a wrong alpha value of 0.Changing the value of this define does not help with the issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Same result from these two draw calls, regardless of total uniform buffer size and (G5) backend. Otherwise possibly a warning/error if the uniform buffer is too large to handle.
Screenshots
With Vulkan the output looks like this:
If compiled using Direct3D12 the correct output looks like this:
Execution Environment:
When running on Windows
Additional context
Since uniform buffer size is a limiting factor on OpenGL/GLES backends regardless, I currently use a texture instead of a uniform buffer to successfully work around this issue. But the behavior difference is interesting and if this can be fixed I would probably switch back to using uniform buffers instead.
The text was updated successfully, but these errors were encountered: