mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-06 15:58:05 +02:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
dbdbef673f
The DDMADT instruction of PDS has out-of-bound test capability, which is used for implementation of robust vertex input fetch. According to the pseudocode in the comment block before the "LAST DDMAD" mark in pvr_pipeline_pds.c, the check is between `calculated_source_address + (burst_size << 2)` and `base_address + buffer_size`, in which the `burst_size` seems to correspond to the BSIZE field set in the low 32-bit of DDMAD(T) src3 and the `buffer_size` corresponds to the MSIZE field set in the DDMADT-specific high 32-bit of src3. As the calculated source address is just the base address adds the multiplication result (the offset), the base address could be eliminated from the check, results in the check between `offset + (BSIZE * 4)` and `MSIZE` . Naturally it's expected to just set the MSIZE field to the buffer size. In addition, as the Vulkan spec says "Reads from a vertex input MAY instead be bounds checked against a range rounded down to the nearest multiple of the stride of its binding", the driver rounds down the accessible buffer size before setting MSIZE to it. However when running OpenGL ES 2.0 CTS, two problems are exhibited about the setting of the size to check: - dEQP-GLES2.functional.buffer.write.basic.array_stream_draw sets up a VBO with 3 bytes per vertex (RGB colors and 1B per color) and 340 vertices (results in a buffer size of 1020 = 0x3fc). However as the DMA request size, which is specified by BSIZE, is counted by dwords, 3 bytes are rounded up to 1 dword (which is 4 bytes). When the bound check of the last vertex happens, the vertex's DMA start offset is 0x3f9, so the DDMADT check happens between 0x3fd (0x3f9 + 1 * 4) and 0x3fc, and indicates a check failure. This prevents the last vertex, which is perfectly in-bound, from being properly fetched; this is against the Vulkan specification, and needs to be fixed. - dEQP-GLES2.functional.vertex_arrays.single_attribute.strides. buffer_0_32_float2_vec4_dynamic_draw_quads_1 sets up a VBO with a size of 168 bytes, and tries to draw 6 vertices (each vertex consumes 2 floats (thus 8 bytes) of attribute) with a stride of 32 bytes using this VBO. Zink then translates the VBO to a Vulkan vertex buffer bound with size = 168B, stride = 32B. Here the optional rule about rounding down buffer size happens in the current PowerVR driver, and the checked bound is rounded down to 160B, which prevented the last vertex's 8B attributes to be fetched. It looks like this kind of situation is considered in the codepath without DDMADT, but omitted for the codepath utilizing DDMADT for bound check. So this patch tries to mimic the behavior of DDMADT when setting the MSIZE field of it to prevent false out-of-bounds. It first calculates the offset of the last valid vertex DMA, then adds the DMA request size to it to form the final MSIZE value. With the code calculating the last valid DMA offset considering the situation of fetching the attribute from the space after the last whole multiple of stride, both problems mentioned above are solved by this rework. There're 99 GLES CTS testcases fixed by this change, and Vulkan CTS shows no regression on `dEQP-VK.robustness.robustness1_vertex_access.*` tests. Fixes: |
||
|---|---|---|
| .ci-farms | ||
| .ci-farms-disabled | ||
| .github/workflows | ||
| .gitlab | ||
| .gitlab-ci | ||
| .marge/hooks | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| licenses | ||
| src | ||
| subprojects | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-format-include | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| .mr-label-maker.yml | ||
| .pick_status.json | ||
| .shellcheckrc | ||
| clippy.toml | ||
| CODEOWNERS | ||
| meson.build | ||
| meson.options | ||
| README.rst | ||
| rustfmt.toml | ||
| VERSION | ||
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.mesa3d.org/meson.html>`_): .. code-block:: sh $ meson setup build $ ninja -C build/ $ sudo ninja -C build/ install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.