-
Notifications
You must be signed in to change notification settings - Fork 28.8k
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.
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
WebGPU-based renderer for the editor #221145
Comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Update on my end for last week. WIP branch #225413 General
RasterizationTexture atlas
Explorations
|
Hope this become default soon. |
@faheemstepsharp I suspect it's going to be a long road to be the default (6 months, 1 year+?). We did eventually switch the terminal to default to GPU rendering, it'll be really bad if we ship an editor that breaks text rendering though. |
Update for @hediet and myself for last week. WIP PR #225413 ArchitectureWe came up with a better approach for where to stick the implementation. GPU parts are now regular "view parts" instead of being more tightly tied to the view. vscode/src/vs/editor/browser/view.ts Line 161 in bd21f3c
A new vscode/src/vs/editor/browser/view.ts Lines 146 to 148 in bd21f3c
❔ The term "context" is becoming a little overloaded (ViewContext, ViewGpuContext, GPUContext). Maybe there's a better name for Drawing shapesBuilt out the
This object isn't hooked up yet, just the data structure and tests are mostly done. General
Texture atlas
Debugging |
This may be a silly question but how do you draw glyphs on WebGPU? Are you drawing the glyph map with canvas or render the font manually? |
@vincentdchan fonts are rasterized to a texture atlas using a 2d canvas context (mostly on CPU), then the texture atlas pages are uploaded and drawn by the shader where each cell is a texture mapped to 2 triangles. So we're leveraging the browser's font rendering stack and can avoid getting into that. |
@Tyriar Great! I am implementing a canvas in WebGPU but AFAIK, 2D canvas doesn't provide API to detect font ligatures. One approach I used is reading from the font file. Do you handle font ligatures? |
@vincentdchan it does not, ligatures are still not supported in the terminal but they're close. The approach uses there is to parse out the ligatures from the font file and then draw the character sequences to the canvas together via a "character joiner" concept, such that they are rendered as ligatures: https://github.com/xtermjs/xterm.js/blob/f186475ec9375256d304fb4563160e2cd3fef291/addons/addon-ligatures/src/LigaturesAddon.ts#L35 There's also a set of "fallback" ligatures which makes it mostly work when font access isn't granted on the web. |
New public GH project to track this work: https://github.com/orgs/microsoft/projects/1367 |
I didn't have too much time last week to work on this but here's what we got done:
|
Main updates for last week:
|
We're finally starting to look at implementing a WebGPU-based rendering in monaco, similar to what xterm.js uses. This issue is used to track all the work which is expected to take several months.
Project: https://github.com/orgs/microsoft/projects/1367/views/1
Related issues
Here are some historical links that might be useful:
Below copied from https://github.com/microsoft/vscode-internalbacklog/issues/4906
GPU-based rendering
branch: tyriar/gpu_exploration
How GPU rendering works
It works by assembling array buffers which represent commands to run on the GPU, these are filled on the CPU with information like the texture to use (chracter, fg, bg), location, offset, etc. xterm.js for example allocates a cols x rows array buffer that represents the viewport only and updates it on every frame where the viewport changes.
There are 2 types of shaders:
How the prototype works
The WebGPU prototype works by pre-allocating a buffer that represents up to 3000 lines in a file with a maximum column length of 200. The buffers* are lazily filled in based on what's the viewport. Meaning once a line is loaded, it doesn't need to be modified again. I think it updates more aggressively currently than needed due to my lack of knowledge around finding dirty lines in Monaco.
Texture atlas
Glyphs are rendered on the CPU using the browser's canvas 2d context to draw the characters into a texture atlas. The texture atlas can have multiple pages, this is an optimization problem as uploading images is relative expensive. xterm.js creates multiple small texture atlas pages, allocates using a shelf allocator and eventually merged them into larger immutable pages as they're more expensive to upload.
Currently the prototype uses a single large texture atlas page, but it warms it up in idle callbacks for the current font and all theme token colors in the background (using the
TaskQueue
xterm.js util).Memory usage
In the above, each text_data_buffer cell is 12 bytes (3x 32-bit floats), so 3000x200 would be:
This is pretty insignificant for a modern GPU.
* Double buffering is used as the GPU locks array buffers until it's done with it.
Scrolling
The prototype currently scrolls extremely smoothly as at most a viewport worth of data is filled but often no viewport data will change. Then we just need to update the scroll offset so the shadow knows which cells to render.
Input
So far, the above is highly optimized for readonly scrolling. For input/file changes there are a few cases we need to target. We essentially want to get these updates to take as little CPU time as possible, even if that means leaving stale and no-longer referenced data in the fixed buffers.
Adding new lines or deleting lines
This could be supported by uploading a map whose job is to map line numbers with the index in the fixed buffer:
That way we only need to update indexes, not the whole line data.
Inserting characters
Simple O(n) solution is to just update the entire line. We could do tricks to make this faster but it might not be worth the effort if line length is fixed.
Fixed buffers and long lines
My plan for how the characters will be send to the GPU is to have 1 or more fixed width buffers (eg. 80, 200?) with maps that point to indexes dynamically as described in the input section and then another more dynamic buffer which supports lines of arbitrary length. This dynamic buffer will be a little less optimized as it's the edge case when coding. The fixed buffers could also be dynamically allocated based on the file to save some memory.
Other things we could do
┌───┘
. Whether this looks good in monaco is up to the font settings. Letter spacing and line height will always mess with theseTest results
These were done on terminalInstance.ts. Particularly slow frames of the test are showed.
The
tyriar/gpu_exploration
tests disabled all dom rendering (lines, sticky scroll, etc.) to get an idea of how fast things could be without needed to perform layouts on each frame. It's safe to assume that rendering other components would be less than or equal to the time of the most complex component (minimap is similar, but could potentially share data as well).Scroll to top command
M2 Pro Macbook main
M2 Pro Macbook tyriar/gpu_exploration (all dom rendering disabled)
Windows gaming PC main
Windows gaming PC tyriar/gpu_exploration (all dom rendering disabled)
Scrolling with small text on a huge viewport
fontSize 6, zoomLevel -4
M2 Pro Macbook main
M2 Pro Macbook tyriar/gpu_exploration (all dom rendering disabled)
Windows gaming PC main
Windows gaming PC tyriar/gpu_exploration (all dom rendering disabled)
Very long line
Long lines aren't supported in the gpu renderer currently
Shaders run in parallel to microtasks and layout
The sample below from the Windows scroll to top test above demonstrates how the shaders execute in parallel with layout, as opposed to all after layout.
Before:
After:
Harfbuzz shaping engine is used by lots of programs including Chromium to determine various things about text rendering. This might be needed for good RTL/ligature/grapheme rendering.
The text was updated successfully, but these errors were encountered: