Dead since the call to _mesa_generate_parameters_list_for_uniforms
was removed in commit 12751ef2. So this was why all of that code that
was supposed to fix up the value of a uniform bool to wasn't happening.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The next patches are going to combine some of the mapi subdirectories'
Makefiles into a single Makefile, giving better build parallelism.
lib_LTLIBRARIES will be set to something like
lib_LTLIBRARIES = shared-glapi/libglapi.la es2api/libGLESv2.la
and the current code in install-lib-links.mk simply prepends .libs/ and
replaces the .la in order to create the filenames that it needs to ln/cp
into the LIBDIR. This doesn't work when the .la file is actually in a
subdirectory.
This patch fixes this and puts .libs/ in the right place.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
The SWIZZLE_1 of the winsys destination was dereffing off the end of the
array, which surprisingly often worked out (since nobody reads the
rendered value anyway, so whatever junk was referenced in the QIR didn't
matter), but shader dumping would sometimes segfault.
We weren't accounting for the level 0 offset in the texture setup (so it
only worked if it happened to be a single-level texture), and doing so
required that we get the level 0 offset page aligned so that the offset
bits don't get interpreted as the texture format and such.
I had the right viewports in vc4_emit.c, but grabbed the wrong values in
the uniform setup, so primitives would claim to be in the wrong parts of
the screen. (The vc4_emit.c state looks like it just decides how big the
clipping guardband is).
This gets fbo-viewport closer to working (which still has the problem that
the HW is always guard-band clipping), and fixes inverted FBO rendering in
general.
If ->sys is non-null, we might decide that it's where the data is
stored.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: <mesa-stable@lists.freedesktop.org>
The function should return GLboolean, not GLenum.
If we detect invalid compressed pixel storage parameters, we should
return GL_TRUE, not GL_FALSE so that the function is no-op'd.
An update to the piglit s3tc-errors test will check this.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Replace the gl_texture_image parameter with mesa_format since we only
used the image's format.
Add some comments.
Reviewed-by: Matt Turner <mattst88@gmail.com>
For gen6 we will use the ALL_SLICES_AT_EACH_LOD miptree layout for
separate stencil/hiz. This is needed because gen6 hiz and separate
stencil only support a single miplevel. When accessing the other LODs,
we will program a tile aligned offset for the bo.
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
"The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed."
We still allocate storage for the other stencil mip-levels within a
single texture, but each mip-level will use non-mip-array spacing.
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
"[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered."
We allocate storage for the other hiz mip-levels within a single
texture, but each mip-level will use non-mip-array spacing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Since gen6 separate stencil & hiz only supports LOD0, we need to
program an offset to the LOD when emitting the separate stencil/hiz.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Gen6 doesn't support multiple miplevels for hiz and stencil.
Therefore, we must point to the LOD directly during rendering.
But, we also have removed the tile offsets from normal depth surfaces,
so we need to align each LOD to a tile boundary for hiz and stencil.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Previously array_layout ALL_SLICES_AT_EACH_LOD was only used for array
spacing lod0 on gen7+ and therefore was only used with a single mip
level.
gen6 separate stencil & hiz only support LOD0, so we need to allocate
the miptree similar to gen7+ array spacing lod0, except we also need
space for multiple mip levels. (Since OpenGL stencil and depth support
multiple LODs.)
The miptree is allocated with tightly packed array slice spacing, but
we still also pack the miplevels into the region similar to a normal
multi mip level packing.
A 2D Array texture with 2 slices and multiple LODs would look somewhat
like this:
+----------+
| |
| |
+----------+
| |
| |
+----------+
+---+ +-+
| | +-+
+---+ +-+
| | :
+---+
v3:
* Use new array_layout enum
* ASCII art!
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
gen6 does not support multiple miplevels with separate
stencil/hiz. Therefore we need to layout its miptree with no mipmap
spacing between the slices of each miplevel.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
We will want to setup gen6 separate stencil and hiz miptrees in a
layout that is similar to array_spacing_lod0. This is needed because
gen6 hiz and stencil only support a single mip-level.
In both use cases (gen7+ LOD0 spacing & gen6 separate stencil/hiz),
the array slices will be packed at each LOD without reserving extra
space for LODs within each array slice.
So, we generalize the name of this field and add comments to indicate
the old and new uses.
Motivation for the gen6 change comes from the PRM:
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
"The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed."
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
"[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered."
v2:
* Rename array_spacing_lod0 to non_mip_arrays
v3:
* Instead, replace array_spacing_lod0 with array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
(bf25ee2 for gen6)
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
We also must disable brw_workaround_depthstencil_alignment for
gen >= 6. Now the hardware will handle alignment when rendering
to additional slices/LODs.
v3:
* Set depth_mt bo RELOC offset to 0, as was done in bf25ee2
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56127
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
