We need to pass the family to register parsing functions.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19419>
In turnip we were using this a lot with the dynamic state enum, and
we're running out of space there because we're needing to add more and
more dynamic states that don't correspond to draw states. Make it
64-bit-safe so we don't need to rewrite everything in turnip. In the
case where the thing being operated on is 32-bit the compiler can
usually optimize it away, as can be seen with the release build size
before and after:
before:
text data bss dec hex filename
5404913 293592 22744 5721249 574ca1 /home/cwabbott/build/mesa-release/lib64/libvulkan_freedreno.so
text data bss dec hex filename
13981320 498550 205000 14684870 e012c6 /home/cwabbott/build/mesa-release/lib64/dri/msm_dri.so
after:
text data bss dec hex filename
5404969 293592 22744 5721305 574cd9 /home/cwabbott/build/mesa-release/lib64/libvulkan_freedreno.so
text data bss dec hex filename
13981320 498550 205000 14684870 e012c6 /home/cwabbott/build/mesa-release/lib64/dri/msm_dri.so
In the end the only changes is an additional ~50 bytes of text in
turnip.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
This avoids a dependency on the sample count in the blend state, and
seems to work. Otherwise, we'd need to make blend dynamic if samples is
dynamic and record whether the sample mask was NULL, which is a lot more
complicated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Most of the time we will only be updating either the number of samples
or whether it should be disabled, not both, and we don't need to compare
both. With pipelines we were comparing both, but with dynamic
rasterization samples we want to only update disable when binding the
pipeline and only update samples when calling
vkCmdSetRasterizationSamplesEXT(). Stop optimizing the uncommon case
where both are changed when binding a pipeline, and split it into 2
parts while sharing the common part that records and emits the state
packet.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
From the spec language, it seems like this change wasn't strictly
required and is just an optimization for when minSampleShading would
be small enough to allow one sample per pixel. However
rasterizationSamples will soon possibly be dynamic, and I don't think we
should keep this around.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
This is a little tricky because now we always have to store the
translated logicOp in the pipeline, regardless of whether it's enabled
or not, because the enable/disable may now be dynamic even if the
logicOp is not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Emit GRAS_SU_CNTL, GRAS_CL_CNTL, the polygon mode, and the VRS registers
in one draw state. We're running out of draw states, and this saves a
draw state while preparing us for the rest of the rasterization state to
be dynamic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
At least in the current Vulkan spec there is no validation language
saying that it isn't valid to set this state if stippled lines aren't
supported, so it seems we have to just ignore it. Ignore it if the user
specifies a dynamic line stipple state and don't emit warnings if they
call CmdSetLineStippleEXT because zink will do this.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Vulkan allows the user to set extraneous dynamic state which then gets
ignored if a pipeline with static state is bound. We weren't
implementing this correctly for viewports because we weren't clearing
the dirty bit, but it was happening to work until changes for dynamic
depth negative-one-to-one broke
dEQP-VK.pipeline.*.depth.depth_clip_control.d32_sfloat_less_viewport_before_static.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18912>
Again sharing the same function across all Intel drivers.
There is still two additional DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM
calls, one in intel/dev and other in perf.
The first one can't call intel_gem_get_context_param() because of the
build order of libs and the second one because it sets the size
parameter.
Will revisit those calls in future but this is already an improvement.
v2:
- using intel_gem_get_context_param() for the recently added query for
I915_CONTEXT_PARAM_PROTECTED_CONTENT
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
Again sharing the same function across all Intel drivers.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
Again sharing the same function across all Intel drivers.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
