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>
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>
Unlike out_fourcc, where the default value 0 is DRM_FORMAT_INVALID, the
default value 0 for out_modifier is DRM_FORMAT_MOD_LINEAR.
This changes nothing in practice as the only user of
virgl_renderer_execute is crosvm, and crosvm takes the
ENABLE_MINIGBM_ALLOCATION path instead.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Isaac Bosompem <mrisaacb@google.com>
The bo contents may be undefined when only GBM_BO_TRANSFER_WRITE is set
(e.g., with radeonsi). When transferring to a subregion, we need to set
GBM_BO_TRANSFER_READ as well.
gbm_bo_map2 does allow us to map a subregion, but not all
implementations work correctly.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We can now use gbm_bo_map(..) directly to match Mesa.
If minigbm doesn't define the needed use flags, we define it
internally.
This should allow us to build with minigbm allocation enabled and
use the Mesa gbm header.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Minigbm's gbm_bo_map signature has diverged from gbm. Update to
minigbm signature, since virglrenderer now explicitly targets minigbm.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
VIRGL_BIND_SHARED allows external allocators to intercept resource
creation. Reserve the upper byte of bind flags to allow passing
allocator-specific flags, and define a set of such flags for minigbm.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
../src/virgl_gbm.c:186:13: warning: ‘virgl_gbm_transfer_internal’ defined but not used [-Wunused-function]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Like in vrend_renderer_transfer_internal, virgl_gbm_transfer is a
special path that is generally preferred. However, a copy transfer
can be a synchronized transfer. We don't want to use GBM in that
case.
v2: add a comment on glFinish
v3: use GBM only when VIRGL_TEXTURE_NEED_SWIZZLE is set
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
We should honor info->offset and info->layer_stride. This brings
virgl_gbm_transfer closer to
vrend_renderer_transfer_{write,send}_iov.
minigbm has a bug and never sets info->offset. The bug went
unnoticed before virgl_gbm_transfer was added. I suppose fixing
virgl_gbm_transfer now should not suddenly make the bug
user-visible.
v2: With virgl_gbm_transfer, we added planar YUV support that was
not available before. We have to make a special case for YUV to not
regress minigbm.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley <davidriley@chromium.org> (v1)
Tested-by: David Riley <davidriley@chromium.org> (v1)
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
When a stride is given, validate it against the box width, not the
bo width.
This mirrors what check_iov_bounds does.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
We convert GBM_BO_USE_TEXTURING to VIRGL_BIND_SAMPLER_VIEW at
Android side, so just convert VIRGL_BIND_SAMPLER_VIEW back to
GBM_BO_USE_TEXTURING, otherwise the allocation won't go
through gbm.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
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>
We only need a recent version of gbm when enable_gbm_allocation gets
set.
Close#134
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
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>
Gbm-resources can be used for data blobs. These are created with a
height of 1 and the required width, which can easily exceed the maximum
supported texture width.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Mesa emulates planar format sampling with per-plane samplers. With this
change, the guest can pass the plane index when creating a sampler view
from a virgl resource to create a per-plane sampler view. The index can
be passed in place of the texture layer, as that will always be 0 for
planar images.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Fix plane handle deduplication logic so that each handle is only
exported as an fd once.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
- 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 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>
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>
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>
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>
Ryan Neph
Dominik Behr
Chia-I Wu
Gurchetan Singh
Lepton Wu
David Stevens
David Stevens