Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird behavior with large uniform buffers with the Vulkan backend #809

Open
tcdude opened this issue Aug 10, 2023 · 0 comments
Open

Weird behavior with large uniform buffers with the Vulkan backend #809

tcdude opened this issue Aug 10, 2023 · 0 comments

Comments

@tcdude
Copy link
Contributor

tcdude commented Aug 10, 2023

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:

  1. bad.frag.glsl has one more function than good.frag.glsl
  2. 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.

To Reproduce
Steps to reproduce the behavior:

  1. Clone this repo
  2. Compile the project using the Vulkan graphics backend
  3. Run the repro binary
  4. 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:
image

If compiled using Direct3D12 the correct output looks like this:
image

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
  • IDE and/or compiler used: msvc/clang
  • Kinc revision: cb50ced
  • Kinc build output:
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant