3 ms·

Frankly, it was X11 which introduced "Graphics Offload" in the first place, with stuff like XV, chroma keying, and hardware overlays. Then compositors came and

Frankly, it was X11 which introduced "Graphics Offload" in the first place, with stuff like XV, chroma keying, and hardware overlays. Then compositors came and we moved to texture_from_surface extensions and uploading things into GPUs. This is just the eternal wheel of reinventing things in computing (TM) doing yet another iteration and unlikely to give any tangible benefits over the situation from decades ago.

play_ac 3y ago
No, nothing like this exists in X11. Xorg still doesn't really have support for non-RGB surfaces. DRI3 gets you part of the way there for attaching GPU buffers but the way surfaces work would have to be overhauled to work more like Wayland, where they can be any format supported by the GPU. There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would. Yes, you're technically right that this would have been possible years ago but it wasn't actually ever done, because X11 never had the ability to do it at the same time as using compositing.
- AshamedCaptain 3y ago
  > Xorg still doesn't really have support for non-RGB surfaces You really need to add context to these statements, because _right now_ I am using through Xorg a program which uses a frigging colormap, which is as non-RGB as it gets. The entire reason Xlib has this "WhitePixel" and XGetPixel and XYPixmap and other useless functions which normally fetch a lot of ire is because it tries to go out of its way to support practically other-wordly color visuals and image formats. If anything, I'd say it is precisely RGB which has the most problems with X11, specially when you go more than 24bpp. > there for attaching GPU buffers None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out, hardware layers or not. Exactly what Xv is about, and the reason Xv supports formats like YUV. > There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would As if that prevented any of the extensions done to X11 in the last three decades, including Xv.
  - play_ac 3y ago
    >I am using through Xorg a program which uses a frigging colormap That doesn't change what I said. The colormap is mapping indexes to RGB palette entries and technically doesn't even support any other color spaces. Nothing about that is "non-RGB". The other visuals are just various other ways to do RGB. If this isn't making sense to you, think about how this would be implemented in the driver. >None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out I'm sorry? What do you suppose is doing the direct scan-out to the monitor if not the GPU? >As if that prevented any of the extensions done to X11 in the last three decades, including Xv. That's not relevant, XV actually does support running over the network as long as you don't use the SHM functions. But regardless, yes, it actually did. The main example being indirect GLX which hasn't been updated in decades because it's not feasible to run it over the network anymore.
kaba0 3y ago
There are plenty of wheel reinventions in IT, but let’s not pretend that modern graphics are anything like it used to be. We have 8k@120Hz screens now, the amount of pixels that have to be displayed in a short amount of time is staggering.
- AshamedCaptain 3y ago
  At the same time, you also have hardware that can push those pixels without problem. When X and these technologies were introduced, the hardware was not able to store the entire framebuffer for one screenful in memory, let alone two. Nowadays you are able to store a handful at the very minimum. Certainly there's a different level of performance here in all parts, but the concepts have changed very little, and this entire article kind of shows it.
  - mananaysiempre 3y ago
    Storing is one thing, pushing another. 32bpp×4K@60Hz works out to 1.8GB/s, which even on modern CPUs requires you to not do stupid things—e.g. a C loop with a (modest) iteration per byte will likely end up an order of magnitude slower. And that’s if you’re doing 32bpp SDR like it’s 2005; a floating-point pixel format will be four times more data than that.

play_ac 3y ago

No, nothing like this exists in X11. Xorg still doesn't really have support for non-RGB surfaces. DRI3 gets you part of the way there for attaching GPU buffers but the way surfaces work would have to be overhauled to work more like Wayland, where they can be any format supported by the GPU. There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would. Yes, you're technically right that this would have been possible years ago but it wasn't actually ever done, because X11 never had the ability to do it at the same time as using compositing.

AshamedCaptain 3y ago
> Xorg still doesn't really have support for non-RGB surfaces You really need to add context to these statements, because _right now_ I am using through Xorg a program which uses a frigging colormap, which is as non-RGB as it gets. The entire reason Xlib has this "WhitePixel" and XGetPixel and XYPixmap and other useless functions which normally fetch a lot of ire is because it tries to go out of its way to support practically other-wordly color visuals and image formats. If anything, I'd say it is precisely RGB which has the most problems with X11, specially when you go more than 24bpp. > there for attaching GPU buffers None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out, hardware layers or not. Exactly what Xv is about, and the reason Xv supports formats like YUV. > There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would As if that prevented any of the extensions done to X11 in the last three decades, including Xv.
- play_ac 3y ago
  >I am using through Xorg a program which uses a frigging colormap That doesn't change what I said. The colormap is mapping indexes to RGB palette entries and technically doesn't even support any other color spaces. Nothing about that is "non-RGB". The other visuals are just various other ways to do RGB. If this isn't making sense to you, think about how this would be implemented in the driver. >None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out I'm sorry? What do you suppose is doing the direct scan-out to the monitor if not the GPU? >As if that prevented any of the extensions done to X11 in the last three decades, including Xv. That's not relevant, XV actually does support running over the network as long as you don't use the SHM functions. But regardless, yes, it actually did. The main example being indirect GLX which hasn't been updated in decades because it's not feasible to run it over the network anymore.

kaba0 3y ago

There are plenty of wheel reinventions in IT, but let’s not pretend that modern graphics are anything like it used to be. We have 8k@120Hz screens now, the amount of pixels that have to be displayed in a short amount of time is staggering.

AshamedCaptain 3y ago
At the same time, you also have hardware that can push those pixels without problem. When X and these technologies were introduced, the hardware was not able to store the entire framebuffer for one screenful in memory, let alone two. Nowadays you are able to store a handful at the very minimum. Certainly there's a different level of performance here in all parts, but the concepts have changed very little, and this entire article kind of shows it.
- mananaysiempre 3y ago
  Storing is one thing, pushing another. 32bpp×4K@60Hz works out to 1.8GB/s, which even on modern CPUs requires you to not do stupid things—e.g. a C loop with a (modest) iteration per byte will likely end up an order of magnitude slower. And that’s if you’re doing 32bpp SDR like it’s 2005; a floating-point pixel format will be four times more data than that.