Comment by delta_p_delta_x
3 days ago
I've mentioned this elsewhere, but nowadays, anything you see out of an HDMI/DP/eDP cable comes out of a GPU. Modern OSs make it impossible to do 'software rendering' any more; it's just that much faster and that much more efficient, even if it is harder to program directly. Even IPMI BMCs have a tiny GPU doing stuff.
Why is it “impossible”? If you mean that a rendered frame has to reside in the graphics memory before being sent to the display, then I think that was the case even when software rendering was a thing.
If you mean rendering a frame entirely in the main memory by the CPU, then there is nothing making it impossible. I mean, most major 3D rendering software still have CPU renderers as an option. Slow, but doable.
P.S: I am using offline renderers here as an extreme example. A game renderer - especially for scenes like Quake’s - are definitely going to be far simpler and cheaper.
By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.
Of course, offline rendering is a different story.
Modern "GPUs" have the ability to scan out from multiple buffers at the same time and do rectangular compositing during the scan out -- basically like a few giant sprites. It's got absolutely nothing to do with normal GPU work. Zero.
It lets a few unobstructed windows do animation without having to involve the compositor => lower latency AND lower energy use. They do NOT have to be full screen at all.
Oh, and they can also handle framebuffer formats that aren't RGB. This is very useful for video, as the natural format there is YUV or something similar. The YUV => RGB conversion step becomes unnecessary.
I suppose the disagreement here is on the scope of “rendering.”
There's in no path for that. Each GPU is different, and I suspect won't even let the CPU access the final framebuffer they use for video signals, even if you wrote the driver yourself.
As for Windows compositing, use the graphics API to acquire exclusive fullscreen. Vulkan gives this example:
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/sam...
> the OS still does compositing in the background
Since Windows 10 fullscreen mode can use a borderless window, with DWM not compositing if the game covers the entire screen. That's how Alt-Tab switches smoother and faster now.
https://devblogs.microsoft.com/directx/demystifying-full-scr...
Using the extra unpopulated memory slots on your VGA card to get that 1024x786 at 256 colors. 800x600 is the largest which will fit in 512k of video memory at that colors depth, or getting 16bit color space in 800x600 due to having doubled your memory from 512k to 1024k. And those were definately the software rendering days, every ramdac needs it's own memory pool.
It's also because at this point the operating systems themselves use the accelerated graphics architecture for things like window compositing, because that also turned out to be faster. And it's much easier to do cute little visual effects like wiggles and window distorts if those entities are actually 3D rendered graphics objects.
Even the standard desktop experience is a 3D graphics application these days.
Indeed. I wrote up a commment[1] explaining why code editors needed graphics acceleration some months ago; this ties in to that.
[1]: https://news.ycombinator.com/item?id=44966266
I think you're misunderstanding. No one is saying that a GPU isn't involved at all.
But if you rasterize your frames into a buffer using the CPU (and not OpenGL, Vulkan, Metal, D3D, etc.), and then scan that out on the GPU, that is indeed software rendering in the sense that matters here.
The idea that software rendering is impossible because the GPU owns the scanout buffers is just silly pedantry.