apps/games using separate shader objects end up passing the separable
shaders to the link_shader hook individually, which is still not ideal for
zink's usage since the more optimal path is to have all the shaders and create
a RAST+FS GPL stage that can run all the inter-stage io handlers
it IS technically possible to handle this for simple VS+FS pipelines using
GPL, however, but it's kinda gross. such shaders now use descriptor buffer
to create their own pipelines/layouts/descriptors async, and then a "separable"
variant of the gfx program can be created by fast-linking these together
the "separable" gfx program can't handle shader variants, but it can do basic
pipeline caching for PSO state changes, which makes it flexible enough to sorta
kinda maybe handle the most basic cases of separate shader objects
descriptor buffer is used because having to create and manage a separate architecture
for sets/pools/templates is too nightmarish even for me
this is, at best, a partial solution, but it's the best the vulkan api can
currently do
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21197>
Only libraries and optimized (LTO) pipelines are still unsupported,
but there is no reason to skip the cache for monolithic pipelines.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21198>
Some dynamic states require to compile PS epilogs on-demand. In this
case, MRT compaction should be disabled because we don't know the CB
state when compiling the fragment shader.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21140>
I found this useful in lining up some perfetto traces between zink+anv and
iris, and understanding what was going on in them. Also it's a demo of
being able to insert annotations for work in the command stream, which I
suspect we'll want more of.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20657>
For zink, we want to know if we should pass command stream markers down to
the underlying driver, but we don't have our own trace context we're
recording trace events with. We definitely want those markers if the
underlying driver is going to be doing perfetto tracing, or is requesting
marker tracing. So, create an interface for querying those flags before
they get copied down to an actual u_trace_context.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20657>
Functions that are in hot paths will have a different treatment to
support i915 and Xe KMD.
Each KMD will have an anv_kmd_backend that will have the hot path
functions set, this way we can avoid branch prediction misses.
Other functions will gradually be moved to anv_kmd_backend.
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/20948>
As we continue to refactor the code base to support Xe KMD here I'm
dropping anv_gem_create() and unifying all graphics memory allocation
calls to anv_gem_create_regions().
anv_gem_create_regions() will call DRM_IOCTL_I915_GEM_CREATE_EXT
for integrated platforms too only leaving DRM_IOCTL_I915_GEM_CREATE
calls to kernel versions that do not support
DRM_IOCTL_I915_GEM_CREATE_EXT.
This can be detected by devinfo->mem.use_class_instance as
DRM_I915_QUERY_MEMORY_REGIONS uAPI landed in the same kernel version
as DRM_IOCTL_I915_GEM_CREATE_EXT.
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/20948>
Also using pointers to intel_device_info struct instead of replicate
the same information.
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/20948>
This is a KMD independent struct to hold memory class and instance
values.
drm_i915_gem_memory_class_instance usage will be gradually replaced.
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/20948>
Small depth/stencil textures were using linear tiling, but depth/stencil
attachments cannot use linear tiling for sysmem rendering.
Fixes:
KHR-GL45.geometry_shader.layered_framebuffer.stencil_support
KHR-GL45.geometry_shader.layered_framebuffer.depth_support
Signed-off-by: Amber Amber <amber@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21046>
non-strictLine Vulkan drivers use either parallelogram or bresenham
rasterization for default line modes.
This method of rasterisation produces close enough results that it
in practice is GL/GLES spec compliant (at least cts wise).
Don't emit a feature missing warning for this case.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20985>
