"constant" is a special keyword in OpenCL C, and we'd like to #define it
suitably in host C23 to facilitate compatiblity between host/device headers.
That means we can't have any identifiers named "global" or "constant".
Fortunately, this is the only 'constant' in any file I'm hitting.
To avoid the clash, don't abbreviate "constant factor", use "constant_factor"
instead. For consistency, "slope factor" then becomes "slope_factor".
The new names are longer but match the Vulkan API exactly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [Intel]
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> [NVK and panvk]
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [V3DV]
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com> [IMG]
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32505>
Tilers need to know, at the very least, which input attachments are
"real" input attachments which map to a color or depth/stencil
attachment in tile memory and which are "fake" input attachments that
should be treated as regular textures. To do this we need to know
VkRenderingInputAttachmentIndexInfoKHR::colorAttachmentCount, which
wasn't provided by the state tracking infrastructure. When the
VkRenderingInputAttachmentIndexInfoKHR isn't provided, we don't know it,
though, so we have to record a special UKNOWN value. In that case, the
driver will know thanks to
VUID-VkGraphicsPipelineCreateInfo-renderPass-09652 that all input
attachments are "real" input attachments that map directly to color
attachments if they have an InputAttachmentIndex.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31261>
For drivers using the new state tracking, __bitset_test_range can be
surprisingly hot because we have a lot of dirty bits and __bitset_test_range has
to handle lots of special cases. __bitset_is_empty does not have to worry about
those special cases so can be much faster.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29008>
I missed a bunch of things like input tracking. Also take the
opportunity to rename things.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: fe19405c46 ("vulkan/runtime: handle new dynamic states for attachment remapping")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27380>
Before this, the render pass code or the driver combined the pipeline
create flags and the implicit flags from the render pass, but the
pipeline create flags will need to be sanitized when they are dynamic
state, so we need to do it in vk_graphics_state where we know that
information.
We also weren't combining pipeline flags correctly when linking, which
on turnip was being hidden by the lack of sanitizing for driver-provided
flags. We can't combine them correctly if they're part of the render
pass state, so they need to be pulled out into the overall pipeline
state.
For drivers using emulated renderpasses or tracking feedback loop
information themselves, this won't make a difference, but we have to
adapt turnip to not pass pipeline flags. This also means that we can
drop all handling of feedback_loop_input_only in turnip and just set it
in the runtime.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25436>
Switch to using VkPipelineCreateFlags2KHR, and use the new common helper
to get the right flags.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25436>
The spec says
A VkRenderPass or VkPipelineLayout object passed as a parameter to
create another object is not further accessed by that object after the
duration of the command it is passed into.
The object could have been destroyed if we get the pointer from a
pipeline library. Since it has no user now, let's remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26000>
Use the hawkmoth c:auto* directives to incorporate vulkan documentation.
Convert @param style parameter descriptions to rst info field lists.
Add static stubs for generated headers. Fix a lot of references, in
particular the symbols are now in the Sphinx C domain, not C++
domain. Tweak syntax here and there.
Based on the earlier work by Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24507>
A future spec clarification will state that pipelines will not have to
fill out the blend attachment count if every blend state is dynamic.
Instead, this comes from the subpass/rendering/inheritance info. To fix
this while still being able to use the same code to emit dynamic and
precompiled state, we have to set the attachment count in the blend
struct at the beginning of the subpass.
This will also help with ESO where it already worked like this.
Closes: #9709
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24957>
Even if this isn't dynamic state per-se because it always comes from the
pipeline, it's useful to be able to track it for the various dynamic
states that it affects, which may be either precompiled or not on
turnip.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
Previously, drivers have either not supported some dynamic state (like
vertex input or sample locations) at all or it's been always dynamic. In
order to be able to set dynamic state sometimes and other times leave it
up to driver-specific state packets, we need a few helpers.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
This is a mirror of vi::bindings_valid, but we can track it and set it
properly even when vertex input state is precompiled, because it is also
needed on turnip for knowing the size of the vertex buffer and vertex
stride state packets even when vertex input state is precompiled.
Previously drivers that could pre-bake vertex input state were expected
to handle this themselves, but this would've been complicated for turnip
because we can handle both pre-baked and dynamic vertex input state. Now
we have the one field which is correctly set in all circumstances and we
never have to setup space for vertex input state in the pipeline.
Reviewed-by: Faith Ekstrand <faith.ekstrand@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
On turnip, there are two cases for feedback loops:
- For feedback loops that involve input attachments, everything works as
normal in GMEM mode but have to do a workaround in sysmem.
- For feedback loops that may involve any texture, GMEM mode is
impossible and we have to disable it.
Currently we track this through a special flag on the pipeline, but this
won't be practical in the future. Add a flag to the common renderpass
state struct to patch this info through when using our own renderpass.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
It only has a subset of the renderpass state, whereas with turnip we
need to use pretty much all of it at one point or another. Just allow
the driver to pass in the entire vk_render_pass_state if it's using its
own renderpass implementation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301>
ANV was the only driver using them and now it's on feedback loop flags.
Other drivers should convert instead of depending on the old version.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22191>
This should make it a lot more clear how depth clip enables work.
Annoyingly, because of the way they originally worked in Vulkan 1.0,
it's dependent on the depth clamp if the state isn't set in the pipeline
and isn't declared dynamic. The enum is explicitly set up so that
drivers don't need to be aware of this change unless they already
implement VK_EXT_extended_dynamic_state3. If depth clamp/clamp are not
dynamic, depth clip will be either TRUE or FALSE which map to 1/0 so the
field can still be treated as a boolean.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18889>
Some of our asserts and other checks depend on the total set of stages,
not just the stages set in the current pCreateInfo. Recording the stage
mask lets us combine them in vk_graphics_pipeline_state_merge().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17696>
Instead of having stencil writes as an out parameter of the optimization
function, we add a new write_enable field for stencil that's equivalent
to the similarly named field for depth. This doesn't mean drivers must
actually support disabling stencil writes independently but the
information may be helpful on some hardware.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17328>
