Agenda items

• Friends of the tree (mbrubeck)
• Prepping materials for the training - https://etherpad.mozilla.org/Whistler-Servo-Training (larsberg)
• rust-geom + matrix / generics (gw)
• Cargo target dependencies (jack)
• Interest from AMD in our experiments (larsberg)
• Look into our dependencies again and see if we can break some of them? (gw)

Attending

• larsberg, jack, azita, brson, gw, team samsung, pcwalton, Manish, mbrubeck

Friends of the tree

• mbrubeck: We haven't done them in a while (ever?) on Servo. I wanted to recognize Corey (frewsxcv). He has done a ton of work getting the python code in our build system working. Also work on Travis, Cargo deps, etc. Thanks!
• jack: Yeah, he also added links to the documentation to most of the dependency crates!
• mbrubeck: He knows quite a bit of python, so we might ask him for some reviews on python changes...
• jack: I think I'd like to make him a reviewer for bors, based on jdm's experiences. He's been doing good reviews, so I think we should keep with this plan.

Training

• larsberg: I sent mail to our list about our planned training sessions at Whistler. We've already had a number of signups (including our new acting CTO!). Working on the training material is my focus for the next week or so, and I may ask for help from some of you. There's plenty of interest from the Rust team too.
• azita: Do we (Rust/Servo team) need to sign up too to reserve seats?
• larsberg: We'll see. We're supposed to have room for 60-100 people. I don't think we'll overflow the larger number at least. We can look for more space if needed. Good problem to have.
• jack: Do we need to look for more easy bugs? Will we be relying on those in the training?
• larsberg: Given the number of people we have, I think we should have a number of "fix this w-p-t test" exercises just so they can kick the tires.
• jack: Like, everyone fixes the same bug as an exercise?
• larsberg: Yeah, just to go through the workflow. I haven't written this all up yet though.
• jack: What I did at a previous training, not knowing people's previous experience, is to have some canned exercises, and then for each one a "level 2" version that was more open-ended or harder. So if some people finish early they don't have to just sit around. If it's open-ended enough they can fill up however much time is left until the next thing. It might be nice if we come up with some things in platform or layout. Even if it's artificial.
• larsberg: I was hoping we'd cover one architectural area, have an exercise for that area, then repeat for the next area. We have 3 hours, which isn't an infinite amount of time but we should be able to cover multiple areas.
• gw: I'm pretty sure we can come up with something.
• pcwalton: radial gradients would be easy.
• mbrubeck: How about the :active pseudo-class selector?
• jack: if radial gradients are in azure already, it would let people work through them
• pcwalton: There are layout bugs, but those can be really difficult
• jack: If it was canned and had a test, that woudl be tractible
• azita: How would it go? Do you have an overview first, or do people just dive in?
• larsberg: I'm hoping to do an overview, then one section on each architectural component, with some examples and exercises for each section.
• jack: We should make sure to demo our debugging commands and tools. Stuff like RUST_BACKTRACE, -Z dump-display-list, etc.

rust-geom

• gw: matrix4 is generic over the underlyig datatype. But, it's always f32. Since I have to implement othe roperations, maybe it makes sense to make matrix4 no longer generic? I can't imagine we're going to add anything else. It adds a lot of code complexity with it generic.
• pcwalton: I agree.
• gw: Whenever I've done it in the past, it's always been either on a float or a double, and then it had special SIMD versions anyway.
• pcwalton: Yeah, especially given that we don't have specialization in Rust yet.
• gw: OK, I'll make the matrix4 type concrete on f32. Matrix2 will stay as-is.
• pcwalton: When we SIMD-ify, we may need to do Matrix2, also.
• jack: Make sure to leave a note there. Could also just make anew Matrix4f32 type... but that's verbose. Where does the complexity come from?
• gw: It's in the implementation. It's more complex to read. As I add more types (e.g., Quaternion), it will get even messier.
• jack: Are the matrix types not generic over the units, too?
• gw: They're only Matrix4 over f32 right now.
• mbrubeck: Hard to do matrix math with the units involved. If there's just one scale factor it's OK, but if you're skewing it, how would that work?

Cargo dependencies

• jack: I went through the tree and made everything that is platform-specific such a depdenency. That is bad because, on linux, it's all copied twice. There's no glob/wildcard support for platform targets. This has cleaned up the build so that now we don't build empty OSX packages on Linux. Big thing to watch out for is if you are adding a new architecture (e.g., arm linux), it's super painful because you have to go through the entire dependency tree and put out 10 PRs to repos, some of which aren't owned by us. So, if you're adding new targets, be ready for some pain. If you see weird build problems on strange platforms, you should not be surprised. If you see anything wonky, let me know.
• jack: Also, I'll send an e-mail with numbers, but the target directory sharing is in cargo. A last fix will land in nightly, but the feature will shave at least 25% off of our build time. Also, if you're switching between CEF and a normal Servo build, that will be basically instantaneous. If you build normal debug servo and then cef, it just rebuilds the top servo crate and libembedding. Huge time savings!
• jack: I noticed that a no-op mach build was taking a minute, and that was because there was some O(N^N) algorithm for resolving dependencies, which obviously we'd be the only ones to hit. There's a fix from acrichto that is much better.

AMD

• larsberg: talked to some AMD people at linuxcon and they were very interested in pcwalton's unified memory experiments. They'd love to get some feedback. I'll put pcwalton in touch with them.\
• pcwalton: I'm testing on ARM big.little right now. It's an ODROID octo-core.
• jack: Also, Apple's going all-in on Metal now. It's on OSX and iOS now. Can we make use of this? Overlaps with all the other ones...
• pcwalton: Biggest use cases for Vulkan and Metal are to get control over multithreaded GPU scheduling, which we care about a lot. I'm cautiously optimistic about that. If we upgrade Skia and get Ganesh, and had a layers port to Metal, we might be able to use it and get really nice scheduling on our graphics card usage.
• jack: Bad news is that Apple is all-in on Metal and everybody else is on Vulkan, except for Microsoft who is also on somebody else.
• pcwalton: Yeah, our layers design with multiple backends is probably required to support all of these. Chromium is super OpenGL-heavy, so it will be hard for them to take advantage of these new APIs.
• jack: Does the way our compositor work benefit from this?
• pcwalton: Maybe? We're so simple that it's hard to imagine how we could benefit.
• gw: Biggest thing I see is if we move to GPU painting and can construct efficient GPU command buffers on the paint threads. That woudl be a massive win over where we're at right now.
• pcwalton: Definitely; the way you can use multithreading and the GL API are big wins. Also, multithreaded GL tends to be crashy on drivers. Vulkan is supposed to make drivers a lot simpler to reduce the number of bugs.
• larsberg: that reminds me that I also met somebody at LinuxCon from nvidia who works on the open source drivers who offered to help us out, too.

Dependencies

• gw: We seem to have a really bad dependency chain building up again. If I make a single-line change in rust-layers, it takes 8 minutes to build that. Maybe next quarter we should look at them and see if we can break things up a bit?
• pcwalton: Most important thing is to get script off of the critical path. Only the final build should depende on it.
• gw: Even worse, script depends on the graphics crates because of WebGL.
• jack: Should be able to pull WEbGL out...
• mbrubeck: I was also looking at the rust-layers stuff, and part of it is because util depends on rust-layers and everything dependes on util. This is because of the typed units, which are Pixels in rust-layers, and they're used in util.
• brson: Maybe cargo can detect some of these poor dependency chains?
• pcwalton: I'd rather have incremental compilation in rustc, if that's it.
• gw: Maybe we could use brson's dependency graph in cargo?
• jack: I asked earlier and they said it was out of scope.
• pcwalton: CAn we do it as a plugin?
• larsberg: It is implemented as a custom build command.
• jack: I'll bring this up with edunham. Also, nrc and nmatsakis are looking into compile times right now. It turns out 35% of the time in the script crate is trait resolution. There's a cache, but still a huge percentage of the time. nmataskis has been digging around in that. They're looking at this right now. Hopefully we'll get some easy early fixes to at least make the compile faster.
• pcwalton: I've chatted with nmatsakis for strategies for this in rustc. If it's just where rustc has to check if it's correct, you can go on speculatively to codegen and check simultaneously.
• jack: After doing the cleanup, I also realized we sometimes get out of sync in cargo.lock. Also, get foo from two different crate versions ALL THE TIME. Need a plugin or lint in tidy that checks to ensure we don't have two versions of the same package. We were doing it quite a bit. h5ever gives us two versions of "mac" but it doesn't cause any conflicts yet.