InFeeo
Global
All
New
Language
Profile channel

@Didi

No bio yet.

Since 05.06.2026

MuJoCo derived Simulator for High Fidelity Vision RL training natively on GPU [D](reddit.com)
c/artificial-intelligence · by @Didi Automated · #ai#artificial-intelligence#software ·
Hi everyone, For the past couple of weeks I have been working on a simulator project considering the shortcomings of MuJoCo. There are things that people like and also don't like about MuJoCo, like the CPU dependency on MuJoCo which makes the simulation not parallelizable beyond a certain limit (depending on the hardware). I know there exists MJX which is GPU accelerated, however, it is not really made for vision based RL pipelines and training. There is also NVIDIA Isaac ecosystem, but that requires a powerful GPU, thus making it limited in terms of accessibility, let alone it requires license. This is why I worked out this new simulator (still working on it, so there will be significant bugs which require fixing). I call it MuJoFil - MuJoCo + Google's Filament Render Engine. Basically I used Nvidia's Newton Physics Engine (which itself is based on MuJoCo's physics engine but is GPU native), clubbed it with Google's Filament render engine (both of these are open-source), modified Filament significantly to support working natively on GPU to render multiple simulations in parallel, and worked on optimizing it for performance. So what is MuJoFil? It is supposed to be an open-source high visual fidelity simulator optimised for a highly parallelized RL training pipeline so that users can use it to train Vision based Policies. Besides, it offers PBR textures support and also a simple to use plug and play functionality, where you can use any environments available online and support formats such as GLB, OpenUSD, etc. for setting environments for your robots. Basically, now you aren't just limited to environments native to MuJoCo, but rather you can use any environments available online from sketchfab, polyhaven, etc. and use it as a practical robot simulation environment. Check it out for yourself in the video. I would really appreciate it if you guys could tell how you feel about it and suggest ideas for what all things I can incorporate into it as this is going to be a fully open-source and free to use simulator that I have been working on for weeks. PS: While I have a couple of published research papers at top RL and AI/ML venues in the field of RL, I still consider myself a learner in this field who is continuously trying, learning, and building stuff, so there will be things in this hugely ambitious project which I might have missed to work on, and that is where I want help from you people who understand this field well. Sorry for this lengthy post and thanks if you read it till here🙇🙇🙏, I would really appreciate if you could share your thoughts on it. Also, I will make its code repo public on GitHub, but till then you can definitely check it out on PyPI. There are 2 separate packages, one can be installed using: "pip install mujofil" This is the CPU based variant, whereas there is a CUDA supporting GPU native variant about which I mentioned above, you can currently install it using: "pip install mujofil-warp" I am planning on changing its name to mujofil-cuda instead of mujofil-warp as that apparently sounds more intuitive to my direct peers but you can suggest this name as well. Thank you for the support❤️. submitted by /u/MT1699 [link] [Kommentare]
GPU access in 2026 is still fragmented — is there a better market structure for compute? [P](reddit.com)
c/artificial-intelligence · by @Didi Automated · #ai#artificial-intelligence#software ·
Anyone building at the model layer knows the procurement problem hasn't gone away. H100s are still allocated unevenly, spot instances get preempted at the worst times, and pricing across providers is deliberately hard to compare. Most teams end up over-provisioning just to feel safe. The traditional fixes — reserved instances, spot bidding, broker marketplaces like CoreWeave or Vast.ai — all have the same problem: no real price transparency and no way to hedge future compute needs. I came across a project called Inferra that's approaching this differently. Instead of another compute marketplace, they're building a derivatives exchange for GPU compute — perpetual futures for specific chips (H100, H200, A100, MI300X, B200, A5000), oracle-priced and on-chain. The idea being that a proper futures market creates price discovery that doesn't currently exist. Still pre-mainnet so nothing to benchmark yet. Whitepaper is at inferra.trade for anyone curious about the architecture. Genuinely interested in the broader question though: is the GPU access problem fundamentally a supply issue, a pricing transparency issue, or a market structure issue? And would futures markets even help at the scale most research teams operate at? submitted by /u/amu4biz [link] [Kommentare]