This is needed to reduce the size occupied by these fields.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Seperate more elements into the shader stages that they are used in
and evaluate them only for the stage they are relevant for.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
There is no reason why this value should be obtained using a return
parameter. Also fix the version to return zero when the version string
doesn't follow the standard.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Mesa clamps the number of cbufs to eight, so we can use uint8_t bitmask for
cbufs states. Be save for the future by only reporting support for
at most eight cbufs.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Compress the structure so that it fits into a 64 bit value.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
In addition combine values into a bitfield so that the compiler can use a
64 bit move instead of individual moves.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Keeping all the information in one place might come in handy when we
want to further refactor this. On the way also compress the structure.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
The info should not be overwritten by other outputs.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Use a bitfield to declare vrend_interp_info and make it a fixed size array.
One one hand this avoids all the hassles with allocating and freeing memory,
and it will make it possible to shrink the size of the data that is passed
from the sinfo to the shader key.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
- don't write zeros, the memory is initialized to zero anyway
- reorder evaluation to check whether it is a FS only once.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
The property doesn't change. so it doesn't make sense to set it in the
shader key.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Caught by fuzzer. surf[0]->texture cannot be assumed to be a valid
pointer.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
For texture arrays, the layer is stored at blit.{src,dst}.box.z.
In those cases, we need to go through the same path as we already do for
GL_TEXTURE_CUBE_MAP.
Fixes piglit's spec@ext_texture_array@copyteximage {1d_array,2d_array}.
Tested on both GLES and GL backends.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
On GLES it is not supported, and on GL it seems to be irrelevant,
because the guest already handles this.
Update the test expectation accordingly.
Fixes#201
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Italo Nicola <italonicola@collabora.com>
With -Dvenus-validation=true, vkr will enable the validation layer by
setting
ctx->validate_level = VKR_CONTEXT_VALIDATE_ON;
ctx->validate_fatal = false;
We would like to set ctx->validate_fatal to true, but even vulkaninfo
has validation errors. We should create a list of VUIDs that are
considered non-fatal before we can set ctx->validate_fatal to true.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
VKR_CONTEXT_VALIDATE_FULL enables all meaningful validations while
VKR_CONTEXT_VALIDATE_ON enables only API_PARAMETERS.
We would like VKR_CONTEXT_VALIDATE_ON to cover more validations, but we
also need to balance for compatibility (most apps have sporadic
validation errors) and performance. That will be an ongoing work.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
We use GL_RGBA internal format for RGBX texture while an imported RGBX
texture uses GL_RGB8 as internal format since
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5034
On GLES host, glBlitFramebuffer doesn't work in such case because the
internal format doesn't match. Fall back to GL to fix it.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Lepton Wu <lepton@chromium.org>
These warnings were detected with clang version 12.0.0.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
On GLES hosts, BGR* resources are manually swizzled to RGB* internal
format on creation and swizzled back to BGR* format on readback.
For small transfers, iovec data is directly passed to the host driver
without staging in a temp buffer first. When swizzling for BGR*
resources, this modifies the persistend iovec buffer when it should
remain in the user-provided format. So we force temp buffers for all
iovec transfers on BGR* resources on GLES hosts to fix this.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
It tests nothing on release builds because virgl_renderer_context_create
is not called and virgl_renderer_submit_cmd fails immediately.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-By: David Riley <davidriley@chromium.org>
This fixes the regression introduced with commit
45eb512a43e257427617699e3849ca93434c1717c and
62cc6ed6e5.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
vrend_renderer_pipe_resource_set_type() called for
VIRGL_RESOURCE_FD_DMABUF resources fail during virgl to GBM format
conversion due to an uninitialized variable.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRX resources backed by EGL images are given GL_RGB8 internal format
on creation outside of virglrenderer, so we must accomodate when
creating a texture view.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Since externally-stored BGRA resource buffers must remain with
BGRA byte ordering, there are several special cases in the custom
blitter that need to be handled, based on the source and destination
resource formats, as well as the views requested on each by the caller.
This change gives the caller more control over the swizzling operation
to perform during the shader-based blit, so the caller can reconcile the
special cases more concisely.
Fixes#225
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRA resources that use external storage (EGL image, GBM)
must keep the data store in the BGRA byte-order, while
producing the correct results when used within the host's
GL or GLES API. To maintain compatability of BGRA resources
with features such as gamma correction, texture views, and
multisampled rendering, virglrenderer swizzles BGRA texture
data to RGBA and passes GL_RGBA to the host API, then swizzles
the RGBA data back to BGRA on readout.
With external storage, virglrenderer no longer has complete
control over buffer accesses, with the possibility that buffers
will be written to and read out by other processes, such as the
display compositor. Under these circumstances, we need to emulate
the external buffer format when using it with the host rendering
API such that data is accessed from the backing buffer as RGBA
and written back as BGRA.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Some virgl_formats rely on the same GL internal format. In such cases,
texture views during blits are unnecessary.
Also, avoid generating a GL texture handle unless a view is created.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When performing blits, a texture view is not necessary if the
base format and view format of either the source or dest
resource are equal. with this change, unnecessary views will
be avoided on the source and destination resources.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Once we know the GL shader-based blitter is needed, there's no need
test remaining conditions.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Removing tweaks could cause wire format inconsistencies between host
and guest. Instead, just mark these two tweaks as non-functional in
log output and ignore their values.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRA emulation was added to address rendering artifacts when GL guest
apps are run on a GLES host with virglrenderer's use_gles == true.
Due to tenuous compatibility of EXT_texture_format_BGRA8888 with
gamma correction (sRGB formats/views) and multisampled rendering on
GLES hosts, it is best to represent BGR* resourcs with RGB* internal
format and add necessary byte re-ordering on to/from transfers instead.
Note, however, that removing the existing BGR* emulation will cause
problems for externally stored resources such as EGL images, and GBM
allocated buffers, which may actually be stored with BGR* byte-order.
This is addressed in the commits immediately following this one.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
For GL hosts CopyImageSubData and TextureView are not defined
when ASTC textures are involved, and the copy fallback currently
doesn't handle these formats correctly. Since Gallium can handles
ASTC texures transparetly in the guest, host support is not really
required to be able to use it.
Fixes all tests out of
dEQP-GLES32.functional.copy_image*astc*
that were failing on the llvmpipe GL host before
Related #224
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
It is always false because venus requires per-context fencing. However,
when it is true (in a private branch), it means
virgl_renderer_create_fence
virgl_renderer_poll
virgl_renderer_export_fence
(but not virgl_renderer_get_poll_fd)
works with venus.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
This is desirable when we have a per-context version of
virgl_renderer_export_fence.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Some game engines rely on the real hardware info to adjust default
graphics quality and other attributes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Some game engines rely on the real hardware info to adjust default
graphics quality and other attributes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Gert Wollny
Ryan Neph
Italo Nicola
Chia-I Wu
Lepton Wu
Akihiko Odaki
Yiwei Zhang