3 ms·

I can tell you why this is happening! I think! OK, so first off, FKMS vs KMS. KMS is Kernel Mode Setting. This is the kernel's framework for setting video mod

by bri3d 5y ago

I can tell you why this is happening! I think! OK, so first off, FKMS vs KMS. KMS is Kernel Mode Setting. This is the kernel's framework for setting video modes, abstracting over HDMI/DSI initialization, timing parameters, etc. etc. across platforms. FKMS is still KMS, but it's a special KMS driver for the Pi which sets up HDMI using the DispmanX API into the Broadcom proprietary OS that runs alongside Linux on the Raspberry Pi. This is nice because it's dead simple for Linux (Linux quite literally gets to say "yo, gimme a 1920x1080 layer!") but bad because it relies on a proprietary blob and the blob can't be extended. Native KMS, on the other hand, sets up HDMI using native device access to the actual registers which affect the HDMI encoder, DSI link, and so on. This is more extensible and isn't closed source, but it's also mega complicated. Now, here's the kicker on your Pi. Other commenters are correct that normally, KMS should just affect mode setting, not rendering. But, on the Pi, this isn't true. KMS and FKMS _also_ affect the way _layers_ are configured in the DRM (Direct Render Manager) subsystem. Why? DispmanX isn't just a mode setter, it's also a scaling and compositing (layering) engine! So, in the course of bypassing DispmanX, the DRM system in KMS mode now needs to act differently - it needs to configure 2D compositing planes through the KMS system instead of through DispmanX. What's on a separate 2D compositing layer? The legacy cursor. Here's the switch where RealKMS is responsible for setting up the cursor compositing layers, a task which in FakeKMS was already handled by DispmanX: https://github.com/raspberrypi/linux/blob/aeaa2460db088fb2c97ae56dec6d7d0058c68294/drivers/gpu/drm/vc4/vc4_drv.c#L318 https://github.com/raspberrypi/linux/blob/aeaa2460db088fb2c9... https://github.com/raspberrypi/linux/blob/1fe617a917eac75800a8174373b3c0a5c1df26e1/drivers/gpu/drm/vc4/vc4_plane.c#L1638 https://github.com/raspberrypi/linux/blob/1fe617a917eac75800... Now, _why_ this makes your cursor lag, I don't know, but that's the difference.

zeusk 5y 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_ 5y ago
  Hardware 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 5y ago
    Dedicated video decoding silicon is not part of the GPU?
    - zeusk 5y ago
      Video 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.

by bri3d 5y ago

zeusk 5y 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_ 5y ago
Hardware 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 5y ago
  Dedicated video decoding silicon is not part of the GPU?
  - zeusk 5y ago
    Video 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.