4 ms·

To this day, moving a Haiku window under a 5k unaccelerated EFI GOP framebuffer still feels _significantly_ faster than doing the same under Windows 11, and eve

To this day, moving a Haiku window under a 5k unaccelerated EFI GOP framebuffer still feels _significantly_ faster than doing the same under Windows 11, and everything KWin's X/Wayland has to offer on the same hardware (AMD Navi 2 GPU). > BeOS and Haiku allowed exposure to kernel graphics buffers decades ago In any case, X also allowed this for ages, with XV and XShm and the like. Of course then everyone got rid of this in order to have the GPU in the middle for fancier animations and whatnot, and things went downhill since.

baybal2 3y ago
Android has horrific UI latency despite heavily employing hardware acceleration. Enlightenments EFL was exclusively software for a long time, but is buttery smooth despite largely using redraw most of the time. Hardware acceleration does not compensate for the lack of hard computer science knowledge about efficient memory operations, caching, and such
- ElectricalUnion 3y ago
  Hardware acceleration in this case is to draw less power doing day-to-day operations and not melt the user's hand. In the general case most effective hardware acceleration uses are supposed to increase latency. Let's take another example for the analogy: you can run your LLM straight in the CPU and it will have awesome latency and very poor throughput; or you can take your sweet time to load the weights into your GPU/NPU/TPU/memory-in-compute device and run it hardware accelerated at lower energy cost and higher throughput.
play_ac 3y ago
>In any case, X also allowed this for ages, with XV and XShm and the like. No, XShm doesn't do that and the way XV does it is completely dependent on drivers. If you're using Glamour then XV won't use overlays at all. XShm uses a buffer created in CPU memory allocated by the client that the X server then has to copy to the screen. > Of course then everyone got rid of this in order to have the GPU in the middle for fancier animations No, for video, the GPU is used in the middle so you can do post-processing without copying everything into main memory and stalling the whole pipeline. I'd like to see an actual benchmark for how a fullscreen 5k video with post-processing plays on Haiku without any hardware acceleration.
- deleted 3y ago
  [deleted]
  - play_ac 3y ago
    Very few clients I've seen actually call XShmGetImage to draw on the root window because this is incredibly slow and error prone. Having multiple clients do this at the same time is an almost guaranteed way to cause graphical corruption. On modern hardware with any kind of acceleration you never want to map the framebuffer into userspace like this. The actual suggested use case of XShm is for the client to allocate its own buffer, which then gets copied to the screen. >colorspace conversion, scaling, etc. This is only a tiny subset of the post-processing operating a video player would implement. If you want arbitrary post-proccessing then realistically, you need to use the GPU.
- AshamedCaptain 3y ago
  > XShm uses a buffer created in CPU memory allocated by the client that the X server then has to copy to the screen. Fair enough. Even with XShmCreatePixmap, you are still never simply mmaping the card's actual entire framebuffer, unlike what BDirectWindow allows (if https://www.haiku-os.org/legacy-docs/benewsletter/Issue3-12.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue3-12.... is to believed, which is closer to something like DGA). In XShm, the server still has to copy your shared memory segment to the actual framebuffer. (sorry for previous answer here, I misunderstood your comment) > No, for video, the GPU is used in the middle so you can do post-processing without copying everything into main memory and stalling the whole pipeline. Depends on what you mean by "post-processing". You can do many types of card-accelerated zero-copy post-processing using XV: colorspace conversion, scaling, etc. At the time, scaling the video in software or even just doing an extra memory copy per frame would have tanked frame rate -- Xine can be used to watch DVDs in PentiumII-level hardware. Obviously you cannot put the video in the faces of rotating 3D cubes, but this is precisely what I call "fancy animations".
  - play_ac 3y ago
    >colorspace conversion, scaling There's a lot more than that. Please consider installing the latest version of VLC or something like that and checking all the available post-processing effects and filters. These aren't "fancy animations" and they're not rotating 3D cubes, they're basic features that a video player is required to support now. If you want to support arbitrary filters then you need to use the GPU. All these players stopped using XV ages ago, on X11 you'll get the GPU rendering pipeline too because of this. I don't really see what's the point of making these condescending remarks like trying to suggest that everyone is stupid and is only interested in making wobbly windows and spinning cubes. Those have never been an actual feature of anything besides Compiz, which is a dead project.

baybal2 3y ago

Android has horrific UI latency despite heavily employing hardware acceleration. Enlightenments EFL was exclusively software for a long time, but is buttery smooth despite largely using redraw most of the time. Hardware acceleration does not compensate for the lack of hard computer science knowledge about efficient memory operations, caching, and such

ElectricalUnion 3y ago
Hardware acceleration in this case is to draw less power doing day-to-day operations and not melt the user's hand. In the general case most effective hardware acceleration uses are supposed to increase latency. Let's take another example for the analogy: you can run your LLM straight in the CPU and it will have awesome latency and very poor throughput; or you can take your sweet time to load the weights into your GPU/NPU/TPU/memory-in-compute device and run it hardware accelerated at lower energy cost and higher throughput.

play_ac 3y ago

>In any case, X also allowed this for ages, with XV and XShm and the like. No, XShm doesn't do that and the way XV does it is completely dependent on drivers. If you're using Glamour then XV won't use overlays at all. XShm uses a buffer created in CPU memory allocated by the client that the X server then has to copy to the screen. > Of course then everyone got rid of this in order to have the GPU in the middle for fancier animations No, for video, the GPU is used in the middle so you can do post-processing without copying everything into main memory and stalling the whole pipeline. I'd like to see an actual benchmark for how a fullscreen 5k video with post-processing plays on Haiku without any hardware acceleration.

deleted 3y ago
[deleted]
- play_ac 3y ago
  Very few clients I've seen actually call XShmGetImage to draw on the root window because this is incredibly slow and error prone. Having multiple clients do this at the same time is an almost guaranteed way to cause graphical corruption. On modern hardware with any kind of acceleration you never want to map the framebuffer into userspace like this. The actual suggested use case of XShm is for the client to allocate its own buffer, which then gets copied to the screen. >colorspace conversion, scaling, etc. This is only a tiny subset of the post-processing operating a video player would implement. If you want arbitrary post-proccessing then realistically, you need to use the GPU.
AshamedCaptain 3y ago
> XShm uses a buffer created in CPU memory allocated by the client that the X server then has to copy to the screen. Fair enough. Even with XShmCreatePixmap, you are still never simply mmaping the card's actual entire framebuffer, unlike what BDirectWindow allows (if https://www.haiku-os.org/legacy-docs/benewsletter/Issue3-12.html https://www.haiku-os.org/legacy-docs/benewsletter/Issue3-12.... is to believed, which is closer to something like DGA). In XShm, the server still has to copy your shared memory segment to the actual framebuffer. (sorry for previous answer here, I misunderstood your comment) > No, for video, the GPU is used in the middle so you can do post-processing without copying everything into main memory and stalling the whole pipeline. Depends on what you mean by "post-processing". You can do many types of card-accelerated zero-copy post-processing using XV: colorspace conversion, scaling, etc. At the time, scaling the video in software or even just doing an extra memory copy per frame would have tanked frame rate -- Xine can be used to watch DVDs in PentiumII-level hardware. Obviously you cannot put the video in the faces of rotating 3D cubes, but this is precisely what I call "fancy animations".
- play_ac 3y ago
  >colorspace conversion, scaling There's a lot more than that. Please consider installing the latest version of VLC or something like that and checking all the available post-processing effects and filters. These aren't "fancy animations" and they're not rotating 3D cubes, they're basic features that a video player is required to support now. If you want to support arbitrary filters then you need to use the GPU. All these players stopped using XV ages ago, on X11 you'll get the GPU rendering pipeline too because of this. I don't really see what's the point of making these condescending remarks like trying to suggest that everyone is stupid and is only interested in making wobbly windows and spinning cubes. Those have never been an actual feature of anything besides Compiz, which is a dead project.