Alyssa Rosenzweig
6b22a02f90
Implement buffer textures in full generality. There are a few issues here: * OpenGL requires buffer textures support a minimum size of 65536 elements, however 1D textures in AGX are (at most) 8192 elements. * OpenGL 4.0 (and OpenGL ES) require buffer textures to support the "RGB32" texture formats. These are 3 packed channels of 32-bits each. In general, non-power-of-two texel sizes are problematic. AGX does not support any such formats and we rely on the GL frontend to lower to a padded format (RGBX) if necessary. Such a lowering cannot work for buffer textures, however, so we need to find a way to implement RGB32 buffer textures. We solve these issues in the follow way: * Use 2D texture descriptors for buffer textures, with a large fixed power-of-two size along one axis. Then large texel indices may be accessed at a small vec2 texel coordinate, and since the fixed dimension is a power-of-two, that vector may be recovered by simply shifting and masking. This effectively avoids size restriction. We do need to clamp texel indices to the buffer size to avoid faulting on OOB reads, since we may read past the end of the buffer (if the app binds a non-page-aligned offset into the buffer). * Use a general purpose memory load for RGB32 buffer textures. Lower the texture load instruction to a memory load from the buffer and some address arithmetic. There's no format conversion needed for RGB32, other than maybe filling in a format-appropriate alpha, so this is straightforward. Again, we need to clamp the texel index for robustness with OOB reads. Each of these solutions brings its own problem. * Using 2D textures instead of 1D requires physically rounding up the buffer size when packing the descriptor, so we can no longer implement textureSize() by reading off the texture descriptor like normal. * We don't know at compile-time whether a given texture load will read from an RGB32 buffer texture or not, so we need to emit code for both. In Vulkan, we can't key the shader to this property, either, since it's descriptor set state and not pipeline state. And each of these problems in turn brings its own solution: * The texture descriptor is linear, so the "compression buffer address" field is ignored by the hardware. We stash the real buffer size there so that textureSize becomes a load from the texture descriptor like usual, without requiring a sideband (which would complicate bindless textures). * If we determine a texture descriptor contains RGB32 data, then it will never be interpreted by the hardware and hence does not need to be a valid texture descriptor. So, we extend the hardware's format enum to contain a software-defined RGB32 format enum. Then, when lowering texture buffer loads, we either read it as a typed RGB32 memory load or as a texture load depending on the value of the format field in the texture descriptor. All of this is accomplished with a big NIR pass generating a pile of strange looking code. But it should be good enough in practice for this silly feature. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21672>
`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 `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://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.