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.
It is just an old school 2D style card, with some (shape) primitives acceleration (unused), two logical controllers (no idea why), but has DMA (used) and a hardware cursor (also used). There's no onboard audio either.
It's pretty much a GPU for rack mount servers that require occasional log in.
It's exactly what I was looking for desktop work, it runs cinnamon fairly well, and won't clash with my Nvidia setup :)
Yes. Stupid comment of mine tbh, I saw it as pointless for this card, but they wouldn't make a separate version of the controller just for this
One avenue I looked at for a real 2560px width was that the second controller was physically independent and could have different hardware limits of the first controller by virtue of supporting DVI directly (but not being physically connected to another port).
Unfortunately other controller is logical so that was a bust.
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.
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 I could use the combined compute power from both generations on a single machine.
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!
VGA displays are something of a dying breed, and HDMI is the single likeliest interface you might find on a random newish display, so there is a market for absolute cheapest, most basic HDMI output device you can make. If you're going to build that interface, 1080p is the resolution you need to target. My point was simply that 16MB is just barely enough to build that interface, and barely enough is still enough.
datacenter guys didn't like digitals. they embrace blurry SVGA pictures coming through excessively long cables and sometimes mechanical switches, and to them DVI/HDMI felt to be an all-or-nothing risk factor
It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.
I will be very surprised if it doesn't start switching over to USB-C over the next decade or two. Having a single port capable of doing the entire local KVM dance using readily-available hardware is just a no-brainer.
Some switches have already started using USB-C for serial instead of RJ45. When the technician is 100% already carrying a smartphone and C-to-C cable to charge it, making the console available with zero additional adapters is quite attractive.
So, display out from USB-C cable is not display signal over USB 3.x digital signal, it's just an electronic analog patch-through to GPU. The pins in the port actually run raw DisplayPort signals when that feature is activated. So you can't plug a laptop to a server and get nicely packetized screen frames out over the USB host hardware. This is often not clearly communicated...
You can put a USB to RS232C or USB to Ethernet adapter behind the port to then expose ttyS0 or to serve a management webpage, that could happen, but I think the DB-9 and/or RGB would have to stay in that case.
Comments
A GPU with HDMI and 16MB of VRAM is a very strange combination.
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.
It is just an old school 2D style card, with some (shape) primitives acceleration (unused), two logical controllers (no idea why), but has DMA (used) and a hardware cursor (also used). There's no onboard audio either. It's pretty much a GPU for rack mount servers that require occasional log in. It's exactly what I was looking for desktop work, it runs cinnamon fairly well, and won't clash with my Nvidia setup :)
two logical controllers (no idea why)
For dual-monitor versions?
Yes. Stupid comment of mine tbh, I saw it as pointless for this card, but they wouldn't make a separate version of the controller just for this
One avenue I looked at for a real 2560px width was that the second controller was physically independent and could have different hardware limits of the first controller by virtue of supporting DVI directly (but not being physically connected to another port).
Unfortunately other controller is logical so that was a bust.
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.
old nvidia cards are pretty terrible actually on linux due to the proprietary drivers not working on mainline kernel after ~6.6
Maybe an LLM can also assist with modifying the Nvidia driver appropriately.
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 I could use the combined compute power from both generations on a single machine.
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!
It's the HDMI output that's the oddity; mid-90s cards with that much (little?) VRAM could already do 2048x1536x32, but usually had a VGA connector.
Yeah, I could've been clearer.
VGA displays are something of a dying breed, and HDMI is the single likeliest interface you might find on a random newish display, so there is a market for absolute cheapest, most basic HDMI output device you can make. If you're going to build that interface, 1080p is the resolution you need to target. My point was simply that 16MB is just barely enough to build that interface, and barely enough is still enough.
datacenter guys didn't like digitals. they embrace blurry SVGA pictures coming through excessively long cables and sometimes mechanical switches, and to them DVI/HDMI felt to be an all-or-nothing risk factor
It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.
I will be very surprised if it doesn't start switching over to USB-C over the next decade or two. Having a single port capable of doing the entire local KVM dance using readily-available hardware is just a no-brainer.
Some switches have already started using USB-C for serial instead of RJ45. When the technician is 100% already carrying a smartphone and C-to-C cable to charge it, making the console available with zero additional adapters is quite attractive.
So, display out from USB-C cable is not display signal over USB 3.x digital signal, it's just an electronic analog patch-through to GPU. The pins in the port actually run raw DisplayPort signals when that feature is activated. So you can't plug a laptop to a server and get nicely packetized screen frames out over the USB host hardware. This is often not clearly communicated...
You can put a USB to RS232C or USB to Ethernet adapter behind the port to then expose ttyS0 or to serve a management webpage, that could happen, but I think the DB-9 and/or RGB would have to stay in that case.
3840 x 2160[px] x 24[bit/px] / 8[bit/byte] = 24883200[bytes]
^ / 1024^2[bytes/MB] = 23.73[MB]