6 ms·

Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? Curious as

Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? Curious as to why use a CPU language for the display engine rewrite? It seems to be wasting the GPU all modern systems now contain.. Also, is it fully replacing the display engine, including the font renderer and image codecs?

daenney 10y ago
> Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? That's not the aim of Rust. Rust, according to its own website is: > Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
- mozumder 10y ago
  Sorry I meant 'servo' not Rust.
  - lucb1e 10y ago
    Editing might be a good idea, it now sounds as if you have no clue what's going on while in a subcomment you mention it was just a mistake (can happen).
jdub 10y ago
Servo makes incredibly good use of the GPU. Being able to do that, and iterate so fast on that work, is part of what Rust brings to the table. (I don't think they've swapped out the font renderer and image codecs yet, but there are quite a few bits and pieces they have swapped out as the Rust community delivers more pure Rust libraries.)
- dingaling 10y ago
  > Servo makes incredibly good use of the GPU. Too good, in fact: it won't run on any laptops that I own because their GPUs don't support a sufficient level of OpenGL. One great aspect of Firefox-with-Gecko is that you can throw it onto just about any machine with more than 512MB of RAM and it will provide bootstrap web access ( slow or otherwise ). That's going to be lost when everything is Servoised. I guess it's back to links2 at that point.
  - eddyb 10y ago
    AFAIK that's not actually true, one option they have is going through Mesa's llvmpipe in such cases. EDIT: to be clear, with the Servo nightlies you need to do this yourself but Firefox could bundle it eventually.
  - akiselev 10y ago
    How old are your laptops? For ease of development, webrender2 is configured to compile with the latest OpenGl 4.x features. I believe there is a way to build it to target a lower OpenGl version. Edit: Correction, its currently targeted at OpenGl 3.2. There's an open issue for bringing it down to OpenGl 3.1 which is the version supported by integrated Sandybridge GPUs. Considering 40% of people running Intel are using Sandybridge or older, that's probably why it wont run on your laptops.
    - dingaling 10y ago
      Youngest laptop here is from 2011: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller OpenGL renderer string: Mesa DRI Intel(R) 965GM Maximum OpenGL version for that chipset is 2.0, apparently, though I can't find a way to push it beyond 1.4 on Linux I appreciate that six years old is ancient by SV standards but I would be interested to learn what proportion of Firefox users are on equally old hardware. I did try launching Servo with CPU rendering but it hung indefinitely.
      - akiselev 10y ago
        Servo isn't a production ready consumer browser and it won't be for a long time because its purpose is to facilitate research into parallel browser engines. While a 2007 chipset may not be very old among the average consumer, it is probably not going to work for a developer machine that's going to be compiling a huge codebase under active development. I don't think the software fallback has gotten much love but AFAIK it'll work fine once llvmpipe support is added to webrender2 [1]. Once that is done, rendering will work with the vast majority of laptops and desktops running Linux/MacOS/Windows. The OpenGL version supported by that chipset is over a decade old so devoting time to compatibility this early in the project would be a waste of time (and defeat the purpose since the standard predates the explosion of mobile devices). [1] https://github.com/servo/servo/issues/13653 https://github.com/servo/servo/issues/13653
Manishearth 10y ago
Servo is not a "display engine". The term is "rendering engine", but that's an inaccurate bit of terminology, most of what a rendering engine does doesn't actually deal with rendering. A better term is "browser engine". Parsing, styling, the DOM, running JS, handling networking, computing layout are all things that a browser engine does that don't involve rendering. Many of these can't be done on the GPU, and for others the GPU brings no additional benefit because it's not the kind of load the GPU can magically parallelize. Servo's rendering stack does make extensive use of the GPU. https://github.com/servo/webrender/ https://github.com/servo/webrender/ (talk by patrick in https://air.mozilla.org/bay-area-rust-meetup-february-2016/ https://air.mozilla.org/bay-area-rust-meetup-february-2016/) There's also work on glyph rasterization on the GPU going on right now.
buzzybee 10y ago
This is a misunderstanding of what a rendering engine does. It operates on at least two layers: 1. On the CPU, architecting the drawing commands and resource management for the GPU 2. GPU programs (in the form of API calls, shaders, output buffers, etc.) Generally speaking, part 1 is not the resource-intensive part unless you also have to run an intensive algorithm on the CPU. If you see the renderer as a synthesizer unit, the CPU is the number of user parameters you have - the number of knobs and switches and sliders and patch points. You would typically only have a few knobs to turn, if you were writing a custom renderer for your application. But a complex, general-purpose renderer like that of the HTML DOM is more like a wall of patch cables; and within that, the Servo renderer found opportunities to make "risky" optimizations that parallelize, make tighter use of memory, etc., but many of them are only reasonable to do from within Rust, because of the additional checks it can perform.
- Manishearth 10y ago
  It's more than just architecting the drawing commands and resource management. That's just the renderer. The term "rendering engine" is misleading; in the context of browsers the rendering engine does basically all the core browser tasks. Basically, all the stuff needed to make a web page _work_ is part of the rendering engine. Stuff like history, bookmarks, URL bar, is part of the rest of the browser. See https://news.ycombinator.com/item?id=13331505 https://news.ycombinator.com/item?id=13331505 Servo's usage of Rust is all for the rest of the stuff. We do have a component, http://github.com/servo/webrender/ http://github.com/servo/webrender/, which handles rendering in particular. That indeed does the architecting of the draw commands and resource management on the CPU, and has a bunch of shaders handling everything else.

daenney 10y ago

> Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine? That's not the aim of Rust. Rust, according to its own website is: > Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

mozumder 10y ago
Sorry I meant 'servo' not Rust.
- lucb1e 10y ago
  Editing might be a good idea, it now sounds as if you have no clue what's going on while in a subcomment you mention it was just a mistake (can happen).

jdub 10y ago

Servo makes incredibly good use of the GPU. Being able to do that, and iterate so fast on that work, is part of what Rust brings to the table. (I don't think they've swapped out the font renderer and image codecs yet, but there are quite a few bits and pieces they have swapped out as the Rust community delivers more pure Rust libraries.)

dingaling 10y ago
> Servo makes incredibly good use of the GPU. Too good, in fact: it won't run on any laptops that I own because their GPUs don't support a sufficient level of OpenGL. One great aspect of Firefox-with-Gecko is that you can throw it onto just about any machine with more than 512MB of RAM and it will provide bootstrap web access ( slow or otherwise ). That's going to be lost when everything is Servoised. I guess it's back to links2 at that point.
- eddyb 10y ago
  AFAIK that's not actually true, one option they have is going through Mesa's llvmpipe in such cases. EDIT: to be clear, with the Servo nightlies you need to do this yourself but Firefox could bundle it eventually.
- akiselev 10y ago
  How old are your laptops? For ease of development, webrender2 is configured to compile with the latest OpenGl 4.x features. I believe there is a way to build it to target a lower OpenGl version. Edit: Correction, its currently targeted at OpenGl 3.2. There's an open issue for bringing it down to OpenGl 3.1 which is the version supported by integrated Sandybridge GPUs. Considering 40% of people running Intel are using Sandybridge or older, that's probably why it wont run on your laptops.
  - dingaling 10y ago
    Youngest laptop here is from 2011: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller OpenGL renderer string: Mesa DRI Intel(R) 965GM Maximum OpenGL version for that chipset is 2.0, apparently, though I can't find a way to push it beyond 1.4 on Linux I appreciate that six years old is ancient by SV standards but I would be interested to learn what proportion of Firefox users are on equally old hardware. I did try launching Servo with CPU rendering but it hung indefinitely.
    - akiselev 10y ago
      Servo isn't a production ready consumer browser and it won't be for a long time because its purpose is to facilitate research into parallel browser engines. While a 2007 chipset may not be very old among the average consumer, it is probably not going to work for a developer machine that's going to be compiling a huge codebase under active development. I don't think the software fallback has gotten much love but AFAIK it'll work fine once llvmpipe support is added to webrender2 [1]. Once that is done, rendering will work with the vast majority of laptops and desktops running Linux/MacOS/Windows. The OpenGL version supported by that chipset is over a decade old so devoting time to compatibility this early in the project would be a waste of time (and defeat the purpose since the standard predates the explosion of mobile devices). [1] https://github.com/servo/servo/issues/13653 https://github.com/servo/servo/issues/13653

Manishearth 10y ago

Servo is not a "display engine". The term is "rendering engine", but that's an inaccurate bit of terminology, most of what a rendering engine does doesn't actually deal with rendering. A better term is "browser engine". Parsing, styling, the DOM, running JS, handling networking, computing layout are all things that a browser engine does that don't involve rendering. Many of these can't be done on the GPU, and for others the GPU brings no additional benefit because it's not the kind of load the GPU can magically parallelize. Servo's rendering stack does make extensive use of the GPU. https://github.com/servo/webrender/ https://github.com/servo/webrender/ (talk by patrick in https://air.mozilla.org/bay-area-rust-meetup-february-2016/ https://air.mozilla.org/bay-area-rust-meetup-february-2016/) There's also work on glyph rasterization on the GPU going on right now.

buzzybee 10y ago

This is a misunderstanding of what a rendering engine does. It operates on at least two layers: 1. On the CPU, architecting the drawing commands and resource management for the GPU 2. GPU programs (in the form of API calls, shaders, output buffers, etc.) Generally speaking, part 1 is not the resource-intensive part unless you also have to run an intensive algorithm on the CPU. If you see the renderer as a synthesizer unit, the CPU is the number of user parameters you have - the number of knobs and switches and sliders and patch points. You would typically only have a few knobs to turn, if you were writing a custom renderer for your application. But a complex, general-purpose renderer like that of the HTML DOM is more like a wall of patch cables; and within that, the Servo renderer found opportunities to make "risky" optimizations that parallelize, make tighter use of memory, etc., but many of them are only reasonable to do from within Rust, because of the additional checks it can perform.

Manishearth 10y ago
It's more than just architecting the drawing commands and resource management. That's just the renderer. The term "rendering engine" is misleading; in the context of browsers the rendering engine does basically all the core browser tasks. Basically, all the stuff needed to make a web page _work_ is part of the rendering engine. Stuff like history, bookmarks, URL bar, is part of the rest of the browser. See https://news.ycombinator.com/item?id=13331505 https://news.ycombinator.com/item?id=13331505 Servo's usage of Rust is all for the rest of the stuff. We do have a component, http://github.com/servo/webrender/ http://github.com/servo/webrender/, which handles rendering in particular. That indeed does the architecting of the draw commands and resource management on the CPU, and has a bunch of shaders handling everything else.