Remove iov from vrend_renderer_resource_create and make a separate
call to virgl_renderer_resource_attach_iov. In practice, this
changes nothing because iov is always NULL.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move resource lookup up from vrend for
virgl_renderer_resource_get_info, virgl_renderer_get_cursor_data,
and virgl_renderer_get_rect.
These functions are mostly for dumb/scanout resources, and they need
information that virgl_resource does not have. I intentionally pass
pipe_resource down to vrend to emphasize that there is no
virgl_context to dispatch to and those functions can only work with
virgl_resource created from virgl_resource_create_from_pipe.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It detaches the virgl_resource from all contexts and remove the
virgl_resource. That can be done generically.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Pass virgl_resource to virgl_context::{attach,detach}_resource.
This allows us to move virgl_resource_lookup up from vrend to
virglrenderer.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Remove the unused length argument. Remove unused
vrend_object_insert_nofree as well now that context resource
management is not built on top of vrend_object.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Do not abuse context object table to manage context resources. Add
a simpler variant, which replaces the now unused vrend_resource_*,
to manage context resources instead.
This is cleaner and more efficient because we no longer allocate a
vrend_object to manage a vrend_resource.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
In vrend_renderer_resource_create, call
virgl_resource_create_from_pipe instead of vrend_resource_insert to
manage the resource as a global virgl_resource. Convert all other
vrend_resource_* calls to the corresponding virgl_resource_* calls.
This is just the first step. Ultimately, we want vrend_context to
deal with vrend_resource exclusively.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Fix not switching to corresponding context when deleting FBOs.
FBOs are not sharable between contexts.
Signed-off-by: Ka Ho Ng <khng300@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Some applications change glAlphaFunc nearly every frame.
Sam 3 apitrace replay went from ~4 fps to ~19 fps on a chromebook.
Signed-off-by: John Bates <jbates@chromium.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
When destroying any user context, vrend_destroy_context already
calls vrend_renderer_force_ctx_0. The manual switch to context 0 is
unnecessary.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Rename vrend_util.h to virgl_util.h. Add the header guard.
"vrend" is the prefix for the GL renderer code. "virgl" is the
prefix for common code.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
If we can't switch to the original context for the query objects,
don't check it.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
This is currently only used with minigbm, and largely untested
elsewhere. This will also allow us to use flags which are not
available in Mesa GBM.
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Per-plane sampler views don't require texture views, so move where that
check is performed when creating sampler views. Also, it's not
necessarily the case that a planar resource's egl image can be reused
for the first plane's sampler view, so just always create and use a
dedicated per-plane egl image.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
GBM_BO_USE_TEXTURING is available in minigbm's gbm.h but not in
mesa's gbm.h. Texture usage is implied with usage 0 in mesa gbm.
Signed-off-by: Jason Macnak <jmacnak@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Always waits fences to make sure the fence objects will be destroyed.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
glSamplerParameter doesn't support GL_TEXTURE_LOD_BIAS on GLES.
Ignore it on GLES backends.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When there is no feat_dual_src_blend, avoid calling glBindFragDataLocationIndexed.
Otherwise epoxy could crash the whole process when this function is not available.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
One bug was found when running dEQP-GLES3.functional.fragment_out.random.*.
If run them one by one, they pass. If run them all together, some cases fails.
The fix is: when independent_blend_enable changes from true to false, we should call
glColorMask, otherwise color masks for some color buffers could stay in
stale states.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Change to use eglWaitSyncKHR which is a server side fence and it
could be sightly better.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
When switching context, if we want to use shared objects from previous
context, we need to insert glWaitSync to make sure the GL commands
are executed in sequences. This fixes 8 dEQP tests on mali:
dEQP-GLES2.functional.texture.mipmap.2d.generate.a8_fastest
dEQP-GLES2.functional.texture.mipmap.2d.generate.a8_nicest
dEQP-GLES2.functional.texture.mipmap.cube.generate.a8_fastest
dEQP-GLES2.functional.texture.mipmap.cube.generate.a8_nicest
dEQP-GLES2.functional.texture.specification.basic_copyteximage2d.2d_rgb
dEQP-GLES2.functional.texture.specification.basic_copyteximage2d.cube_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgb
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This was hard coded as zero before and can't be changed at runtime.
Change to use the "VREND_DEBUG" environment variable to control this
behavior.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Container objects like framebuffers are not shared between contexts
and we have to delete them in the original context. Otherwise we
could delete wrong objects which is in using by others.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
The structure is allocated outside this function and also deleted there
if texture creation failes or it is asserted that it doesn't fail
for intermediate blitting textures. Therefore, don't free the struct inside
this function when allocation fails.
Closes#154
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
The old code is buggy and set numlayers to 1 for GL_TEXTURE_2D_ARRAY
when creating the view. Just change to use array_size directly.
This fixes such tests in CtsNativeHardwareTestCases:
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#MultipleLayers_ColorTest_MipmapComplete_GL_RGB10_A2
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#MultipleLayers_ColorTest_MipmapComplete_GL_RGB8
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#MultipleLayers_ColorTest_MipmapComplete_GL_RGBA16F
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#MultipleLayers_ColorTest_MipmapComplete_GL_RGBA8
android.hardware.nativehardware.cts.AHardwareBufferNativeTests#MultipleLayers_ColorTest_MipmapComplete_GL_SRGB8_ALPHA8_sRGB
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Lepton Wu <lepton@chromium.org>
Do the same thing we do with regular textures, and swap the R and B
color channels.
TEST=Portal, HL2 have better lighting in Crostini
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
With the prior patch and without this one, I get
../src/.libs/libvrend.a(vrend_renderer.o): In function `vrend_format_can_scanout':
src/vrend_renderer.c:703: undefined reference to `gbm'
src/vrend_renderer.c:703: undefined reference to `gbm
src/vrend_renderer.c:706: undefined reference to `gbm'
../src/.libs/libvrend.a(vrend_renderer.o): In function `vrend_resource_gbm_init':
/virglrenderer/src/vrend_renderer.c:6337: undefined reference to `gbm'
/virglrenderer/src/vrend_renderer.c:6337: undefined reference to `gbm'
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
It's a bit misleading currently. For example, all resources have
guest memory associated with them, and resource can be both a GL
texture and GBM buffer at the same time. Use bits to more accurately
capture this.
No functional change.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
We don't know whether the caller cleans up the error states they are
responsible for, so do this here. This is needed to correctly query
some features, because otherwise checks that rely on correct error
reporting might give the wrong result.
v2: Log stale error codes (Gurchetan)
Closes#148
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
When transfering from host use normal path. On sona performance jumps
from 46 mpixels/s to ~105 mpixels/s.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Fix cases where trying to transfer from host directly after submitting
command buffer (eg when trying to run
dEQP-GLES2.functional.read_pixels.* or crosvm gpu_renderer::simple_clear
tests) would fail non-deterministically due to the mapping occuring
prior to the rendering completing by forcing a fence.
In particular Mali platforms are highly susceptible to synchronization
issues and also require setting the context prior to fencing.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Chia-I Wu
Tomeu Vizoso
Ka Ho Ng
John Bates
Lepton Wu
Gurchetan Singh
Elie Tournier
David Stevens
Jason Macnak
Gert Wollny
Woody Chow
Marc-André Lureau
David Riley