v3: (Lionel)
- Handle VkPipelineRenderingCreateInfoKHR not being present
- Rename dynamic_pass and set it for regular render passes too
v4: C99 is good (Lionel)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13980>
There's two of them because they can be created from three points in the
code that provide different details and this is the least ugly way I
could think of for now.
v2: Avoid allocations (Lionel)
v3: Move definition closer to its usage (Lionel)
v4: (Lionel)
- Simplify anv_dynamic_pass_init_full
- Zero out pass/subpass to avoid stall pointers
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13980>
This was made way more complicated than it needs to be for a Midgard-only pass.
The only caller doesn't care about the class, only if it's native or not.
Simplify it appropriately.
It really isn't that hard.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14724>
These "quirks" are common for Midgard, yet are only consumed by
pan_lower_framebuffer -- a Midgard-only pass. So the quirks should be removed
and inlined into their users. Thid removes MIDGARD_QUIRKS altogether.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14724>
When multiple variables are packed into the same location, we need
to re-construct variables that read/write the same components of that
register so that the DXIL signature is correct. We could try to
merge these variables, but getting the types right sounds harder than
just preserving the multiple individual variables.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
GLSL puts a bunch of tessellation info in the eval shaders, because
passthrough control shaders can exist. D3D12 puts it in the control
(hull) shader instead. So, when specializing, copy info from domain
to hull. For initial compiles (no domain shader), just make something
up.
D3D12 also requires the domain and hull shaders to have identical
patch constant signatures. Use the existing infrastructure and extend
it to also propagate patch constants. Notably, patch constant locations
are outside of the 64-bit range value so they require a separate pass
to avoid shifts larger than 64.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
This is required to be able to use the necessary number of varyings,
otherwise we hit asserts because mesa/st starts assigning varyings
locations above 64 due to the +9 reserving these texcoords.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
In order to get the semantics right, we need to know how many of the clip/
cull fields are designated for which purpose. In the case of a shader that
can receive these fields as both input and output, the shader_info property
is reserved to store the output info. We could add a dedicated input field
to shader_info, but since it'd probably only be useful for us, just send
it through a side channel during shader linking.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Docs say that its presence in signatures as a "shadow" element (meaning it's not
accessed via load/store, but with a dedicated opcode) is legacy. It seems it
wasn't carried forward when HS/DS were added in D3D11.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
In HS, store_per_vertex_output maps to storeOutput in DXIL. The data
that isn't per-vertex is patch constants.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
DXIL validation will complain if the tess factor signature entries have the
wrong number of components for the shader's domain. Make sure that both
hull and domain shaders have the right number, and drop loads and stores
from the removed components.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
This way, patch varyings come before the patch sysvals (tess levels).
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Also add tess factors to the list of sysvals that can cause vars to be sorted last.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
- Skip patch variables, those go into a separate patch constant signature
- Use nir_is_arrayed_io and only strip one level of array when it's true
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Note that this requires the shader info "tess" data to be correct.
For GLSL tess control shaders, only the output primitive count is
automatically available. The rest will need to be either guessed
or filled in from a matching tess eval (domain) shader. This is handled
by the d3d12 driver in a later patch.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Once we start writing multiple functions, we can't keep calling all
of them "main"
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
The instruction and block lists are moved into a new "function definition"
struct, and the DXIL module tracks one at a time for adding instructions
into. The NIR side still only emits the main function here though.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
The resource declarations are module-wide, but the resource handles
are function-local. A future change will add multi-function support,
but requires these handles to be potentially emitted multiple times.
The alloca used for scratch is also function-local.
This is the same pattern that the DXBC to DXIL converter uses.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14399>
Iván Briano
Jason Ekstrand
Alyssa Rosenzweig
Jesse Natalie