Avoid using a sparse and relatively large array for HALIGN encoding.
Additionally, this provides validation of the input alignment values.
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
We're going to start asserting for valid halign/valign values during
surface state emission. Pre-SKL, isl_surf_get_uncompressed_surf creates
uncompressed surfaces with invalid halign/valign values - 1x1. Fix this
by replacing the call to isl_surf_get_image_surf with isl_surf_init,
passing in the uncompressed format up-front.
As we're no longer using isl_surf_get_image_surf, we also need to get
the x and y offset of the image ourselves. Instead of getting a
sample-based offset, then converting to elements later on, we use
isl_surf_get_image_offset_B_tile_el to get the offset in elements
up-front.
With the above two changes, the generic code after the else-block is no
longer needed for the single-layer-view code path. We move it and
specialize it to the if-block (which is executed SKL+ and handles
multi-layer views).
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
Stencil on Gfx7 has a vertical alignment element of 8, but the largest
its surface state can express is 4. Apply the Gfx6 solution of changing
the alignment in blorp_surf_retile_w_to_y.
Cc: mesa-stable
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
On XeHP, NPOT and POT formatted surfaces will use different image
alignment units when emitting surface states. When BLORP fakes an RGB
image as RED, update the image alignment to prevent assert failures when
emitting surface states.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
Try to avoid having to update isl_gfx6_filter_tiling when new tilings
are added for new platforms. Note that the allow-list uses
ISL_TILING_ANY_Y_MASK and thus assumes that no new Y-tilings will be
added in the future.
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
In order to size Tile64 surfaces correctly, make sure that the total
physical extent is arrayed. The code should handle 3D surfaces as well,
but is untested for now.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
Implement the new XeHP alignment rules for surface layout.
RENDER_SURFACE_STATE objects still need updating, but that's left for a
separate commit.
Rework:
* Nanley: Include Sagar's VALIGN fix for D16_UNORM.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
XeHP defines new tiling formats, Tile4 and Tile64. They are needed in
order to support depth/stencil surfaces and multisampling. Create new
ISL enums and define some initial tiling information in order to enable
them later on.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
They are not used yet but the layout of Yf and Ys tiles are dependent on
these parameters. While we're here, better document the function.
Rework:
* Nanley: Update crocus.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12132>
currently keys for shaders are always the same size, but this will change
in the future, at which point the keysize becomes relevant
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12547>
We do not want to set an interpolation method for vertex shader inputs.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12513>
If the z components here contain negative values, we'll end up with the
wrong maximum value.
This updated equation is taken from the D3D11 functional spec (section
15.10 Depth Bias), which is a bit more clear than the OpenGL spec.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12443>
The formula for calculating these two values seems to depend on
tess_use_shared, ie. a6xx_gen3 and a6xx_gen4 match. The existing
calculation matches a6xx_gen1 and a6xx_gen2.
The new formula is based on traces varying # of output (from VS)
varyings from (1..31)*vec4 and vertices from (1..31) and coming up
with something that matches the blob. Once hs_input_size*4 divided
by tcs_vertices_out goes above 64, this deviates a bit from the
blob, but AFAICT it is safe to pick a larger values.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12497>
