Consider this series of events:
glColorMask(GL_FALSE, GL_TRUE, GL_TRUE, GL_TRUE);
glClearColor(0.125f, 0.25f, 0.5f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glClearColor(0.1f, 0.1f, 0.1f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
With virgl, this may render an incorrect result. This is because
there our two paths for clears in Gallium -- one for full clears
(st->pipe->clear) and another for color-masked/scissored clears
(clear_with_quad). We only encode the color mask in the
virgl_encode_blend_state in the clear_with_quad case.
We should set the colormask the case of full clears as well, since
we need to update the GL state on the host driver.
With this patch, the number of dEQP GLES2 failures on Virgl with a
nvidia host driver goes from 260 to 136 with no regressions.
Some representative test cases are:
dEQP-GLES2.functional.color_clear.masked_scissored_rgb
dEQP-GLES2.functional.color_clear.masked_scissored_rgba
dEQP-GLES2.functional.depth_stencil_clear.depth_stencil_scissored
dEQP-GLES2.functional.fragment_ops.random.0
dEQP-GLES2.functional.fragment_ops.interaction.basic_shader.0
v2: Revise comments, fix curly braces (Elie)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not supported at all in GLES, 1x1 texture rectangles can be emulated by
GL_TEXTURE_2D, which was the only usage I have come accross in my limited
testing.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not supported in GLES, this silences lots of errors.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is not supported in GLES, only warn any setting other then the default.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The size of 1.0 is supported since it is the default, while the
size of 0.0f is invalid so we don't have to warn about it.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenGL ES glDepthRange clamps the values, warn if the range is out of bounds.
We can't do much more then then this, during normal guest side Desktop OpenGL
operation this does not seem to happen.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
GLES is missing various bits that is also missing in core profile. The there is
warnings for those so copy those warnings and make them GLES specific.
Current batch is:
* GLES only supports GL_FILL polygon mode.
* GLES does not support line stipple.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
GL_KHR_robustness exposes some of the GL_ARB_robustness functions, use those
functions if available. Where possible we want to use safe variants.
v2: Fix detection logic in if case
v3: Use GL_KHR_robustness instead of GL version
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Detect OpenGL ES context being given to us. This is just the detection code,
it does not do any other fallback or work around. This is required for the
rest of the OpenGL ES code that follows. It is assumed that virgl will not
decide to use OpenGL ES and that is the hardware platform that forces this.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make sure we add debug printing to the sub-context
and disable printing when getting the format list.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The glGetQueryObjectuiv is available both in GLES and in Desktop OpenGL.
While glGetQueryObjectiv is not available in GLES.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Currently only prints errors, not enabled by default.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
OpenGL ES does not have glDrawBuffer, but it does have glDrawBuffers. It has
been available in Desktop OpenGL since 2.0 and was exposed in OpenGL ES 3.0.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Reported-by: Li Qiang
Free the vertex array in error path.
This was introduced by this commit:
renderer: fix heap overflow in vertex elements state create.
I rewrote the code to not require the allocation in the first
place if we have an error, seems nicer.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Free vertex element in error path.
This was introduced by this commit:
vrend: add sanity check for vertext buffer index.
Reported-by: Matthias Gerstner <mgerstner@suse.de>
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There will be a crash if the guest destroy context 0. As the context 0 is
allocate in renderer init, not destroy in vrend_renderer_context_destroy.
The context will be freed in renderer fini by calling vrend_decode_reset.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In vrend clear dispatch function, the 'buffers' is read from
guest. A malicious guest can specify a bad 'buffers' to make
a the function call util_format_is_pure_uint() even the
'ctx->sub->surf[i]' is NULL. This can cause a NULL pointer deref.
Make a sanity check to avoid this.
[airlied: use a define]
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As the 'pkt_length' and 'offlen' can be malicious from guest,
the vrend_create_shader function has an integer overflow, this
will make the next 'memcpy' oob access. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 'num_elements' can be controlled by the guest but the
'vrend_vertex_element_array' has a fixed 'elements' field.
This can cause a heap overflow. Add sanity check of 'num_elements'.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When parsing texture instruction, it doesn't stop if the
'cur' is ',', the loop variable 'i' will also be increased
and be used to index the 'inst.TexOffsets' array. This can lead
an oob access issue. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In parse_identifier, it doesn't stop copying '*pcur'
untill encounter the NULL. As the 'ret' has a
fixed-size buffer, if the '*pcur' has a long string,
there will be a buffer overflow. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vertext_buffer_index is read from guest and then used
to index the 'vbo' array in struct 'vrend_sub_context'.
Add sanity check for this to avoid oob issue.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 'blit_ctx->initialised' is not setted to true.
Every time init blit context, it will create a new
'blit_ctx->gl_context' thus causing a memory leak.
This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the sanity check of the 'nr_cbufs' to avoid stack
overflow.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Create a context more than once causes memory leak issue.
Juest return if the context exists.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just return if the resource has been attached a iov
to avoid memory leak.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The benchmark fails to start, the translation of gl_Identity is incorrect,
UMAD TEMP[0], SV[0].xxxx, TEMP[0].xxxx, TEMP[1]
is translated to:
temp0[0] = vec4(uintBitsToFloat((gl_InstanceID * floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
Which results in the following error:
shader failed to compile
0:23(34): error: could not implicitly convert operands to arithmetic operator
0:23(34): error: operands to arithmetic operators must be numeric
0:23(17): error: no matching function for call to `uintBitsToFloat(error)'; candidates are:
It seems we can use the same workaround as gl_VertexID, I didn't
observe any regression running various gl_InstanceId tests from
piglit:
temp0[0] = vec4(uintBitsToFloat((floatBitsToUint(vec4(intBitsToFloat(gl_InstanceID))) * floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
apitrace & epoxy with EGL don't work nicely together, using glx works
around this issue for now (disabled by default).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They should mostly be fine, as long the shader compiles. The reported
error should be enough to diagnose something going wrong in case of
failure.
This should help avoiding temporary regressions when new properties are
introduced in mesa.git before they are either handled or filtered out by
virgl, as was the case with commit fbe6e92899.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Gurchetan Singh
Jakob Bornecrantz
Dave Airlie
Ondřej Súkup
Li Qiang
Marc-André Lureau