- Host plane offset queried from the gbm_bo should not be accumulated
across plane transfer loop iterations.
- Host plane stride cannot be calculated from host plane0 stride in a
generic way, as alignment adjustments cannot be subsampled. Instead of
trying of trying to calculate the stride, just query the gbm_bo for
it.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This patch adds the meson build system as alternative to the
autotools build system.
v2: Thanks to Alexandros for his comments that lead to the following changes:
- Fix logic for platforms so that the ones selected by 'auto' don't
fail if the dependencies are missing, but fail when explicitely
requested
- declare project version differently
- set a minimun meson version
- clean up some braces
- reformat some code
- squesh remaining separate patches
v3: require meson 0.46 (Gurchetan)
v4: set minimum gbm version to 18.0.0
v5: - fix gbm version requirement (Gurchetan)
- don't duplicate glx files (Gurchetan)
Fixes: #129
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This change makes a set of changes to increase the range of gbm-based
resources that can be allocated:
- Add VIRGL_BIND_LINEAR to support linear gbm allocations.
- Relax the bind flag argument check if VIRGL_BIND_SHARED or
VIRGL_BIND_LINEAR is set.
- For resources allocated from gbm, only try to create an image if one
of the render target or sampler view bind flags is set.
- Don't try to calculate the internal image format for external images.
This change also fixes a use-after-free that could occur if external
image creation failed.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The value should never haven been part of the shader key.
Fixes#132
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The comment claims that this is wrong and only used for debugging,
so replace the code with a debug message.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
BGRA formats don't support texture storage on GLES, but GLES supports
creating multisample textures only by using glTexStorage*Multisample,
so switch to a swizzled RGB* format.
v2: Simplify handling of whether we should emulate (Gurchetan)
v3: Fix spaces and use VREND_DEBUG (Gurchetan)
Related #126
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Don't use the shader key when forcing it.
Changing a shader key within vrend_create_shader will always force
virglrenderer to recreate the shader the next time it is looked up, so
memory usage will grow and performance will go down.
Also it is actually not needed if with each emitted back color also has a
corresponding front color is emitted. So restrict forcing two-sided coloring
to the cases where a back color is emitted without a front color, and don't
change the shader key.
Fixes#130
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
When doing a blit in blit_int we use the same context that we use for drawing.
Now with qemu or crostini blits may be issued that are not issued by the guest
program so that it expects a GL_FRAMEBUFFER_SRGB state that might actually have
been clobbered.
Keep track of how GL_FRAMEBUFFER_SRGB is set when the framebuffer state is issued,
and restore its value after doing a blit via glBlitFramebuffer.
Thanks to Lepton Wu for tracking this down.
Fixes#126
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
When transferring to/from a planar buffer, multiply by bytes-per-pixel
when computing each plane's stride from stride0. In particular, this
is necessary when transferring to/from biplanar yuv buffers.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With old DRM implementations, drmPrimeHandleToFD always returned a fd
that could be mapped read/write. However, new kernels require the
DRM_RDWR flag to be specified to create read/write mappings.
Try passing the DRM_RDWR flag but fall back to the old way if that
fails.
Signed-off-by: David Stevens <stevensd@chromium.org>
Acked-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The interpolation identifier must come after the precise and invariant
specifier. Also add a newline after these specifiers to make it easier
parsable.
Fixes #128
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Since not all varyings are passed from one shader stage to the next,
the invariant flag must be set based on the SID and not the number of
the IO slot used.
Fixes: 5f28eb8868
shader: fix mismatching shader invariants on GL
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This looks like a typo, we should use view->target instead of
view->texture->target since we are handling the view.
This fixes these 12 tests:
dEQP-EGL.functional.image.create.gles2_cubemap_positive_x_rgb_texture
dEQP-EGL.functional.image.create.gles2_cubemap_positive_y_rgb_texture
dEQP-EGL.functional.image.create.gles2_cubemap_positive_z_rgb_texture
dEQP-EGL.functional.image.create.gles2_cubemap_negative_x_rgb_texture
dEQP-EGL.functional.image.create.gles2_cubemap_negative_y_rgb_texture
dEQP-EGL.functional.image.create.gles2_cubemap_negative_z_rgb_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_positive_x_rgb8_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_positive_y_rgb8_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_positive_z_rgb8_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_negative_x_rgb8_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_negative_y_rgb8_texture
dEQP-EGL.functional.image.render_multiple_contexts.gles2_cubemap_negative_z_rgb8_texture
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Also add ARB_clip_control to the supported extensions.
v2: Correct soname because of abi changes:
- since we now use the visibility('hidden') for internal functions
many functions are no longer exposed with the public interface
- some functions were added to the public interface
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> (v1)
Maybe it's a bug in mesa, maybe I didn't search long enough, but when I
use the source texture directly in the blit then occationally we hit #112,
and no unbinding of the textures from the texture unit or the framebuffers
involved seems to help.
Using a texture view, however, seem to solve the problem.
Fixes#112
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Sometime the shader key "color_is_twosided" is not set, but the vertex
shader only emits a back color and the fragment shader expects a front
color. So if a back color is found set the "twoside" key to force the emission
of the declaration for both, the front and the back color.
Fixes the piglits:
vertex-program-two-side
Fixes#123
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Keep track of the per SID back and front color emission and emit the
counterparts accordingly.
Fixes some of the piglits:
vertex-program-two-side
Related #123
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This should fix the following fuzzer failures.
SCARINESS: 10 (null-deref)
v2: Merge various checks (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
This optimization is for some specific situation, but actually we
do see some android apps create 1x1 windows. So remove this optimization
now.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
"out_supported_structure_mask" is a bitmask representing the structures that
virglrenderer knows how to handle for a given "in_stype_version".
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
For memoryBarrier() which require ARB_shader_image_load_store
extension, we need to add it as required extension, otherwise will get
compile failure for current compute shader version setting.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
On OpenGL with GLSL < 4.30 the invariant input specifiers must match the
invariant output specifiers of the previous stage.
Fixes#75
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
In this case the paramters 'format' is not used in 'vrend_format_can_scanout'
and 'gr' are not used in 'vrend_allocate_using_gbm'.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Gallium sends the shaders in the order FS-[GS]-[TES]-[TCS]-VS. If an old
shader program is still bound when a new shader is send, then it would use the
old bounds shader of the previous stage to evaluate the shader key and code
creation might create an invalid shader. Hence, if the shader to be translated
is not yet bound ignore the previous stage when evaluating the shader key
(Gurchtan)
Fixes#114
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's desirable to query or modify virgl_renderer state for various values.
We've done it for resources (virgl_renderer_get_fd_for_texture /
virgl_renderer_get_fd_for_texture2 / virgl_renderer_resource_get_info) a
few times, but more parameters are often desired.
Let's define a protocol instead. That way, more queries/operations (is "ctx
{num} lost?", "is x host feature supported?") can be formulated.
It's also possible to put the protocol in virgl_hw.h, so in theory
the guest can recieve a response directly from virglrenderer. Any
opinions on this?
v2: virgl_renderer_query --> virgl_renderer_execute
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's good to tell the guest about these formats.
v2: move this check with the rest of the v2 caps
remove host version check bump (@kusma)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Certain 2D allocations will take the GBM path if the option
is set.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
We don't want to open the vgem or pvr drivers.
v2: return fd as-is as well (@davidriley)
v3: order of loops (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
virgl_renderer_transfer_write_iov doesn't work for YUV buffers, since
it's based on glTexSubImage.
We assume the YUV image is not disjoint, since that's currently what
Mesa gbm supports.
For RGBA buffers, this will also eliminate a copy in the cases
where the gbm_bo_map(..) implementation doesn't use a shadow buffer
[i915, mediatek, rockchip].
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
These formats can be allocated by gbm implementations.
v2: fix test (not needed on i965, maybe on softpipe)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's possible to EGL images from any dmabuf. Currently, gbm-based
dma-bufs are supported.
v2: 39 attributes --> 37 attributes (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It is possible to open rendernodes when using EGL_MESA_platform_surfaceless.
v2: fail if user-provided fd fails (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
These extensions allow for multi-plane images and modifiers, and
are more widely supported than EGL_MESA_drm_image or EGL_MESA_image_dma_buf_export.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Just a cleanup -- no functional changes.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
vrend_clear executes the Gallium clear command which is only called
when the whole viewport is cleared. So far mesa was doing excessive checks
on the scissors, thereby updating the scissors to framebuffer size when they
were disabled, and the according state changes were transmitted to the host.
With mesa/2037478 this was optimized away, so that not disabling the scissors
in the clear command manifested itself as a regression in a number of tests.
Keeping track of the scissor state in the hardware and disabling the scissors
before the clear is executes, and re-enabling them according to the last state
fixes this.
Closes#116
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
virglrenderer doesn't know with which parameters the external
image was created, so it doesn't make sense to emulate it.
This fixes Portal, HL2 etc. not going past the loading screen
in Crostini.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
ARM platforms such as Mali might not support Mesa surfaceless platform
so fall back to using a default display.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
ARM GL stacks might not support these extensions, and if buffers
are not being exported since they're being imported from externally
created buffers, then these are not necessary.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
ARM platforms may only advertise GLES 2.0 configurations.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Gurchetan Singh
David Stevens
Gert Wollny
David Stevens
Lepton Wu
Zhenyu Wang
David Riley