- 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>
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>
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>
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>
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>
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>
There are many possible testure targets that can be bound as
framebuffer attachment, so it doesn't make sense to check assert
on this here.
Fixes: 4405172812
virgl: implement EXT_multisampled_render_to_texture
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This looks like a copy-paste error. For desktop GL it is
disabled here, so on GLES this should probably be the same.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
A vrend_context structure contains a current vrend_sub_context, which
in turn keeps references on various resources like textures, VBOs,
index buffers, etc. which are used for actual drawing operations.
Certain actions can change the current sub-context in use.
There is a split of what resources are cleaned up directly as part of
a context destruction and which are handled by the sub-context
destruction. VBOs, while referenced by sub-contexts, are cleaned up by
the context. To do that, it uses the at the time of destruction
current sub-context to access these. As a result, only the VBOs in the
active sub-context are cleaned up; every other sub-context referenced
by the context will keep references to the VBOs used.
The responsibility of VBO dereferencing is moved to the destruction of
the sub-context, so all VBOs, not just the one from the current
sub-context, are dereferenced during the destruction of a context.
Closes#198
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Fix
[DEBUG:rutabaga_gfx/src/virgl_renderer.rs:104]
GL_IMPLEMENTATION_COLOR_READ_FORMAT is not expected native format 0x80e1 != imp 0x0
with crosvm introduced by commit d9aad06ba2 (vrend: Create frame
buffer object in do_readpixels). We can do the warning check only after
an fb with read buffer is bound.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
and init flag for preferring discrete GPU. Modify GBM selection to
prefer integrated GPU for display. Report "different GPU" back to
client to enable drawable shadowing. Allocate linear GBM buffers to make
them shareable between different devices.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When virglrenderer creates VIRGL_FORMAT_B8G8R8X8_UNORM texture, it
uses internal format GL_BGRA_EXT.
When Mesa imports dma_buf VIRGL_FORMAT_B8G8R8X8_UNORM/DRM|GBM_FORMAT_XRGB8888
it uses internal format GL_RGB8.
These formats are not copy compatible.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This was regressed by commit 3a2a537c (vrend: hook up per-context
fencing internally), bisected by Gert.
When there is no sync thread, vrend_renderer_check_fences checks fences
on vrend_state.fence_list for signaled ones and call ctx->fence_retire
on them. Because fences belonging to the same context are ordered, as
an optimization, we ideally want to call ctx->fence_retire only on the
last fence of those belonging to the same context. (Note we are close to
that but not quite because we want to avoid complex changes until virgl
starts using per-context fencing, if ever)
The issue is in need_fence_retire_signal_locked. It has this check
if (fence->fences.next == &vrend_state.fence_list)
return true;
which says that, if the fence is the last one in vrend_state.fence_list,
call ctx->fence_retire (because it must be the last fence of some
context). The check is incorrect because not all fences on the list
have signaled when the sync thread is not used. It will fail when there
are also unsignaled fences on the list.
To fix the issue, we contruct a list of signaled fences first before
calling need_fence_retire_signal_locked. We could merge the paths with
and without sync thread further because the non-sync-thread path just
needs this extra step to construct a list of signaled fences. But we
will save that for future and focus on fixing the performance
regression.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Avoids compiling shader variants in the host driver if they will never
be used for rendering.
Wait to register shaders with the host GL driver until after shader
dependencies have been resolved and the selected set of variants is
known to be used for rendering.
The cost of this workaround is taht TGSI to GLSL conversion is still
performed for every variant (observed to happen twice for every
vertex/fragment shader in some cases), but this is expected to be much
cheaper than calling out to the host driver to compile unused variants.
Workaround for #180.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Shader programs are submitted for linking in the host driver twice as
frequently as for native applications due to circular shader
dependencies, immediate TGSI conversion, and explicit shader variant
selection ordering at draw-time.
Circular dependencies are resolved by re-running shader variant
selection twice before emitting calling glUseProgram() in the host.
The cost of this workaround is that GLSL is still emitted to the host
driver for compilation into intermediate/native instructions even for
unused shader variants, but the extraneous linking has been eliminated.
Workaround for #180.
v2: changed shader select order on second pass; only select frag shader
once.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This implements accepting a marker message string from the
guest and passing it to the host implementation.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
On hosts that support the NVX_GPU_MEMORY_INFO extension, we can query
the total GPU memory through GL_GPU_MEMORY_INFO_DEDICATED_VIDMEM_NVX.
Signed-off-by: Rohan Garg <rohan.garg@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Per-context fences signal in creation order only within a context. Two
per-context fences in two contexts might signal in any order.
When a per-context fence is created, a fence cookie can be specified.
The cookie will be passed to write_context_fence callback. This
replaces fence_id that is used in ctx0 fencing.
write_context_fence is called on each fence unless the fence has
VIRGL_RENDERER_FENCE_FLAG_MERGEABLE set. When the bit is set,
write_context_fence might be skipped.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Other than hooking things up, vrend_renderer_check_fences and
vrend_renderer_export_ctx0_fence have some non-trivial changes. This is
because fence->ctx is no longer always vrend_state.ctx0. It can also
point to a user context or be NULL now.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
A fence cookie (void *) is more flexible than a fence id to the users.
When per-context fencing is introduced, its API will use fence cookies.
Conversions between fence ids and fence cookies are some free casts.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Replace the unused ctx_id by a vrend_context pointer. When a
vrend_context is destroyed, remove fences associated with the context to
avoid dangling pointers.
For now, the context is always ctx0 which is never destroyed before the
fences. That will change later when per-context fencing is introduced.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
There are two calls of do_readpixels, and both of them creates a new
frame buffer object and destroys it immediately after that. This change
integrates those operations into do_readpixels.
One thing to note that glReadBuffer(GL_COLOR_ATTACHMENT0) has been
called after binding such a newly created frame buffer object and before
calling do_readpixels in vrend_transfer_send_readpixels. The call is
simply deleted because a new frame buffer object should have
GL_COLOR_ATTACHMENT0 as read buffer.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
vrend resource could cache a frame buffer object to read a texture
back. However, vrend resource is independent of OpenGL context
while a frame buffer object is not because it is a container
object. On QEMU, a frame buffer object is typically cached on each
renderer context while its destruction operation is performed on
"0 context", resulting in destroying another frame buffer object
whose name is identical but is created in "0 context".
This change simply removes the caching mechanism and eliminates the
need of a context switch when destroying a cached frame buffer
object and some handling of cache misses.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Allow for querying of detailed GPU memory information
through the GL_ATI_meminfo and GL_NVX_gpu_memory_info
extensions.
Signed-off-by: Rohan Garg <rohan.garg@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Otherwise the code will simply crash, we should give it a chance to
exit cleanly.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
They were detected with clang-1200.0.32.29.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Gert Wollny
Ryan Neph
Lepton Wu
Akihiko Odaki
Yiwei Zhang
Chia-I Wu
Italo Nicola
chenjiangnan
Robert Wetzel
Dominik Behr
Gurchetan Singh
Rohan Garg