Re: Microarch Club

On 3/27/2024 6:06 PM, Michael S wrote:

On Wed, 27 Mar 2024 21:14:01 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

>
What I don't get is the reluctance for using the FP multiplier as a
fast divisor (IBM 360/91). AMD Opteron used this means to achieve
17-cycle FDIS and 22-cycle SQRT in 1998. Why should IDIV not be under
20-cycles ?? and with special casing of leading 1s and 0s average
around 10-cycles ???
>
I submit that at 10-cycles for average latency, the need to invent
screwy forms of even faster division fall by the wayside {accurate or
not}.
>

 All modern performance-oriented cores from Intel, AMD, ARM and Apple
have fast integer dividers and typically even faster FP dividers.
The last "big" cores with relatively slow 64-bit IDIV were Intel Skylake
(launched in 2015) and AMD Zen2 (launched in 2019), but the later is
slow only in the worst case, the best case is o.k.
I'd guess, when Skylake was designed nobody at Intel could imagine that
it and its variations would be manufactured in huge volumes up to 2021.
 

FWIW: Newest CPU that I have is Zen+ ...
A lot of the other stuff around (excluding a few RasPi's I have, is stuff from the mid-to-late 2000's).
But, yeah, I guess fast dividers are possible, question I guess is more whether they can be done cheaply enough for cores where one would actually care about things like the costs of instruction decoding?...
Otherwise:
But, yeah, at the moment, apart from debugging, had gotten around to starting to work on some more of the GUI related stuff:
Added support for drawing window bitmaps using 256 and 16 color graphics;
Starting working on a "toolkit" for GUI widget drawing;
Also starting to add stuff for scalable / SDF font rendering.
For UI widgets:
Idea is that the widgets will be primarily drawn into a bitmap buffer that will be mapped to the window (lower level window management will not know or care about UI widgets);
Generally, I am breaking the UI into "forms" which will be applied to the windows, with the information about the "form" and its contained widgets being handled separately from any state associated with those widgets (unlike GTK, which tends to keep the widget definition and state in the same object).
Likewise, also generally approaching things in a way that "makes sense" for C (IOW: not the struct-casting mess that GTK had used). Also in the current design, the idea is that UI elements will be sized and positioned explicitly using window pixel coordinates (scaling UI based on window resizing may possibly be treated as more of an application concern, but could maybe have "layout helper" logic for this, TBD).
I have yet to decide on the default bit-depth for UI widgets, mostly torn between 16-color and 256-color. Probably don't need high bit-depths for "text and widgets" windows, but may need more than 16-color. Also TBD which color palette to use in the case if 256 color is used (the palette used for the lower-level parts of the GUI works OK, but requires a lookup table to convert RGB555 to indexed color, don't want to duplicate this table for every program; and don't necessarily need to force programs to all use the same palette, even though this would be better in a color-fidelity sense). Though, for UI widgets it almost makes most sense to instead use a palette based around RGB222 (64 color) or similar.
Say:
   00..0F: RGBI colors
   10..1F: Grayscale
   20..3F: Dunno
   40..7F: RGB222 colors
   80..FE: Dunno
       FF: Transparent
Well, or maybe reuse a variant of the 216 color "web safe" palette:
   00..0F: RGBI colors
   10..1F: Grayscale
   20..FD: 216 colors
       FE: Dunno
       FF: Transparent
Well, unless RGBI is sufficient (where, in this mode, the high-intensity-magenta color was interpreted as transparent).
May also make sense to either overlay UI elements with different bit-depths, and/or treat the UI widgets as an overlay (though, this could have its own issues, say, if the background image is redrawn and the UI overlaps part of, the UI will also need to be redrawn). And/or render the UI bitmap at a higher bit-depth (such as hi-color) if higher bit-depth elements are present (say, if there is a widget representing a "Bitmap object" or similar). In the "overlaid UI widgets" scenario, would likely make most sense to draw the parts showing the underlying image as a dedicated transparent color.
Though, non-overlap would be preferable in the case of things like video playback or similar.
For scalable fonts, current idea is mostly to use SDF fonts encoded as 256-color BMP images, where the X/Y distances are encoded as 4 bits each. The color palette is kinda redundant in this case, but doesn't add too much additional storage overhead to a group of 16x16 character cells (say, representing CP-1252 with each glyph encoded as 16x16 pixels).
Partly this is because SDF font rendering seems technically simpler than dealing with TrueType fonts (and was also used in some of my prior 3D engine projects; though with the alteration of representing the SDF's as 256-color BMP images rather than TGA or similar).
Currently no plans to address the rest of Unicode with this though (and it would take around 17MB to represent the entire Unicode BMP with this scheme).
In the past, had used Unifont, which was encoded in a form that stores each glyph as 16x16 at 1bpp; basically works, but no good way to scale the glyphs in this case without them looking terrible (well, absent upscaling them, possibly smoothing the edges, and transcoding into SDF form).
But, no really a good algorithmic way to figure out which corners need to be sharp and which should be rounded. Best option is likely to look at blocks of, say, 3x3 or 5x5 pixels, and then make a guess based on the pattern how the pixel in the center should expand from 1 pixel to 2x2 (which is applied iteratively to double the resolution of each glyph).
Though, 3x3 is small enough to make it viable to figure out a lookup table by hand. Well, or generate a bunch of images of large-font text and try to "mine" the patterns from the images (and then use these patterns to hopefully upsample Unifont glyphs to 64x64 or similar, as needed for the 16x16 SDF generation...).
Any thoughts on any of this?...
...