>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.
> 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.... 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".
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.
I don't see what you mean by "condescending remarks", but I do think it is stretching it to claim "arbitrary filters" is a "basic feature that a video player is required to support now". As a consumer, I have absolutely _never_ used any such video filters, doubt most consumers are even aware of them, have seen few video players which support them, and most definitely I have no idea what they are in VLC. Do they even enable any video filters by default? The only video filter I have sometimes used is deinterlacing which doesn't really fit well in the GPU rendering pipeline anyway but fits very nicely in fixed hardware. So yes, I hardly see the need to stop using native accelerated video output and fallback to GPU just in case someone wants to use such filters. This is how I end up with a card which consumes 20W just for showing a static desktop on two monitors.
Anyway, discussing about this is besides the point, and forgive me from the rant above.
If you really need GPU video filters then the GPU is obviously going to be the best way to implement them, there's no discussion possible about that. But the entire point of TFA is to (dynamically) go back to a model where the GPU is _not_ in the middle. And that model -- sans GPU -- happens to match what Xv was doing and is actually faster and less power consuming than to always blindly use the GPU which is where we are now post-Xv.
>The only video filter I have sometimes used is deinterlacing
I don't know about anything else, but ffmpeg has some deinterlacing filters that run on the GPU. So your one example is a bad one.
>Anyway, discussing about this is besides the point, and forgive me from the rant above.
Next time can you please not post the rant? It's not interesting to parse through all that just to get to the point. It's also extremely uninteresting to have this conversation like "well I haven't personally used that so it must not be important". VLC and ffmpeg are used by millions (billions?) of people, so can we at least agree that neither of our own very particular and personal use cases are that important?
>But the entire point of TFA is to (dynamically) go back to a model where the GPU is _not_ in the middle.
No? Overlays are entirely driven by the GPU. The entire reason these are performant is because it's zero-copy from a GPU buffer to an overlay.
>And that model -- sans GPU -- happens to match what Xv was doing and is actually faster and less power consuming than to always blindly use the GPU which is where we are now post-Xv.
I have no idea what you're talking about. XV (with a driver that supports it) uses the GPU to do the overlays. If you aren't using any filters, this should have the same power consumption as XV.
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.
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.