We already set up a short-hand accessor for vstate->base, so let's
use that for somewhat cleaner code.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of having the features in separate named bool, convert it
to an array of bools indexed by an enum.
This is a straight mechanical patch, no code flows should change
and it doesn't change any functionality, it just refactors the
code to use the enum list and a bool array.
Future work should be a lot easier on this, so I'd like to
land it first.
v2: use lowercase enum, move debug_cb in as well.
rename tf2, sort list.
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
This way, mesa can know that the TGSI-parser groks the _PRECISE
modifier, and it doesn't need to cull them any more.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenGL ES 3.1 does not have glPrimitiveRestart; only OpenGL 3.1
does. So let's avoid making the renderer thing calling this is OK.
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
This is a bit trickier than the previous one, because we were already
mixing calls to the OpenGL 3.0 version and the GL_NV_conditional_render
version, which indicates that this was previously only safe if *both*
were supported, that is OpenGL 3.0 *with* GL_NV_conditional_render.
Now, this code should match the caps we generate, which shouldn't give
any percieved feature-regressions or gl-versions supported.
v2: do not set have_gl_conditional_render if on GLES 3.0 or above.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Po-Hsien Wang <pwang@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise, it'd be possible to generate evil commands from a rouge
guest-driver that can crash the VM.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This pulls the code out from the gles31 development,
and modifies the caps to support two different limits
(so far I've only found fs/cs vs everyone else limits differ)
v2: fix buffer creation paths, limit maximums, handle indirect
(don't pass -1 into gl funcs when we don't need to).
v3: free ssbo locs
v4: use two caps fields
Co-authors: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh at chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
When the host is gles >= 3.2, gl >= 4.3, or when the extension
GL_(ARB|EXT|OES)_copy_image is available, memcopy like blitting and region
copying can be done for many color format combinations by using
glCopyImageSubData.
This fixes a number of tests from the subset
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_*
v2: - Clean list of canonical formats (Gurchetan Singh)
- Use size of canonical formats to decide whether they can be copied via
gCopyImageSubData
- Also honour the render state when deciding whether glCopyImageSubData
will do, or whether we need to do a blit.
v3: - replace format size check by compatibility check (Gurchetan Singh) but
keep the check seperate because we need to add logic for compressed
texture later
Reviewed-by: Gurchetan Singh <gurchetansingh at chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
I had some missunderstanding about what glEnable(sRGB) did when I added this
warning. As in GLES there is no need to do glEnable(sRGB) at all since it is
implied from the framebuffer.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
The protocol will never send negative numbers, so use uints
to avoid having to compare to 0 and other warnings.
Reviewed-by: Po-Hsien Wang <pwang@chromium.org>
This is required to implement glMinSampleShading().
Sadly, we've been setting has_sample_shading for a while, even
though this is needed. So we need to set a capability so mesa will
know that it's safe to emit this command.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
When we use independent blending, we need to check every rendertarget
indevidually, not just once for all, otherwise we end up using the
wrong blend-mode for some render-targets.
Fixes these test-cases:
dEQP-GLES31.functional.draw_buffers_indexed.random.max_implementation_draw_buffers.0
dEQP-GLES31.functional.draw_buffers_indexed.random.max_implementation_draw_buffers.6
dEQP-GLES31.functional.draw_buffers_indexed.random.max_implementation_draw_buffers.14
[airlied: rebased onto master hopefully correct]
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Otherwise, we'll end up destroying the state when restoring after
clears.
Fixes these test-cases:
dEQP-GLES31.functional.draw_buffers_indexed.random.max_required_draw_buffers.7
dEQP-GLES31.functional.draw_buffers_indexed.random.max_implementation_draw_buffers.13
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
When a texture is bound in its original form then the swizzle states and
the sRGB state were updated and if a texture view of this texture was bound
later it was assumed that the state is already submitted. However, it seems
that a texture view has its own, separate state that must be set separately,
so keep track of it on a per-view basis.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Query the number of supported samples and the sample position and
store these to the caps.v2 structure. We support only up to 16 samples.
This implementation requires a GL host backend.
v2: - glTexImage2Dmultisample is not available on a gles 3.1 host
and trying to call it crashed qemu (Jakob Bornecrantz)
Use glTexStorage2DMultisample instead and delete texture each
round because the texture becomes immutable.
- move call to get sample positions only when caps v2 needs to be
filled.
v3: - rebase against master
- take care of nits (Dave)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
For multisample textures glTexStorage*DMultisample was only used on GLES
and not when the GL host provided it. Texture views need the texture to be
immutable and this is achieved by allocating them using glTexStorage.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This adds the renderer support for exposing texture views.
The change adds support to sampler views and surfaces for the backing
object to be a separately allocated textureview instead of the actual
resource. It also adds support for parsing the updated packet where
we put the sampler view target in the top 8 bits of the format,
which should be safe as up until now it's always 0.
This doesn't do the final enable of the extension, but it will
cause us to use views in a few places we didn't before so could have
some other side effects
v2: check for buffers on surface creation, reword comment
to better explain if statement.
v3: fix logic bug (Gert). This uncovered a wierd corner case, possibly
due to how the state tracker allocates textures, but it tries to create
a surface with more layers than there are, I think it then reallocate
the whole texture object in the guest and it works out in the end,
this adds check to catch this, and to avoid creating a texture view
in that case.
v4: realise the problem with v3 was 3D textures and use
util_max_layer to fix the logic properly.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
OpenGL defaults GL_TEXTURE_MIN_FILTER=GL_NEAREST_MIPMAP_LINEAR and
GL_TEXTURE_MAX_LEVEL=1000, and expects all these mip-map levels to be
defined. With glTexStorage this is set apropriately, but when the mip-map
levels are initialiazed manually, then the GL_TEXTURE_MAX_LEVEL must be set.
Tested-by: Jakob Bornecrantz <jakob@collabora.com>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
This just makes the two functions look a lot more like each other,
since for texture views I have to add some more code to them.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
I want to change the incoming format to use some bits for texture
view support, so this is precursor to avoid causing problems.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When calling glGetnTexImage, glGetnCompressedTexImage, or
glCompressedTexSubImage*D and the data pointer is updated with the
per-slice offset but as bufSize value the full length of the
buffer was given, which can result in a crash of qemu when the buffer
size was not evaluated correctly.
Vor cubemaps instead of passing the size of the whole buffer pass the
size of the slice to make sure that glGetnTexImage doesn't write to
unallocated memory.
v2: Correct handling for 3D textures that are read as one big chunk
vs. cubemaps that are read slice-by-slice (Gurchetan Singh)
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
For rgb8 and rgb16 textures the element size is 3 and 6 respectively,
and the packing must correspond to the component size (1 and 2).
Fixes:
dEQP-GLES3.functional.texture.specification.basic_teximage3d.rgb16i_3d
dEQP-GLES3.functional.texture.specification.basic_teximage3d.rgb16ui_3d
dEQP-GLES3.functional.texture.specification.basic_teximage3d.rgb8i_3d
dEQP-GLES3.functional.texture.specification.basic_teximage3d.rgb8ui_3d
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
In the copy fallback, when a texture can not be rendered, the data that resides
in the backing iovec needs to be used. For the non-zero levels of mip-map textures
the data is located at an offset. This patch adds storing this offset and using it
when data is read from the backing iovec and updating the dst iov. We limit the
mip-map levels for which this is done to 1-17, which is enough to cover
32kx32k textures. The patch also fixes the stride when accessing mip-map levels.
Fixes:
dEQP-GLES3.functional.texture.specification.teximage3d_depth.depth_component24_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component32f_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component24_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component16_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth32f_stencil8_2d_array
dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth24_stencil8_2d_array
v2: * rebase and remove unused variables
* also correct offset when writing to the destination backing iovec
v3: * follow mesa/virgl notation and range for storing the mip-map offsets
Suggested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Since the code path emmiting these warnings is no longer used, remove
them and, because with this removal the ctx parameter is now unused,
remove it as well.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
GLES doesn't have glGetTexImage, so we rely on the assumption that a
resource's backing iovec is always in sync with the texture data if it
isn't renderable.
Fixes on GLES host:
dEQP-GLES3.functional.texture.shadow.*
dEQP-GLES3.functional.texture.wrap.etc2_*.
dEQP-GLES3.functional.texture.units.*
v2: * Special-case VIRGL_FORMAT_Z24X8_UNORM (Gert Wollny)
v3: * Use IOV backing store as data source only on GLES
* Keep backing store only up to date only on GLES
(both Gurchetan Singh)
* copy the backing store data before it is corrected for the Z24X8
format upload
* remove test whether the src surface is renderable, because at this
point it is only relevant whether glGetTexImage is available (i.e.
whether we are on a GLES host)
* Reword commit message
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
Setting the sampler parameter GL_TEXTURE_CUBE_MAP_SEAMLESS in GLES generates a GL_INVALID_ENUM error.
This patch completes the previously committed patch 241b88ac8c.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This refactors out the shader type code into a separate function,
makes it easier to add compute support later.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This pulls the per shader type code out into a separate function.
This is prep work for adding compute shaders.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
[airlied: pushed the get up a bit higher to make it cleaner]
Reviewed-by: Jakob Bornecrantz <jakob@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
v2: With epoxy GL/gl.h is not directly included (Dave Airlie).
Instead move the include of epoxy/gl.h from vrend_renderer.c to
vrend_renderer.h
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Allow resources created externally (eg gbm created buffers as
dma bufs) to be used. As an example, crosvm
(https://chromium.googlesource.com/chromiumos/platform/crosvm/)
will intercept resource creation to use minigbm to allocate
buffers that its compositor is able to properly handle since it
only supports compositing with buffers allocated via minigbm.
This patch allows direct rendering to those buffers without
requiring an extra copy.
v2: Handle missing extension better.
v3: Update commit message with more details on usage.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Erik Faye-Lund
Tomeu Vizoso
Dave Airlie
Gert Wollny
Jakob Bornecrantz
Elie Tournier
Ramin Azarmehr
David Riley