- Mar 15, 2025
-
-
Part-of: <!994>
-
Signed-off-by:
Vinson Lee <vlee@freedesktop.org> Part-of: <!989>
-
- Mar 05, 2025
-
-
Since the OVR_multiview tests have been bumped to use GLSL 3.3 for the sake of running on NVIDIA's proprietary driver, add a test that multiview vertex shaders which use gl_ViewID_OVR can be compiled back to GLSL-1.30 (#version 130). Signed-off-by:
James Hogan <james@albanarts.com> Acked-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <!987>
-
In order to allow the OVR_multiview tests to run on NVIDIA's proprietary driver for sanity checking, bump all OVR_multiview shaders to GLSL 3.3. Signed-off-by:
-
Add test that blits to multiview framebuffers only blit to the first view in the framebuffer. A normal 2D read framebuffer containing green is blitted to a multiview draw framebuffer containing red, either as a single full blit or two half blits, and the multiview framebuffer is read to confirm that only the first view is changed to green and the others remain red. This test is called with different arguments to control whether full blits or partial blits are performed, and the base view layer index. Signed-off-by:
-
Add test that mismatches between multiview framebuffers and the num_views declared in shaders result in the appropriate errors after draw commands. The test takes 2 arguments, the number of framebuffer views and the number of views declared in the vertex shader. A glClear, triangle draw, and glFinish are performed, and the appropriate error is checked for. The test is run with a variety of arguments between 0 (non-multiview) and 3 (3 views). Tests between non-multiview and single multiview are omitted due to uncertainty or abiguity over whether a non multiview FB/shader counts as having 1 view or none? Signed-off-by:
-
Add a test that reading from a multiview framebuffer with multiple views produces an GL_INVALID_FRAMEBUFFER_OPERATION error as specified in the OVR_multiview spec, and that reading from a multiview framebuffer with only a single view does not produce an error. The cases tested are only those explicitly mentioned in the spec, namely glBlitFramebuffer, glReadPixels, glCopyTexImage2D, and glCopyTexSubImage2D. Signed-off-by:
-
Add a test to render a triangle to multiple layers of two textures, first using separate passes with glFramebufferTextureLayer() to the first texture, and then using a single multiview pass with glFramebufferTextureMultiviewOVR() to the second texture. The resulting texture layers are read back with glGetTexImage() and compared to verify that the multiview drawing gives the same result as equivalent separate passes. This tests the values of gl_ViewID_OVR when used for various things (including both OVR_multiview and OVR_multiview2 cases), baseViewIndex multiview draw behaviour, the use of multiview depth attachments, and display lists with multiview. The test is called with different arguments in order to test single view, stereo views, quad views, and max (GL_MAX_VIEWS_OVR) views, along with both zero and non-zero base layer, and one case of more layers after the multiview views. Depth attachment, display lists, and the OVR_multiview2 cases are tested with max views and both zero and non-zero base layer. v2: Add a couple more test cases, triangle_compare_max_base7 to catch the issue where views beyond layer 7 wouldn't get drawn to, and triangle_compare_max_basemax_layersmax to catch where only the first view would get drawn to when baseViewIndex >= 8, and to push the concept to the limit by maximising both views and baseViewIndex. Signed-off-by: -
Add some basic shader tests for OVR_multiview2. The implied-ovr_multiview.{vert,frag} tests simply check that an OVR_multiview2 extension declaration enables the use of OVR_multiview. The other-static-dependence.vert test checks that a different output than gl_Position can statically depend on gl_ViewID_OVR when OVR_multiview2 is enabled. Signed-off-by: -
Add a test that reading the framebuffer attachment parameters described in the OVR_multiview spec give the appropriate values. A varied set of framebuffer attachments are configured: - COLOR_ATTACHMENT0: non-multiview, 2D - COLOR_ATTACHMENT1: non-multiview, 2D array, 1 layer (1) - COLOR_ATTACHMENT2: non-multiview, 2D array, all layers (0-3) - COLOR_ATTACHMENT3: multiview, 2D array, 1 layer (3) - COLOR_ATTACHMENT4: multiview, 2D array, 2 layers (1-2) - COLOR_ATTACHMENT5: non-multiview, 3D, 1 layer (3) Then the following parameters are read back and validated: - GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR - GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR - GL_FRAMEBUFFER_ATTACHMENT_LAYERED (if exists) - GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER Signed-off-by:
-
Add a test for the additional conditions required for multiview framebuffer completeness in the OVR_multiview spec, namely that the number of views is the same for all populated attachments. We test completeness for each of a sequence of changes to the attachments using the glFramebufferTextureMultiviewOVR() function, covering multiple matching and mismatching combinations in depth, stencil, and several color attachments. Signed-off-by:
-
Add a test for the additional conditions required for framebuffer multiview attachment completeness in the OVR_multiview spec, namely that all the selected layers are less than the layer count of the texture. We test with a 4 layer texture, and an attachment of layers 3-4 (which should be considered an incomplete attachment), and attachments of layers 0-2 and 2-3 (which should be considered complete). Signed-off-by:
-
Add test that glFramebufferTextureMultiviewOVR generates the errors required by the OVR_multiview spec under the specified conditions, and doesn't generate them for several valid cases on the boundary. Signed-off-by:
-
Add an additional linker test to ensure that multiple shaders with only a single num_view declaration will link even if the declaration is in the 2nd shader. Signed-off-by:
-
- Feb 27, 2025
-
-
Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <!992>
-
This also adds a helper to check if an extension is supported. Reviewed-by:
-
Reviewed-by:
-
Reviewed-by:
-
- Feb 20, 2025
-
-
This test is a copy of multidrawarrays-vertexid.c, ported to use OpenGL ES 3.1 and GL_EXT_multi_draw_arrays instead. Part-of: <!991>
-
- Feb 17, 2025
-
-
Iago Toral authored
Dithering is enabled by default in OpenGL but the test checks for results assuming that no dithering is used. Fixes gettextureimage-formats with format RGB5A1 on Panfrost when the init-by-rendering parameter is used to initialize the texture by rendering: Panfrost uses an internal format with higher bit precision than RGB5A1 to represent the framebuffer for the texture. Particularly, it has more than 1 alpha bit and it will take advantage of that to apply dithering on the writeback when dithering is enabled, causing the alpha on the texture to have a dithered pattern and breaking the test expectation. Reviewed-by:
Alejandro Piñeiro <apinheiro@igalia.com> Part-of: <!990>
-
- Feb 07, 2025
-
-
Mykhailo Skorokhodov authored
ARB_program_interface_query, question 8: For GetProgramResourceIndex, what sort of strings can be used to match the resource names for arrays of arrays? For example, let's say a shader declares a uniform such as: uniform vec4 a[3][4][5]; Which one of the following names are accepted? "a[2][1][0]" to identify the base of the bottom-level array? "a[2][1]", to identify the same without the final "[0]"? "a[2]", equivalent to "a[2][0][0]"? Just "a", equivalent to "a[0][0][0]"? RESOLVED: We only accept entries of the form "a[2][1][0]" or "a[2][1]", which is consistent with the existing rules that only allow applications to omit the last index of a bottom-level array that has been rolled up. According to the resolution above, the possible names for vec4 vs_input2[2][2]; are: vs_input2[0] vs_input2[0][0] vs_input2[1] vs_input2[1][0] Signed-off-by:
Mykhailo Skorokhodov <mykhailo.skorokhodov@globallogic.com> Part-of: <!988>
-
- Jan 25, 2025
-
-
This is an exhaustive microbenchmark to evaluate how many pixels hw can process under different circumstances with as little shader code as possible. Part-of: <!979>
-
- Jan 21, 2025
-
-
Timothy Arceri authored
Part-of: <!986>
-
This bug is going to be fixed in server side, but failing the piglit test in this case doesn't make much sense as the driver cannot do anything about the failure. In this situation, the test would now report a warning to be able to tell the difference between a client-side failure and a server-side one. Reviewed-by:
-
- Jan 17, 2025
-
-
Timothy Arceri authored
Part-of: <!984>
-
- Jan 16, 2025
-
-
Fixes arb_clear_texture-float on Panfrost. Reviewed-by:
-
- Jan 15, 2025
-
-
Pierre-Eric Pelloux-Prayer authored
The spec says BadMatch should be generated, which is a X error not a GLX one. The original code was only successful if "glx_error_code != -1" (= there was a GLX error) and "validate_glx_error_code(BadMatch, -1)" (= there was a X error and no GLX error) which is wrong. This commit the glx_error_code != -1 test, but still verifies that BadMatch is generated. This fixes this test on radeonsi (and probably other drivers). Reviewed-by:
-
- Jan 08, 2025
-
-
Jordan Justen authored
Fixes: c2b31333 ("framework: call destroy directly instead of using atexit") Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Acked-by:
-
- Dec 13, 2024
-
-
Marek Olšák authored
The missing test is the one that enables both alpha-to-coverage and alpha-to-one. It currently fails on AMD drivers, but passes on llvmpipe. Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!978>
-
- Dec 09, 2024
-
-
Part-of: <!976>
-
- Nov 28, 2024
-
-
Timothy Arceri authored
Part-of: <!975>
-
These tests make sure changes to mesas loop analysis don't cause loops that do subtraction on the induction var to incorretly unroll. Reviewed-by:
-
- Nov 20, 2024
-
-
Test for a mesa bug where global temps created by the compiler to copy the global constants were conflicting across shaders in the same stage. mesa#12136 Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <!973>
-
Check plane number before really export the buffer, otherwise we may get overflowed results. Part-of: <!965>
-
Verfify texture modifier exported by eglExportDMABUFImageQueryMESA() are in the supported modifier list queried by eglQueryDmaBufModifiersEXT(). Driver may use different modifier for different texture format and size. This test make sure we don't miss any of them in the supported modifier list. Part-of: <!965>
-
- Nov 13, 2024
-
-
Timothy Arceri authored
mesa#12115 Reviewed-by:
-
- Nov 11, 2024
-
-
Pavel Ondračka authored
It is OK to return GL_NONE even if the specific format supports clearing, but there is no HW support for the format. Signed-off-by:
Pavel Ondračka <pavel.ondracka@gmail.com> Reviewed-by:
-
- Nov 07, 2024
-
-
Pavel Ondračka authored
Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Part-of: <!969>
-
- Nov 06, 2024
-
-
David Heidelberg authoredReviewed-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org> Signed-off-by:
David Heidelberg <david@ixit.cz>
Part-of: <!968>
-
- Oct 24, 2024
-
-
Mike Blumenkrantz authoredThere are two possible factories: * `piglit_fbo_framework_create` has a `destroy` function which is called inline in `run_test` before `piglit_report_result`, so this shouldn't need an atexit * `piglit_winsys_framework_init` has no destroy function, so there is nothing to call by adding a hook to be called directly by `piglit_report_result`, the whole atexit thing can be avoided, and instead `piglit_report_result` can just call the fbo framework destructor as needed Part-of: <!966>
-
