The code was using a prim assembler after the tess stage, however
tess prims aren't necessarily the output prim types, so just put
the prim ids into the vertices at tess stage, and skip prim assembly.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This ensures space for the extra outputs is calculated in the
tes vertex outputs.
dEQP-VK.pipeline.misc.primitive_id_from_tess
Fixes: dacf8f5f5c ("draw: hook up final bits of tessellation")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This fixes a possible problem if a non-indexed draw comes in first
in a new batch, then the batch might not emit the index buffer.
I'm unsure if we see this, I just spotted it trying to fix alacritty
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11705>
+ 9.31% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
+ 2.36% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
If the app never uses compute, then the compute bindings bit will always
be dirty causing these two paths never get shortcuts.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11699>
Even with the wrap mode forced to REPEAT, we get undefined results in
CelShading when the Y channel is unwritten since the beginning of the
program.
I dropped the coords==0 case in the process, since that's not possible and
made the 1D case confusing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11457>
This was used in the heuristics for deciding whether to CPU map,
but those have since been deleted, so this is now unused.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
If the caller has asked for a coherent BO with snooping, and the kernel
fails to set it for whatever reason, we were happily returning them a
non-coherent buffer. This isn't what they wanted and could lead to
surprising results.
Better to simply fail the allocation. Probably.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
On integrated GPUs without LLC, we enable snooping when someone requests
coherency for a buffer. (With LLC, it's already coherent.)
For discrete GPUs...if someone requests coherency, we allocate the
buffer in SMEM and resort to WC maps rather than WB maps with CPU
caches enabled. There's no snooping to enable, and calling this ioctl
is nonsensical, and may fail.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
batch tracking has until now been the same as refcounting, but this
is inefficient and incurs additional overhead from constant atomic ops,
so make them separate
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11684>
I think maybe I misunderstood how things worked, or there were issues
generally with resource lifetimes, or whatever, but this isn't needed anymore
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11684>
this is now a screen-based queue which can be triggered to serialize
cache updates, ensuring synchronization
the cache is on the program object, enabling incremental updates as well as
variant loading for an entire pipeline collection at once
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11595>
with tc enabled, we get genuine multidraws with valid drawids, so we can
update this to reflect the new capabilities...which are the same as the old
ones except that potentially some drivers can now do direct multidraws
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11662>
