# Ray Tracing in One Weekend
**URL:** https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078
**Category:** Show and Tell
**Created:** [August 2, 2024, 11:12am UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078 "2024-08-02T11:12:37Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [August 2, 2024, 11:12am UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/1 "2024-08-02T11:12:37Z")
I’ve wanted to do this particular [kata](https://raytracing.github.io/books/RayTracingInOneWeekend.html) for a long time and finally got to it.
> **[IC Rainbow / rtow · GitLab](https://gitlab.com/dpwiz/rtow/)**
>
> Ray Tracing in One Weekend
There are some post hoc [notes](https://gitlab.com/dpwiz/rtow/-/blob/main/notes/week-1.md) I’ve written down if you’re interested in reading stream of grumpy remarks (with the pictures of the intermediate steps!).
---
### Author:  [@waivio](https://discourse.haskell.org/u/waivio)
#### Post date: [August 2, 2024, 7:32pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/2 "2024-08-02T19:32:01Z")
Thank you for your contribution. I enjoyed it completely. I love that you used `massiv` I think that it is a awesome library that demonstrates Haskell’s laziness allowing fusion and control over evaluation for parallel and concurrent programming. I’m not gonna lie `geomancy` is really giving me some SIMD envy. This is a good example of Haskell’s numerical strengths. I hope to contribute in this way more in the future. I also hope to see more contributions from you.
---
### Author:  [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)
#### Post date: [August 2, 2024, 8:15pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/3 "2024-08-02T20:15:12Z")
> Found out there’s a gotcha then adding multiple `-with-rtsopts` args in a package. Had to collect them into one pile of `- '"-with-rtsopts=-s -N -A64m"'` to avoid the repeated overwriting of it. Gotta check the rest of my packages for this…
This is [#18117: It's not possible to specify multiple `-with-rtsopts` flags · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/issues/18117), it might be helpful to chime in there.
---
### Author:  [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)
#### Post date: [August 2, 2024, 8:17pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/4 "2024-08-02T20:17:44Z")
> The `interval` class is just a pair of numbers, with extra functions. I briefly dived into Hackage archives, but the solutions are way to complex for the task.
There is indeed a zoo of libraries for intervals on Hackage. As a maintainer of [data-interval: Interval datatype, interval arithmetic and interval-based containers](https://hackage.haskell.org/package/data-interval), I’m curious if you can identify any possible improvements.
---
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [August 3, 2024, 3:30pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/5 "2024-08-03T15:30:51Z")
I ended up removing the `Interval` entirely. It was only needed to find the closest positive hit (if any).
The next book has BVH building chapter and I’m going to take `data-interval` for a walk.
---
### Author:  [@romes](https://discourse.haskell.org/u/romes)
#### Post date: [August 3, 2024, 10:14pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/6 "2024-08-03T22:14:19Z")
What’s the next book?
---
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [August 4, 2024, 8:23am UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/7 "2024-08-04T08:23:41Z")
Next two books, actually…
- RTOW - the basics
- [The Next Week](https://raytracing.github.io/books/RayTracingTheNextWeek.html) - optimization and advanced materials
- [The Rest of Your Life](https://raytracing.github.io/books/RayTracingTheRestOfYourLife.html) - sampling intricacies
---
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [August 14, 2024, 5:49pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/8 "2024-08-14T17:49:36Z")
“The Next Week” is finished too and [the notes](https://gitlab.com/dpwiz/rtow/-/blob/main/notes/week-2.md) are up.
I’ll have some rest now and think if I want to do the final book in the series, delve into [PBR book](https://www.pbr-book.org/) instead, or… do something else entirely (like generating that SPIR-V disassembler from the specs).
---
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [March 30, 2026, 10:52pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/9 "2026-03-30T22:52:23Z")
> Use SIMD, do ssssttttuuuuppppiiiidddd tttthhhhiiiinnnnggggssss faster, with more energy efficiency ☕
A long-delayed post-Zurihac update. The only primops used so far are the basics that the NCG got in 9.12. No special layouts and fancy primops as they will only appear in 9.16 (and then I’ll need some more). Just do the regular thing four lanes at once. It’s a good start… oh wai~
It got better since then. The models took a repo with half-staged commits and made it running without segfaults. They also told me that I was absolutely right, but my BVH code is stupid and could be much simpler and faster. And also cooked benchmark harness which I was procrastinated since the very beginning. I love getting faster, but hate writing benchmarks 😅
But one scene was quite resistant to the improvements, the `finalSceneHigh` from the 2nd book.
I wasn’t sure why and had to guess until I implemented a tiled scheduler. The abysmally slow tile was not where I expected it to be, but it persisted through most of the run at just 1/40 of the mean pixel rate. And also broke the tiled scheduler by leaving the last job working full steam, while the remaining 15 cores were idle.
I took a low-SPP run to measure the tiles and put the slowest first. Then subdivide the slowest half. Then subdivide the slowest quarter again. This mostly solved the idling cores, but the solution wasn’t satisfactory.
And the code was a mess. While refactoring it around I thought that I can skip the tile/subtile distinction and the grid itself and just work with arbitrary rectangles. That also served one of the long-standing project’s goals - binding the renderer to UI where I can select regions and get them rendered for debugging.
I still have no UI (or a job server to distribute the load over all of the household appliances around my house and my parents’ too), and no debugging. But after a few iterations the round limit and most of the manual size tweaking were gone as the system was optimizing itself by measuring and subdividing until the tiles are fast enough or too small.
The slow bunch is still slow, but the system now crushes it first and fills the scheduling gap at the end with the easier tiles.
I even got back and recorded the historical renders to make a timeline mini-site: [https://dpwiz.gitlab.io/rtow/](https://dpwiz.gitlab.io/rtow/)
This is far from over, but I’m not dead-inside wrt this codebase anymore.
---
### Author:  [@wiz](https://discourse.haskell.org/u/wiz)
#### Post date: [April 1, 2026, 1:55pm UTC](https://discourse.haskell.org/t/ray-tracing-in-one-weekend/10078/10 "2026-04-01T13:55:58Z")
Give that package a prize or something [lucid-svg: DSL for SVG using lucid for HTML](https://hackage.haskell.org/package/lucid-svg)
Seriously underrated for debugging stuff for cheap.
