91cf9b4e43
This is the most serious bug we've had in a long time due to a fundamental misunderstanding of the hardware (due to incomplete reverse-engineering). It caught me off guard. The texture descriptor has "mode" bits which configure two aspects of how the address pointer is interpreted: * whether it is indirected, pointing to a secondary page table for sparse * whether it writes texture access counters (for Metal's idea of sparse). ...Neither of these is a "null texture" mode. So why did I see Apple's blob using a non-normal mode for null textures, and why did I copy those settings? 1. Because the hardware texture access counters provide a cheap way to detect null texture accesses after the fact, which I think their GPU debug tools use. I'm not sure why release builds of the driver do/did that, but whatever. 2. Because I assumed Cupertino knew best and I didn't bother looking too close. We can't use them here (without doing extra memory allocations), since then the GPU will increment access counters. And since our null texture address used to just be a pointer in the command buffer, that mean the GPU will trash whatever memory happened to be 0x400 bytes after the start of the null texture descriptor. The symptom being random faults. This bug was caught when trying to use the zero-page instead, which raised a permission fault when the GPU tried to write counts. Then I remembered the sparse mechanism and had a bit of a eureka moment. Immediately followed by an "oh, f#$&" moment as I realized how many random bugs could potentially be root caused to this. The fix is two-fold: 1. Use normal layout instead. 2. Set the address to the zero-page (which is a fixed VA) and detect null textures by checking the address, instead of the mode. The latter is a good idea anyway, but both parts needs to be done atomically to maintain bisectability. Backport-to: 25.1 Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34703> (cherry picked from commit 3eb75756795ef29fd7a983ebeb0b095358aadc38)
`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.