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
I noticed DepthGaussianNoise fails on my machine but works fine in the CI server.
The integration fails:
[ RUN ] GaussianNoise/RenderPassTest.DepthGaussianNoise/ogre2
/home/matias/Projects/ign/src/ign-rendering/test/integration/render_pass.cc:357: Failure
Expected equality of these values:
255u
Which is: 255
ma
Which is: 0
[ FAILED ] GaussianNoise/RenderPassTest.DepthGaussianNoise/ogre2, where GetParam() = "ogre2" (12204 ms)
To be more specific the integration expects an alpha value (packed/encoded) of 255, but instead it's 0.
Upon closer examination, this is because the test uploads this colour texture:
However the texture is of format R8G8B8_SRGB, therefore GPUs are allowed to do whatever they want with the alpha value.
In the case of my AMD Radeon RX 560 2GB using Mesa drivers, it decides to fetch an alpha of 0 instead of 255, thus causing the test to fail.
This bug should fix itself in the Ogre 2.2 version, because Ogre 2.2 explicitly forbids the use of RGB888 textures in the GPU. The PFG_RGB8_* family of pixel formats can only be used for CPU operations.
direct rendering: Yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 560 Series (POLARIS11, DRM 3.40.0, 5.11.0-051100-generic, LLVM 10.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.1.3 (git-663fa46287)
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.1.3 (git-663fa46287)
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.1.3 (git-663fa46287)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev cf)
root 1680 1.4 0.5 2840064 165080 tty7 Ssl+ 18:35 0:27 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
matias 11249 0.0 0.0 17988 1032 pts/2 S+ 19:05 0:00 grep --color=auto Xorg
Description
Expected behavior: Test should pass
Actual behavior: Test fails
Steps to reproduce
Run ign/build/ignition-rendering5/bin/INTEGRATION_render_pass
Use AMD Radeon RX 560 2GB HW, Mesa drivers.
Workaround
Run the test with LIBGL_ALWAYS_SOFTWARE=1
Other
This bug is incredibly low priority for me; given that the CI does its job, I can comment out the failing lines involving alpha or workaround it with SW, and that it should fix itself with Ogre 2.2
The text was updated successfully, but these errors were encountered:
I noticed DepthGaussianNoise fails on my machine but works fine in the CI server.
The integration fails:
To be more specific the integration expects an alpha value (packed/encoded) of 255, but instead it's 0.
Upon closer examination, this is because the test uploads this colour texture:
However the texture is of format R8G8B8_SRGB, therefore GPUs are allowed to do whatever they want with the alpha value.
In the case of my AMD Radeon RX 560 2GB using Mesa drivers, it decides to fetch an alpha of 0 instead of 255, thus causing the test to fail.
This bug should fix itself in the Ogre 2.2 version, because Ogre 2.2 explicitly forbids the use of RGB888 textures in the GPU. The
PFG_RGB8_*
family of pixel formats can only be used for CPU operations.Environment
Description
Steps to reproduce
Workaround
Run the test with LIBGL_ALWAYS_SOFTWARE=1
Other
This bug is incredibly low priority for me; given that the CI does its job, I can comment out the failing lines involving alpha or workaround it with SW, and that it should fix itself with Ogre 2.2
The text was updated successfully, but these errors were encountered: