Just need to ensure there are 16 bytes of unused space at the end of the last row, where the other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But the last row it can run off the end of the runway without the extra bytes. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Bug 1647946 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Just need to ensure there are 16 bytes of unused space at the end of the last row, where the other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But the last row it can run off the end of the runway without the extra bytes. Doing it via alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row... SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Just need to ensure there are 16 bytes of unused space at the end of the last row. The other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But on the last row, it can run off the end without the extra bytes of padding for it to read. Doing it via stride alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Just need to ensure there are 16 bytes of unused space at the end of the last row. The other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But on the last row, it can run off the end without the extra bytes of padding for it to read. Doing it via stride alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row, though it could still work. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Just need to ensure there are 16 bytes of unused space at the end of the last row. The other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But on the last row, it can run off the end without the extra bytes of padding for it to read. The masked reads themselves are potentially unaligned, so even if the stride of the row was somehow aligned to SIMD width, it would still run off the end if the draw started on, say, the last pixel of that row, it may still read 3 pixels past it off the end. In any case, doing it via stride alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row, though it could still work. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Just need to ensure there are 16 bytes of unused space at the end of the last row. The other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But on the last row, it can run off the end without the extra bytes of padding for it to read. The masked reads themselves are potentially unaligned, so even if the stride of the row was somehow aligned to SIMD width, if the draw started on, say, the last pixel of that row, it may still read 3 pixels past it off the end. In any case, doing it via stride alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row, though it could still work. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.
Just need to ensure there are 16 bytes of unused space at the end of the last row. The other rows don't matter at all, since an overread of an intermediate row will just read some junk data from the next row, which is okay. But on the last row, it can run off the end without the extra bytes of padding for it to read. The masked reads themselves are potentially unaligned, so even if the stride of the row was somehow aligned to SIMD width, if the draw started on, say, the last pixel of that row, it will still read 3 pixels past it off the end (up to 4 pixels packed into one read). In any case, doing it via stride alignment would be pretty wasteful since it would put 16 bytes of unused space at the end of every row, though it could still work. SWGL internally just inflates every texture allocation size by 16 bytes to handle this.