Buckle up, we're writing a GPU driver

Рет қаралды 7,211

sphaerophoria

Күн бұрын

Пікірлер: 29

@cooltrashgamer 3 күн бұрын

I like that you say "we" for all of the steps taken, I graciously accept some of the credit for all your work

@LinguisticMirage 3 күн бұрын

😂

@alst4817 Күн бұрын

I helped too!

@elorrambasdo5233 3 күн бұрын

Also could the end goal be to have the sludge content display be a webcam view of the LED thing?

@bashbarash1148 3 күн бұрын

I'm literally becoming a better programmer with every piece of your content. Insane stuff

@cvabds 2 күн бұрын

I bet you can't do that for templeOS

@user-sb5vt8iy5q 4 күн бұрын

next step, vulkan path tracer

@metroid031993 2 күн бұрын

If I'm remembering correctly, the BAR is the "Base Address Register" which is needed because PCIe can address a larger than 64 bit address space, so you sort of use the BAR to tell the PCIe devices where things should appear inside the CPU's address space

@cyberbemon 2 күн бұрын

the other day I was thinking, man how the fuck do I start getting into writing a GPU driver and now I see this on my recommended youtube videos. Amazing.

@andrejbartulin 3 күн бұрын

From maps to GPU! Next step is making sphaerophoria PC

@jpack61108 2 күн бұрын

Turning off kaslr makes debugging with GDB a lot easier

@sphaerophoria 2 күн бұрын

yeah, i found the answer after stream, just didnt wanna spend film time on that :). KVM also seemed to make it more difficult

@eldonad 3 күн бұрын

I think a "saner" way to approach the problem would be to implement a HDMI or VGA decoder on said shitty stm32, and use part or all of the screen as the pixel buffer to be displayed on the LED wall. As it stands you probably will end up needing to either reimplement 3D acceleration and OpenGL api from scratch, or get an existing software stack working with your gpu. But hey, if you start implementing a software GPU from scratch, I'm all in to seeing it!

@sphaerophoria 3 күн бұрын

"needing to", i think you mean "get to". I mean in all honesty the led wall is pretty loose justification, the real goal is to make a real 3d accelerated gpu cause its neat

@eldonad 3 күн бұрын

@@sphaerophoria Yeah, I figured as much 😄 Honestly I've been interested to know how this kind of thing works too (more so because of AI than graphics), but I think if I had to do something like that I would try to invest in an FPGA to play around with parallel computing and such, because a pure software GPU doesn't feel like much of an improvement over no GPU at all...

@sphaerophoria 3 күн бұрын

That's where this is going, but I want to understand the software stack before designing any hardware. Iteration in software will be easier, and I want to do something that's at least semi-sane

@eldonad 3 күн бұрын

@@sphaerophoria Very nice, then I wish you the best with that ! I will certainly follow along in the shadows, I'm learning a lot from your videos !

@metroid031993 2 күн бұрын

Unless the STM32 has a dedicated HDMI peripheral, you aren't going to be decoding it fast enough, not even close. As an example, in order to just sample fast enough, you need at least double the sample rate as the speed of the thing you're targeting, and one of the lowest supported resolutions, 640x480, uses a TMDS (protocol HDMI uses) clock rate of 252 MHz, with data encoded across 3 channels. And you need at least double that, half a GHz, just to sample it properly! Then TMDS encodes pixels in a specific way which you need to untangle. That untangling needs to happen at minimum at the rate it comes in, preferably faster so its easy to keep up, and then all that needs to be conveyed to whatever pixel hardware you want to display to... You're probably actually looking at an FPGA to get it fast enough, unfortunately.