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>
The software may implement third party technologies (e.g. third party libraries) that are not licensed to you by AMD and for which you may need to obtain licenses from other parties. Unless explicitly stated otherwise, these third party technologies are not licensed hereunder. Such third party technologies include, but are not limited, to H.264, MPEG-2, MPEG-4, AVC, and VC-1. For MPEG-2 Intermediate Products: ANY USE OF THIS PRODUCT IN ANY MANNER OTHER THAN PERSONAL USE THAT COMPLIES WITH THE MPEG-2 STANDARD IS EXPRESSLY PROHIBITED WITHOUT A LICENSE UNDER APPLICABLE PATENTS IN THE MPEG-2 PATENT PORTFOLIO, WHICH LICENSES IS AVAILABLE FROM MPEG LA, LLC, 6312 S. Fiddlers Green Circle, Suite 400E, Greenwood Village, Colorado 80111 U.S.A. WARRANTY DISCLAIMER: THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. AMD DISCLAIMS ALL WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, THAT THE SOFTWARE WILL RUN UNINTERRUPTED OR ERROR-FREE OR WARRANTIES ARISING FROM CUSTOM OF TRADE OR COURSE OF USAGE. THE ENTIRE RISK ASSOCIATED WITH THE USE OF THE SOFTWARE IS ASSUMED BY YOU. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to You. LIMITATION OF LIABILITY AND INDEMNIFICATION: AMD AND ITS LICENSORS WILL NOT, UNDER ANY CIRCUMSTANCES BE LIABLE FOR ANY PUNITIVE, DIRECT, INCIDENTAL, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING FROM USE OF THE SOFTWARE OR THIS AGREEMENT EVEN IF AMD AND ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event shall AMD's total liability to You for all damages, losses, and causes of action (whether in contract, tort (including negligence) or otherwise) exceed the amount of $100 USD. You agree to defend, indemnify and hold harmless AMD and its licensors, and any of their directors, officers, employees, affiliates or agents from and against any and all loss, damage, liability and other expenses (including reasonable attorneys' fees), resulting from Your use of the Software or violation of the terms and conditions of this Agreement. U.S. GOVERNMENT RESTRICTED RIGHTS: The Software is provided with "RESTRICTED RIGHTS." Use, duplication, or disclosure by the Government is subject to the restrictions as set forth in FAR 52.227-14 and DFAR252.227-7013, et seq., or its successor. Use of the Software by the Government constitutes acknowledgement of AMD's proprietary rights in them. EXPORT RESTRICTIONS: The Software may be subject to export restrictions as stated in the Software License Agreement.