v86
v86 copied to clipboard
copy
add virtio gpu support
see http://lists.freedesktop.org/archives/dri-devel/2015-March/079867.html
Just saw this "issue" accidental. I am already working on enhancement on virtio to support it. So jor1k will support it sooner or later. Who wants to write an opengl to webgl translation in a few months? ;)
My solution would entail AMD modules, but I should imagine you could port it to your own thing.
When a DLL is loaded, and function is called, it is downloaded via requirejs and executed before returning to the process being executed. Binary DLLs also happen in this manner via kernel32.dll/LoadLibrary and kernel32.dll/GetProcAddress (and of course the imports field in the PE JSON header).
JSIX Application Update:
I am on holiday all next week so I hope to have a couple of apps completed and published into the web. I have a hosting provider, SSL and CDN ready.
You can check progress @ http://test.emulayer.com from tomorrow, I'm still compressing js at the moment.
What works:
- Notepad (Provided by wine project) -> Works but need to continue porting functions and needs tweaks. IT WILL CRASH because functions are missing, but by the end of the week it will be done.
- WineMine (Also wine) -> Got to the menu, but need to sort out jwtk.
- cmd (Untested)
- AkelPad (Works but again still porting functions so it will crash)
- Notepad++ (Works but still . . . you get the picture).
- WineFile (Untested)
- Write works fully (when porting I didn't realise all it does is run WordPad and then exits(), oops)
Planned: At least two fully working apps by the end of the week supported on Firefox, Chrome and IE 11.
Data Storage is provided by OneDrive and Google. At the minute when an open dialog box is opened it will just load "Lorem Ipsum . . .". No Saves or anything for a couple of days.
Longer Term:
- More complex apps
- OpenGL (perhaps), and audio capability
- Basic Games
- Notepad, after clicking "Edit -> Date/Time", Many functions to implement though. Rendering is slightly off for now.
- WineMine (MineSweeper clone). Need to enhance jwtk to render the grid buttons. Just menu working for now [and registry accesses and what not]
Any ideas for apps? Porting is becoming a lot easier and quicker as time goes by. I've been scouring portableapps.com as well and most of those are feasible and are under going testing/integration also.
Ok copy, smacke,
As promised in my email a few weeks ago, proof of concept is up at http://test.emulayer.com
On my computer (slow), network (~50 Mb/s fast), app load time is about 20 seconds (No CDN or enhancements yet, SPDY and what not).
Second run (cache), 10 seconds. All apps take approximately the same depending on what code is executed prior to ShowWindow()/CreateWindow[Ex].
Once a CDN is active, we can (in theory) halve these times. In JSIX Iteration 7, [end of the year/next year], we have further optimisations to implement, just lets get a few apps out first.
Whilst smaller apps are optimal, really large apps can work too due to the chunked data, i.e. if an app is 1GB in size, and your executing 24MB of it you only get those chunks that are being executed [.text and .data segments for example]. That's a feature of the PE JSON format, plus the chunks are compressed using LZG and uncompressed in the virtual memory controller.
Microsoft(R) Windows(TM) compatibility JavaScripts are just AMD modules loaded on the fly by requirejs.
Wine also works but is slower, so:
*kernel32.dll *user32.dll *advapi32.dll *msvcr[X].dll *commctl32.dll *commdlg32.dll *gdi32.dll *ntdll.dll *ole32.dll *shell32.dll *version.dll and libwine.dll
are all written/encoded in JavaScript, although they are only partial implementations and are being ported in a function by function basis. Depending on the app, some functions may never be ported [as it's never called]
That looks already pretty promising. Unfortunately you can't do much at the moment. I can basically click in the menus. What do you think about implementing Minesweeper or Solitar?
Regarding the virtio gpu driver: Sounds like a cool project, but I'm not convinced that there are big performance gains from this. v86 currently implements Bochs VBE extensions, which provide a linear frame buffer. The only improvements the virtio driver seems to have over that are pixel formats and a hardware cursor. Am I missing something here?
@warpcoil Very nice. Maybe some interpreters like Python or PowerShell? Have you tried .NET applications? If this is mature enough, MS Office would be very interesting. How about Firefox?
Do you need something from us? I have fixed a pretty serious CPU bug in 6978f963fa, make sure to upgrade if you haven't already.
I partly have implemented virtio gpu today. It is indeed just a little bit more advanced framebuffer what you get. However I hope for some hardware acceleration in the future. Also I want to understand how it works.
@s-macke Yes, long way to go. winemine (aka minesweeper) is on the way.
@copy PowerShell is a no no because of copyright/licensing. Python, yes definitely wouldn't take too much, I'll look at that today. Firefox would work but I'd say performance would be an issue, along with MS Office.
I'm thinking smaller apps for now to reduce bugs.
CPU bug todo, but issue not yet encountered.
Still haven't implemented it fully. But I see one good reason. Looks like you only have to update the screen on certain commands. Like during the flush command. A background job, which permanently updates the screen with 10-30fps would be unnecessary. Especially when switching to a worker thread this might be important.
Closing since my suggestion suffers from the XY problem: Instead of defining specific benchmark for graphics and suggesting how to achieve it, I suggested a specific way that I thought would speed up graphics. As noted by copy above:
I'm not convinced that there are big performance gains
So I'll close this. Bugs should be actionable unlike this one.
@hello-smile6 Yeah, that was years ago i.e. before WebAssembly. The project stalled for a while as time was always an issue. I don't currently use v86 in this project and switched to libx86emu (which does compile with Emscripten). I'll bring that back up online at some point.
@hello-smile6 Yeah, that was years ago i.e. before WebAssembly. The project stalled for a while as time was always an issue. I don't currently use v86 in this project and switched to libx86emu (which does compile with Emscripten). I'll bring that back up online at some point.
Okay
@hello-smile6 Yeah, that was years ago i.e. before WebAssembly. The project stalled for a while as time was always an issue. I don't currently use v86 in this project and switched to libx86emu (which does compile with Emscripten). I'll bring that back up online at some point.
is it online yet?
Let's reopen this.
Even though I'm not planning to work on it, it'd still be useful for graphics performance, especially now that the cpu is fast(-ish).
Note that there are several options with varying amounts of complexity (see https://www.qemu.org/docs/master/system/devices/virtio-gpu.html):
- virtio-gpu 2d: Reasonably complex, can probably be implemented with 2d canvas operations
- virtio-gpu virglrenderer: Very complex, as we'd need to reimplement virglrenderer and/or translate opengl to webgl
- virtio-gpu rutabaga: Probably similar to virtio-gpu virglrenderer
I mentioned this in the gitter but just wanted to put it here for anyone wandering through the issue.
I think one thing that may be possible is running virglrenderer with the es backend (emscripten takes care of OpenGL ES -> WebGL conversion automatically) in emscripten, and then forwarding the socket to the VM, though I'm currently unsure on the specifics on how exactly this can be accomplished. I may try and compile virgl test server to emscripten to see how well things work
VirGL GPU acceleration works with the virpipe Mesa driver and the virgl_test_server.
To get this working, run the virgl_test_server on a Linux host like this:
strace --follow-forks --trace=memfd_create --fault=memfd_create virgl_test_server --use-glx
strace is needed to make the memfd_create syscall fail, otherwise it will try to use shared memory which isn't possible.
The virgl_test_server creates a Unix socket at /tmp/.virgl_test. We need to make this available to the VM, so we can use socat on the host to create a TCP server that forwards messages to the Unix socket:
socat TCP-LISTEN:1234,fork,nodelay UNIX-CONNECT:/tmp/.virgl_test
This Unix socket needs to be accessible from the guest VM, so use Wisp networking and run socat in the guest:
socat UNIX-LISTEN:/tmp/.virgl_test,fork TCP:10.0.0.1:1234,nodelay
I modified the Wisp server to make 10.0.0.1 an alias for localhost on the host system.
With this, I can get significantly improved performance compared to llvmpipe, however, it's very limited by the bandwidth of the virtual network. All OpenGL data gets copied and sent over the network due to the lack of shared memory, and I've only been able to get about 200mbit/s of bandwidth from the virtual network card (with some patches). There may also be extra latency added from excessive buffering in the Wisp code.
You can see that the glmark2 score increased from 2 with llvmpipe to 4 with virgl. That's a 100% increase!
Notably, virgl performance seems to be unaffected by the complexity of the rendered scene. In glmark2, it had a consistent 5-6 fps no matter what.
This is good because very complex games like supertuxkart now can run fairly well inside the guest VM:
Supertuxkart is running with 2 fps at the maximum graphics quality. I can't imagine how slow llvmpipe would be here.
All of this requires virgl_test_server running natively on the host. I've started trying to port it to the browser with Emscripten, but I'm not sure how difficult that will end up being.
My testing was done on https://github.com/MercuryWorkshop/anuraOS
