glXCreatePixmap() may specify a GLX_TEXTURE_FORMAT_RGB_EXT format
for an RGBA resource, causing us to create an RGBX view for an
RGBA resource, a combination vgpu10 does not support.
When this is detected, change the request to create an RGBA view
instead.
Reviewed-by: Brian Paul <brianp@vmware.com>
With this patch, make sure the shader resource view is properly created
before referencing it in the generate mipmap command.
Reviewed-by: Brian Paul <brianp@vmware.com>
If running with a software renderer backend, the timeout may be
insufficient, and we don't want to release busy buffers too early.
In practice, SVGA gpu lockups are extremely rare.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviwed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
dEQP-GLES31.functional.fbo.no_attachments.maximums.{all,height,size,width}
started hitting assertion failures when emitting SURFACE_STATE, after
commit e8fd60e789 where Samuel increased the maximum viewport size to
32768, from 16384.
MaxFramebufferWidth/Height were being set to the maximum viewport size,
but are actually limited by the SURFACE_STATE width/height field range,
which is 16384 on Gen7+ (where ARB_framebuffer_no_attachments is
exposed). So, reduce these to 16384 explicitly.
Fixes assert fails in the above mentioned dEQP tests. (Those tests
still fail, however.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The adjusted polynomial coefficients come from the numerical
minimization of the L2 norm of the relative error. The old
coefficients would give a maximum relative error of about 15000 ULP in
the neighborhood around acos(x) = 0, the new ones give a relative
error bounded by less than 2000 ULP in the same neighborhood.
Fixes four dEQP subtests:
dEQP-GLES31.functional.shaders.builtin_functions.precision.acos.
highp_compute.{scalar,vec2,vec3,vec4}
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will allow us to share the implementation while using different
polynomials for asin() and acos().
Francisco Jerez did this in the SPIR-V front-end; I'm merely porting
his idea to the GLSL world.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
From section 6.2 ("State Tables") of the GL 2.1 specification
(the text also appears in the GL 3.0 and ES 3.1 specifications):
"However, state variables for which IsEnabled is listed as the query
command can also be obtained using GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev."
GL_DEBUG_OUTPUT, GL_DEBUG_OUTPUT_SYNCHRONOUS, and GL_FRAGMENT_SHADER_ATI
were missing from the glGet*() functions. All other IsEnabled() pnames
look to be present, as far as I can tell.
Fixes 8 dEQP-GLES31.functional.debug.state_query subtests:
debug_output[_synchronous]_get{boolean,float,integer,integer64}.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
dEQP-GLES31.functional.debug.state_query.debug_group_stack_depth_*
tries to call glGet on GL_DEBUG_GROUP_STACK_DEPTH right away, before
doing any other debug setup. This should return 1.
However, because ctx->Debug wasn't allocated, we bailed and returned 0.
This patch removes the open-coded locking and switches the two glGet
functions to use _mesa_lock_debug_state(), which takes care of
allocating and initializing that state on the first time. It also
conveniently takes care of unlocking on failure for us, so we don't
need to handle that in every caller.
Fixes dEQP-GLES31.functional.debug.state_query.debug_group_stack_depth_
{getboolean,getfloat,getinteger,getinteger64}.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Support in Mesa main and i965 has just been added.
v2: Include note in 'New Features' of docs/relnotes/11.3.0.html.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Most of the code in anv_meta_blit2d() is borrowed from do_buffer_copy().
Create an image and image view for each rectangle.
Note: For tiled RGB images, ISL will align the image's row_pitch up to
the nearest tile width.
v2 (Jason):
Keep pitch in units of bytes
Make src_format and dst_format variables
s/dest/dst/ in every usage
v3: Fix dst_image width
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Some fields are unnecessary. The variables "pitch" and "bs" are used
for consistency with ISL.
v2: Keep pitch in units of bytes (Jason)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This API is designed to be an abstraction that sits between the VkCmdCopy
commands and the hardware. The idea is that it is simple enough that it
*should* be implementable using the blitter but with enough extra data that
we can implement it with the 3-D pipeline efficiently. One design
objective is to allow the user to supply enough information that we can
handle most blit operations with a single draw call even if they require
copying multiple rectangles.
This is a preparatory commit that will simplify the future usage of
this function.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
If a linear image is requested, the only possible result should be a
linearly-tiled surface.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
If a specific bit is set, the intention to create a surface with a
specific tiling format should be respected.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This pname is tricky. The spec states that an internal format should be
returned, that is compatible with the passed internal format, and has
at least the same precision. There is no clear API to resolve this.
The closest we have (and what other drivers (i.e, NVidia proprietary) do,
is to return the same internal format given as parameter. But we validate
first that the passed internal format is supported by i965.
To check for support, we have the TextureFormatSupported map'. But
this map expects a 'mesa_format', which takes a format+typen. So, we must
first "come up" with a generic type that is suited for this internal format,
then get a mesa_format, and then do the validation.
The cleanest solution here is to add a method that does exactly what
the spec wants: a driver's preferred internal format from a given
internal format. But at this point we lack a clear view of what
defines this preference, and also there seems to be no API for it.
Reviewed-by: Dave Airlie <airlied@redhat.com>
_mesa_format_from_format_and_type() is currently not considering DEPTH and
STENCIL formats, which are not array formats and are not handled anywhere.
This patch adds cases for common combinations of DEPTH/STENCIL format and
types.
Reviewed-by: Dave Airlie <airlied@redhat.com>
We call the driver to provide its preferred type, but also provide a
default implementation that selects a generic type based on the passed
internal format.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is supported since very early version of OpenGL, but we still call the
driver to give it the opportunity to report caveat or no support.
Reviewed-by: Dave Airlie <airlied@redhat.com>
It discards out the targets and internalformats that explicitly
mention (per-spec) that doesn't support filter types other than
NEAREST or NEAREST_MIPMAP_NEAREST. Those are:
* Texture buffers target
* Multisample targets
* Any integer internalformat
For the case of multisample targets, it was used the existing method
_mesa_target_allows_setting_sampler_parameter. This would scalate
better in the future if new targets appear that doesn't allow to
set sampler parameters.
We consider RENDERBUFFER to support LINEAR filters, because although
it doesn't support this filter for sampling, you can set LINEAR
on a blit operation using glBlitFramebuffer.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- FRAMEBUFFER_RENDERABLE: The support for rendering to the resource via
framebuffer attachment is returned in <params>.
- FRAMEBUFFER_RENDERABLE_LAYERED: The support for layered rendering to
the resource via framebuffer attachment is returned in <params>.
- FRAMEBUFFER_BLEND: The support for rendering to the resource
via framebuffer attachment when blending is enabled is returned in
<params>."
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource is unsupported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_SHADOW: The support for using the resource with shadow samplers
is written to <params>.
- TEXTURE_GATHER: The support for using the resource with texture gather
operations is written to <params>.
- TEXTURE_GATHER_SHADOW: The support for using resource with texture gather
operations with shadow samplers is written to <params>."
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_VIEW: The support for using the resource with the TextureView
command is returned in <params>.
Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned.
- VIEW_COMPATIBILITY_CLASS: The compatibility class of the resource when
used as a texture view is returned in <params>. The compatibility
class is one of the values from the /Class/ column of Table 3.X.2. If
the resource has no other formats that are compatible, the resource
does not support views, or if texture views are not supported, NONE is
returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
It will be used by the ARB_internalformat_query2 implementation to
implement the VIEW_COMPATIBILITY_CLASS <pname> query.
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- CLEAR_BUFFER: The support for using the resource with ClearBuffer*Data
commands is returned in <params>.
Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- TEXTURE_COMPRESSED: If <internalformat> is a compressed format
that is supported for this type of resource, TRUE is returned in
<params>. If the internal format is not compressed, or the type of
resource is not supported, FALSE is returned.
- TEXTURE_COMPRESSED_BLOCK_WIDTH: If the resource contains a compressed
format, the width of a compressed block (in bytes) is returned in
<params>. If the internal format is not compressed, or the resource
is not supported, 0 is returned.
- TEXTURE_COMPRESSED_BLOCK_HEIGHT: If the resource contains a compressed
format, the height of a compressed block (in bytes) is returned in
<params>. If the internal format is not compressed, or the resource
is not supported, 0 is returned.
- TEXTURE_COMPRESSED_BLOCK_SIZE: If the resource contains a compressed
format the number of bytes per block is returned in <params>. If the
internal format is not compressed, or the resource is not supported,
0 is returned.
(combined with the above, allows the bitrate to be computed, and may be
useful in conjunction with ARB_compressed_texture_pixel_storage)."
Reviewed-by: Dave Airlie <airlied@redhat.com>
From the ARB_internalformat_query2 specification:
"- SIMULTANEOUS_TEXTURE_AND_DEPTH_TEST: The support for using the resource
both as a source for texture sampling while it is bound as a buffer for
depth test is written to <params>. For example, a depth (or stencil)
texture could be bound simultaneously for texturing while it is bound as
a depth (and/or stencil) buffer without causing a feedback loop, provided
that depth writes are disabled.
- SIMULTANEOUS_TEXTURE_AND_STENCIL_TEST: The support for using the resource
both as a source for texture sampling while it is bound as a buffer for
stencil test is written to <params>. For example, a depth (or stencil)
texture could be bound simultaneously for texturing while it is bound as
a depth (and/or stencil) buffer without causing a feedback loop,
provided that stencil writes are disabled.
- SIMULTANEOUS_TEXTURE_AND_DEPTH_WRITE: The support for using the resource
both as a source for texture sampling while performing depth writes to
the resources is written to <params>. For example, a depth-stencil
texture could be bound simultaneously for stencil texturing while it
is bound as a depth buffer. Feedback loops cannot occur because sampling
a stencil texture only returns the stencil portion, and thus writes to
the depth buffer do not modify the stencil portions.
- SIMULTANEOUS_TEXTURE_AND_STENCIL_WRITE: The support for using the resource
both as a source for texture sampling while performing stencil writes to
the resources is written to <params>. For example, a depth-stencil
texture could be bound simultaneously for depth-texturing while it is
bound as a stencil buffer. Feedback loops cannot occur because sampling
a depth texture only returns the depth portion, and thus writes to
the stencil buffer could not modify the depth portions.
For all of them,
"Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE.
If the resource or operation is not supported, NONE is returned."
Reviewed-by: Dave Airlie <airlied@redhat.com>
