mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-10 23:20:14 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
90a7573a65
On 32 bits, virtual memory is sometimes too short for apps. Textures can hold virtual memory 3 ways: 1) MANAGED textures have a RAM copy of any texture 2) SYSTEMMEM is used to have RAM copy of DEFAULT textures (to upload them for example) 3) Textures being mapped. Nine cannot do much for 3). It's up to driver to really unmap textures when possible on 32 bits to reduce virtual memory usage. It's not clear whether on Windows anything special is done for 1) and 2). However there is clear indication some efforts have been done on 3) to really unmap when it makes sense. My understanding is that other implementations reduce the usage of 1) by deleting the RAM copy once the texture is uploaded (Dxvk's behaviour is controlled by evictManagedOnUnlock). The obvious issue with that approach is whether the texture is read by the application after some time. In that case, we have to recreate the RAM backing from the GPU buffer. And apps DO that. Indeed I found that for example Mass Effect 2 with High Texture mods (one of the crash case fixed by this patch serie), When the character gets close to an object, a high res texture and replaces the low res one. The high res one simply has more levels, and the game seems to optimize reading the high res texture by retrieving the small-resolution levels from the original low res texture. In other words during gameplay, the game will randomly read MANAGED textures. This is expected to be fast as the data is supposed to be in RAM... Instead of taking that RAM copy eviction approach, this patchset proposes a different approach: storing in memfd and release the virtual memory until needed. Basically instead of using malloc(), we create a memfd file and map it. When the data doesn't seem to be accessed anymore, we can unmap the memfd file. If the data is needed, the memfd file is mapped again. This trick enables to allocate more than 4GB on 32 bits apps. The advantage of this approach over the RAM eviction one, is that the load is much faster and doesn't block the GPU. Of course we have problems if there's not enough memory to map the memfd file. But the problem is the same for the RAM eviction approach. Naturally on 64 bits, we do not use memfd. Signed-off-by: Axel Davy <davyaxel0@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9377> |
||
|---|---|---|
| .appveyor | ||
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| bin | ||
| build-support | ||
| docs | ||
| doxygen | ||
| include | ||
| scons | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| Android.common.mk | ||
| Android.mk | ||
| appveyor.yml | ||
| CleanSpec.mk | ||
| common.py | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| REVIEWERS | ||
| SConstruct | ||
| 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://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `Freenode's #dri-devel <irc://chat.freenode.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://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.