The Voodoo cards had no right to look as good as they did for their time. Someone rebuilding one from scratch is exactly the kind of project HN was made for.
Yes but the Nvidia NV-1 preceding the Vooodoo was much more impressive. Using NURBS you could display perfectly round objects. Also it had forward texture mapping which significantly improves cache utilization and would be beneficial even today.
It was just way harder to program for. Triangles are much simpler to understand than bezier curves after all. And after Microsoft declared that DirectX only supports triangles the NV-1 was immediately dead.
Thank you! These things do pack in a ridiculous amount of functionality for what they do. Probably why they look so good but also why it took 30 years for a hardware re-implementation.
I exhausted my teenage savings to buy the Voodoo 1 due to the Linux support. Granted, I was running Red Hat at the time so the installation consisted of installing what, two RPMs? Played a lot of Q3 and Unreal on that card.
I tend to feel the same way, although I'm actively trying to move past it. I'm OK at writing, but thanks to a combination of educational background and natural aptitude, I'm darned near illiterate at math. That puts me behind the 8-ball as an engineer, even though I've been reasonably successful at both hardware and software work. I tend to miss tricks that are obvious to my peers, but when I do manage to come up with something useful, I have no problem communicating with both my peers and my customers.
So here's somebody who's clearly strong on the quantitative side of engineering, but presumably bad at communicating the results in English. What right do I have to call them out for using AI to "cheat" at English, when I rely on it myself to cover my own lack of math-fu? Is it just that I can conceal my reliance on advanced mathematical tools, while they can't hide their own handicap due to its very nature?
That doesn't sound fair. I would like to adopt a more progressive outlook with regard to this sort of thing, and would encourage others to do the same.
I find it odd the author adds all these extra semantics to their input registers, rather than keeping the FIFOs, "drain + FIFOs", "float to fixed point converting register", etc as separate components, separate from the task of being memory mapped registers. The central problem they were running into was one where they let the external controller asynchronously change state in the middle of the compute unit using it.
I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.
Maybe I'm misunderstanding, but that functionality is implemented in another component. The register bank only records the category of each register and implements the memory-mapped register functionality.
This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.
Well still, why tie this kind of processing to the registers themselves? Sure having a shorthand to instantiate a queue of writes I could see, but float to fixed conversion has no place being part of a memory mapped register bank.
Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it?
That way still all handling of inputs is done in the same place.
Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.
You do have a nice point here. Then the compute unit can simply stall the commands coming out of the register bank. Without this I need to stall the write FIFO, which feels less elegant and has given me some pain in terms of combinational loops. The drawback though is that you have to duplicate a significant amount of registers in the compute unit.
It was just way harder to program for. Triangles are much simpler to understand than bezier curves after all. And after Microsoft declared that DirectX only supports triangles the NV-1 was immediately dead.
Getting it working in linux in ~1999 was really not easy, especially for a teenager with no linux experience.
My networking card wasn't working either, so I had to run to a friend's house for dial-up internet access, searching for help on Altavista.
Very cool project. Way above my head, still!
So here's somebody who's clearly strong on the quantitative side of engineering, but presumably bad at communicating the results in English. What right do I have to call them out for using AI to "cheat" at English, when I rely on it myself to cover my own lack of math-fu? Is it just that I can conceal my reliance on advanced mathematical tools, while they can't hide their own handicap due to its very nature?
That doesn't sound fair. I would like to adopt a more progressive outlook with regard to this sort of thing, and would encourage others to do the same.
https://lockbooks.net/pages/overclocked-launch
I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.
This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.
Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it? That way still all handling of inputs is done in the same place.
Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.