copy / v86

x86 PC emulator and x86-to-wasm JIT, running in the browser
https://copy.sh/v86/
BSD 2-Clause "Simplified" License
19.65k stars 1.38k forks source link

add virtio gpu support #51

Open ysangkok opened 9 years ago

ysangkok commented 9 years ago

see http://lists.freedesktop.org/archives/dri-devel/2015-March/079867.html

s-macke commented 9 years ago

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? ;)

warpcoil commented 9 years ago

That's not too difficult, it's already planned for JSIX

warpcoil commented 9 years ago

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:

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:

winenote

winemine

warpcoil commented 9 years ago

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.

warpcoil commented 9 years ago

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]

s-macke commented 9 years ago

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?

copy commented 9 years ago

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.

s-macke commented 9 years ago

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.

warpcoil commented 9 years ago

@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.

s-macke commented 9 years ago

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.

ysangkok commented 2 years ago

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 commented 2 years ago

@warpcoil Your server's down.

warpcoil commented 2 years ago

@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 commented 2 years ago

@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

PurpleVoidEpic commented 11 months ago

@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?

copy commented 1 month ago

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):

ProgrammerIn-wonderland commented 1 month ago

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