4 ms·
I recall a demo app from my teen years (late 1908s to early 90s) that demonstrated, after installing your coprocessor, improved 3D performance by rotating at "h
by delinka 8y ago
I recall a demo app from my teen years (late 1908s to early 90s) that demonstrated, after installing your coprocessor, improved 3D performance by rotating at "high" speed a 3D sprite on the screen. This was an Intel 80386 with an 80387 coprocessor - I thought it was doing matrix math. Nope, the 8037 was an external floating-point unit that arrived two years after the processor with which it was paired. Cringey.
- Retric 8y agoMath coprocessors worked fairly well due to much slower clock speed minimizing the latency issues. Off chip level 2/3 cache was still a thing into 486 days. And x86 ASM still treats floating point as if it’s on a separate processor. PS: Got a real chuckle out of that 1908s typo. I would probably keep it.
- benj111 8y agoL2 cache only got packaged with the chip in the Pentium 2, and even then, wasn't on chip, hence the weird packaging.
- seanmcdirmid 8y agoThey were packaged closely together in the Pentium Pro (two dies in the same processor package). The Pentium II was a cheaper downgrade that preserved the separate bus but just put the cache next to the CPU in the weird packaging.
- loeg 8y ago> Off chip level 2/3 cache was still a thing into 486 days. Yep! I have a sad 586 (Pentium) with an empty motherboard slot labelled "CACHE MODULE" sitting behind me in the office. (It's L2 — the 586 has a small on-die L1.) You can theoretically still buy these "Cache on a stick"[1] modules on ebay and the likes; who knows if they work, and they're definitely not worth it in an economic sense. I missed the on-die L2 by one generation (Pentium Pro was the 686)! [1]: https://en.wikipedia.org/wiki/Cache_on_a_stick https://en.wikipedia.org/wiki/Cache_on_a_stick
- Gibbon1 8y ago> ASM still treats floating point as if it’s on a separate processor I read assay on the failure of a RISC design. The reason was they didn't have separate registers for the floating point unit. The extra bus loading from the floating point unit limited speed at which the registers could be accessed and thus the clock speed. So it was never able to meet it's performance spec's and there was no way to fix it. I hadn't realty thought until then that there is a trade off between clock speed and the number of and usage of registers. PDP11 and 68000's have a lot of flat generic registers. Where 0x86 had a limited number of specialized registers. 0x86 could probably clock faster at the expense of higher register pressure.
- pjc50 8y agoIt probably was doing matrix math - the fact that the FPU was external is somewhat irrelevant, it was still decoding out of the same instruction stream and could inter-communicate with the integer unit registers. Still not as fast as doing 16-bit fixed-point maths, which I used back in the day for a toy 3D system. https://github.com/pjc50/ancient-3d-for-turboc https://github.com/pjc50/ancient-3d-for-turboc >> the post is from 2012 back when nobody was doing hardware matrix multiplication so it's understandable. Missed that first time round: off by a decade or two! https://en.wikipedia.org/wiki/3dfx_Interactive https://en.wikipedia.org/wiki/3dfx_Interactive / https://en.wikipedia.org/wiki/Silicon_Graphics https://en.wikipedia.org/wiki/Silicon_Graphics /
- atq2119 8y agoGPUs traditionally don't do matrix multiplication, though. They do matrix-vector multiplications only, which is related but still a somewhat different beast.
- deepnotderp 8y agoGEMVs can be used to do GEMMs
- atq2119 8y agoYes. The difference for the purpose of this discussion is in the dispatch (data movement) cost per useful operation. Both GEMV and GEMM can be described as performing (m,k,n) matrix multiplication of an mxk matrix by a kxn matrix. GEMV is simply the case n=1. The number of useful operations is m * k * n, while the size of the input data is m * k + k * n. So a (4,4,4) GEMM does 64 useful operations while moving 32 input values. Implementing the same GEMM as 4xGEMV also does 64 useful operations, but at the cost of moving 20 input values per GEMV, or 80 overall. That's where the benefit of hardware GEMM comes from. Computer graphics doesn't require high throughput of matrix-matrix multiplication. You might need a few matrix-matrix multiplications to set up your transformation matrices, but you do that once for matrices that are then applied to many vertices, so there's not much to be gained by optimizing those. The high throughput matrix-vector multiplies happen on the GPU, but you don't need GEMM for that and so GPUs traditionally didn't offer it. I guess you could argue that if you multiply one matrix by many vectors, for processing many vertices of a model, then you do in fact have an implied GEMM if you group your vertices accordingly. It seems that for some reason, the computer graphics folks never quite saw it that way, maybe because you also do stuff like animation blending which breaks the GEMM analogy.
- asaph 8y ago> I recall a demo app from my teen years (late 1908s to early 90s) You were a teen for at least 82 years. Talk about a protracted adolescence!