| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following changes are crucial for GPU H/W acceleration because
some graphics applications like games perform very frequent QEMU pipe
operations to send GLES commands to the host translator.
For each read/write buffer operation, currently QEMU pipe requires five
MMIO operations.
This causes significant overhead when running with hardware virtualization
enabled (e.g. HAXM) because each MMIO causes expensive transition from
the guest kernel to the kernel driver, and to the QEMU user space in the end.
Among such five MMIO accesses, four of them are required to just set up the
parameters for the access, like the buffer address, length etc. By passing
a buffer containing such parameters, we need only one MMIO operation to
send a GLES command to the host translator.
Update the qemu_pipe save version for pipe struct changes.
Change-Id: Idf6400f3c4c9c8473311312bb1d8f3ea92d68797
Signed-off-by: Xin, Xiaohui <xiaohui.xin@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Nakajima, Jun <jun.nakajima@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add snapshot load/save support to QEMU Pipes
This adds the ability to save and load QEMU Pipe connections
with snapshots. Note that by default, all loaded pipe client
connections are force-fully closed on load.
We don't have a good way to save the state of network
connections to persistent storage.
Properly implements snapshot save / load for qemu pipe clients.
Change-Id: Ie5767f8ce40c8341b958cc5844e724dd4fc1ed2b
|
| |
|
|
|
|
|
|
|
| |
Throughout emulator's code pipe's 'poll' callback was returning PIPE_WAKE_XXX,
instead of PIPE_POLL_XXX flags. This created whole sort of issues with the
qemu pipe service <-> client communications.
This is also a fix for http://b/issue?id=5196348
Change-Id: I92202cf4ef4554559eb022c4410ee93923edec1b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new virtual hardware device named "goldfish_pipe"
used to implement a very fast communication channel between the
guest system and the emulator.
IMPORTANT: This depends on a special kernel driver, see:
https://review.source.android.com/#change,22496
Usage from the guest is simply the following:
fd = open("/dev/qemu_pipe", O_RDWR);
const char* pipename = "pipe:<name>";
ret = write(fd, pipename, strlen(pipename)+1);
if (ret < 0) {
/* could not connect to service named <name> */
}
/* now you can read()/write()/close() as a normal
* file descriptor to exchange data with the service.
*/
In addition, this implements the following pipe services in the
emulator:
tcp:<port>
tcp:<hostname>:<port>
unix:<path>
opengles
The 'tcp:' and 'unix:' services simply redirect to a TCP or Unix
socket on the host with minimal
The 'opengles' service simply connects to tcp:locahost:22468 for now.
We may change this to be more configurable in the future, but that's
the port number used by the current experimental OpenGL ES hardware
emulation host libraries / programs.
Benchmarking with a simple ping-pong program shows that the
guest <-> emulator can achieve a roundtrip bandwidth of 192 MB/s
(on a 2.7 Ghz Xeon PC).
Using the tcp: service to talk to a ping-pong server listening
on localhost reaches 102 MB/s on the same machine, using a Unix
socket reaches 140 MB/s.
By contrast, using standard sockets in the guest reaches only
3.8 MB/s on the same machine (and requires special privileges
from the application anyway).
|
|
|
Change-Id: I338334d53fa9bc52c87e9da18341d0cb94fd4269
|
