Add links back to the projects

_posts/2019-10-01-update.md

@@ -3,15 +3,15 @@ layout: post
 title: Project update
 ---
 
-gfx-rs is a Rust project aiming to make low-level GPU programming portable with low overhead. It's a single Vulkan-like Rust API with multiple backends that implement it: Direct3D 12/11, Metal, Vulkan, and even OpenGL.
+[gfx-rs](https://github.com/gfx-rs/gfx) is a Rust project aiming to make low-level GPU programming portable with low overhead. It's a single Vulkan-like Rust API with multiple backends that implement it: Direct3D 12/11, Metal, Vulkan, and even OpenGL.
 
-wgpu-rs is a Rust project on top of gfx-rs that provides safety, accessibility, and even stronger portability.
+[wgpu-rs](https://github.com/gfx-rs/wgpu-rs) is a Rust project on top of gfx-rs that provides safety, accessibility, and even stronger portability.
 
 This is an update that is not aligned to any dates or releases. We just want to share about some of the exciting work that landed recently, which will make it to the next release cycle.
 
 ## Slimmed down gfx-rs
 
-We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the fresh gfx-hal build by a factor of 8.5X.
+We've done a few big steps towards making gfx-hal easier to build and maintain. First of all, we removed the "magical" dependencies, such as `failure` and `derivative` in favor of straight and simple code. That sped up the fresh gfx-hal build by a [factor of 8.5X](https://github.com/gfx-rs/gfx/pull/2970).
 
 Secondly, the "typed" layer of gfx-hal got removed. Previously, we recognized that the view of the API for the backends (when implementing it) needs to be different from the users (to use it). Backends just need to implement "raw" interfaces, while users need more type safety, such as limiting the set of operations available on a command buffer when recording a render pass. For example, we had different entry points [create_command_pool](https://docs.rs/gfx-hal/0.3.1/gfx_hal/device/trait.Device.html#tymethod.create_command_pool) versus [create_command_pool_typed](https://docs.rs/gfx-hal/0.3.1/gfx_hal/device/trait.Device.html#method.create_command_pool_typed).
 
@@ -29,7 +29,7 @@ dx12 = ["rgx/dx12"]
 
 With the set of supported backends growing, this became more and more of an issue. Asking the user to enable the proper feature doesn't solve the problem - it just puts it on the users shoulders. Moreover, using features in such a way is typically non-idiomatic, because in Rust features are supposed to be additive, but all of the user code (including our examples) was written to work with a single backend, even if it's generic.
 
-Today, we are happy to announce that the problem is solved in wgpu-rs! Features are gone. The library knows which backends are supported on the target platform, it checks for their availability and enumerates their phusical adapters. When the user requests an adapter, they can provide a mask of backends, and the implementation will pick the most suitable adapter on one of the enabled backends.
+Today, we are happy to announce that the problem is solved in wgpu-rs! [Features are gone](https://github.com/gfx-rs/wgpu/pull/311). The library knows which backends are supported on the target platform, it checks for their availability and enumerates their physical adapters. When the user requests an adapter, they can provide a mask of backends, and the implementation will pick the most suitable adapter on one of the enabled backends.
 
 The immediate effect on the users is that the library "just works". All the complicated machinery of the backends is now hidden within the implementation. This is the case currently for `master` and will make it to the next release.
 
@@ -42,7 +42,7 @@ To solve this, an entirely new API was prototyped and implemented - all the way
   2. render to it
   3. present it
 
-It maps very nicely to Metal, OpenGL, and DX12/DX11, however requiring a bit more complexity on the Vulkan backend side, which is a cost we can live with.
+It maps very nicely to Metal, OpenGL, and DX12/DX11, however requiring a bit more complexity on the Vulkan backend side, which is a cost we can live with. This new swapchain model is currently provided alongside the old Vulkan-style one. If we are able to make gfx-portability to use it in the future, we'll consider removing the old model entirely.
 
 What we have in the end is:
   - fast start-up