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.
We are seeing shaders with 0 and 2 inputs, but no 1, so we need
to handle gaps properly.
This fixes some regressions in drawpixels after some mesa changes
on the guest.
It's unfortunate, but the i965 driver deliberately crash on such simple test
case. Fortunately, it seems fairly straightforward to avoid it in virgl.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
If the current context is one of the subcontext to be destroyed,
vrend_destroy_sub_context() will fail after the last context is
destroyed.
Found thanks to amaerican fuzzy lop.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Some american fuzzy lop tests managed to replace resources, however the
old values got leaked (I am not sure if this should be allowed)
In all cases, introduce a destroy callback to the hashtable, used when a
value is removed, replaced or the table is cleared. This simplifies a
bit resource management and help avoid potential errors by using simply
refcounts.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Resources are reference-counted, if another object holds a reference to
a resource, it should not free it. Change the resource hashtable destroy
callback to unref.
Currently, this doesn't happen, since the resource hashtable is kept
until the renderer is reset. However, in the next commit, the destroy
callback will be used if a resource is replaced in the hashtable, and we
want to keep the original resource. Furthermore, even if replace
shouldn't happen, it avoids confusion and future errors if use only
reference-counting mechanism.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Jakob Bornecrantz
Dave Airlie
Li Qiang
Marc-André Lureau