Over the past 2 days I described hypothetical hardware to layout & render a webpage. So how would I incorporate text into this? That's crucial for a hypothetical browser!
The first step would be to select which "glyphs" from the font to display onscreen (like Harfbuzz). The second step would be to rasterize those (vector) glyphs so they can be composited onscreen.
See if this'll be one thread or two?
1/?
The tricky bit with glyph selection is that it has to run inside webpage layout, parallelized per-paragraph. It would have to run it on the hypothetical tree-SIMT I described the other day.
The process for looking up & laying out glyphs is complex, possibly including opcodes from the font or writingsystem-specific code. But mostly it involves looking up data from various tables in the font.
From a hardware perspective I'll focus on data-lookup & opcode interpretation.
2/3 + rasterization.
To support data-lookups in the hypothetical tree-SIMT I described the other day I'd start by adding an opcode which splices a subtree into the binary tree. Or would I do that as a preprocessing step?
Either way I'd have a child of each inline element be the font to apply to it. Add opcodes for traversing up, left, or right in that subtree. Which could be needed anyways to store nontrivial amounts of text for processing!
So add GRAFT, UP, LEFT, & RIGHT opcodes!
3/4! + rasterization.
Usually opcode interpretation is easy, but given we're saying we're running this on a SIMT... Overusing branching can inefficiencies. Since with all compute-units receiving the same data the shared control unit cannot skip any branches at least one compute unit needs to take.
With enough cleverness or automation a bytecode interpreter could minimize this cost by sharing code between branches. Or I could further strategy of letting compute units choose their instruction stream.
4/4! + rasterize
@radehi That's not disimilar to what's happening inside in modern CPUs...
Tomosolu Algorithm I think it was called?
@alcinnz It has some similarities to Tomasulo's algorithm, but Tomasulo's algorithm isn't SIMD.
@alcinnz A thing I've been thinking about for a while is heavy multithreading by enqueuing execution states in per-opcode queues, so that you can then do SIMD (or SIMT) execution of a single opcode in 64 or 128 concurrent execution states at once.