(will also add "DMA"-esque commands which allow memory to be copied to and from VRAM - which, otherwise, is inaccessible to the CPU to simplify emulation)

Things remaining for rasterization:
- Textures (texture formats, bilinear filtering, & mipmapping)
- Table fog
- Blending
- Antialiasing?

(and then hooking up some kind of "command list" system to allow the emulated CPU to control all of this)

(oh, and you can also specify a clip rectangle now)

Can configure the z-buffer address, enable color/depth writes, enable depth test, & configure depth compare op.

(also added support for configuring whether the rasterizer swizzles output tile order for rendering to a format suitable for textures)

(for reference: Larrabee was an experimental GPGPU architecture by Intel, and one of the interesting things is that it had almost no fixed function bits at all, so even rasterization was implemented using compute resources)

This was an extremely useful set of posts for triangle rasterization.

fgiesen.wordpress.com/2013/02/08/t...

It has some broken links, but also one of the posts references the "Larrabee" rasterizer, which I managed to find on the wayback machine (& is where I got the idea to split into tiles)

Midnight & noon should just be 0 tbh. Then it's just a wrap/modulo operation 😅

As for video output I guess you'd probably have a "resolve" step which copies the rendered output to another address & reshuffles all of the data so it's in the correct layout for the video encoder.

(this would also be where I'd add support for resolving multi-sampled buffers I think)

(might also swizzle the order of these 8x8 blocks so that the output of the rasterizer matches what the texture units will expect, so that rendered output can seamlessly be used as a texture.)

(and also if you misconfigure registers it will look busted in fairly authentic "fucking around with the hardware" ways lmao😅)

The other thing is I can start emulating all kinds of funky memory shit :)
For example, since the rasterizer already works in 8x8 tiles, I could lay out each of those tiles contiguously in memory.

And then a linear scanout of that looks REAL funny lmao.

One of the reasons for doing this is I can now arbitrarily confgure:

- the target address in VRAM for the rasterizer, and width/height of that
- the source address in VRAM for the video encoder, and the output format

eyy 2x multisampling is pretty trivial yeah (not yet storing both color samples, so rn I'm just computing a "coverage" factor & multiplying color by that, but still!)

Works pretty much exactly like I initially planned, although I think for attribute interpolation I might just cheat and directly multiply with barycentric weights instead of summing 🤷‍♀️

Also think 2x MSAA would be pretty trivial to implement fwiw (just a bias & sign check for the second sample)

(oh forgot to mention but this is RiscV emulation btw)

Also fun wrinkle was finding out that, even though the top 16 MIE and MIP bits are basically allowed for platform-defined interrupts, Unicorn explicitly masks them out so I can't use them.

So I had to basically build my own emulation of a PLIC as well.

Once I get interrupts working I think I can move on to having the CPU actually issue commands to the GPU, and from there start working on triangles & whatnot

Problem: for some reason even if I never flag that AtomicBool the wait function still successfully exits, which shouldn't be possible??

So that's what I'm debugging now.