Ben Widawsky <b...@bwidawsk.net> writes: > I guess I'd appreciate a comment about how the total_width is > guaranteed to be a multiple of 64, and therefore is a multiple of all > possible H_ALIGNS. This is required to meet the qpitch restraint in > the surface format, "This field must be set to an integer multiple of > the Surface Horizontal Alignment."
My interpretation of that comment is that for 1D surfaces 64 *is* the horizontal alignment so other possible alignments don't matter. I think it's expected that total_width is aligned to the horizontal alignment, and in this case that is enforced in gen9_miptree_layout_1d. I will add a comment to make that clearer. > Note, I don't know anything about compressed textures and what the > block widths can be, but just doing the math, if block size > 16 and > not a multiple of 16, this constraint will not hold. Currently I think all of the block sizes are either 4x4 or 8x4. None of these would make any sense for a 1D texture and wouldn't make the texture any smaller. The bspec explicitly disallows compressed formats for 1D surfaces. If someone were to eventually invent a compressed format with a block height of 1 then I guess the block alignment would be handled in gen9_miptree_layout_1d in the unlikely event that the size isn't a factor of 64. Note that I'm putting off landing this patch and the other qpitch one until someone can review patch 6 in the series because without that patch the qpitch patch seems to cause a GPU hang which makes the kernel panic. Thanks for the review. Regards, - Neil
pgp6HowmsfWV7.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
