Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

remote: handle IPC on Windows #146

Closed
grovesNL opened this issue May 1, 2019 · 4 comments · Fixed by #358
Closed

remote: handle IPC on Windows #146

grovesNL opened this issue May 1, 2019 · 4 comments · Fixed by #358
Labels
type: enhancement New feature or request
Milestone
Gecko integration

Comments

@grovesNL
Copy link
Collaborator

grovesNL commented May 1, 2019

We need to consider some options to support IPC on Windows. The crate which is currently being used https://github.com/servo/ipc-channel states in the README that Windows is not supported yet.

Relevant PRs/issues:
servo/ipc-channel#166
servo/ipc-channel#108
servo/ipc-channel#118
@grovesNL grovesNL changed the title Handle IPC on Windows remote: handle IPC on Windows May 1, 2019
@grovesNL grovesNL added the type: enhancement New feature or request label May 1, 2019
@kvark
Copy link
Member

kvark commented May 1, 2019

Alternatives:

cc @JohnColanduoni

@JohnColanduoni
Copy link

JohnColanduoni commented May 2, 2019 •
edited
Loading

sandbox-ipc indeed has Windows support, but it as of yet doesn't have a way to safely send kernel resources (file handles, sockets, etc.) from a less privileged process to a more/equal privileged one (it has to do with a lack of granularity to handle duplication rights). There are ways to work around this via having a more privileged process to act as a sort of "escrow" agent, but I've not yet implemented it.

If you don't need to do that, and it's fine doing all IPC through Tokio, it should suffice as is. I've run into some performance/scheduling limitations due to Tokio/Windows impedance mismatches and am halfway through a solution, but the performance may already be sufficient for your needs. I'm also moving the MacOS implementation to use mach IPC like ipc-channel does as part of the same rework, if that's a consideration (IOSurfaces for example cannot be passed via the current socketpair implementation, which could be useful for WebGPU).

@kvark
Copy link
Member

kvark commented Oct 4, 2019

Another thing - https://github.com/NikVolf/parity-tokio-ipc

@JohnColanduoni

it's fine doing all IPC through Tokio

Could you clarify how this would be done? Perhaps, point me to an example, if possible.

@kvark kvark added this to the Gecko integration milestone Oct 16, 2019
@kvark kvark mentioned this issue Oct 16, 2019
Closed
@kvark
Copy link
Member

kvark commented Oct 17, 2019

I finished the round of investigations on IPC. We are going to use Gecko's standard IPC mechanism called IPDL. The client side will be serializing commands and data into a raw Vec<u8> using Rust code, which is sent over the IPC and then decoded by the server bit of Rust code.

The good news is that this is precisely what WebRender does today! So we aren't going to invent new ways of IPC communication, and any follow-up improvements to Gecko infrastructure would benefit us automatically.

As for the wgpu-remote responsibilities, it will need to provide that serialization/deserialization code and communicate to wgpu-native more closely than the native WebGPU API allows. The wgpu-remote crate would have no IPC mechanisms in itself. I'm open to renaming it to something like wgpu-ipc.

I'll be prototyping this solution shortly in Gecko and follow-up with the code changes here.

@kvark kvark mentioned this issue Oct 17, 2019
Closed
@kvark kvark mentioned this issue Oct 25, 2019
Merged
bors bot added a commit that referenced this issue Oct 26, 2019
@bors @kvark
Merge #358
dc206c6 
358: Remove all the IPC r=grovesNL a=kvark

Closes #146 
Closes #22

We have decided to use Gecko IPC for Firefox. `wgpu-remote` will therefore provide all the Rust glue that Gecko needs for client and server:
  - initialization/termination of client/server
  - ID management for the client
  - pass encoding blobs

In Servo, we'd need to enable `serde` feature of `wgpu-native` and potentially roll out a different remoting crate that would establish a protocol based on `ipc-channel`, as we wanted originally.

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
bors bot added a commit that referenced this issue Oct 26, 2019
@bors @kvark
Merge #358
b6dd767 
358: Remove all the IPC r=grovesNL a=kvark

Closes #146 
Closes #22

We have decided to use Gecko IPC for Firefox. `wgpu-remote` will therefore provide all the Rust glue that Gecko needs for client and server:
  - initialization/termination of client/server
  - ID management for the client
  - pass encoding blobs

In Servo, we'd need to enable `serde` feature of `wgpu-native` and potentially roll out a different remoting crate that would establish a protocol based on `ipc-channel`, as we wanted originally.

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
bors bot added a commit that referenced this issue Oct 26, 2019
@bors @kvark
Merge #358
61dd820 
358: Remove all the IPC r=grovesNL a=kvark

Closes #146 
Closes #22

We have decided to use Gecko IPC for Firefox. `wgpu-remote` will therefore provide all the Rust glue that Gecko needs for client and server:
  - initialization/termination of client/server
  - ID management for the client
  - pass encoding blobs

In Servo, we'd need to enable `serde` feature of `wgpu-native` and potentially roll out a different remoting crate that would establish a protocol based on `ipc-channel`, as we wanted originally.

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
bors bot added a commit that referenced this issue Oct 26, 2019
@bors @kvark
Merge #358
bcf1169 
358: Remove all the IPC r=grovesNL a=kvark

Closes #146 
Closes #22

We have decided to use Gecko IPC for Firefox. `wgpu-remote` will therefore provide all the Rust glue that Gecko needs for client and server:
  - initialization/termination of client/server
  - ID management for the client
  - pass encoding blobs

In Servo, we'd need to enable `serde` feature of `wgpu-native` and potentially roll out a different remoting crate that would establish a protocol based on `ipc-channel`, as we wanted originally.

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
@bors bors bot closed this as completed in 94f43c1 Oct 26, 2019
@bors bors bot closed this as completed in #358 Oct 26, 2019
@kvark kvark mentioned this issue Nov 6, 2019
Closed
14 tasks
kvark pushed a commit to kvark/wgpu that referenced this issue Jun 3, 2021
@bors @StarArawn
[rs] Merge gfx-rs#259
f984eb1 
259: Remove zerocopy and replace with bytemuck. r=kvark a=StarArawn

fixes gfx-rs#146 

I've removed `zerocopy` from the examples and replaced it with `bytemuck`. I ran all of the examples/tests and everything ran great in vulkan on my windows box.

Co-authored-by: StarToaster <startoaster23@gmail.com>
Patryk27 pushed a commit to Patryk27/wgpu that referenced this issue Nov 23, 2022
@lachlansneff
Make "None" interpolation mean default or nothing, depending on conte…
e9d00d3 
…xt (gfx-rs#146)

* Make no interpolation mean default or nothing, depending on context

* Re-add Interpolation::Perspective
RandyMcMillan pushed a commit to RandyMcMillan/wgpu that referenced this issue Jun 19, 2024
@hecrj
Merge pull request gfx-rs#146 from hecrj/feature/custom-styling
0a83024 
Custom styling
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: enhancement New feature or request
Projects
None yet
Milestone
Gecko integration
Development

Successfully merging a pull request may close this issue.

Remove all the IPC kvark/wgpu
3 participants
@JohnColanduoni @kvark @grovesNL