Currently, we always try to create an OpenGL 3.1 context. Some
dEQP tests require an OpenGL 3.2 context (specifically, ones
that use glGetInteger64v). Let's try to create the highest
version context we can, and iterate to lower versions, i.e:
https://developer.android.com/guide/topics/graphics/opengl.html#version-check
The return code for (*create_gl_context) is a little unclear.
This patch assumes NULL is returned on failure. This should work
for GLX and EGL.
GLX:
"On failure glXCreateContextAttribsARB returns NULL and generates
an X error with extended error information"
https://www.khronos.org/registry/OpenGL/extensions/ARB/GLX_ARB_create_context.txt
EGL:
"#define EGL_NO_CONTEXT ((EGLContext)0)"
https://www.khronos.org/registry/EGL/api/1.1/EGL/egl.h
The semantics of rcbs->create_gl_context may be different, though.
Fixes:
dEQP-GLES3.functional.state_query.integers.max_vertex_output_components_getinteger64
dEQP-GLES3.functional.state_query.integers.max_vertex_output_components_getfloat
Signed-off-by: Dave Airlie <airlied@redhat.com>
... previously we were only looking at the last attachment.
Fixes dEQP-GLES3.functional.fragment_out.random.86 and probably others
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These two formats are required by DRI in the guest and as such
Wayland, X11, GBM or any API built on top if DRI. The format
GL_BGRA_EXT is not supported on Desktop OpenGL.
v2: Better documentation.
Signed-off-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Another requirement for GL4.0 is support for ARB_sample_shading.
This enables it and turns on the cap when needed.
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are needed for ARB_draw_indirect and GL4.0
This enables support and turns in the cap when
support is present.
This also enhances the draw packets to cover
future features, it doesn't enable or show these
yet, since other work is required in the shaders.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that we have the proper line width limitations, we can emit the
actual line width. This fixes:
dEQP-GLES2.functional.clipping.line.wide_line* tests.
Reviewed-by: Jakob Bornecrantz <jakob.bornecrantz@collabora.com>
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
This new struct allows us to report:
- accurate max point size and line width
- accurate texel and texture gather offsets
- vertex and geometry shader limits
- one future tessellation limit
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
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>
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>
If the shader failed to be finished, it should be removed from the
hashtable if it was already inserted. Use the goto error path in this
case to handle shader destroy and prevent potential later lookup of
invalid shader from the hashtable.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we have a lot of draws we end up traversing the linked list
looking for the same shader on each draw call even if the
shader is the same one we used the last time.
This removes a chunk of CPU overhead in the draw path.
This seems to do better in xonotic traces, we at least don't
traverse as much of the list to pick up the shaders.
I think we should be using a hash table here really.
Gurchetan Singh
Stéphane Marchesin
Dave Airlie
Jakob Bornecrantz
Elie Tournier
Li Qiang
Marc-André Lureau