EGL_ANDROID_native_fence_sync only works on gles profiles.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
capset 1 has version 0 and 1, and they are the same. capset 2 has
version 0, 1, and 2, and they are also the same.
Note that Mesa always asks for version 0.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabra.com>
0 is never an invalid capset id.
For an invalid capset id, we have to assume caps points to a buffer of
size 0 (what vrend_renderer_get_cap_set reports). We can't set
caps->max_version.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabra.com>
So that it can be shared by different renderers (there is only vrend
right now).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
vrend_free_fences should free fences on both fence_list and
fence_wait_list. vrend_renderer_fini should call vrend_free_fences.
Since vrend_free_sync_thread is always called before vrend_free_fences,
we can assert(!vrend_state.sync_thread) rather than do the locking.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This extension is needed to get GL 4.4 in the guest when we
run on a GLES host.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
This change is being done in preparation for exporting fences, so the
fences are built on EGL_ANDROID_native_fence_sync instead of on
EGL_KHR_fence_sync.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
In the past, we only transfer texture data in "zero" context, changing
the texture binding was fine. Now the transfer could happen in the rendering
context, so we need to recover the bindings.
This fixes unitTest_WritePixelsNonTexture_Gpu in SkQP.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When running some traces, we see the following on AMD.
file:dmabuf fault:ttm_bo_vm_fault mmap:dma_buf_mmap_internal readpage:0x0
Disable for now.
Reviewed-By: David Riley <davidriley@chromium.org>
When reading back a BGRA surface the client expects the data in BGRA
order, and when we emulate the format by using a swizzled BGRA on GLES
we still have to use the original format information to read back the
data.
However, this results in mesa internally swizzling the RGBA data to BGRA
ordering on the CPU. This performance hit can be avoided for
applications that only blit or render to BGRA surfaces, because here we
can set the bgraswz tweak that does the szizzling on the GPU when
drawing or blitting to a BGRA surface and then we can read the data back
as is.
With that for vtest the bgraswz tweak becomes purley a performance
tweak. Replaying a trace of The Raven Remastered showed a 1% increase
of performance when enabling the bgraswz tweak.
Closes#174
v2: Fix typo (Gurchetan)
v3: fix more typos (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The resource table should not be tied to vrend.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add vrend_renderer_prepare_reset, and move context/resource table
cleanups, to the beginning of the fini/reset functions.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We want a centralized place to initialize different subsystems (vrend,
winsys, resource/context tables). This is the first step.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
I am not sure what the check in vrend_renderer_init was previously for.
This gives it some sense.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It is a wrapper for virgl_egl_get_fourcc_for_texture.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move and rename it to vrend_winsys_has_gl_colorspace.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move winsys-related includes and globals to the new files.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
If host support dual_src_blend extension, it's possible we need
to call glBindFragDataLocationIndexed to set fragment output location.
We can't explicitly set it in GLSL in such cases.
Fixes: b17ba74 ("shader: Add layout qualifier to fragment shader outputs")
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Currently, even the input/output buffers are integer formats, we still
use float type for them. This is actually undefined behavior and MALI
GPU will do type conversion and cause unexpected results. To fix this,
we check the input buffer format for vertex shader and also color buffer
format for fragment shader, if they are integer types, just use integer
types in generated shaders. Since the old way works fine on other GPU,
only enable this fix for ARM MALI for now. The plan is to enable this
for other GPU also with auto detection.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is useful when we need an fd from a virgl_resource.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Capset ids belong to virgl_hw.h. Mesa uses magic numbers right now
and can be fixed with this change.
Capset ids are also leaked in virtio_gpu.h, for use with
virgl_renderer_get_cap_set by qemu. We should replace
virgl_renderer_get_cap_set by something that enumerates all capsets
to stop the leaking, but that is another story.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The intention is to warn the users, not to inconvenience ourselves.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The plan is to remove the patch step and generate the correct glsl
from the beginning. As the first step, just move the patch step to
where we create glsl.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This make sure we have a valid framebuffer in current context.
Some GPU driver like MALI is buggy and will crash on glEndQuery with targets
like GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN if no valid framebuffer in
current context.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
In case GL_ARB_buffer_storage is available, use that.
If not, attempt to allocate a dma-buf and import it into GL.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is to tell virglrenderer that blob resources used with
the 3d driver must be able represented as file descriptors.
This affects the availability of certain features.
Suggested-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
For non-exportable memory, add map/unmap.
For additional validation, query virglrenderer about the preferred
caching type. The response will be returned in to the guest
in virtio_gpu_resp_map_info.
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
A blob resource is a container for:
- VIRGL_RENDERER_BLOB_MEM_GUEST: a guest memory allocation
(referred to as a "guest-only blob resource")
- VIRGL_RENDERER_BLOB_MEM_HOST3D: a host3d memory allocation
(referred to as a "host-only blob resource")
- VIRGL_RENDERER_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation
(referred to as a "default blob resource").
Blob resources can be used to implement new features and fix shortcomings
with the current resource create path. The subsequent patches show how
blob resources may be leveraged to implement GL_ARB_buffer_storage
and GL4.5.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
I don't see the point why we want to use context0 to do transfer.
If we always use original context to do transfer, then we can
avoid sync between contexts for mobile GPU.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
If the next shader stage doesn't declare an input block,
we should not emit an output block in the current stage.
Fix the remaining compilation issue when using the GLES backend.
error: redeclaration of gl_PerVertex must be a subset of the built-in members of gl_PerVertex
Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Lepton Wu
Chia-I Wu
Gert Wollny
David Stevens
Gurchetan Singh
Elie Tournier