Show HN: High speed graphics rendering research with tinygrad/tinyJIT

31 pointsposted 6 days ago
by quantbagel
(github.com)

11 Comments

nl

6 days ago

Why is this a fork of tinygrad and not just something that imports it?

sixtyj

6 days ago

Because forking is new coding /s (What we see is natural entropy of systems. Wannabe codies fork a repo… and instead of contributing to original one they make their own copy. What will happen if you repeat this a few times? ;)

Keyframe

6 days ago

That is a legit way of working on contribution. You fork, you work on the fork - if it's not junk then you issue a pull request. What's the deal with belittling and holier-than-thou moralizing?

sixtyj

6 days ago

I have nothing against forking ofc. I like it. But I really don’t like laziness when there is no contribution to original project - instead those codies make the project as their, in fact it is just a (poor) fork. The result is the mess. My first comment was about this behaviour.

Forking is nice when it’s nice.

quantbagel

6 days ago

Well I wanted to implement light transport papers without having to deal with cpp. I think tinygrad, and more specifically tinyJIT are super useful abstractions. This is def not available in ts

nl

5 days ago

My question was more why a fork instead of doing the conventional "import tinygrad" into your own project.

I don't think there is anywhere you are modifying tinygrad itself is there?

sxp

6 days ago

Claude didn't follow your "Every line must earn its keep. Prefer readability over cleverness. We believe that if carefully designed, 10 lines can have the impact of 1000." from https://github.com/quantbagel/gtinygrad/blob/master/AGENTS.m... given how bloated this demo is.

https://blog.evjang.com/2019/11/jaxpt.html is a better demo of how to render the Cornell Box on a TPU using differentiable path tracing.

suhacker256

6 days ago

so cool! id love to read a blog post about this.

user

6 days ago

[deleted]