iris/program: Don't try to push ubo ranges for compute
We only can push constants for compute shaders from one range.
Gallium glsl-to-nir (src/mesa/state_tracker/st_glsl_to_nir.cpp) lowers
all uniform accesses to a ubo.
Unfortunately we also load the subgroup-id as a uniform in the
compiler. Since we use the 1 push range for this subgroup-id, we then
lose the ability to actually push the ubo with all the normal user
uniform values.
In other words, there is lots of room for performance improvement, but
at least retrieving the uniforms as pull-constants is functional for
now.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
This can happen when faking Z32_S8X24 and setting StencilSampling = true
I guess we'll just turn it into S8_UINT...
Fixes KHR-GL45.texture_swizzle.functional
We were accidentally using the ISL_FORMAT_R32_FLOAT_X8X24_TYPELESS
format, which is NOT what we use. We just store R32_FLOAT depth.
fixes Piglit's texwrap GL_ARB_depth_buffer_float
iris: don't mark contains_draw = false when chaining batches
chaining to a new batch reuses create_batch(), but we don't need to do
the work of pinning BOs we inherit from a previous batch...when that is
actually part of the same execbuf invocation.
instead, just flag it when setting primary_batch_size = 0, in
iris_batch_reset
this is more obviously correct. I think the two end up being the same
in practice, since this is in the alloc_from_cache case, and presumably
bo from the bucket has bo->size == bucket->size, and bo_size also is
bucket->size...
still. better to do the obvious thing.
brw_bufmgr already does it this way.
otherwise, get results may check q->map->snapshots_landed...before our
commands to initialize it to false have actually executed...so it'd get
some random garbage from the BO...