On Monday, July 25, 2022 at 9:44:10 PM UTC+1, BGB wrote:

> It is more like:
> Adders for bits (15: 0)
> Adders for bits (31:16)
> Adders for bits (47:32)
> Adders for bits (63:48)
>
> tValRtV = tInvRt ? ~tValRt : tValRt;
> tAddValA0 = {1'b0, tValRs[15: 0]} + {1'b0, tValRtV[15: 0]} + 17'h0000;
> tAddValA1 = {1'b0, tValRs[15: 0]} + {1'b0, tValRtV[15: 0]} + 17'h0001;
> tAddValB0 = {1'b0, tValRs[31:16]} + {1'b0, tValRtV[31:16]} + 17'h0000;
> tAddValB1 = {1'b0, tValRs[31:16]} + {1'b0, tValRtV[31:16]} + 17'h0001;
> ... Gather up carry-bits for various operations ...
> tAddValRn[15: 0] = tAddSelA ? tAddValA1[15:0] : tAddValA0[15:0];
> tAddValRn[31:16] = tAddSelB ? tAddValB1[15:0] : tAddValB0[15:0];

you'll love this - see this page
https://libre-soc.org/3d_gpu/architecture/dynamic_simd/add/

(of course google groups will mangle this so i will replace space with
underscore, look at the original page to see it properly lined up)

partition:_____P____P____P_____(3_bits)
a________:_...._...._...._...._(32_bits)
b________:_...._...._...._...._(32_bits)
exp-a____:_....P....P....P...._(32+3_bits,_P=0_if_no_partition)
exp-b____:_....0....0....0...._(32_bits_plus_3_zeros)
exp-o____:_....xN...xN...xN..._(32+3_bits_-_x_to_be_discarded)
o________:_...._N..._N..._N..._(32_bits_-_x_ignored,_N_is_carry-over)

so instead of

Adders for bits (15: 0)
Adders for bits (31:16)
Adders for bits (47:32)
Adders for bits (63:48)

you have a *67* bit adder and...

Adders for bits (15: 0) in bits 15:0
partition bit in 16
Adders for bits (31:16) in bits 32:17
partition bit in 33
Adders for bits (47:32) in bits 49:34
partition bit in 50
Adders for bits (63:48) in bits 66:51

now let's say you want to do a full 64-bit add. guess what you do?

you set bits 16, 33 and 50 to ONE in the A input (and zeros
in the B input).

that's it. that's all there is to it.

let's say you now want to do 4x 16-bit adds. guess what you do?

you set bits 16, 33 and 50 to ZERO in both A and B.

why does this work? because due to the B-input being always zero,
when the partition bits are set to 1, they cause a carry-roll-over
condition into to the next partition. ta-daaa

it's so obvious, and so elegant. the beautiful bit is, you can use
standard HDL, you don't even have to do anything special for the
FPGA or VLSI synthesis tools.

the "cost"? you need a 67-bit adder instead of a 64-bit adder.
pffh. big deal. want 8-bit SIMD granularity? use 7 partitions.
want 8-bit SIMD granularity in a 128-bit ALU? use 15 partitions.
sooo difficult :)

l.

On Monday, July 25, 2022 at 9:55:56 PM UTC+1, BGB wrote:

> Then again, looking at it, probably not doing enough cross-products and
> similar to make this worthwhile.

if you have matrix multiply and have a skew-matrix system you get
cross-product effectively for free.

https://en.m.wikipedia.org/wiki/Skew-symmetric_matrix

On Monday, July 25, 2022 at 3:44:10 PM UTC-5, BGB wrote:

> Yeah, bulk duplicating this stuff for every scenario does not seem like
> a great idea.
>
>
> It is more like:
> Adders for bits (15: 0)
> Adders for bits (31:16)
> Adders for bits (47:32)
> Adders for bits (63:48)
>
> tValRtV = tInvRt ? ~tValRt : tValRt;
> tAddValA0 = {1'b0, tValRs[15: 0]} + {1'b0, tValRtV[15: 0]} + 17'h0000;
> tAddValA1 = {1'b0, tValRs[15: 0]} + {1'b0, tValRtV[15: 0]} + 17'h0001;
> tAddValB0 = {1'b0, tValRs[31:16]} + {1'b0, tValRtV[31:16]} + 17'h0000;
> tAddValB1 = {1'b0, tValRs[31:16]} + {1'b0, tValRtV[31:16]} + 17'h0001;
> ... Gather up carry-bits for various operations ...
> tAddValRn[15: 0] = tAddSelA ? tAddValA1[15:0] : tAddValA0[15:0];
> tAddValRn[31:16] = tAddSelB ? tAddValB1[15:0] : tAddValB0[15:0];
> ...
<
Build the adders in 9-bit quanta. Use this 9th bit to control carrys.
00 no carry propagation
01 and 10 carry will propagate
11 carry in
<
>
> One can deal with the SIMD cases while figuring out what the carry bits
> should be.
<
You KNOW what the inputs to the 9-th bit need to be by OpCode.

On Monday, July 25, 2022 at 3:55:56 PM UTC-5, BGB wrote:
> On 7/25/2022 5:46 AM, luke.l...@gmail.com wrote:
> > On Monday, July 25, 2022 at 2:18:26 AM UTC+1, BGB wrote:
> >
> >> Recently, was also left thinking about a possible operation to invert or
> >> flip the sign bits of selected vector elements.
> >>
> >> Say:
> >> 00: Leave element unchanged;
> >> 01: Invert low bits of element;
> >> 10: Invert sign bit of element;
> >> 11: Invert all bits of element.
> >
> > this is integer? what's the benefit / use-case?
> > (you should be able to XOR optionally with 0b100000000..., 0b0111111.....
> > immediates, to achieve the same effect)
> >
> Both integer and floating point (both use the same registers in my case).
<
There are 3 cases {integer, logical, floating point}
{integer and logical} invert the bit pattern
{floating point} invert the sign
{Integer} append a carry in to the inverted bit pattern.
<
This gives you the bit inversion for logical, negation for integer, and negation
for FP, and only cost the inverter (and some decode).
<

On 7/25/2022 4:07 PM, luke.l...@gmail.com wrote:
> On Monday, July 25, 2022 at 9:55:56 PM UTC+1, BGB wrote:
>
>> Then again, looking at it, probably not doing enough cross-products and
>> similar to make this worthwhile.
>
> if you have matrix multiply and have a skew-matrix system you get
> cross-product effectively for free.
>
> https://en.m.wikipedia.org/wiki/Skew-symmetric_matrix
>

There is no matrix multiply operation in my case.

What there is, is vector multiply, vector add, and some instructions
that can be used to implement a matrix transpose (turning the matrix
multiply into a series of vector multiplies and adds).

Then again, looking at my runtime code for some of the cross-product
operators:

(3D cross product)
__vnf_v4f_cross:
PSHUFX.L R4, 0x49, R16
PSHUFX.L R6, 0x52, R18
PMULX.F R16, R18, R20
PSHUFX.L R4, 0x92, R16
PSHUFX.L R6, 0x89, R18
PMULX.F R16, R18, R22
PSUBX.F R20, R22, R2
EXTU.L R3
RTS

(2D cross product)
__vnf_v2f_cross:
MOVLHD R5, R5, R7
PMUL.F R4, R7, R6
FLDCF R6, R7
FLDCFH R6, R3
FSUB R7, R3, R2
RTS

And, quaternion multiply:
__vnf_vqf_mul:
PSHUFX.L R4, 0xFF, R16
PMULX.F R6, R16, R22

PSHUFX.L R4, 0x92, R16
PSHUFX.L R6, 0x89, R18
PMULX.F R16, R18, R20
PSUBX.F R22, R20, R2

PSHUFX.L R4, 0x24, R16
PSHUFX.L R6, 0x3F, R18
PMULX.F R16, R18, R20
FNEG R21
PADDX.F R2, R20, R2

PSHUFX.L R4, 0x49, R16
PSHUFX.L R6, 0x52, R18
PMULX.F R16, R18, R20
FNEG R21
PADDX.F R2, R20, R2
RTS

Where, eg:
00=i, 01=j, 10=k, 11=r
And, usual rules:
i^2=j^2=k^2=-1
ij=k jk=i, ki=j;
ji=-k, kj=-i, ik=-j

It would appear that I had gotten by OK enough without per-element
negate in this case (so, not entirely sure what I was thinking earlier...).

Though, "FNEG R21" in the latter was effectively flipping the sign bit
of the 'r' component.

And, I guess I can note that BGBCC lacks a Binary16 quaternion type, I
guess I could add it if it turned out to be needed.

I guess it is in a similar category to "_Complex short float"...

Or, I guess I can note the vertex-projection function (from my OpenGL
implementation):

TKRA_ProjectVertexB:
MOV.X (R6, 0), R22
MOVLD R4, R4, R20 | MOVLD R4, R4, R21
MOV.X (R6, 16), R18
PMULX.FA R20, R22, R2
MOVHD R4, R4, R20 | MOVHD R4, R4, R21
MOV.X (R6, 32), R22
PMULX.FA R20, R18, R16
PADDX.FA R2, R16, R2
MOVLD R5, R5, R20 | MOVLD R5, R5, R21
MOV.X (R6, 48), R18
PMULX.FA R20, R22, R16
MOVHD R5, R5, R20 | MOVHD R5, R5, R21
PADDX.FA R2, R16, R2
PMULX.FA R20, R18, R16
PADDX.FA R2, R16, R18
FLDCFH R19, R4
FLDCH 0x0A00, R5
FABS R4, R4
FADDA R4, R5, R4
MOV 0x7FE, R5 | MOV 0x3FF, R6
SHLD.Q R5, 52, R5 | MOV 0x400, R3
SHLD.Q R6, 52, R6 | SUB R5, R4, R5
FMULA R5, R4, R7
SHLD.Q R3, 52, R3 | SUB R6, R7, R7
ADD R7, R5, R2
FMULA R2, R4, R6
FSUBA R3, R6, R7
FMULA R2, R7, R2
MOV.X tkra_prj_xyzsc, R22
MOV.X tkra_prj_xyzbi, R20
MOV 0x3F800000, R5 | FSTCF R2, R1
MOVLD R1, R1, R16 | MOVLD R5, R1, R17
PMULX.FA R16, R22, R16
PMULX.FA R18, R16, R18
PADDX.FA R18, R20, R2
RTS

Where the 'FA' operations encode a hint to use lower precision.
FMULA / FSUBA / ... also encode a "low precision" hint.
The projection operation doesn't really need much precision, but does
need to be reasonably fast...

This code fakes FDIV with bit twiddling partly because:
Originally there was no FDIV;
Even with FDIV, the instruction takes significantly longer than faking
it in this case.

Also note that, for performance reasons, my GL implementation uses
affine texturing with dynamic tessellation rather than
perspective-correct texturing (pros/cons here).

Or, its C equivalents:
tkra_vec4f TKRA_ProjectVertex(tkra_vec4f vec, tkra_mat4 mat)
{ register tkra_vec4f v0x, v0y, v0z, v0w;
float f;

v0x=tkra_v4f_xxxx(vec);
v0y=tkra_v4f_yyyy(vec);
v0z=tkra_v4f_zzzz(vec);
v0w=tkra_v4f_wwww(vec);

v0x=tkra_v4fmul(v0x, mat.row0);
v0y=tkra_v4fmul(v0y, mat.row1);
v0z=tkra_v4fmul(v0z, mat.row2);
v0w=tkra_v4fmul(v0w, mat.row3);

v0x=tkra_v4fadd(v0x, v0y);
v0y=tkra_v4fadd(v0z, v0w);
v0z=tkra_v4fadd(v0x, v0y);

return(v0z);
}

tkra_vec4f TKRA_ProjectVertexB(tkra_vec4f vec, tkra_mat4 mat)
{ tkra_vec4f v0xyzw, v0ww, v0p;
float f0, f1;

v0xyzw=TKRA_ProjectVertex(vec, mat);
f0=tkra_v4f_w(v0xyzw);
f1=tkra_frcpabs(f0); // f1=1.0/(fabs(f0)+0.001);

v0ww=tkra_mkvec4f(f1, f1, f1, 1.0);
v0ww=tkra_v4fmul(v0ww, tkra_prj_xyzsc);
v0p=tkra_v4fadd(tkra_v4fmul(v0xyzw, v0ww), tkra_prj_xyzbi);

return(v0p);
}

Where, this code is using wrappers over BGBCC's SIMD system (and also
the "xmmintrin.h" system and similar) mostly to allow it to also be
built using MSVC.

I am not sure if there are any "obvious" areas where further improvement
is possible.

Note that the relative lack of bundling in these code sequences is due
to 128-bit SIMD instructions being unable to be encoded in bundles and
similar (and a lot of the rest either has dependencies, or did not
represent instruction sequences which could be bundled effectively).

On 8/08/22 09:58, BGB wrote:

> It would mostly help if one is throwing multiple cores at the problem.
> Some of my past experiments with multi-threaded renders had split the
> screen half or into quarters, with one thread working on each part of
> the screen.

Which call me a pessimist, would not work very well at all, except for
carefully rigged demos.
I'm sure there's a version of Murphy's law for 3d rendering at play.

> Though, my current rasterizer is single threaded.
>
> Originally, it was intended to be dual threaded, but ran into a problem
> when I started exceeding the resource budgets needed for doing dual core
> on the FPGA I am using, and the emphasis shifted to trying to make a
> single core run fast.

Which still strikes me as an impressive effort none the less.

Sometimes it's not how well the monkey dances, the fact it can dance at
all is what impresses most.

> Splitting up geometry and then drawing each tile sequentially is not as
> likely to be helpful.

Depends I guess, I've a tendency towards per-polygon texture maps, so
splitting polygons offline at the level building stage to suit max
texture sizes would be a thing for me.

> There is a possibility of a slight advantage to drawing geometry
> Z-buffer-only first, and then going back and drawing surfaces.

No z-buffer in a tile renderer AFAIK, just z-sort front to back, then a
kind of a modified painters algorithm where you get the overwrite out of
the way quickly with a per polygon constant value.

>> Of course ripping up and changing your existing core probably isn't
>> something you'd happily contemplate, so take my suggestion with a
>> large grain of salt. ;-)
>>
>
> Yeah.
>
> Also it isn't likely to offer a huge advantage in this case (with a
> software renderer).

That potentially could be augmented with custom FPGA resources if it helps?

> Also possibly counter-intuitively, a bigger amount of time is currently
> going into the transform stages than into the raster-drawing parts.
>
>
> So for GLQuake, time budget seems to be, roughly, say:
> ~ 50%, Quake itself;
> ~ 38%, transform stages
> ~ 4%, Edge Walking
> ~ 12%, Span Drawing
>

I'm no expert, but I wouldn't have guessed that half the compute was
going to just Quake engine housekeeping duties. :-)

What on earth is going on in there I wonder?
(no, no, please don't answer that, it's not a real question) :-)

>
> Wasn't aware of any of the code for any of the Tomb Raider games having
> been released, but then again I wasn't really much into Tome Raider.

???Tome-Raider??? -- blasphemy if ever I saw it!!! ;-)

And I'm not sure released is quit the right word, but the company that
wrote it - Core Design, pretty much went bankrupt twice, leaving the
source code with no clear legal owners so the story goes, but of course
trademarks and copyrights for the franchise still exist, despite their
recent selloff not-withstanding.

>
> Contrary to some people, I suspect the HL/HL2 era is when graphics got
> "good enough", despite newer advances in terms of rendering technology,
> the "better graphics" don't really improve the gameplay experience all
> that much.

Oh, I agree completely, well mostly, more polygons == more pretty
applies to at times.

>
> One of the more interesting recent developments is real-time ray-tracing.
>

I'm not so sure on the recent, I remember Silicon Graphics (remember
them?) did a ray tracing demo donkeys years ago with some hideously
expensive multi-core machine entirely on CPU power alone.

And it's been a sort-of holy grail quest for graphics rendering "if only
we had the computing resources to pull it off" ever since.

Quite why that was such a good idea was pretty much left unspoken, given
that hardware accelerated 3D on PCs was a thing by then and PC gaming
had already taken off big time.

> However, it is not so easy to write a ray-tracer that is competitive
> with a raster renderer. I had experimented (not too long ago) with

Not easy?, there's an understatement, try impossible!! (until very
recently obviously, and Intel Larrebee demos not withstanding) the're
being so many orders of magnitude difference in the calculation costs
between the two.

> implementing a software ray-tracer in the Quake engine, but it fell well
> short of usable performance.
>

Not surprising at all, given even a Nvidia 3090 GPU struggles with
acceptable frame rates while raytracing, and technically cheating as
well with hardware enhanced image noise reduction and resolution
up-scaling even then.

Maybe the 4000 series fares better, but that's only if you can afford
the things in the first place.

>
> IME, line-tracing over a regular grid structure (or an octree) tends to
> be more efficient than doing so via a recursive BSP walk (an octree
> based engine likely being more efficient if one wants to implement a
> ray-cast or ray-tracing renderer).

I pretty much ignored the deluge years of SIGGRAPH papers on new and
improved ray-tracing acceleration methods, so what the state of the art
is these days I couldn't say.

But, Internet!, I'm sure somebody does!

>
> But, OTOH, doing a modified version of Quake where I rebuild all of the
> maps from the map source (with custom tools) using an octree and similar
> rather than a BSP, is probably "not really worth it".
>

I wouldn't be so quick to dismiss the idea outright, I mean how do you
really know if you're not flogging a dead horse with regards to
everything else, and it's the data structures that are holding back that
last bit of performance improvement to be had?

Perhaps our man from super mega hand optimized assembler programming -
Terje Mathisen has some sage words of advice on discovering where the
limits of optimization lie?

>>> I could make stuff look a lot better, but this would require:
>>> Using RGBA32 buffers and textures;

Yep, millions of colors is more betterist.

>
> Probably, I am using RGB555A, which can sorta mimic RGBA32 and (on
> average) looks better than RGBA4444 or similar.
>
>
> RGBA32 for a framebuffer can look better, but using it would be kind of
> a waste when the output framebuffer is using RGB555. And, on the FPGA
> board I am using, the VGA output only has 4 bits per component, so even
> the RGB555 output is effectively using a Bayer dither in this >case.

Damn those pesky demo boards, just a taste of what could be done, but
never quite doing a decent job of it!, often despite the rather high
price tags to boot!

I guess if money is an object then moving to a better board with 24bit,
or better still an HDMI/Display port and the high-speed serial drivers
to drive them at full speed is out of the question?

And probably the worst time in recent memory to be shopping for new
electronics boards anyway, it's truly the end times to be sure, for
realzies this time!!!

> It is possible, though if I were to try to fit TKRA-GL to it, it would
> likely mean cores that were more like:
> 2-wide with 64-bit Packed-Integer SIMD;
> Probably still needing a 32-bit address space.

You don't seem to do 'small' much do you! ;-)

Small can be beautiful too you know!
Watch the Lord of the Rings trilogy, sometimes the smallest of Hobbits
can achieve the mightiest of deeds. :-)

> Though, my attempts at RISC-V cores have thus far end up more expensive
> than ideal (in my attempts, a full RV64G core would end up costing
> *more* than another BJX2 core), and even making it single-issue isn't
> really enough to compensate for this.

At this point I feel I should start calling your design 'Sybil Core',
(don't worry it's a 'dad' joke)

> A bigger amount of savings would likely be possible with a redesigned
> API design, possibly:
> Rendering state configuration is folded into "objects";
> Front-end interface mostly uses fixed-point or similar;
> ...

Your FPGA only has integer DSP multipliers?, with floating point units
having to be synthesized manually?

Might be worth a shot, but do you remember a 3D rendering library called
'Pixomatic', an all integer polygon rendering tool from way back when by
Rad Game Tools I think?

Don't know what it's state of existence is these days, but if it by
chance has gone open source it could be a veritable gold mine of source
code to port or idea mine for a lean, mean hand optimized rendering
engine that might make a perfect fit for an integer FPGA.
YMMV of course.

>
> Kinda curious that they did this back then, whereas many later games
> (Half-Life 2, Doom 3, etc) didn't bother with these sorts of effects
> (they probably could have if they wanted as special cases of ragdoll
> within their skeletal animation systems).

Have you seen the graphics accelerator core on opencores.org? orsoc_graphics_accelerator.
It can do basic drawing operations, draw triangles, and fill areas. It takes about 15k LUTs. I have
modified it and used it for my own purposes. For some operations it would be hard to beat with
a computing core.

On Tuesday, August 9, 2022 at 9:18:46 PM UTC+1, robf...@gmail.com wrote:
> Have you seen the graphics accelerator core on opencores.org? orsoc_graphics_accelerator.
> It can do basic drawing operations, draw triangles, and fill areas. It takes about 15k LUTs. I have
> modified it and used it for my own purposes. For some operations it would be hard to beat with
> a computing core.

it's what's termed a "Fixed Shader" Engine, and consequently
is useless for modern GPU compute which is 100% "Shader"
based (i.e. Vulkan).

GPLGPU likewise is a "Fixed Shader"
https://github.com/asicguy/gplgpu

but Jeff Bush the author of Nyuzi did an analysis and
showed that actually GPLGPU internally has functions
remarkably similar to modern GPU instructions needed
for modern Shader design
https://jbush001.github.io/

l.

On 8/9/2022 7:31 AM, Andy wrote:
> On 8/08/22 09:58, BGB wrote:
>
>
> > It would mostly help if one is throwing multiple cores at the problem.
> > Some of my past experiments with multi-threaded renders had split the
> > screen half or into quarters, with one thread working on each part of
> > the screen.
>
> Which call me a pessimist, would not work very well at all, except for
> carefully rigged demos.
> I'm sure there's a version of Murphy's law for 3d rendering at play.
>

It was faster than a single-threaded renderer.

The front-end though does need to divide up geometry based on where it
is on screen, which would be of limited advantage if rendering is
transform limited rather than fill-rate limited.

It wouldn't work well with TKRA-GL on my BJX2 core, which is mostly
transform limited.

>
> > Though, my current rasterizer is single threaded.
> >
> > Originally, it was intended to be dual threaded, but ran into a problem
> > when I started exceeding the resource budgets needed for doing dual core
> > on the FPGA I am using, and the emphasis shifted to trying to make a
> > single core run fast.
>
> Which still strikes me as an impressive effort none the less.
>
> Sometimes it's not how well the monkey dances, the fact it can dance at
> all is what impresses most.
>

I had been recently experimenting with a stripped down "GPU Profile" for
the BJX2 core, which ended up being primarily using "parameter" settings
for disabling some parts of the core (idea being to have one core remain
"full featured", and the other is more stripped down).

General idea for the GPU Profile being:
Has WEX and XGPR
Omits TLB and the main FPU;
Omits various other functionality;
...

Then have now ended up doing some things to try to reduce costs in other
areas:
Eliminated DLR, DHR, and LR writable side-channels;
These may now only be written to via the register ports.

Replaced the logic for swapping SP and SSP in the pipeline, to doing it
in the decoder (it now effectively causes these registers to switch
places at decode-time when executing inside an interrupt; rather than by
having a side-channels mechanism to swap the registers when entering or
leaving).

The former had an obvious LUT savings.

The latter appeared to cause LUT use to increase slightly, but given
both timing and power have improved, this seems to be a case of "logic
is looser so now Vivado uses more LUTs".

I have still yet to shave down LUT usage enough to fit two cores on the
FPGA though.

>
>
>
> > Splitting up geometry and then drawing each tile sequentially is not as
> > likely to be helpful.
>
> Depends I guess, I've a tendency towards per-polygon texture maps, so
> splitting polygons offline at the level building stage to suit max
> texture sizes would be a thing for me.
>

OK.

Can note that officially TKRA-GL claims in the API to support up to
256x256; actual technical limit is closer at present to 4096x4096, but
in this case I don't actually have enough RAM to make textures this size
viable.

>
> > There is a possibility of a slight advantage to drawing geometry
> > Z-buffer-only first, and then going back and drawing surfaces.
>
> No z-buffer in a tile renderer AFAIK, just z-sort front to back, then a
> kind of a modified painters algorithm where you get the overwrite out of
> the way quickly with a per polygon constant value.
>

Getting rid of a Z-Buffer would be a problem for OpenGL, since some
parts of the API are built around the assumption of a Z-Buffer existing
(as opposed to Painter's Algorithm or similar).

Similarly, OpenGL tends to also assume things like that you can stop the
scene mid-render, use glReadPixels, and fetch a copy of whatever has
been drawn thus far (including both the contents of the color buffer and
Z-buffer), ...

>
>
> >> Of course ripping up and changing your existing core probably isn't
> >> something you'd happily contemplate, so take my suggestion with a
> >> large grain of salt. ;-)
> >>
> >
> > Yeah.
> >
> > Also it isn't likely to offer a huge advantage in this case (with a
> > software renderer).
>
> That potentially could be augmented with custom FPGA resources if it helps?
>

There is some amount of ISA level support:
Helper ops to pack and unpack RGB555 / etc;
Operations to help with compressed-texture blocks;
An "LDTEX" instruction to help speed up texture-map rendering (*);
...

The LDTEX instruction basically turns the texture fetch into a special
addressing mode, with a texture block decoder shoved onto the end of the
load instruction. It doesn't do any texture filtering, so is basically a
"Nearest" fetch, but it is possible to encode which pixel position one
wants to help with implementing bilinear filtering or similar.

>
> > Also possibly counter-intuitively, a bigger amount of time is currently
> > going into the transform stages than into the raster-drawing parts.
> >
> >
> > So for GLQuake, time budget seems to be, roughly, say:
> >    ~ 50%, Quake itself;
> >    ~ 38%, transform stages
> >    ~  4%, Edge Walking
> >    ~ 12%, Span Drawing
> >
>
> I'm no expert, but I wouldn't have guessed that half the compute was
> going to just Quake engine housekeeping duties. :-)
>
> What on earth is going on in there I wonder?
> (no, no, please don't answer that, it's not a real question)  :-)
>

CPU is slow enough in this case that much of the time ends up going into
things like audio mixing and the main BSP walk (R_RecursiveWorldNode,
etc), and a fair bit of time into RecursivePointLight and similar as
well (eg, figuring out the light-level at a given spot in the map).

The "BoxOnPlaneSide" function also eats a good chunk of time, ...

I am mixing sound at 16 kHz, one can get a slight speed increase by
mixing at 8 kHz, but it sounds bad enough that it really worth it.

Part of the audio mixing overhead is due to Quake playing near constant
looping ambient sound effects (albeit usually at a fairly low volume),
but this "loses something".

>
> >
> > Wasn't aware of any of the code for any of the Tomb Raider games having
> > been released, but then again I wasn't really much into Tome Raider.
>
> ???Tome-Raider??? -- blasphemy if ever I saw it!!!   ;-)
>

Typo.

> And I'm not sure released is quit the right word, but the company that
> wrote it - Core Design, pretty much went bankrupt twice, leaving the
> source code with no clear legal owners so the story goes, but of course
> trademarks and copyrights for the franchise still exist, despite their
> recent selloff not-withstanding.
>

OK.

I guess this happens sometimes.

Sometimes things can't continue because the original company is now
defunct. Or, sometimes the company splits and then the parts get bought
by different companies, and no one can agree who owns the rights to the
original media, ...

>
>
> >
> > Contrary to some people, I suspect the HL/HL2 era is when graphics got
> > "good enough", despite newer advances in terms of rendering technology,
> > the "better graphics" don't really improve the gameplay experience all
> > that much.
>
> Oh, I agree completely, well mostly, more polygons == more pretty
> applies to at times.
>

Probably true; for example, games like Minecraft can push pretty massive
numbers of polygons despite the "simplistic" graphics.

>
> >
> > One of the more interesting recent developments is real-time
> ray-tracing.
> >
>
> I'm not so sure on the recent, I remember Silicon Graphics (remember
> them?) did a ray tracing demo donkeys years ago with some hideously
> expensive multi-core machine entirely on CPU power alone.
>
> And it's been a sort-of holy grail quest for graphics rendering "if only
> we had the computing resources to pull it off" ever since.
>
> Quite why that was such a good idea was pretty much left unspoken, given
> that hardware accelerated 3D on PCs was a thing by then and PC gaming
> had already taken off big time.
>

Practicality is more hit or miss.

>
>
> > However, it is not so easy to write a ray-tracer that is competitive
> > with a raster renderer. I had experimented (not too long ago) with
>
> Not easy?, there's an understatement, try impossible!! (until very
> recently obviously, and Intel Larrebee demos not withstanding) the're
> being so many orders of magnitude difference in the calculation costs
> between the two.
>
>
> > implementing a software ray-tracer in the Quake engine, but it fell well
> > short of usable performance.
> >
>
> Not surprising at all, given even a Nvidia 3090 GPU struggles with
> acceptable frame rates while raytracing, and technically cheating as
> well with hardware enhanced image noise reduction and resolution
> up-scaling even then.
>
> Maybe the 4000 series fares better, but that's only if you can afford
> the things in the first place.
>

On 8/9/2022 3:44 PM, luke.l...@gmail.com wrote:
> On Tuesday, August 9, 2022 at 9:18:46 PM UTC+1, robf...@gmail.com wrote:
>> Have you seen the graphics accelerator core on opencores.org? orsoc_graphics_accelerator.
>> It can do basic drawing operations, draw triangles, and fill areas. It takes about 15k LUTs. I have
>> modified it and used it for my own purposes. For some operations it would be hard to beat with
>> a computing core.
>
> it's what's termed a "Fixed Shader" Engine, and consequently
> is useless for modern GPU compute which is 100% "Shader"
> based (i.e. Vulkan).
>
> GPLGPU likewise is a "Fixed Shader"
> https://github.com/asicguy/gplgpu
>
> but Jeff Bush the author of Nyuzi did an analysis and
> showed that actually GPLGPU internally has functions
> remarkably similar to modern GPU instructions needed
> for modern Shader design
> https://jbush001.github.io/
>

FWIW, there isn't any hard-limit preventing running shaders on the BJX2
core, it is mostly a software issue (needing to write a shader compiler
and similar, ...).

One other limit at the moment is that trying to have a second "GPU core"
(modified BJX2 core lacking TLB and FPU, but still having WEX+Jumbo96
and XGPR and 128-bit FP-SIMD and similar) currently needs ~ 25 kLUT.

Lane 3 is partially disabled in the GPU core (its ability to run
instructions was disabled, but it can still provide register ports for
128-bit SIMD ops and similar).

This mode also omits the Shift-Add MUL/DIV unit, along with most of the
96-bit address-space stuff (I turned this off for now trying to see if I
can make everything fit).

For now, the "GPU core" still has the ALUX and BCD extensions as well
(128-bit ALU and BCD ADD/SUB), could probably add logic to exclude these
if needed (but doing so isn't likely to save much).

Main core (with most features still enabled), using ~ 40 kLUT.

Externally, the DDR+L2 costs 4.0k, and the display output costs 3.3k.

This currently goes a bit outside the total LUT budget (63k).

Looks like (GPU core):
L1 Caches : ~ 6.0k
ALUs : ~ 5.3k (1/2)
Reg-File : ~ 3.1k
Int32 MUL : ~ 1.5k
LFP SIMD : ~ 1.7k
Rest : ~ 8.0k

Within the main core:
L1 Caches : ~ 6.0k
TLB : ~ 3.0k
ALUs: : ~ 6.7k (1/2/3)
Reg-File: : ~ 4.8k (extra plumbing)
Int32 MUL : ~ 1.5k
LFP SIMD : ~ 1.7k
Binary64 FPU: ~ 4.5k (FADD/FMUL units)
Shift-Add : ~ 1.0k (64-bit MUL/DIV, FDIV)
Rest : ~ 10.8k

This is with the internal store forwarding disabled in the L1 D$, which
increases LUT cost of the L1 D$ from 5k to 11k (but saves 1 cycle if a
store is directly followed by a load from the same cache line).

The LDTEX extension seems to cost around 2k, but is fairly relevant to
the 'GPU' use-case.

Disabling XGPR has very little effect on cost; also, having a 1-wide
core as a GPU would have a significant adverse effect on rasterizer
performance. Fast Int32 multiply and similar are also kinda important as
well, ...

I had also disabled the recent experimental LoadOp extension and similar
as well for these tests.

Also had to reduce L1 cache sizes down to 16K, otherwise the two cores
also blew out the Block RAM budget...

Still a bit over-budget though...

On 10/08/22 16:32, BGB wrote:

> I had been recently experimenting with a stripped down "GPU Profile" for
> the BJX2 core, which ended up being primarily using "parameter" settings
> for disabling some parts of the core (idea being to have one core remain
> "full featured", and the other is more stripped down).

Yep, Big & Little cores, it's the wave of the future! (or the present)

>
> I have still yet to shave down LUT usage enough to fit two cores on the
> FPGA though.

Kinda why I suggested a minimal 16(18?)bit core might be a good idea,
once you've got a LUT count for the most minimal but functional core,
you'd be in a better position to decide how many cores you could expect
to fit on your FPGA.

> Getting rid of a Z-Buffer would be a problem for OpenGL, since some
> parts of the API are built around the assumption of a Z-Buffer existing
> (as opposed to Painter's Algorithm or similar).

Yeah true, but I'm not sure what your goal is here, higher frame rates
in Quake through any means fair or foul?
Or you're just using Quake to illustrate the performance of your
standards compliant OpenGL renderer?

> I am mixing sound at 16 kHz, one can get a slight speed increase by
> mixing at 8 kHz, but it sounds bad enough that it really worth it.
>
> Part of the audio mixing overhead is due to Quake playing near constant
> looping ambient sound effects (albeit usually at a fairly low volume),
> but this "loses something".

Well, looking at this from the Commodore Amiga way of doing things,
maybe a simple co-processor here and there to handle the simple but
real-time constrained parts of the game so the main core can just 'set
and forget' things like this - is a worthwhile investment of some number
of LUTS? YMMV

> I had considered getting a better board, but then sat on the fence some,
> and now they are all sold out.
>
>
>> And probably the worst time in recent memory to be shopping for new
>> electronics boards anyway, it's truly the end times to be sure, for
>> realzies this time!!!
>>
>
> Yeah, pretty much all the FPGA boards are out of stock, and those that
> remain are in dwindling numbers.
>
> People can fight for the last remaining Nexys A7 and Arty boards, ...

Yep, waiting out the current mess, and seeing what turns up when the
dust settles seems like a good plan.

I wonder though, there are startups designing and selling cheap
bare-bones FPGA boards for makers and the like, so I would have thought
someone's selling a basic-everything you need for a stand-alone
soft-core computer for a reasonable price.

After all it seems like there is no shortage of comp.sci students and
hobbyists who would love such a thing.

> I have doubts that a 16-bitter could do much in terms of running an
> OpenGL backend. The task is mostly shoveling data around with some
> amount of math, and 64-bits is better for the "shoveling a lot of data
> around in relatively few clock cycles".
>
> Partly this was also based on realizing that making the core "bigger"
> has generally been cheaper than having more cores.
>
> So, from past experience, the FPGA I am using could fit roughly:
>   8x 16 bit cores (16 or 16-pair-32);
>   4x 32-bit cores (roughly SH2 or RV32I level);
>   2x 64 bit cores (plain 64-bit);
>   1x "big" 64 bit core (with 64 and 64-pair-128-bit operations).
>
> There is a "modest" cost difference between 1, 2, and 3 wide. Along with
> a modest cost difference due to wider or narrower registers
>
> But, going from a 1-wide RISC to 3-wide VLIW costs less than going from
> 1 core to 2 cores.
>
> Though, it is non-linear, going single core to dual core costs less than
> trying to go from 3-wide to 6-wide.

Ah okay, if you've been down every road before and know the tradeoffs,
then ignore me I'm just throwing ideas 'out there'.

Still, it's an interesting question I think, what size and number of
cores delivers the most performance per unit resource? - two strong
oxen, or a thousand chickens?

Seymour Cray seems to be on the losing end of this argument at this
point in time I think, now that even PCs and laptops can be bought with
a dozen or more cores.

And then on the other end of the scale there is the wafer scale Cerberus
with '850,000 AI-optimized cores'

The chickens are winning big time I think, at least for machine learning
applications.

But how long until the compiler techniques Cerberus invented trickle
down to open source software and anyone with a few hundred cores can
throw them via a compiler at whatever problem they might have?

Seems like you're in a good position with your FPGA cores to experiment
your way to an answer for the hardware question at least.

>> At this point I feel I should start calling your design 'Sybil Core',
>> (don't worry it's a 'dad' joke)
>>
>
> Had to look this up, I am guessing this is a movie reference?...
> Had never seen that movie.

Not surprised, it was before our time I think..

It was the name of a patient and books and films about the first widely
publicized person with multiple personality disorder, now largely
debunked, but still good for the odd joke or two. ;-)

> Half-Life 2 also had ragdolls, but an entity would only be either be
> either fully under the control of skeletal animation, or fully ragdoll.
>
> IIRC, it also had cases where different sequences could run at the same
> time, say with one animation loop controlling the upper torso and
> another the legs, etc.

In Tombraider the shooting mechanic locks Lara's guns and arms onto a
target regardless of what the rest of her body animation is doing, so
the independent bone animation system is a big win for that sort of thing.

> Didn't really have a feature, say, where some bones would be keyframe
> animated and some ragdoll, or maybe have "inertial" bones with elastic
> effects, ... Then again, remembering some of the scenes in Portal and
> Portal 2, I suspect it is possible they may have added something like
> this. Not really looked into it though.

Pretty standard for a game engine these days AFAIK.

<snip>

> Decided not to try to explain the Mega-Man series timeline...

Okay then.

Last game I played was the simple click and point adventure game 'I have
no mouth, but I need to scream' based on Harlan Ellison's short story of
the same name, I'd recommend it for the voice-over work by Mr Ellison
himself for the evil AI in the game (funny and twistedly evil).

It's kinda spooky on two levels, 1) the story's world building itself
and the situation it presents.

And 2) the kicker is that it has Russia and China and the US at war with
each other, they each made an AI machine to control their war efforts,
the machines secretly hookup and decide to kill off almost the entire
human race.

Except for the last part, does it remind you of anything going on in the
real world perhaps?

Scary stuff, I hate it when life imitates art, especially when the
artist was trying to deliver a dire warning, not an instruction manual!

> I guess the bigger issue with making an arbitrarily large world within
> Quake-style map technology, would be having to be the person to build
> such a world in a map editor...

Yeep, par for the course I'm afraid, although writing a 3D-world
translator from something pre-existing might be an option to.

>
> My second and 3rd engines had mostly fallen back to 2D sprite graphics
> (3D modeling and animation is a pain).

And many Indie game devs would seem to agree with you, going by the
latest game being spammed on Youtube 'The Cult Of The Lamb', looks very
2D sprites in a virtual 3D setup, makes sense if you can paint and draw
I guess.

On 8/12/2022 8:47 PM, Andy wrote:
> On 10/08/22 16:32, BGB wrote:
>
>
>> I had been recently experimenting with a stripped down "GPU Profile"
>> for the BJX2 core, which ended up being primarily using "parameter"
>> settings for disabling some parts of the core (idea being to have one
>> core remain "full featured", and the other is more stripped down).
>
> Yep, Big & Little cores, it's the wave of the future! (or the present)
>
>
>>
>> I have still yet to shave down LUT usage enough to fit two cores on
>> the FPGA though.
>
> Kinda why I suggested a minimal 16(18?)bit core might be a good idea,
> once you've got a LUT count for the most minimal but functional core,
> you'd be in a better position to decide how many cores you could expect
> to fit on your FPGA.
>

I managed to get a lot closer, but is it worth it?...

I have managed to shave things enough that the main core went from 82%
of the FPGA's LUT budget to 68%, though in the process some bugs have
appeared that I am still trying to sort out (such as the low-precision
SIMD unit seemingly not working reliably).

But, a 16-bit GPU wouldn't be sufficient:
The data it needs to deal with is too big for this.

Generally the rasterizer and blending operations involve shoving around
64 bits at a time. While I could potentially shave RGBA vectors down to
32 bits (using packed-byte rather than packed-word), this leaves *no*
bits for fractional steps.

Say, for drawing a span of length N, one needs around ceil(log2(N)+1)
bits below the effective ULP. Less than this, and the interpolation is
prone to break.

If say, the max span length is around 64 pixels, then a 16-bit
intermediate value is sufficient for stepping the RGBA vector (treating
each element as 8.8 fixed point).

And, 4x 16 = 64 bits.

Longer spans don't really happen as by this point the primitive will
have been tessellated into smaller pieces.

If one did the math with discrete 16-bit elements, this would be slow
(and one would also need around 128 or 256 registers to deal with all
the working state inside the raster loop).

Generally, the smallest cores I was able to make were 16/32 cores, which
generally weighed in at around 5k LUT.

These were using very simplistic L1 caches, namely a single cache line,
with no misaligned accesses.

Allowing for a RAM interface (but little else), I could maybe fit 10 of
them in the FPGA I am using.

>
>
>> Getting rid of a Z-Buffer would be a problem for OpenGL, since some
>> parts of the API are built around the assumption of a Z-Buffer
>> existing (as opposed to Painter's Algorithm or similar).
>
> Yeah true, but I'm not sure what your goal is here, higher frame rates
> in Quake through any means fair or foul?
> Or you're just using Quake to illustrate the performance of your
> standards compliant OpenGL renderer?
>

It doesn't need to be standards compliant, but I do want typical code to
work.

Something which fundamentally breaks the way the API works, or the
ability to use glReadPixels, is probably no-go.

>
>
>> I am mixing sound at 16 kHz, one can get a slight speed increase by
>> mixing at 8 kHz, but it sounds bad enough that it really worth it.
>>
>> Part of the audio mixing overhead is due to Quake playing near
>> constant looping ambient sound effects (albeit usually at a fairly low
>> volume), but this "loses something".
>
> Well, looking at this from the Commodore Amiga way of doing things,
> maybe a simple co-processor here and there to handle the simple but
> real-time constrained parts of the game so the main core can just 'set
> and forget' things like this - is a worthwhile investment of some number
> of LUTS? YMMV
>

Possibly.

My PCM audio output device is a smallish MMIO mapped buffer which plays
in a loop with a few control register fields (such as selecting the
sample rate and format and mono-vs-stereo and similar).

If you leave something in the buffer and then stop updating it, it does
the "jackhammer" artifact.

I also have an FM module, which has several programmable FM channels.
Its operation is that it will basically step through the channels
calculating and adding their current output value into an accumulator
and updating the step, and when it gets to the end, it resets back to
the start and resets the accumulator, with the final accumulator value
driving a PCM output signal.

Sadly, sounds pretty bad if compared with an OPL2/3 chipset.
Would likely need to more accurately mimic the parameters and behavior
of the OPL2.

While a programmable mixer is possible, the Block-RAM requirements to
make this usable are harder, and giving it a ringbus interface to allow
it to use a DRAM backed buffer would be "kinda expensive".

>
>> I had considered getting a better board, but then sat on the fence
>> some, and now they are all sold out.
>>
>>
>>> And probably the worst time in recent memory to be shopping for new
>>> electronics boards anyway, it's truly the end times to be sure, for
>>> realzies this time!!!
>>>
>>
>> Yeah, pretty much all the FPGA boards are out of stock, and those that
>> remain are in dwindling numbers.
>>
>> People can fight for the last remaining Nexys A7 and Arty boards, ...
>
> Yep, waiting out the current mess, and seeing what turns up when the
> dust settles seems like a good plan.
>
> I wonder though, there are startups designing and selling cheap
> bare-bones FPGA boards for makers and the like, so I would have thought
> someone's selling a basic-everything you need for a stand-alone
> soft-core computer for a reasonable price.
>
> After all it seems like there is no shortage of comp.sci students and
> hobbyists who would love such a thing.
>

There are the Numato Labs boards, but most were more expensive for less
capability when Digilent options.

Similar with ALINX, where for a similar FPGA the board would be around
twice the cost as from Digilent, and they seem to be (mostly) focusing
on FPGA boards which go into PCIe slots, rather than standalone boards
with an SDcard and VGA port and similar.

A lot of the hobbyist-built boards are using ICE40 parts, where a
generally a 16-bit CPU is about all that is going to fit on the FPGA.

>
>
>> I have doubts that a 16-bitter could do much in terms of running an
>> OpenGL backend. The task is mostly shoveling data around with some
>> amount of math, and 64-bits is better for the "shoveling a lot of data
>> around in relatively few clock cycles".
>>
>> Partly this was also based on realizing that making the core "bigger"
>> has generally been cheaper than having more cores.
>>
>> So, from past experience, the FPGA I am using could fit roughly:
>>    8x 16 bit cores (16 or 16-pair-32);
>>    4x 32-bit cores (roughly SH2 or RV32I level);
>>    2x 64 bit cores (plain 64-bit);
>>    1x "big" 64 bit core (with 64 and 64-pair-128-bit operations).
>>
>> There is a "modest" cost difference between 1, 2, and 3 wide. Along
>> with a modest cost difference due to wider or narrower registers
>>
>> But, going from a 1-wide RISC to 3-wide VLIW costs less than going
>> from 1 core to 2 cores.
>>
>> Though, it is non-linear, going single core to dual core costs less
>> than trying to go from 3-wide to 6-wide.
>
> Ah okay, if you've been down every road before and know the tradeoffs,
> then ignore me I'm just throwing ideas 'out there'.
>

> Still, it's an interesting question I think, what size and number of
> cores delivers the most performance per unit resource? - two strong
> oxen, or a thousand chickens?
>

The problem is if your options are one or two "strong cores", or 4 or 8
"pathetically weak" cores, the strong cores generally win out here.

The cost of an L1 cache varies considerably:
Single line vs cache-line array (1);
Aligned-only vs allowing unaligned access (2);
...

1: Single-cache-line allows getting rid of a whole bunch of stuff.
However, now the vast majority of memory accesses result in an L1 miss.

Works "sorta OK" for fixed-length 16-bit instructions with an I$
(roughly 8 cycles between each I$ miss).

2: Aligned only can effectively halve the internal "width" of the cache,
since now nothing may cross a cache line boundary.

Register size and pipeline width only have a "modest" effect on CPU core
cost.

Some of my 5k LUT cores were basically using this design.

Spent part of the day studying the Nyuzi core by Jeff Bush. It synthesizes to
about 88,000 LUTs in an Artix-7 xc7a200 part. But that is for 16 lanes. It could
probably be reduced in size by reducing the number of lanes. I also found this
article about using a rasterizer in addition to a GPU like core.

http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf
nyuziraster.pdf (binghamton.edu)

Sounds like a rasterizer may be a good addition have in place.
I read through NVIDEA GPU docs a while ago. Also worth a read.

On 8/15/2022 12:21 AM, robf...@gmail.com wrote:
> Spent part of the day studying the Nyuzi core by Jeff Bush. It synthesizes to
> about 88,000 LUTs in an Artix-7 xc7a200 part. But that is for 16 lanes. It could
> probably be reduced in size by reducing the number of lanes. I also found this
> article about using a rasterizer in addition to a GPU like core.
>

If reduced to 1/8 or 1/16 that size, it might be OK.

> http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf
> nyuziraster.pdf (binghamton.edu)
>
> Sounds like a rasterizer may be a good addition have in place.
> I read through NVIDEA GPU docs a while ago. Also worth a read.

Maybe.

Quick skim, seems like it works very differently from the BJX2 core...

My experiment with the GPU profile for a tweaked BJX2 core was that I
still couldn't get stuff small enough to fit it alongside the main core.

But, can't go much smaller as then I am not likely to have any real
advantage over the existing software rasterizer (and, even if I disable
a bunch of features; it doesn't save enough LUTs to make a significant
difference).

My biggest LUT savings was from modifying the workings of my interrupt
mechanism and similar.

I had also gained a little bit of performance from my OpenGL rasterizer
(along with a reduction in distortion), by addling dedicated code for
rasterizing quads.

Drawing quads is more complicated, however, one needs to draw fewer of
them, so it works out as a net win. Also, they seem to distort slightly
less due to affine warping, so they can be a little bigger while still
looking OK.

Also made some minor tweaks to how vertex projection is handled during
dynamic tessellation (to reduce the number of vertices being projected).

And, the code for how to tessellate now operates in world-space
coordinates rather than screen space coordinates (has fewer artifacts).

I guess a question is if there is some way to get things smaller without
compromising performance.

Something I can fit in 10k to 15k LUTs would be nice. Ideally, should
still be fully programmable (sufficient to run both C and GLSL).

Would be nice to have fully pipelined FPU. This is at least sorta doable
at Binary32 precision without needing an unreasonably long pipeline

This is sorta what the Low-Precision FPU aims to do in myself, except
that it is apparently "not working" for some reason at the moment (while
trying to run GLQuake on my main core).

Looking at SIMD unit output is hard to figure out, I have been gathering
large chunks of output like:
(A): Rs=4394000043940000 Rt=000000003bcccccd Rn=000000003feccc00 Ixt=067
(B): Rs=41c0000041c00000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
(A): Rs=41c0000041c00000 Rt=bc23d70a00000000 Rn=be75c28000000000 Ixt=067
(B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
(A): Rs=000000003feccc00 Rt=be75c28000000000 Rn=be75c2803feccc00 Ixt=065
(B): Rs=0000000000000000 Rt=00000000b727c61a Rn=0000000000000000 Ixt=067
(A): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
(B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
(A): Rs=be75c2803feccc00 Rt=0000000000000000 Rn=be75c2803feccc00 Ixt=065
(B): Rs=3f8000003f800000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=067
(A): Rs=3f8000003f800000 Rt=3f800000bf800000 Rn=3f800000bf800000 Ixt=067
(B): Rs=0000000000000000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=065
(A): Rs=be75c2803feccc00 Rt=3f800000bf800000 Rn=3f428f003f599700 Ixt=065
(B): Rs=3f8000003f7ff401 Rt=3f80000046dffe00 Rn=3f80000046dff380 Ixt=067
(A): Rs=3f7ff4013f7ff401 Rt=42c8000043200000 Rn=42c7f680431ff880 Ixt=067
(B): Rs=3f80000000000000 Rt=3f80000046dff380 Rn=3f80000000000000 Ixt=067
(A): Rs=3f428f003f599700 Rt=42c7f680431ff880 Rn=4297f8004307f800 Ixt=067
(B): Rs=3f80000000000000 Rt=0000000000000000 Rn=3f80000000000000 Ixt=065
(A): Rs=4297f8004307f800 Rt=42c8000043200000 Rn=432ffc004393fc00 Ixt=065

Which may, theoretically, contain a hint as to why it isn't working
(067=Packed FMUL, 065=Packed FADD). The (A/B) indicates which lane is
printing (and the general lack of "random garbage" seems to imply timing
is OK).

But, deciphering floating point numbers in hexadecimal form is a pain
(there seems to be a fault with FADD here, but basic tests pass in the
unit tests and in a few sanity-check cases).

I have spent several days thus far trying to figure out what is going on
here...

I guess one thing I could try would be to (more exactly) mimic the
behavior of the low-precision SIMD operators in the emulator, and see if
the bug appears in the emulator... (It doesn't tend to produce exactly
the same results as one would get by truncating the Binary32 values).

....

On Monday, August 15, 2022 at 2:33:34 AM UTC-4, BGB wrote:
> On 8/15/2022 12:21 AM, robf...@gmail.com wrote:
> > Spent part of the day studying the Nyuzi core by Jeff Bush. It synthesizes to
> > about 88,000 LUTs in an Artix-7 xc7a200 part. But that is for 16 lanes. It could
> > probably be reduced in size by reducing the number of lanes. I also found this
> > article about using a rasterizer in addition to a GPU like core.
> >
> If reduced to 1/8 or 1/16 that size, it might be OK.
> > http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf
> > nyuziraster.pdf (binghamton.edu)

> > Sounds like a rasterizer may be a good addition have in place.
> > I read through NVIDEA GPU docs a while ago. Also worth a read.
> Maybe.
>
>
> Quick skim, seems like it works very differently from the BJX2 core...
>
>
>
>
> My experiment with the GPU profile for a tweaked BJX2 core was that I
> still couldn't get stuff small enough to fit it alongside the main core.
>
> But, can't go much smaller as then I am not likely to have any real
> advantage over the existing software rasterizer (and, even if I disable
> a bunch of features; it doesn't save enough LUTs to make a significant
> difference).
>
> My biggest LUT savings was from modifying the workings of my interrupt
> mechanism and similar.
>
>
> I had also gained a little bit of performance from my OpenGL rasterizer
> (along with a reduction in distortion), by addling dedicated code for
> rasterizing quads.
>
> Drawing quads is more complicated, however, one needs to draw fewer of
> them, so it works out as a net win. Also, they seem to distort slightly
> less due to affine warping, so they can be a little bigger while still
> looking OK.
>
> Also made some minor tweaks to how vertex projection is handled during
> dynamic tessellation (to reduce the number of vertices being projected).
>
> And, the code for how to tessellate now operates in world-space
> coordinates rather than screen space coordinates (has fewer artifacts).
>
>
>
> I guess a question is if there is some way to get things smaller without
> compromising performance.
>
> Something I can fit in 10k to 15k LUTs would be nice. Ideally, should
> still be fully programmable (sufficient to run both C and GLSL).
>
>
> Would be nice to have fully pipelined FPU. This is at least sorta doable
> at Binary32 precision without needing an unreasonably long pipeline
>
>
>
> This is sorta what the Low-Precision FPU aims to do in myself, except
> that it is apparently "not working" for some reason at the moment (while
> trying to run GLQuake on my main core).
>
> Looking at SIMD unit output is hard to figure out, I have been gathering
> large chunks of output like:
> (A): Rs=4394000043940000 Rt=000000003bcccccd Rn=000000003feccc00 Ixt=067
> (B): Rs=41c0000041c00000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
> (A): Rs=41c0000041c00000 Rt=bc23d70a00000000 Rn=be75c28000000000 Ixt=067
> (B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
> (A): Rs=000000003feccc00 Rt=be75c28000000000 Rn=be75c2803feccc00 Ixt=065
> (B): Rs=0000000000000000 Rt=00000000b727c61a Rn=0000000000000000 Ixt=067
> (A): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
> (B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
> (A): Rs=be75c2803feccc00 Rt=0000000000000000 Rn=be75c2803feccc00 Ixt=065
> (B): Rs=3f8000003f800000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=067
> (A): Rs=3f8000003f800000 Rt=3f800000bf800000 Rn=3f800000bf800000 Ixt=067
> (B): Rs=0000000000000000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=065
> (A): Rs=be75c2803feccc00 Rt=3f800000bf800000 Rn=3f428f003f599700 Ixt=065
> (B): Rs=3f8000003f7ff401 Rt=3f80000046dffe00 Rn=3f80000046dff380 Ixt=067
> (A): Rs=3f7ff4013f7ff401 Rt=42c8000043200000 Rn=42c7f680431ff880 Ixt=067
> (B): Rs=3f80000000000000 Rt=3f80000046dff380 Rn=3f80000000000000 Ixt=067
> (A): Rs=3f428f003f599700 Rt=42c7f680431ff880 Rn=4297f8004307f800 Ixt=067
> (B): Rs=3f80000000000000 Rt=0000000000000000 Rn=3f80000000000000 Ixt=065
> (A): Rs=4297f8004307f800 Rt=42c8000043200000 Rn=432ffc004393fc00 Ixt=065
>
> Which may, theoretically, contain a hint as to why it isn't working
> (067=Packed FMUL, 065=Packed FADD). The (A/B) indicates which lane is
> printing (and the general lack of "random garbage" seems to imply timing
> is OK).
>
> But, deciphering floating point numbers in hexadecimal form is a pain
> (there seems to be a fault with FADD here, but basic tests pass in the
> unit tests and in a few sanity-check cases).
>
> I have spent several days thus far trying to figure out what is going on
> here...
>
>
> I guess one thing I could try would be to (more exactly) mimic the
> behavior of the low-precision SIMD operators in the emulator, and see if
> the bug appears in the emulator... (It doesn't tend to produce exactly
> the same results as one would get by truncating the Binary32 values).
>
> ...
I would run tests against random test cases and see what falls out. For
my decimal float multiply I found one in 5,000 random cases did not work.
It turned out to be an issue with carries in the Karatsuba multiplier.
And, I did not run enough test cases the first time through.

On 8/15/2022 3:05 PM, robf...@gmail.com wrote:
> On Monday, August 15, 2022 at 2:33:34 AM UTC-4, BGB wrote:
>> On 8/15/2022 12:21 AM, robf...@gmail.com wrote:
>>> Spent part of the day studying the Nyuzi core by Jeff Bush. It synthesizes to
>>> about 88,000 LUTs in an Artix-7 xc7a200 part. But that is for 16 lanes. It could
>>> probably be reduced in size by reducing the number of lanes. I also found this
>>> article about using a rasterizer in addition to a GPU like core.
>>>
>> If reduced to 1/8 or 1/16 that size, it might be OK.
>>> http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf
>>> nyuziraster.pdf (binghamton.edu)
>
>>> Sounds like a rasterizer may be a good addition have in place.
>>> I read through NVIDEA GPU docs a while ago. Also worth a read.
>> Maybe.
>>
>>
>> Quick skim, seems like it works very differently from the BJX2 core...
>>
>>
>>
>>
>> My experiment with the GPU profile for a tweaked BJX2 core was that I
>> still couldn't get stuff small enough to fit it alongside the main core.
>>
>> But, can't go much smaller as then I am not likely to have any real
>> advantage over the existing software rasterizer (and, even if I disable
>> a bunch of features; it doesn't save enough LUTs to make a significant
>> difference).
>>
>> My biggest LUT savings was from modifying the workings of my interrupt
>> mechanism and similar.
>>
>>
>> I had also gained a little bit of performance from my OpenGL rasterizer
>> (along with a reduction in distortion), by addling dedicated code for
>> rasterizing quads.
>>
>> Drawing quads is more complicated, however, one needs to draw fewer of
>> them, so it works out as a net win. Also, they seem to distort slightly
>> less due to affine warping, so they can be a little bigger while still
>> looking OK.
>>
>> Also made some minor tweaks to how vertex projection is handled during
>> dynamic tessellation (to reduce the number of vertices being projected).
>>
>> And, the code for how to tessellate now operates in world-space
>> coordinates rather than screen space coordinates (has fewer artifacts).
>>
>>
>>
>> I guess a question is if there is some way to get things smaller without
>> compromising performance.
>>
>> Something I can fit in 10k to 15k LUTs would be nice. Ideally, should
>> still be fully programmable (sufficient to run both C and GLSL).
>>
>>
>> Would be nice to have fully pipelined FPU. This is at least sorta doable
>> at Binary32 precision without needing an unreasonably long pipeline
>>
>>
>>
>> This is sorta what the Low-Precision FPU aims to do in myself, except
>> that it is apparently "not working" for some reason at the moment (while
>> trying to run GLQuake on my main core).
>>
>> Looking at SIMD unit output is hard to figure out, I have been gathering
>> large chunks of output like:
>> (A): Rs=4394000043940000 Rt=000000003bcccccd Rn=000000003feccc00 Ixt=067
>> (B): Rs=41c0000041c00000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
>> (A): Rs=41c0000041c00000 Rt=bc23d70a00000000 Rn=be75c28000000000 Ixt=067
>> (B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
>> (A): Rs=000000003feccc00 Rt=be75c28000000000 Rn=be75c2803feccc00 Ixt=065
>> (B): Rs=0000000000000000 Rt=00000000b727c61a Rn=0000000000000000 Ixt=067
>> (A): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=067
>> (B): Rs=0000000000000000 Rt=0000000000000000 Rn=0000000000000000 Ixt=065
>> (A): Rs=be75c2803feccc00 Rt=0000000000000000 Rn=be75c2803feccc00 Ixt=065
>> (B): Rs=3f8000003f800000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=067
>> (A): Rs=3f8000003f800000 Rt=3f800000bf800000 Rn=3f800000bf800000 Ixt=067
>> (B): Rs=0000000000000000 Rt=3f80000000000000 Rn=3f80000000000000 Ixt=065
>> (A): Rs=be75c2803feccc00 Rt=3f800000bf800000 Rn=3f428f003f599700 Ixt=065
>> (B): Rs=3f8000003f7ff401 Rt=3f80000046dffe00 Rn=3f80000046dff380 Ixt=067
>> (A): Rs=3f7ff4013f7ff401 Rt=42c8000043200000 Rn=42c7f680431ff880 Ixt=067
>> (B): Rs=3f80000000000000 Rt=3f80000046dff380 Rn=3f80000000000000 Ixt=067
>> (A): Rs=3f428f003f599700 Rt=42c7f680431ff880 Rn=4297f8004307f800 Ixt=067
>> (B): Rs=3f80000000000000 Rt=0000000000000000 Rn=3f80000000000000 Ixt=065
>> (A): Rs=4297f8004307f800 Rt=42c8000043200000 Rn=432ffc004393fc00 Ixt=065
>>
>> Which may, theoretically, contain a hint as to why it isn't working
>> (067=Packed FMUL, 065=Packed FADD). The (A/B) indicates which lane is
>> printing (and the general lack of "random garbage" seems to imply timing
>> is OK).
>>
>> But, deciphering floating point numbers in hexadecimal form is a pain
>> (there seems to be a fault with FADD here, but basic tests pass in the
>> unit tests and in a few sanity-check cases).
>>
>> I have spent several days thus far trying to figure out what is going on
>> here...
>>
>>
>> I guess one thing I could try would be to (more exactly) mimic the
>> behavior of the low-precision SIMD operators in the emulator, and see if
>> the bug appears in the emulator... (It doesn't tend to produce exactly
>> the same results as one would get by truncating the Binary32 values).
>>
>> ...
> I would run tests against random test cases and see what falls out. For
> my decimal float multiply I found one in 5,000 random cases did not work.
> It turned out to be an issue with carries in the Karatsuba multiplier.
> And, I did not run enough test cases the first time through.

Turns out it wasn't actually the math that was failing here, but rather
another edge case related to a previously observed (and not fully
resolved) issue:
Previously, if a branch directly fallowed a memory operation, it would
cause the operation to fail;
Turns out, this also applies not just to memory loads, but seemingly any
other 3-stage operation (apparently includes Low-precision FPU and also
Integer Multiply and similar).

The workaround was apparently to extend the interlock-checks for this
case to also include checking for the low-precision FPU and also for
integer multiply and similar...

Also possible would be to go on a bug hunt and try to figure out what is
actually going on here (a branch should not effect the EX3 stage), but
when a predicted branch initiates it will flush whatever was in EX1 (the
instruction following the branch op).

Also doesn't appear to effect operations where EX3 merely forwards the
result from a previous stage (with the result value having been
generated in EX2 or EX1), but more seems to effect operations where the
result arrives in EX3 (in these cases, the next stage is for the value
to be written back to the register file).

There was a special case check here, which adds an interlock stall,
mostly because previous attempts to figure out the cause of this issue
were unsuccessful.

....

On Tuesday, August 16, 2022 at 2:05:15 AM UTC-5, BGB wrote:
> On 8/15/2022 3:05 PM, robf...@gmail.com wrote:
> > On Monday, August 15, 2022 at 2:33:34 AM UTC-4, BGB wrote:

> > I would run tests against random test cases and see what falls out. For
> > my decimal float multiply I found one in 5,000 random cases did not work.
> > It turned out to be an issue with carries in the Karatsuba multiplier.
> > And, I did not run enough test cases the first time through.
> Turns out it wasn't actually the math that was failing here, but rather
> another edge case related to a previously observed (and not fully
> resolved) issue:
> Previously, if a branch directly fallowed a memory operation, it would
> cause the operation to fail;
> Turns out, this also applies not just to memory loads, but seemingly any
> other 3-stage operation (apparently includes Low-precision FPU and also
> Integer Multiply and similar).
<
Why not just check the pipeline flip-flops to see if a register you need
in the issuing instruction is still in the pipeline. {This is how MIPS 2000
performed forwarding}
>
> The workaround was apparently to extend the interlock-checks for this
> case to also include checking for the low-precision FPU and also for
> integer multiply and similar...
>
If the operand registers are interlocked, why do you need more ?
>

On 8/16/2022 11:04 AM, MitchAlsup wrote:
> On Tuesday, August 16, 2022 at 2:05:15 AM UTC-5, BGB wrote:
>> On 8/15/2022 3:05 PM, robf...@gmail.com wrote:
>>> On Monday, August 15, 2022 at 2:33:34 AM UTC-4, BGB wrote:
>
>>> I would run tests against random test cases and see what falls out. For
>>> my decimal float multiply I found one in 5,000 random cases did not work.
>>> It turned out to be an issue with carries in the Karatsuba multiplier.
>>> And, I did not run enough test cases the first time through.
>> Turns out it wasn't actually the math that was failing here, but rather
>> another edge case related to a previously observed (and not fully
>> resolved) issue:
>> Previously, if a branch directly fallowed a memory operation, it would
>> cause the operation to fail;
>> Turns out, this also applies not just to memory loads, but seemingly any
>> other 3-stage operation (apparently includes Low-precision FPU and also
>> Integer Multiply and similar).
> <
> Why not just check the pipeline flip-flops to see if a register you need
> in the issuing instruction is still in the pipeline. {This is how MIPS 2000
> performed forwarding}

This doesn't seem to be a forwarding issue.

But, yeah, there is "check register is in the pipeline" logic.
Register is in pipeline, Held=0:
We can forward the result from this register (back to ID2).
Register is in pipeline, Held=1:
Result doesn't exist yet (need to interlock).

The value-forwarding part is kinda expensive though.
Effectively needs to route 9 possible stage outputs back to ID2;
Each of which may be in turn routed to 6 different register ports.

Could save some LUTs by using interlocks rather than forwarding, but
this would cause pretty much every instruction to now have a 3 cycle
latency.

I guess it could be possible to forward from the stage inputs rather
than the outputs, which could potentially be cheaper and a little better
for timing. For the pipeline, values are forwarded along using
flip-flops (presumably there is no other option here?...).

But, would effectively add 1-cycle of latency to everything:
EXTU.B R4, R6
ADD R6, R7

So, EX1 for EXTU.B would happen at ID2 for ADD, but could not forward in
this case (would need to treat this as an interlock). Effectively,
raising the latency from 1 cycle to 2 cycles (and causing an interlock
stall in the above example).

But, "everything is now 2 or 3" cycles wouldn't be much better than
"everything is now 3 cycles".

In the scenario that came up recently, the PADDX.FA instruction would
have already left the pipeline by the time its result was being used.

PADDX.FA R2, R5, R2
RTS
BREAK

EX1a EX2a EX3a WBa~ **** PADDX.FA
---- EX1b EX2b EX3b **** RTS (Decoded as "JMP LR")
---- ---- EX1c EX2c EX3c BREAK (Flushed)
---- ---- ---- EX1~ EX2~ (*2)
---- ^^^^ ---- (Branch Address Calculated)
**** **** ^^^^ (Branch Happens Here)

So, when the branch takes place, the Fetch PC is overridden.
EX1c is Flushed (forced to become NOP), otherwise it would behave like a
delay slot.

The PC override (and pipeline flush) is skipped if the branch was
handled by the branch predictor (this appears to be the scenario where
the bug in question is happening).

However, if EX3a is doing something (receiving a result from another
FU), it seems to get stomped, for some as-of-yet undetermined reason.

*2: If the branch was predicted, this is the first instruction from the
new PC. If a full branch happened, this stage (and the next several that
follow) are flushed.

In this scenario, the first instruction following the RTS would be a
"MOVX R2, Rn" or similar (accessing the register from the WB stage).

Previously, I had thought the issue was somehow effecting the L1 D$, but
based on the observations with PADDX.FA, it appears to be somehow
effecting EX3s in some other way.

If it were disrupting the EX3->WB interface (or incorrectly flushing
EX3), I would expect it to disrupt *any* instruction preceding the
branch. Likely, likely disruption of WB->ID2 path would likely be "very
obvious", ...

I guess, it could be possible to try to look into whether stalls from
possible L1 I$ misses are quietly causing WB to fail or something, since
a stall from a branch-related L1 I$ miss would happen on this clock cycle.

It doesn't seem to be on the input side to EX3 (from the FUs), as the
debug prints were not showing either garbage or the debug values (for
testing, had rigged up a mechanism so that the LFP-FPU will output
0xAAAAAAAAAAAAAAAA or 0x5555555555555555 if it is misaligned; everything
looked fine from debug prints of the values arriving at EX3).

But, as noted, this is a mystery that I have not figured out as of yet.
But, I guess now I know that it is something to do with EX3, rather than
something related to the L1 D$.

>>
>> The workaround was apparently to extend the interlock-checks for this
>> case to also include checking for the low-precision FPU and also for
>> integer multiply and similar...
>>
> If the operand registers are interlocked, why do you need more ?

In this case, "make it work" hacks...

In theory, an interlock for "ID2 contains a branch and EX1 contains a
Load/etc" should be unnecessary.

But, it exists mostly because previously I ran into a bug and this was
the only way I could figure out at the time to "make it work".

Doesn't help that apparently it extends to other cases beyond loads.

In my case, my boot ROM contains some sanity checks for branches (some
"branch mazes" and mixtures of branches and some other types of
instructions), mostly to detect if the original form of the bug
reappears (along with a few other cases, like a lot of BREAK
instructions for if the branch suddenly decides to gain a delay slot, or
if the target PC gets misaligned somehow, ...).

This is along with a bunch of ALU sanity tests, memory Load/Store sanity
checks, and for various other instructions. Does only minimal checks for
WEX, and hardly anything for SIMD, mostly because there is only so much
space in the Boot ROM.

The 'OS'/Shell also runs some additional sanity checks.

Sadly, my ISA is a little out of scope of what can be adequately
addressed with sanity checks (would likely need impractical levels of
sanity checking code).

On Sunday, July 24, 2022 at 4:28:47 AM UTC-6, luke.l...@gmail.com wrote:

> 3) RVV or any other Cray-Style Vector ISA requiring strict compliance
> with IEEE754 FP accuracy will punish you with a 400% power/area
> penalty compared to modern 3D-optimised GPUs which, as explicitly
> spelled out and allowed in the Vulkan(tm) Spec by the Khronos
> Group, are permitted significant accuracy reductions. Mitch
> will (or will have already) filled you in on that.

Well, if your purpose is building a device that is helpful to scientists
wishing to perform large-scale computations on FP64 numbers, you'll
just have to pay that penalty. After paying that penalty, though, something
based on a GPU architecture instead of that of a conventional non-vector
CPU is *still* vastly more powerful.

And we have the NEC Aurora TSUBASA as an example of a Cray-style
vector ISA. At a significantly higher cost, it was capable of about half
of the FP64 FLOPS that a video card with high FP64 capabilities made
on the same technology could provide. But because this architecture is
more flexible, one could use it for a higher proportion of the floating-point
calculations in typical scientific programs.

That is a tradeoff that might be well worth it.

John Savard

On Sunday, July 24, 2022 at 4:41:19 PM UTC-6, luke.l...@gmail.com wrote:

> AVX-512 *shudder*

And here I was wondering why Intel hadn't been rushing to
put AVX-512 on its consumer CPUs, so that they would
squash AMD with vastly superior games and graphic
performance.

John Savard

On 8/17/2022 1:39 AM, Quadibloc wrote:
> On Sunday, July 24, 2022 at 4:41:19 PM UTC-6, luke.l...@gmail.com wrote:
>
>> AVX-512 *shudder*
>
> And here I was wondering why Intel hadn't been rushing to
> put AVX-512 on its consumer CPUs, so that they would
> squash AMD with vastly superior games and graphic
> performance.
>

I can make a prediction: For most workloads, if it gets used at all, it
probably wont make things much faster, or very possibly, will cause
things to get slower.

Quite possibly it would power through things like "multiply this big
matrix with this other big matrix", but then suck pretty hard for pretty
much everything else.

Or, sort of like 256-bit AVX, but even more so...

Or, say, it is something that would require special compiler support and
funky coding practices to get much benefit from (say, as traditional
auto vectorization continues to fall on its face, but now even more so...).

> John Savard

On 8/17/2022 1:35 AM, Quadibloc wrote:
> On Sunday, July 24, 2022 at 4:28:47 AM UTC-6, luke.l...@gmail.com wrote:
>
>> 3) RVV or any other Cray-Style Vector ISA requiring strict compliance
>> with IEEE754 FP accuracy will punish you with a 400% power/area
>> penalty compared to modern 3D-optimised GPUs which, as explicitly
>> spelled out and allowed in the Vulkan(tm) Spec by the Khronos
>> Group, are permitted significant accuracy reductions. Mitch
>> will (or will have already) filled you in on that.
>
> Well, if your purpose is building a device that is helpful to scientists
> wishing to perform large-scale computations on FP64 numbers, you'll
> just have to pay that penalty. After paying that penalty, though, something
> based on a GPU architecture instead of that of a conventional non-vector
> CPU is *still* vastly more powerful.
>
> And we have the NEC Aurora TSUBASA as an example of a Cray-style
> vector ISA. At a significantly higher cost, it was capable of about half
> of the FP64 FLOPS that a video card with high FP64 capabilities made
> on the same technology could provide. But because this architecture is
> more flexible, one could use it for a higher proportion of the floating-point
> calculations in typical scientific programs.
>
> That is a tradeoff that might be well worth it.
>

Pretty much, there are reasons I am mostly going for DAZ + FTZ and FPU
designs which don't give exact 0.5 ULP rounding. These make the FPU so
much cheaper.

For GPU-like uses, it is possible there could be a use-case for a
further reduced-precision Binary64 variant, say:
S.E11.F32.Z20

This is partly because there are still a few cases where a 16-bit
mantissa is not sufficient (and where needing to keep the main FPU
around is also fairly expensive).

Namely, there is the point in my rasterizer where it goes from
single-precision to 32-bit fixed-point.

On the floating-point side, it can use low precision calculations just
fine. On the integer side, it is 16.16 fixed point. However, the
conversion step from floating point to fixed point integer exceeds the
accuracy requirements of both the truncated-single and full single
precision (so, would effectively need something with a 32-bit mantissa
to deal with this).

This may be added as another possible sub-feature to the low-precision
unit, namely scalar FADD/FMUL units with 32-bit mantissa, and also needs
to support integer conversion. Mostly to serve as a cheaper stand-in for
the main FPU.

Though, it is possible the "GPU core" idea might be dead for now, given
I still can't quite make stuff cheap enough.

Well, either that, or try to cheap out on the FP->Int conversion process
and add some additional "low cost" SIMD converters (2x FP32 <-> Packed
Int32). Say, if one adds a bias of 1024, this is enough to get approx
10.6 output, which can then be shifted to give values in the 16.16
format (but would also require doing this step via a specialized blob of
ASM; at present this part of the rasterizer is still written in C).

I guess this could potentially side-step the need for a higher precision
unit (but would limit maximum viewport size).

> John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>And here I was wondering why Intel hadn't been rushing to
>put AVX-512 on its consumer CPUs, so that they would
>squash AMD with vastly superior games and graphic
>performance.

Intel engineering has. They put AVX512 in Cannon Lake, Ice Lake,
Tiger Lake, Rocket Lake and Alder Lake. Thanks to Intel's 10nm woes,
Cannon Lake did not appear in 2016 as the tick-tock plan would have
had it, but in 2018 in very small numbers and with disabled GPU, Ice
Lake and Tiger Lake only in laptops and NUCs, so the desktop saw it
only in Rocket Lake in 2021 (and that appeared only in high-priced
SKUs). For Alder Lake, the AVX512-capable Golden Cove cores are
combined with the non-AVX512 Gracemont cores, and because OSs cannot
(yet?) deal with cores that support different instruction set
extensions, AVX512 was disabled (even if the Gracemont cores are
disabled).

There are also the low-cost cores (Silvermont, Goldmont, Goldmont+,
Tremont, Gracemont), which don't execute AVX512 instructions (and,
except for Gracemont, not AVX, either). AMD showed that you can
implement AVX with 128-bit functional units, and I think you can also
do that with AVX512. AMD showed with Jaguar and Puma that this can
also be done in low-cost cores. If Intel actually wanted to
support AVX512 everywhere, they could have followed this example.

And then you have Intel marketing, which disables AVX512 in SKUs for
chips that actually support AVX512 (and likewise disable AVX in some
SKUs), ensuring that most programmers will steer clear of AVX for many
years to come and even longer for AVX512.

If they do this disabling and the non-support of these extensions on
the low-cost cores for market segmentation reasons, they don't
understand their job: Their actions ensure that AVX and AVX512 are
used by so little software that few people will see AVX and AVX512 as
product differentiators. It would be better for them if they had
cores (and maybe also SKUs) with fast and slow AVX and AVX512
implementations.

If they do this to salvage chips with broken high parts of their
AVX/AVX512 units, another way to deal with this is to build the
support for synthesizing AVX/AVX512 from narrower functional units
into cores that actually have wide units. They could achieve both
goals by disabling the high part of the AVX/AVX512 units and enable
the synthesizing on cheaper SKUs; then there would be SKUs with fast
AVX512 and SKUs with slow AVX512, a situations that is much more
likely to lead to widespread AVX512 usage in software.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

> 3) RVV or any other Cray-Style Vector ISA requiring strict compliance
> with IEEE754 FP accuracy will punish you with a 400% power/area
> penalty compared to modern 3D-optimised GPUs which, as explicitly

What is the origin of this extra cost? IOW, where's the meat of the
savings (I mean: which part of the computation of the last few bits
costs so much)?
Does the saving vary significantly between instructions?

Stefan

>For GPU-like uses, it is possible there could be a use-case for a
>further reduced-precision Binary64 variant, say:
>S.E11.F32.Z20

>This is partly because there are still a few cases where a 16-bit
>mantissa is not sufficient (and where needing to keep the main FPU
>around is also fairly expensive).

I have been thinking of going with 21-bit floats S1.E5.F15 because
three can be fit into 64-bits and so extra vector lanes can be had
cheaply.

I like the low precision idea. Keeping the significand under 18 bits
means just a single DSP can be used for the multiply.