Now that information about which array-of-arrays elements are accessed
is tracked, use that information to only mark an instance array element
as used-by-stage if, in fact, it is.
Fixes GL45-CTS.program_interface_query.uniform-block-types.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If there's a better way to provide access to ir_array_refcount_entry
private members to the test functions, I am very interested to know
about it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Francisco Jerez <currojerez@riseup.net>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Very soon this visitor will get more complicated. The users of the
existing ir_variable_refcount visitor won't need the coming
functionality, and this use doesn't need much of the functionality of
ir_variable_refcount.
v2: ir_array_refcount_visitor::get_variable_entry cannot return NULL, so
don't check it. Suggested by Timothy.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
One for the array parts and one for the leaf members. This will
simplify later changes.
The indentation is wonkey after this patch. This was done to make it
more obvious that the function is just getting split. The next patch
will fix the indentation.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes 555 dEQP tests (using the nougat-cts-dev branch), Piglit's
arb_program_interface_query/arb_program_interface_query-resource-query,
and GL45-CTS.program_interface_query.separate-programs-{tess-control,
tess-eval,geometry}. Only one dEQP program interface failure remains.
I would have liked to split this up into several distinct changes, but
I wasn't sure how to do that given thet tangled nature of these issues.
So, the issues:
* We need to treat interface blocks declared as an array of instances
as a single block - removing the outer array. The resource list
entry's name should not include the array length. Properties such
as GL_ARRAY_SIZE should refer to the variable inside the block, not
the interface block's array properties.
* We need to do this prefixing even for structure variables.
* We need to do this for built-ins (such as gl_PerVertex.gl_Position).
* After interface array unwrapping, any variable which is an array
should have [0] appended. It doesn't matter if it's a TCS/TES/GS
input or TCS output - that looked like an attempt to unwrap for
per-vertex variables, but that didn't consider per-patch variables,
and as far as I can tell there's nothing to justify this.
Several Mesa developers have suggested that Issue 16 contradicts the
main specification, but I believe that it doesn't - the main spec just
isn't terribly clear. The main ARB_program_interface query spec says:
"* For an active interface block not declared as an array of block
instances, a single entry will be generated, using the block name from
the shader source.
* For an active interface block declared as an array of instances,
separate entries will be generated for each active instance. The name
of the instance is formed by concatenating the block name, the "["
character, an integer identifying the instance number, and the "]"
character."
Issue 16 says that built-ins should be named "gl_PerVertex.gl_Position",
but several people suggested the second bullet above means that it
should be named "gl_PerVertex[array length].gl_Position".
There are two important things to note. Those bullet points say
"an active interface block", while the others say "variable" or "active
shader storage block member". They also don't mention applying the
rules recursively (unlike the other bullets). Both suggest that
these rules apply to blocks themselves, not members of blocks.
In fact, for GL_UNIFORM_BLOCK queries, we do have "block[0]",
"block[1]", ... resource list entries - so those rules are real,
and actually used. So if they don't apply to block members, then how
should members be named? Unfortunately, I don't see any rules outside
of issue 16 - where the rationale is very unclear. I hope to clarify
the spec in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
stage_mask is a bitmask of shader stages, so the proper comparison would
be (1 << MESA_SHADER_VERTEX), not MESA_SHADER_VERTEX itself.
But we only care for structure types, and VS inputs cannot be structs.
So we can just drop this entirely.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
These are listed as Z+ in the GL spec, and often have values of
0xFFFFFFFF. For glGetFloat, we should return 4294967295.0 rather than
-1.0. Similarly, for glGetInteger64v, we should return 0xFFFFFFFF, not
the sign extended 0xFFFFFFFFFFFFFFFF.
Fixes 6 dEQP tests matching the pattern
dEQP-GLES3.functional.state_query.integers.stencil*value*mask*getfloat
when run in a single process (with state reset code happening between
tests, which makes dEQP set the stencil value mask to 0xFFFFFFFF).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The "State Tables" section of the OpenGL specification lists many values
as belonging to Z+ (non-negative integers), not Z (all integers).
For ordinary glGetInteger queries, this doesn't matter. However, when
accessing Z+ values via glGetFloat or glGetInteger64, we need to treat
the source value as an unsigned value. Otherwise, we'll produce a
negative number when bit 31 is set.
This commit merely adds the plumbing. It doesn't convert any values.
v2: Gotta catch 'em all (add missing cases caught by Ilia)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
GetFloat of integer valued things is supposed to perform a simple
int -> float conversion. INT_TO_FLOAT is not that. Instead, it
converts [-2147483648, 2147483647] to a normalized [-1.0, 1.0] float.
This is only used for COMPRESSED_TEXTURE_FORMATS, which nobody in
their right mind would try and access via glGetFloat(), but we may
as well fix it.
Found by inspection.
v2: Gotta catch 'em all (fix another case of this caught by Ilia)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Remove currently bound sampler states from the hash table before pruning
entries from the hash table, so they cannot accidentally be deleted by
the pruning.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Only copy/memset the pointers that actually need to be.
v2:
* Cast info->nr_samplers to int for calculating delta (Nicolai)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If info->nr_samplers > ctx->nr_fragment_samplers_saved, the assignment
would prevent cso_single_sampler_done from unbinding the no longer used
samplers from the driver, which could result in use-after-free. This is
probably unlikely to happen in practice though.
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Some dri drivers will pass multiple bits in buffer_mask parameter
to droid_image_get_buffer(), more than the actual supported buffer
type combination. For such case, will go through all the bits, and
will not return error when unsupported buffer is requested, only
return error when the allocation for supported buffer failed.
v2: coding style and log changes
v3: coding style changes and update patch format
Signed-off-by: Liu Zhiquan <zhiquan.liu@intel.com>
Signed-off-by: Long, Zhifang <zhifang.long@intel.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Not sure where the 16k comes from, but pretty sure 2k is the max.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
These aren't used yet but we will want to use them when we
implement a separate compute queue.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This is required for having a separate compute queue, we
probably can't use this on GFX queue due to DCC.
v2: Set coord_components = 2 for itoi texture fetch. (Bas)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This implements the reverse of the current buffer->image path
and can be used when we need to do image transfer on compute queues
This just adds the code turned off as we don't support separate
computes queues yet, and we don't want to use this path on the GFX
queues for DCC reasons.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Needed when accessing a comrpessed texture as R32G32B32A32 from a shader. This
was not encountered previously, as we used the CB for the reinterpretation, which
does not use this pitch.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
