7 ms·

Why open source rocks – a new SM750 (Silicon Motion GPU) HDMI Driver

127 points by SillyUsername 18d ago

SillyUsername 18d ago
I wrote* a modern Linux driver that supports ultrawide resolutions, higher refresh, and faster performance than the original driver(s) on this cheap HDMI only variant server GPU. I created it because I wanted my Nvidia GPUs to be compute only, and needed a cheap and small display GPU to run X11. I bought this GPU on AliExpress, after learning it had Linux support. It does, but kernel 5.x series and the sm750 driver in modern Linux only supports the older VGA/DVI variants. Rather than send it back or throw it away, I decided to vibe code a new driver with new features, to make it usable for day to day desktop use. I've a little bit of a background in low level graphics so also added a cool little magic ordered dither (a pretty good one I think!) I devised myself, called "bbdither", and a few hacks to get 2560x1080 at 75hz on a device only officially documented as capable of up to 1920x1200 at 60hz, and PCI-E 1x speed. Screenshots here: https://github.com/KodeMunkie/sm750hdmifb#screenshots https://github.com/KodeMunkie/sm750hdmifb#screenshots If you try it out, be careful - read the project disclaimer :) *Vibe coded, as mentioned in Hackernews comments here https://news.ycombinator.com/item?id=49415282 https://news.ycombinator.com/item?id=49415282
- mmastrac 18d ago
  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.
  - SillyUsername 18d ago
    Ah you mean this https://www.pcworld.com/article/393815/the-asrock-rack-m2-vga-is-a-gpu-that-fits-in-a-tiny-m2-slot.html https://www.pcworld.com/article/393815/the-asrock-rack-m2-vg... That one is VGA so I think the original upstream driver should support it.
- ramon156 18d ago
  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!
- bigstrat2003 17d ago
  [flagged]
  - ChickeNES 17d ago
    Don't you people have something better to do than hound people for their choice of tools?
  - Brian_K_White 17d ago
    That's a thing that happens, but this doesn't look like that. The words "I vibe coded this" explicitly disclaim any excess credit. They did exactly what anyone can reasonably ask for. They exhibited essentially perfect integrity.
  - SillyUsername 17d ago
    I guess this is trolling, but I've never claimed credit for the traditional coding part. The unique bits I did do - Checked the specs for actual hardware limits, DMA and any acceleration - A magic dither based on my previous (normally coded) older projects (see GitHub) - Image width "compression" idea with loss reduction using sharpening and a slight aspect change. - Optimising DMA size chunking for optimal memory transfer. - A lot of actual manual testing, including sheer reduction, frame rate testing, and multiple resolution and different monitor tests (and I lost one - the HDMI port no longer works on my old Celcus) Failed experiments with: - using the onboard secondary controller to bypass the primary controller limitations - devising a hack that would use the vertical scan horizontally using monitor rotation - attempting an 8, not 16/32 bit desktop for higher performance (old school technique). - investigating non hardware hacks for overclocking the onboard chips. - fixing a KVM issue, that required multiple physical disconnects and reconnects to replicate, and a significant amount of weekend time. So yeah, vibe coded, because I'd never have been able to try these ideas in such a short timescale if I hadn't.
  - exe34 17d ago
    I'm assuming your gotcha is going to be "but that's not vibe-coding", but in case you're sincere, you might not have realised this yet: there's a whole range between writing every line by yourself and letting the slop machine create the entire thing. You can rely on your knowledge and understanding to guide it, to the point that it writes code that you would have written, but saves you an enormous amount of time and effort looking up things and creating/running small tests to figure out details. It's a tool, not a spell, so your pearl clutching is a few years out of date...
- internet2000 17d ago
  Title fix proposal: Why vibecoding rocks
  - spockz 17d ago
    To be fair, vibe coding is only possible because the models have been trained on the countless open source projects out there. And it could take the original drivers as basis in Linux.
- stuaxo 17d ago
  Nice. Is your vibecoded driver from scratch or does it bring the old driver forward ?
  - SillyUsername 17d ago
    Bit of both. It uses the GPL low-level sm750 chip/DDK code from Linux’s old sm750fb driver, but it's not just that framebuffer driver updated. The DRM/KMS architecture, board specific SiI9024 HDMI support, modes, DMA updates, hardware cursor, ultrawide support and custom dither are new.
realusername 18d ago
Will you upstream it?
- SillyUsername 18d ago
  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 :)
  - cromka 17d ago
    How did they react to it being vibe coded? Were they pragmatic about it, as Linus recently suggested I have like 4 drivers to upstream myself, plus a couple of patches here and there. Quality is good and they're tested, and while I understand the code and how things work low level, I wouldn't be able to write them myself.
    - SillyUsername 17d ago
      I've never tried it, I am put off by the amount of work for a few weekends on what I considered a personal project, plus I don't understand the code base well enough (problem domain is ok, I grew up with 8 and 16 Bit machines, and pushing graphics driver boundaries in Amiga and VGA monitor era machines). This is why my readme asks for help with issues :) The dev on this driver used a combination of local Qwen 3.6 and 3.8 27B for admin and basic work, and extensive Codex 5.6 Sol Max to catch the issues I found and do last stage optimisations / isolate the bugs. I'll freely admit I relied heavily on AI, my expertise and day job is in other software stacks. I stand on the back of giants :)
userbinator 18d ago
A GPU with HDMI and 16MB of VRAM is a very strange combination.
- SillyUsername 18d ago
  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.
  - theokrueger 18d ago
    old nvidia cards are pretty terrible actually on linux due to the proprietary drivers not working on mainline kernel after ~6.6
  - userbinator 17d ago
    Maybe an LLM can also assist with modifying the Nvidia driver appropriately.
    - SillyUsername 17d ago
      Funny you should say that On the same machine I experimented with IOMMU and a lightweight VM to run Nvidia Pascal era GPUs in a VM with 580 drivers, while Nvidia Blackwell on the host uses 590. I vibe coded that too When exposed via openai compatible endpoints with GPUStack https://github.com/gpustack/gpustack https://github.com/gpustack/gpustack I could use the combined compute power from both generations on a single machine.
- wtallis 18d ago
  It doesn't really do much in the way of processing (https://www.siliconmotion.com/download/3PS/a/SM750_PB_EN_201910.pdf 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.
arjie 17d ago
Hey, how did you iterate on it? Quite interested in your process here considering you say it’s vibe coded. The iteration loop is crucial for that.
- SillyUsername 17d ago
  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.
marcodiego 17d ago
Hmmm... How about adding it to the Free Software Foundation's "respects your freedom" hardware list?
eggsome 17d ago
What kind of motherboard has no onboard iGPU these days?
torvin92 17d ago
Another piece of silicon saved from the landfill! Open source keeps hardware relevant way past its commercial lifecycle.
sabot90260 17d ago
Proprietary drivers for obscure hardware were the bane of my existence. Glad to see this SM750 driver open-sourced.
EdwardDiego 17d ago
NGL, I read the title initially as Why open source rocks? - a new SM750 (Silicon Motion GPU) HDMI Driver And got excited that you were open sourcing a chip.
techsage 17d ago
[dead]
reindeer2 17d ago
[flagged]
listingbott 17d ago
[flagged]

127 points by SillyUsername 18d ago

I wrote* a modern Linux driver that supports ultrawide resolutions, higher refresh, and faster performance than the original driver(s) on this cheap HDMI only variant server GPU. I created it because I wanted my Nvidia GPUs to be compute only, and needed a cheap and small display GPU to run X11. I bought this GPU on AliExpress, after learning it had Linux support. It does, but kernel 5.x series and the sm750 driver in modern Linux only supports the older VGA/DVI variants. Rather than send it back or throw it away, I decided to vibe code a new driver with new features, to make it usable for day to day desktop use. I've a little bit of a background in low level graphics so also added a cool little magic ordered dither (a pretty good one I think!) I devised myself, called "bbdither", and a few hacks to get 2560x1080 at 75hz on a device only officially documented as capable of up to 1920x1200 at 60hz, and PCI-E 1x speed. Screenshots here: https://github.com/KodeMunkie/sm750hdmifb#screenshots https://github.com/KodeMunkie/sm750hdmifb#screenshots If you try it out, be careful - read the project disclaimer :) *Vibe coded, as mentioned in Hackernews comments here https://news.ycombinator.com/item?id=49415282 https://news.ycombinator.com/item?id=49415282

mmastrac 18d ago
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.
- SillyUsername 18d ago
  Ah you mean this https://www.pcworld.com/article/393815/the-asrock-rack-m2-vga-is-a-gpu-that-fits-in-a-tiny-m2-slot.html https://www.pcworld.com/article/393815/the-asrock-rack-m2-vg... That one is VGA so I think the original upstream driver should support it.
ramon156 18d ago
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!
bigstrat2003 17d ago
[flagged]
- ChickeNES 17d ago
  Don't you people have something better to do than hound people for their choice of tools?
- Brian_K_White 17d ago
  That's a thing that happens, but this doesn't look like that. The words "I vibe coded this" explicitly disclaim any excess credit. They did exactly what anyone can reasonably ask for. They exhibited essentially perfect integrity.
- SillyUsername 17d ago
  I guess this is trolling, but I've never claimed credit for the traditional coding part. The unique bits I did do - Checked the specs for actual hardware limits, DMA and any acceleration - A magic dither based on my previous (normally coded) older projects (see GitHub) - Image width "compression" idea with loss reduction using sharpening and a slight aspect change. - Optimising DMA size chunking for optimal memory transfer. - A lot of actual manual testing, including sheer reduction, frame rate testing, and multiple resolution and different monitor tests (and I lost one - the HDMI port no longer works on my old Celcus) Failed experiments with: - using the onboard secondary controller to bypass the primary controller limitations - devising a hack that would use the vertical scan horizontally using monitor rotation - attempting an 8, not 16/32 bit desktop for higher performance (old school technique). - investigating non hardware hacks for overclocking the onboard chips. - fixing a KVM issue, that required multiple physical disconnects and reconnects to replicate, and a significant amount of weekend time. So yeah, vibe coded, because I'd never have been able to try these ideas in such a short timescale if I hadn't.
- exe34 17d ago
  I'm assuming your gotcha is going to be "but that's not vibe-coding", but in case you're sincere, you might not have realised this yet: there's a whole range between writing every line by yourself and letting the slop machine create the entire thing. You can rely on your knowledge and understanding to guide it, to the point that it writes code that you would have written, but saves you an enormous amount of time and effort looking up things and creating/running small tests to figure out details. It's a tool, not a spell, so your pearl clutching is a few years out of date...
internet2000 17d ago
Title fix proposal: Why vibecoding rocks
- spockz 17d ago
  To be fair, vibe coding is only possible because the models have been trained on the countless open source projects out there. And it could take the original drivers as basis in Linux.
stuaxo 17d ago
Nice. Is your vibecoded driver from scratch or does it bring the old driver forward ?
- SillyUsername 17d ago
  Bit of both. It uses the GPL low-level sm750 chip/DDK code from Linux’s old sm750fb driver, but it's not just that framebuffer driver updated. The DRM/KMS architecture, board specific SiI9024 HDMI support, modes, DMA updates, hardware cursor, ultrawide support and custom dither are new.

realusername 18d ago

Will you upstream it?

SillyUsername 18d ago
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 :)
- cromka 17d ago
  How did they react to it being vibe coded? Were they pragmatic about it, as Linus recently suggested I have like 4 drivers to upstream myself, plus a couple of patches here and there. Quality is good and they're tested, and while I understand the code and how things work low level, I wouldn't be able to write them myself.
  - SillyUsername 17d ago
    I've never tried it, I am put off by the amount of work for a few weekends on what I considered a personal project, plus I don't understand the code base well enough (problem domain is ok, I grew up with 8 and 16 Bit machines, and pushing graphics driver boundaries in Amiga and VGA monitor era machines). This is why my readme asks for help with issues :) The dev on this driver used a combination of local Qwen 3.6 and 3.8 27B for admin and basic work, and extensive Codex 5.6 Sol Max to catch the issues I found and do last stage optimisations / isolate the bugs. I'll freely admit I relied heavily on AI, my expertise and day job is in other software stacks. I stand on the back of giants :)

userbinator 18d ago

A GPU with HDMI and 16MB of VRAM is a very strange combination.

SillyUsername 18d ago
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.
- theokrueger 18d ago
  old nvidia cards are pretty terrible actually on linux due to the proprietary drivers not working on mainline kernel after ~6.6
- userbinator 17d ago
  Maybe an LLM can also assist with modifying the Nvidia driver appropriately.
  - SillyUsername 17d ago
    Funny you should say that On the same machine I experimented with IOMMU and a lightweight VM to run Nvidia Pascal era GPUs in a VM with 580 drivers, while Nvidia Blackwell on the host uses 590. I vibe coded that too When exposed via openai compatible endpoints with GPUStack https://github.com/gpustack/gpustack https://github.com/gpustack/gpustack I could use the combined compute power from both generations on a single machine.
wtallis 18d ago
It doesn't really do much in the way of processing (https://www.siliconmotion.com/download/3PS/a/SM750_PB_EN_201910.pdf 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.

arjie 17d ago

Hey, how did you iterate on it? Quite interested in your process here considering you say it’s vibe coded. The iteration loop is crucial for that.

SillyUsername 17d ago
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.

marcodiego 17d ago

Hmmm... How about adding it to the Free Software Foundation's "respects your freedom" hardware list?

eggsome 17d ago

What kind of motherboard has no onboard iGPU these days?

torvin92 17d ago

Another piece of silicon saved from the landfill! Open source keeps hardware relevant way past its commercial lifecycle.

sabot90260 17d ago

Proprietary drivers for obscure hardware were the bane of my existence. Glad to see this SM750 driver open-sourced.

EdwardDiego 17d ago

NGL, I read the title initially as Why open source rocks? - a new SM750 (Silicon Motion GPU) HDMI Driver And got excited that you were open sourcing a chip.

techsage 17d ago

[dead]

reindeer2 17d ago

[flagged]

listingbott 17d ago

[flagged]