Hacker Newsnew | past | comments | ask | show | jobs | submit | qrios's commentslogin

It’s been a while since I’ve struggled with Xilinx tools, but I can’t imagine there aren’t any hardware limitations these days. Does this run on a Spartan 6, or do you need the latest UltraScale for it?

Or does this only run in simulation anyway?


This fits and runs in a DE-10 Nano without too much difficulty, uses around 70% of the fabric. I've been working on timing closure and just got it to 50 MHz.

Note that I also implemented cache components not present in the original Voodoo in order to be more flexible in terms of the memory that can be used. So it could be quite a bit smaller, maybe 50% of the fabric if you got rid of that.


That's quite impressive. 70% is obviously way too big for a MiSTer core, but I wonder if one day we will have an affordable FPGA board able to simulate a late '90s PC...


FPGA simulations are a naive attempt to guess at Metastability problems by finding a "steady state" latency after a certain amount of simulation time. Clock domain crossing mitigation only gets folks so far, and state propagation issues often get worse with larger and faster chips.

Note, there are oversized hobby Voodoo cards that max out the original ASIC count and memory limits. There are also emulators like 86box that simulate the hardware just fine for old games.

https://www.youtube.com/watch?v=C4295RCp0GQ

>Or does this only run in simulation anyway?

If they are a LLM user, than it is 100% an April fools joke. =3


A simple skill markdown for Claude Code was enough to use the local Wolfram Kernel.

Even the documentation search is available:

```bash

/Applications/Wolfram.app/Contents/MacOS/WolframKernel -noprompt -run '

Needs["DocumentationSearch`"];

result = SearchDocumentation["query term"];

Print[Column[Take[result, UpTo[10]]]];

Exit[]'

```


Works on my computer: RTX 3090, CUDA 12.6

Interesting project! I haven't really worked with Vulkan myself yet. Hence my question: how is the code compiled and then loaded into the cores?

Or is the entire code always compiled in the REPL and then uploaded, with only the existing data addresses being updated?


Thanks for trying it! :)

Each gpu_* call emits SPIR-V and dispatches via Vulkan compute. Data stays resident in VRAM between calls — no round-trips to CPU unless you need the result.

No thread_id exposed. The runtime handles thread indexing internally — gpu_add(a, b) means "one thread per element, each does a[i] + b[i]." Workgroup sizing and dispatch dimensions are automatic.

The tradeoff: you can't write custom kernels with shared memory or warp-level ops. OctoFlow targets the 80% of GPU work that's embarrassingly parallel. For the other 20% you still want CUDA/Vulkan directly.

Cheers


Very interesting! I'll definitely give it a try. However, the documentation link[1] isn't working at the moment (404).

[1] https://crux-ecosystem.github.io/MOL/



Via certificate invalidation, or turning off services for certificate pinning?



Same for me with ISP from Austria.


Sorry. Maybe US-only government site. Unfortunate



> … what human intelligence is because intelligence is best described as a side-effect of consciousness …

Is "human intelligence" and "intelligence" equal?

And: How to become conscious before being intelligent?

Or: If intelligence is a side-effect, how often this side-effect can't be observed?

Xor: What if an intelligent being denies being conscious?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: