Oh nice. I have a little PCIe/VGA one that I use for truenas and it's a bit flaky but I love that it's basically free from a PCIe perspective (just toss it off _any_ root). These are super useful and there are even m.2 variants.

Title fix proposal: Why vibecoding rocks

looks cool, and thanks for being upfront about the LLM-assisted part. It seems like a genuine project with a lot of time put into it!

Nice. Is your vibecoded driver from scratch or does it bring the old driver forward ?

It doesn't really do much in the way of processing (https://www.siliconmotion.com/download/3PS/a/SM750_PB_EN_201...); it's pretty much just a dumb framebuffer. You can wire it up to output over an HDMI connector, but with the features it supports you're really just getting a single-link DVI signal.

I agree but these things are only about $25 USD. Arguably an older Nvidia GPU is a better investment at this price if you just want basic desktop use. Unfortunately if I did that, the old Nvidia drivers wouldn't support my newer Nvidia Blackwell hardware.

16 * 1024 * 1024 / 1920 / 1080 = 8.0909, so you have enough VRAM for double-buffered 24-bit 1080p, with a bit to spare. For pure software rendering, that's good enough!

3840 x 2160[px] x 24[bit/px] / 8[bit/byte] = 24883200[bytes]

^ / 1024^2[bytes/MB] = 23.73[MB]

Initially I just needed a driver for the device.

tldr; had Qwen orchestrate, do admin and assist with investigations, builds and debugging when codex was unavailable. Codex had a dedicated test physical machine, and I promoted the driver it created to the actual target (production) machine when it was stable enough. Used syncthing to keep the code synced between the different environments, with Qwen sending me progress updates on Telegram and querying Codex periodically.

Long answer:

1) Ran the concept and investigation past Qwen 3.6, I wanted a card that would fit my spare PCIe 3 X1 socket (faster cards in other sockets). Identified the sm750, and read up on its capabilities.

2) Due to speed and Qwen 3.6's capability, I handed Codex (on high) a whole physical scrap machine / fresh Mint install, with root access and the GPU directly connected and asked it what was needed. Syncthing copied the work folder to my machine desktop for visibility to my main orchestrating Qwen AI. Qwen could also ssh to the Codex owned machine to check progress and send me Telegram messages when any milestones were passed, as well as issues that might need me there.

3) I Identified all the chips on the sm750, whilst it was trying the official older sm750 drivers (attempting to get a HDMI signal) and gave them to it.

4) Used /plan mode to set the first iteration expectations, no DRM/integration into the control panel, modifying a checked out fbdev low level FB to test my magic dither algorithm (this can only be used for test, the integration needs to go elsewhere in the stack typically).

5) Left it a few hours, came back to see colour bars (success!)

6) Asked it to do the basic plumbing for X11, wondered how far I could push the frequencies past the VESA standards, fried the HDMI TV attempting high frequency modes (only realised next day I'd done this after the TV refused to activate that connector)

7) Plugged the card directly into the machine it would be used in, and the actual ultrawide monitor. Resumed the codex session on that machine, when daily limits were hit used Qwen 3.6/3.8 to package up builds, look for solutions to issues I was hitting. At this point the hardware is my "production" system, so effectively I've promoted test to staging.

8) From here I manually iterated with Codex by having it create scripts that would build the module for the current kernel to restart X11 with 1-3 ideas / fixes at a time.

9) In parallel, used Qwen to prep the GitHub project, Codex and Qwen to do research for ideas on how to overclock the chips, feasibility of hacks I wanted investigating

10) Asked Codex and Qwen to identify bugs Vs specs, it found a few in event sequencing, resuming events, wrong bits in packets etc.

11) Switched Codex to Max after the the bugs were fixed because the driver performance was laggy, and recommendations from Qwen and Codex Medium/High for optimisations either caused degradations in some way (e.g. DMA was slower) and asked it to audit and optimise the code. I did this over 3 nights due to credit limits getting hit, again 1 to 3 changes at a time.

12) After I was happy with the quality ran the licencing checks again past Qwen and Codex and set up the project on GitHub, held private until I got workflows working.

Possibly, but in order to be safe for everyone, reviewers may want me to remove features that allow the driver to achieve the non-standard performance. There's a lot of hoops to jump through :)