Realistically, this has nothing to do with gfxstream
per se. It's just one of the options discussed on
on how to do fence passing, which gfxstream may or
not leverage.
Rename the option for clarity.
BUG=328083772
TEST=CI
Change-Id: I1292f329a1935ca512ec22b0993958bbb06180e4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6012806
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Fix build with the updated dev_container to enable upgrading to Rust
1.81.
BUG=b:365852007
Change-Id: Iea1d88084101c075c043665ad153d5f63cc090b9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6013345
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
It's a marginally better API for the WaitContext.
BUG=b:378101009
TEST=gfxstream end2end tests
Change-Id: Ideaa89710568af25096409767213cbf721c9210d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/6003726
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change is sufficient to compile Kumquat in more
cross-platform way. The basic idea was to:
- Replace AsFd with AsBorrowedDescriptor
- Create a Pipe abstraction
- All other changes sort of follow from that
This allows us to delete the "sys" directory from
cross-domain, for example.
BUG=356504311
TEST=GfxstreamEndToEndTests pass
Change-Id: I8944bb63c17803b1f6648133a6763af3c5a17a22
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5980832
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
... so that restore() reads from the beginning of the buffer written
by snapshot().
Bug: b/369615058
Test: GfxstreamEnd2EndTests
Change-Id: I766b70737d392cafecb87f2e35b4519acd88eae8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5989430
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
... to not break virgl backend.
Follow up to https://crrev.com/c/5907645
Bug: b/369615058
Test: presubmit
Change-Id: I202c7bacb9df2c3c51247df46ca709c5d4b2b9d8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5960109
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We can delete some open-coding and use more standard
Rust functions.
Create an OwnedDescriptor, since the underlying type
is either OwnedFd or OwnedHandle.
This essentially meant:
find ./ -type f -exec sed -i -e 's/SafeDescriptor/OwnedDescriptor/g' {} \;
Fuchsia also works with OwnedFd, but with a
compat layer known as fdio. Currently, there is
no consensus whether the standard library should be
fdio-first or zx_handle_t first.
BUG=356504311
TEST=compile
Change-Id: I52c8bc1470ad6f0f4565083600c39b422e4ff1ea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5941157
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Nixpkgs devs report a regression with crrev.com/c/5747102
"A Tube is always a SOCK_SEQPACKET socket on Linux,
so this changed the base channel socket from SOCK_STREAM
to SOCK_SEQPACKET, which is not correct for a Wayland
socket. This caused connections to the Wayland socket
to fail with EPROTOTYPE."
BUG=372776092
TEST=run a cross-domain vhost-user gpu device
Change-Id: Id7389fb0a2722be4ac97a4a5a4b8140395191c7d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5924626
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This is an abstraction over eventfd, essentially.
BUG=356504311
TEST=GfxstreamEnd2EndTests
Change-Id: I137491b8ef2c24e72baec77ad1e00129bf82b43e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5893905
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This commit introduces new `cfg` checks for conditional compilation of
the unstable `virgl_renderer` and `gfxstream` features in the
`rutabaga_gfx` crate.
Change-Id: I3d12d6b7dfcb92a9ce188b88acdfdb3a384d8816
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5836694
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Modify Transfer3D::new_2d to accept an offset argument, ensuring
it is correctly initialized.
This change ensures the offset is no longer ignored during 2D
transfers to the host, hence it addresses potential issues
that could arise with data transfer alignment.
Change-Id: I83a7436e825e1fa6e44fb46d921dd84a799baa93
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/5785895
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
(cherry picked from commit a3ec3b77dbcfa44defd91775c6ecfc5af605d42c)
Reason for cherry-pick: CL was initially merged to `chromeos` branch by
mistake; never made it to `main` branch.
BUG=None
Test=builds
Change-Id: Ic7f720e59c6f43b3477e891f6da91acc23cde0fb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5838083
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The Tesla V-100 driver seems to enter a power management
mode and stops being available to the Vulkan loader if
more than a certain number of VK instances are created in
the same process.
Workaround this by having a singleton gralloc per-process.
BUG=b:354706346
TEST=GfxstreamEnd2EndTests --gtest_filter="*MultiThreadedVkMapMemory*"
Change-Id: I95480064d18b9443c32d934d66556afbe77418ad
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5766173
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Clients may want to connect to a particular instance of
kumquat, in the case of multi-threaded tests that launch
multiple kumquats. Add the proper API for it.
BUG=b:354706346
TEST=end2end tests
Change-Id: I8ed21f5d1f4cdb719ba69e60c2241848ef35ee0f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747430
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In the case a parent process exists, kumquat needs to
communicate that it's ready to receive connections to
that parent process.
BUG=b:354706346
TEST=end2end tests
Change-Id: I6edaa5a7aec256af0a65646dc7f373144b1b7f1b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747109
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
The client needs to wait for these commands to be
processed before proceeding.
BUG=b:354706346
TEST=gfxstream end2end test
Change-Id: I771270851ff0a4c1fb9c5a0051f09c0311d66c2b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747105
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Kumquat needs to check for additional messages from other
connections rather than waiting on one connection forever.
BUG=b:354706346
TEST=gfxstream end2end test
Change-Id: I2bd69091991255eec11b2cc37ab16115a00f8e12
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747104
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This reduces the amount of OS-specific code in the
cross-domain subdir.
BUG=b:354706346
TEST=it would just work (TM)
Change-Id: Id317577e19fbbda06ed61b192e73456b13c66e95
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747102
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This is mostly to use SockType::SeqPacket in nix,
since std::os::unix::net for some reason does not
support SeqPacket yet.
As predicted in crrev.com/c/5645904, not using
SeqPacket does lead to test failures for
multi-threaded tests, so we actually need it for
kumquat.
Note RutabagaStream takes it's naming inspiration from
gfxstream, not UnixStream.
Also, since RutabagaStream is more cross-platform friendly
now, remove the "ipc" feature. It's now always compiled.
BUG=b:354706346
TEST=tfw-pkg/bin/testfw_app --gfx egl --gl_api=gles \
-w 1280 -h 720 -t gl_driver2_off
Change-Id: I0aebbe4239ba78c70f9049ff8b3fcd0e5fc27d28
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5747101
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
It matches the C API now.
BUG=b:354706346
TEST=GfxstreamEnd2EndGlTest.AhbExternalOesTextureBlitProgramBinary
Change-Id: I10102ae1934dc8b41f8bc55cb11a8889b4657ec7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5730017
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Soong doesn't define CARGO_PKG_DESCRIPTION in it's
Rust rules. Use default value to make Clap happy.
BUG=b:354706346
TEST=compile in AOSP
Change-Id: I658b0b0d03f2ce19b2dab9aa4f06cf8b236469f9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5730015
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Following observed:
thread '<unnamed>' panicked at library/core/src/panicking.rs:156:5:
unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`
stack backtrace:
20: 0x7fbc13444397 - rutabaga_ffi::rutabaga_submit_command::{{closure}}::h396fa3925e07701c
21: 0x7fbc1342af28 - core::ops::function::FnOnce::call_once::h83bf6f55aff2e840
22: 0x7fbc13423a36 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h988a1c0089589129
23: 0x7fbc134292a8 - std::panicking::try::do_call::h83aa5cffd0c7a46a
24: 0x7fbc13444eeb - __rust_try
25: 0x7fbc13428c13 - std::panicking::try::hc36d232483e714b8
26: 0x7fbc13427c7d - std::panic::catch_unwind::h2433ece368f25877
27: 0x7fbc134442f0 - rutabaga_submit_command
Reason, according to the docs:
"data must be non-null and aligned even for
zero-length slices."
Add check to prevent hitting this case.
BUG=none
TEST=compile
Change-Id: Ic0d36055a13cd1cc9c65e7e12c0aef7aa95a58ce
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5718431
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
wayland_service cannot startup without this fix because crosvm
incorrectly only reports the last supported channel
(CROSS_DOMAIN_CHANNEL_TYPE_CAMERA = 0x4) instead of all
(CROSS_DOMAIN_CHANNEL_TYPE_WAYLAND | CROSS_DOMAIN_CHANNEL_TYPE_CAMERA =
0x6).
BUG=b:322173539
TEST=ARCVM reports caps.supported_channels = 0x6 instead of 0x4
Change-Id: I84928176beecc051d407017d204fbe0936e1dc26
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5717781
Commit-Queue: Ryan Neph <ryanneph@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Ryan Neph <ryanneph@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
- this ensures descriptor is closed after sendmsg(..)
- also nuke CmdWithFile(T, Vec<u8>, File), not used
BUG=b:300140266
TEST=run glxgears without running of fds
Change-Id: I9ed63411044b4267d5041f31e17c63c649fb7b81
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5709565
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
- dma-buf mmap does not work on Tesla V-100
- system blob does not work on Tesla V-100
- opaque fd mmap does not work on Tesla V-100
- Opaque fd + VK map does work on Tesla V-100
Since we need to make sure the Nvidia ICD is used
when calling VK map + unmap, we save and restore
VK_ICD_FILENAMES when loading gralloc.
This is not super-robust, but the perhaps the best
can that can be done on Nvidia.
BUG=b:300140266
TEST=see successful memory access with Nvidia
Change-Id: I4f4084921b6267b137e7aeeafbfb8839a120c63e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5698370
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Mesa Vulkan WSI expects real sync files, not fake ones
backed by eventfd. These fences are attached to the dma-buf
via DMA_BUF_IOCTL_IMPORT_SYNC_FILE.
This allows windowing to work with Kumquat, on systems that
support dma-buf and sync-files.
There's still a bunch of gfxstream bugs though, but vkcube works.
glxglears crashes in gfxstream, due an timeline semaphore
encoding error in gfxstream.
BUG=b:350965057
TEST=export RUSTFLAGS="--cfg gfxstream_unstable" + cargo build --features=gfxstream
run vkcube via Kumquat + gfxstream
Change-Id: I37428970651113d48521f9c88d8946f8fccf009d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5689425
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
We defined the generic interface, but did not
have gfxstream implementation until now.
This is an unreleased, unstable gfxstream API.
The aosp side change is at aosp/3163844.
BUG=b:350965057
TEST=see fences being shared to Kumquat client
Change-Id: I4be086757e7f5f1c3cf9d743de1e8ec160bfefd4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5689424
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
As we iterate on the virtio-spec, it probably makes sense
to explore various options at the same time given the different
use cases.
To not trip over one another, add the gfxstream_unstable flag
in case someone wants to experiment with other methods of
fence passing.
Someone else with different ideas may add their own expermental
preprocessor.
The main success criteria for all projects: passing the fence
from the rendering context to the display context [or virtio-gpu
KMS].
With this method, we may reach the success criteria faster and
compare notes before we pitch something less experimental.
BUG=328083772
TEST=export RUSTFLAGS="--cfg gfxstream_unstable"
cargo build
Change-Id: I2011456e1207f84ea2d12b8877e5af66cf69d591
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5341729
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
rutabaga_gfx needs to known which context to export to the fence
from. One can either fish through all contexts at a later time,
or use the observation when created, a fence comes along with
it's `ctx_id`.
BUG=328083772
TEST=compile
Change-Id: I17b983e0b99269d9fa50441e933b49f145c7efaa
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5527478
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Both cross-domain/gfxstream contexts expect an handle to kernel
side fence at the moment, not fence_ids.
i.e, rutabaga_gfx tracks fencing for those context types.
BUG=328083772
TEST=compile
Change-Id: I2139156c1803f63e21a3914596ad00ddb6200451
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5527476
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
When running kumquat via gdb, it's common to encounter
this signal.
BUG=b:300140266
TEST=run kumquat
Change-Id: If022e70466c90466a15186d050424eadb406d01c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5683769
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Not neccessarily required to run kumquat.
BUG=b:300140266
TEST=compile
Change-Id: Ia1aa8d1ae27836cf18cf4d01dd95e2445cd1d618
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5683768
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This introduces a client-side library with FFI bindings
(libvirtgpu_kumquat_ffi.so) + server (Kumquat). The main goal
is to develop features and test applications, without
a VM.
gfxstream and other virtio-gpu contexts may easily connect to the
virtio-gpu part of the multi-media server via replacing
traditional virtgpu DRM ioctls with FFI functions (they are ABI
compatible).
gfxstream has had similiar features for a long time, with the main
goal of testing deqp-{gles, vk} without a VM. It was known the
"Android host build" for the longest time, and it was recently
improved to GfxstreamEnd2EndTests. The downside of this approach is
if you want to test complex apps (think gfxbench) and multiple apps
at the same time, it breaks down.
This is good enough to run vulkaninfo and all headless apps
probably. Apps with windowing fail, but due to gfxsteam-specific
bugs so far. Getting windowing working + Kumquat is a goal.
A side goal would be to test cross-domain and that requires the
ability for multi-context interop using external memory. The current
GfxstreamEnd2EndTests only support one GPU context at a time.
It addition, camera/video support is important too, hence the name
Kumquat (since ideally it won't just be rutabaga, it'll be something
different). If we added emulated virtio-media support, we in theory
can test GPU <--> media interop without a VM too.
Probably the allocator <--> renderer flow should work first, and
generically it really doesn't (everyone has their own workarounds). We
might want to connect the virtgpu_rutabaga APIs in minigbm..
Dependencies: Clap 4.1.8, same version as in AOSP
KNOWN ISSUES:
1) Use of UnixStream as the socket type. This is a stream socket, so
there are no message boundaries (the bytes sent by a particular
send() won't necessarily be received by a single corresponding recv()).
This could also lead to partial commands. The proper solution
would be to leverage SEQPACKET socket, but std::os::unix::net does
not have support yet. One could leverage nix and do a DIY
RutabagaSocket.
However, this is not observed in practice yet, since the client
side library as a mutex around every access. Many commands also
wait for a response ensuring ordering. It should be fixed though.
2) Mmap instead of Vulkano Mapping. Unlikely to work on Nvidia.
3) Emulated import/export not complete.
BUG=b:300140266
TEST = cargo build --features=gfxstream + target/debug/kumquat
vulkaninfo via gfxstream (works)
tfw-pkg/bin/testfw_app --gfx egl --gl_api=gles -w 1280 -h 720 -t gl_manhattan_off
(loads but hangs due X11/virtio-gpu spec/gfxstream bugs).
Change-Id: I4c16a2fc7b41691585cf4ba7ee8f36602cb6036d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5645904
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The rutabaga_gfx crate might have an increased need to
read/write from byte streams in the future. This
is an adaption of implementations elsewhere in crosvm.
BUG=b:300140266
TEST=none
Change-Id: I478967723860c49ec8fb763a5eb4d72b83907784
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5656254
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It's a better fit there. Most of the OS-specific items
in cross_domain can be replaced like this using similar methods.
BUG=b:300140266
TEST=compile
Change-Id: Idc1a803d0304b342a4aeb8558dd8bacad3400de4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5656256
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
