4 ms·
> Other commenters are correct that normally, KMS should just affect mode setting, not rendering. Clearly those commenters don't have much experience working c
by zeusk 4y ago
> Other commenters are correct that normally, KMS should just affect mode setting, not rendering.
Clearly those commenters don't have much experience working close to the wire around GPUs then. Scanout used to be very closely tied to rendering, and in some ways it still is. You can't take an arbitrary texture in GPU memory and scan it out to the display.
Windows has this thing called VidPN to work around the dependencies between source and target modes which gets even more complicated with VRR and virtual resolutions (retina).
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/introduction-to-video-present-networks https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
- stefan_ 4y agoHardware composer is the Android version of this: https://source.android.com/devices/graphics/implement-hwc https://source.android.com/devices/graphics/implement-hwc This has become a lot more important with smartphones than desktop systems. You now have often very different silicon for things like video decoding, graphics and scanout - and to achieve reasonable battery time you need common use cases like watching a video to not involve the GPU at all.
- froh 4y agoDedicated video decoding silicon is not part of the GPU?
- zeusk 4y agoVideo decoders are usually fixed function blocks, separate from the SMs (which I believe the parent is referring to by "GPU") but are still usually on the same physical silicon as the GPU (in case of SoCs, also shared with CPU). They're exposed as an independent engine on the GPU/SoC and can operate with most of the chip power gated.