3 ms·
Something that frustrates me a little is that my system (apple silicon) has unified memory, which in theory should negate the need to shuffle data between CPU a
by Retr0id 2y ago
Something that frustrates me a little is that my system (apple silicon) has unified memory, which in theory should negate the need to shuffle data between CPU and GPU. But, iiuc, the GPU programming APIs at my disposal all require me to pretend the memory is not unified - which makes sense because they want to be portable across different hardware configurations. But it would make my life a lot easier if I could just target the hardware I have, and ignore compatibility concerns.
- deviantbit 2y agoUnified memory doesn't mean unified address space. It frustrates me when no one understands unified memory.
- morphle 2y agoIf you fix the pages tables (partial tutorial online) you can have continuous unified address space on Apple Silicon.
- deviantbit 2y agoLet’s be honest, saying “just fix the page tables” is like telling someone they can fly if they “just rewrite gravity.” Yes, on Apple Silicon, the hardware supports shared physical memory, and with enough “convincing”, you can rig up a contiguous virtual address space for both the CPU and GPU. Apple’s unified memory architecture makes that possible, but Apple’s APIs and memory managers don’t expose this easily or safely for a reason. You’re messing with MMU-level mappings on a tightly integrated system that treats memory as a first-class citizen of the security model. I can tell you never programmed on an Amiga.
- morphle 2y agoOh yes I programmed all the Amiga models, mostly in assembly level. I reprogrammed the ROMs. I also published a magazine on all the Commodore computers internals and build lots of hardware for these machines. We had the parallel Inmos Transputer systems during the heyday of the Amiga, they where much better designed than any the custom Amiga chips.
- deviantbit 2y agoInmos was a disaster. No application ever shipped on one. EVER. It used a serial bus to resolve the problems that should have never been problems. Clearly you never wrote code for one. Each oslink couldn't reach more than 3 feet. What a disaster that entire architecture was.
- sitkack 2y agoHey don't shit on my retro alternative timeline nostalgia. We were all writing Lisp programs on 64 CPU Transputer systems with FPGA coprocessors, dynamically reconfigured in realtime with APL.
- zozbot234 2y ago/s/LISP/Prolog and you've basically described the old "Fifth Generation" research project. Unfortunately it turns out that trying to parallelize Prolog is quite a nightmare, the language is really, really not built for it. So the whole thing was a dead-end in practice. Arguably we didn't have a real "fifth-gen" programming language prior to Rust, given how it manages to uniquely combine ease of writing parallel+concurrent code with bare-metal C like efficiency. (And Rust is now being used to parallelize database query, which comfortably addresses the actual requirement that Prolog had been intended for back then - performing "search" tasks on large and complex knowledge bases.)
- hollerith 2y agoAlso, the Fifth Generation computer project subscribed to the old AI paradigm, not based on statistics.
- sitkack 2y agoYou probably already know about https://github.com/mthom/scryer-prolog https://github.com/mthom/scryer-prolog are you saying we should accelerate scryer-prolog with a Grayskull board?
- morphle 2y ago
- Retr0id 2y agoI know the APIs don't make it easy, that's precisely why I want different APIs.
- morphle 2y agoNot true. "just fix the page tables" took me 4 hours. And only 15 minutes with the Linux kernel on Apple Silicon.
- deviantbit 2y agoObviously you missed the sarcasm.
- jms55 2y agoYou can. There are API extensions for persistently mapping memory, and it's up to you to ensure that you never write to a buffer at the same time the GPU is reading from it. At least for Vulkan/DirectX12. Metal is often weird, I don't know what's available there.