Inconsistent compute shader behavior about panda3d HOT 8 CLOSED

I can confirm. Important to note that when I write the pixel green in the shader, instead of flipping the red and green channels, I do get a green texture. This might mean that the input texture might not be getting through correctly.

OpenGL renderer string: Mesa Intel(R) HD Graphics 5300 (BDW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.2.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.2.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:```

from panda3d.

I can confirm that this program works and displays as expected with Intel HD Graphics 630 running on Ubuntu 22. It displays as a black quad only running with a dedicated NVIDIA GPU on the same machine and OS. Technically I've only tested this with a slightly different but related gist here: https://gist.github.com/Schwarzbaer/c2087389e55e1c83bc5ac9f5c41626e8

from panda3d.

I wonder if this is a mesa regression.

from panda3d.

I would like information about the exact Panda version used from the people who can and can't reproduce the bug.

What if you assign the textures like so?

dummy.set_shader_input("fromTex", texture_in, read=True, write=False)
dummy.set_shader_input("toTex", texture_out, read=False, write=True)

And what if you set gl-immutable-texture-storage true in Config.prc?

I'm also wondering if it's possible that pending writes haven't been flushed yet--but Panda should be issuing the proper memory barriers, so I don't think anything else (like a fence) is necessary. Could people who experience the bug also try spamming a couple of render_frame() calls before extract_texture_data call, just to check, though?

from panda3d.

Updated the demo code: https://gist.github.com/Schwarzbaer/5d43f4b43b49420667912ccbe5d7e0ee
It now incorporates the explicit read/write flags on dummy.set_shader_input, which you can toggle off again by setting explicit_read_write = False in line 16.
Here is the code I used to extract version information from Panda3D:

from panda3d.core import PandaSystem
from direct.showbase.ShowBase import ShowBase


ShowBase()
gsg = base.win.getGsg()

print(f"Panda3D version: {PandaSystem.get_version_string()}")
print(f"git commit     : {PandaSystem.get_git_commit()}")
print()
print(f"Driver vendor  : {gsg.get_driver_vendor()}")
print(f"Driver version : {gsg.get_driver_version()}")
print(f"Shader version : {gsg.get_driver_shader_version_major()}.{gsg.get_driver_shader_version_minor()}")

Okay, and the result?

Green square and appropriate data with and without explicit read/write.

Panda3D version: 1.10.13
git commit     : 470e352ab87ceae6e30429720e4690c8371f5a55

Driver vendor  : Intel
Driver version : 4.6 (Compatibility Profile) Mesa 20.3.5
Shader version : 4.60

from panda3d.

both with

Panda3D version: 1.10.14
git commit     : 26fae21cb9ffed023a3dda385b88ebe213c5c200

Driver vendor  : Intel
Driver version : 4.6 (Compatibility Profile) Mesa 23.3.0
Shader version : 4.60

and

Panda3D version: 1.11.0
git commit     :  ( doesn't show, it's commit 6f89b8e72090c4ab4302dbe357b8d005cf60a847 from main, October 13)

Driver vendor  : Intel
Driver version : 4.6 (Compatibility Profile) Mesa 23.3.0
Shader version : 4.60

on both wayland and x11 (though I doubt this matters),
with gl-immutable-texture-storage true, false or default,
and with the explicit read/write kwargs,
still only a black square.

I'll repeat that writing the pixels explicitly green in the shader, bypassing the input texture, does produce a green square, meaning the shader is producing output.

from panda3d.

I get the black square with:

Windows 10
Nvidia GTX 1660 Ti

Panda3D version: 1.10.13
git commit     : 470e352ab87ceae6e30429720e4690c8371f5a55

Driver vendor  : NVIDIA Corporation
Driver version : 4.6.0 NVIDIA 535.98
Shader version : 4.60

from panda3d.

There's no bug here, not really, but a serious usability defect.

When you call texture.load(...), it replaces all information about a texture, including its format. In this case, the format is being set to F_rgba. By default, for floating-point data, that translates to GL_RGBA16F, which doesn't match what you have in the shader, so you get undefined behaviour.

Panda can't catch this because it doesn't know what format you wrote in your shader. With the new shader pipeline, we'll be able to catch format mismatches. I will add a note to #1381.

To fix the sample code, add a line to texture_in.set_format(Texture.F_rgba32) (also for texture_out) after the call to load(). Remove the lines to setup_2d_texture, since whatever that does gets overridden by load().

An alternative way to create an empty texture using setup_2d_texture is to use set_clear_color, without load().

from panda3d.