Create the mt for the drawable bo directly and call our new
intel_miptree_create_for_bo() helper instead.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This factors out the work of setting up a miptree as the backing for a
texture image into a new helper.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This lowers sampling from YUV textures to 1) one or more texture
instructions to sample each plane and 2) color space conversion to RGB.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will be used to select the plane to sample from for planar
textures.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Otherwise, if the call executes normally we'll hit an assertion later
in the VBO code when we draw something. Note that these cases were
already handled correctly for the glIsEnabled() function (and the API
checks were copied from there).
Tested with new piglit gl-3.1-enable-vertex-array test.
v2: fix compat/es mix-up, per Ilia.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
We added support for Android build using autotools (configure),
update the documentation to reflect that.
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
For double-precision vertex inputs we need to measure them in dvec4
terms, and for single-precision vertex inputs we need to measure them in
vec4 terms.
For the later case, we use type_size_vec4() function. For the former
case, we had a wrong implementation based on type_size_vec4().
This commit introduces a proper type_size_dvec4() function, that we use
to measure vertex inputs.
Measuring double-precision vertex inputs as dvec4 is required because
ARB_vertex_attrib_64bit states that these uses the same number of
locations than the single-precision version. That is, two consecutives
dvec4 would be located in location "x" and location "x+1", not "x+2".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Images aren't supported on maxwell, but neither is tessellation. Don't
overly confuse matters by trying to expose those subtleties in the
GL3.txt file/relnotes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Dave Airlie <airlied@redhat.com>
This extension appears to be a strict subset of the ARB version. Also
remove it from GL3.txt since it doesn't seem relevant.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
V2: fix error checking for arrays and components. V1 was
only taking into account all the array elements and all the
components of one of the varyings during the comparision
and treating the other as a single slot/component.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
We apparently pass all the relevant CTS tests. There are probably some
shortcomings, but they can be addressed down the line.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This is just a copy-and-paste from brw_surface_formats.c. For the
supports_vertex_fetch function, we do a bit more work so that it properly
handles Bay Trail.
This prevents array overflow when the block is actually an array of UBOs or
SSBOs. On some hardware such as i965, such overflows can cause GPU hangs.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were using the size of the whole BO which may be
substantially larger than the actual index buffer size.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were using the size of the BO which may be substantially
larger than the actual vertex buffer size.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For a long time, several of the 3-channel vertex formats didn't exist so we
faked them with 4-channel versions. Starting with Sandy Bridge, we can use
R16G16B16_FLOAT and 8 and 16-bit integer formats become available on
Haswell and Bay Trail.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bay Trail and Haswell added a bunch of new vertex formats. There was also
the addition of 64-bit passthrough formats for BDW+.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The old code always divided rounded down and then subtracted 1. What we
wanted was to divide rounded up and then subtract 1 which is equivalent to
subtracting 1 and then dividing rounded down.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we only handled the "I don't know what's going on" case for
things with InstanceDivisor == 0. However, in the DrawIndirect case we can
get num_instances == 0 and we don't know what's going on with the instanced
ones either. This commit makes the worst-case bound the default and then
conservatively tightens the bound.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous code got the BO the first time we encountered it. However,
this can potentially lead to problems if the BO is used for multiple arrays
with the same buffer object because the range we declare as busy may not be
quite right. By delaying the call to intel_bufferobj_buffer, we can ensure
that we have the full range for the given buffer.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The vbo layer passes an index_bounds_valid flag that we should be using
instead. This also fixes a bug when min_index == -1 and basevertex != 0
where we were actually comparing min_index + basevertex == -1 which was
false and we were getting the wrong buffer-sizing path.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Right now, we're setting the range to [0, 0] which is obviously bogus.
Instead, we should set it to be invalid like we do for DrawIndirect.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Right now, we're just setting the range to [0, MAX_UINT32] which, while
correct isn't helpful. With DrawIndirect, you can't really know what the
actual range is so we may as well flag it as being an invalid range. This
is what we do for draws with index buffer which is similar (the indices
aren't statically known) if a bit simpler.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we would fail to find a match for the second half of a
dvec4 as 'i' would get incremented to 1 before we added the var to
the array at component 0.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The last version of this broke clipping, and I had to spend
sometime getting this working properly.
I had to introduce a third pass to count the clip/cull totals,
all due to one messy corner case. We have a piglit test
tes-input-gl_ClipDistance.shader_test
that doesn't actually output the clip distances, it just passes
them like a varying from TCS->TES, the older lowering pass worked
but to lower clip/cull we need to know the total number of clip+culls
used to defined the new variable correctly, and to offset culls
properly.
This adds an extra pass that works out the sizes for clip/cull,
then lowers gl_ClipDistance then gl_CullDistance into the new
gl_ClipDistanceMESA.
The pass checks using the fixed array sizes code if they array
has been referenced, or is actually never used, and ignores
it in the latter case.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes a bug that breaks cull distances. The problem
is the max array accessors can't tell the difference between
an never accessed unsized array and an accessed at location 0
unsized array. This leads to converting an undeclared unused
gl_ClipDistance inside or outside gl_PerVertex to a size 1
array. However we need to the number of active clip distances
to work out the starting point for the cull distances, and
this offset by one when it's not being used isn't possible
to distinguish from the case were only the first element is
accessed. I tried to use ->used for this, but that doesn't
work when gl_ClipDistance is part of an interface block.
So this changes things so that max_array_access is an int
and initialised to -1. This also allows unsized arrays to
proceed further than that could before, but we really shouldn't
mind as they will get eliminated if nothing uses them later.
For initialised uniforms we no longer change their array
size at runtime, if these are unused they will get eliminated
eventually.
v2: use ralloc_array (Ilia)
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In agreement with the SNB PRM, alpha blending is a property that render
targets may or may not support.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This format does not support alpha blending, according to the SNB PRM.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When we have the geometry extensions, enable querying of the new param.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
