6 ms·

That article wasn't really accurate, most clients aren't using the X drawing commands anymore. The "vast majority of cases" has moved to using GL or Vulkan, whi

by md8z 5y ago

That article wasn't really accurate, most clients aren't using the X drawing commands anymore. The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network.

cesarb 5y ago
> The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network. IIRC, GLX did serialize over the network (though AFAIK limited to an older version of OpenGL; the vast majority of cases has moved to a newer version of OpenGL).
- md8z 5y ago
  Yeah, indirect GLX is limited to OpenGL 1.4 and earlier. It also isn't even enabled by default on recent Xorg releases, you have to opt-into it.
sprash 5y ago
Then why not use a wire protocol for Vulkan? SPIRV already exists. It only needs some wrapper code tacked on to work as a X extension and you have perfectly efficient server side rendering that potentially works even over the network without breaking anybodies backwards compatibility.
- md8z 5y ago
  I'm very confused by this comment, SPIR-V is not a wire protocol for Vulkan. And you can't really serialize Vulkan over the network, that breaks things like vkMapMemory. If you want something like a remote Vulkan, the thing to watch there would be WebGPU.
  - sprash 5y ago
    WebGPU translates 1:1 to SPIR-V.
    - md8z 5y ago
      That sentence doesn't really make sense to me, did you mean WGSL translates 1:1 to SPIR-V? "WebGPU" refers to the API, not the shading language.
      - sprash 5y ago
        Yes I was referring to the "WebGPU Shading Language" which I abbreviated with WebGPU which should be obvious. The WebGPU API is the boiler plate you need to make WGSL over the wire work. My original proposal was an X extension in a similar fashion that makes SPIR-V over the wire work.
        md8z 5y ago
        I don't see why you would need an X extension, WebGPU works fine within a browser. You don't need to touch X or Wayland or Mesa or anything.
AshamedCaptain 5y ago
The number of Vulkan or GL programs running in a desktop Linux is close to zero (or at most 1: the compositor). Browsers vary but on most setups they use practically nothing with GL/Vulkan (blame drivers). Gtk+ (even 3) still sends X drawing commands. Qt5 does not by default (it renders by itself, without any GL/Vulkan) but can still be configured to use X.
- md8z 5y ago
  Qt has Qt Quick and QGraphicsScene which will use a GL backend. GTK4 has a GL backend by default. Web browsers and Electron use Skia which has GL and Vulkan backends. Pretty much every video game is using GL and Vulkan already, or Proton which translates D3D to Vulkan. Video players are using VA-API directly instead of XvMC. The only thing in your list that doesn't have a GPU accelerated backend is GTK3, which GNOME is currently migrating away from to use GTK4. To my knowledge GTK3 also tries really hard to use Cairo on the client side for as many things as possible, and generally avoids using X drawing commands. I think it should be fairly obvious by now that graphics developers will prefer to use accelerated APIs whenever possible and don't care at all for "network transparency" if it means they have to use an outdated and mostly inadequate API.
  - AshamedCaptain 5y ago
    I have absolutely no single program using Qt Quick on my desktop, nor I can actually remember the name of any single one. Which is funny since I actually was a Qt Quick developer in the past and can tell you a shitton of embedded platforms (i.e. cars) that use Qt Quick. Just no desktop programs. I do not have any single Gtk4+ program on my desktop, and I use a quite up-to-date rolling distribution. Skia having a GL backend does not mean it is used. Firefox does not use it on almost any Linux platform. It still blacklists even the FOSS drivers. Tested today with upstream v93 and using radeon opensource driver. No idea why bring VA-API into this. It is practically the same thing as XvMC with a much more generic API. It is also not necessarily Vulkan or GL. Ironically this is also one area where intelligent remoting tools win (they can send the original compressed video stream down the wire. RDP does it), where a plain H264 stream will be forced to recompress, increasing latency at best. Cairo is also backed by X rendering and this is the default. Basically, if I ignore the compositor and games, I do not have _any single program_ on my system which uses GL or Vulkan for 2d graphics. Not surprising: in my experience, using GL for 2D graphics (i.e. arcs, lines, etc.) usually ends up in a big slowdown -- and a big increase in memory usage and crashes. It is mostly worth only for when you do pure texture manipulation like scaling, rotating, etc. i.e. final compositing or layering. And, if, in addition to the above, I ignore the browser, and set the corresponding Qt flag, then _all programs_ in my system render using X rendering. Easily tested because the performance difference is abysmal when using NX.

by md8z 5y ago

cesarb 5y ago

> The "vast majority of cases" has moved to using GL or Vulkan, which also doesn't serialize over the network. IIRC, GLX did serialize over the network (though AFAIK limited to an older version of OpenGL; the vast majority of cases has moved to a newer version of OpenGL).

md8z 5y ago
Yeah, indirect GLX is limited to OpenGL 1.4 and earlier. It also isn't even enabled by default on recent Xorg releases, you have to opt-into it.

sprash 5y ago

Then why not use a wire protocol for Vulkan? SPIRV already exists. It only needs some wrapper code tacked on to work as a X extension and you have perfectly efficient server side rendering that potentially works even over the network without breaking anybodies backwards compatibility.

md8z 5y ago
I'm very confused by this comment, SPIR-V is not a wire protocol for Vulkan. And you can't really serialize Vulkan over the network, that breaks things like vkMapMemory. If you want something like a remote Vulkan, the thing to watch there would be WebGPU.
- sprash 5y ago
  WebGPU translates 1:1 to SPIR-V.
  - md8z 5y ago
    That sentence doesn't really make sense to me, did you mean WGSL translates 1:1 to SPIR-V? "WebGPU" refers to the API, not the shading language.
    - sprash 5y ago
      Yes I was referring to the "WebGPU Shading Language" which I abbreviated with WebGPU which should be obvious. The WebGPU API is the boiler plate you need to make WGSL over the wire work. My original proposal was an X extension in a similar fashion that makes SPIR-V over the wire work.
      - md8z 5y ago
        I don't see why you would need an X extension, WebGPU works fine within a browser. You don't need to touch X or Wayland or Mesa or anything.

AshamedCaptain 5y ago

The number of Vulkan or GL programs running in a desktop Linux is close to zero (or at most 1: the compositor). Browsers vary but on most setups they use practically nothing with GL/Vulkan (blame drivers). Gtk+ (even 3) still sends X drawing commands. Qt5 does not by default (it renders by itself, without any GL/Vulkan) but can still be configured to use X.

md8z 5y ago
Qt has Qt Quick and QGraphicsScene which will use a GL backend. GTK4 has a GL backend by default. Web browsers and Electron use Skia which has GL and Vulkan backends. Pretty much every video game is using GL and Vulkan already, or Proton which translates D3D to Vulkan. Video players are using VA-API directly instead of XvMC. The only thing in your list that doesn't have a GPU accelerated backend is GTK3, which GNOME is currently migrating away from to use GTK4. To my knowledge GTK3 also tries really hard to use Cairo on the client side for as many things as possible, and generally avoids using X drawing commands. I think it should be fairly obvious by now that graphics developers will prefer to use accelerated APIs whenever possible and don't care at all for "network transparency" if it means they have to use an outdated and mostly inadequate API.
- AshamedCaptain 5y ago
  I have absolutely no single program using Qt Quick on my desktop, nor I can actually remember the name of any single one. Which is funny since I actually was a Qt Quick developer in the past and can tell you a shitton of embedded platforms (i.e. cars) that use Qt Quick. Just no desktop programs. I do not have any single Gtk4+ program on my desktop, and I use a quite up-to-date rolling distribution. Skia having a GL backend does not mean it is used. Firefox does not use it on almost any Linux platform. It still blacklists even the FOSS drivers. Tested today with upstream v93 and using radeon opensource driver. No idea why bring VA-API into this. It is practically the same thing as XvMC with a much more generic API. It is also not necessarily Vulkan or GL. Ironically this is also one area where intelligent remoting tools win (they can send the original compressed video stream down the wire. RDP does it), where a plain H264 stream will be forced to recompress, increasing latency at best. Cairo is also backed by X rendering and this is the default. Basically, if I ignore the compositor and games, I do not have _any single program_ on my system which uses GL or Vulkan for 2d graphics. Not surprising: in my experience, using GL for 2D graphics (i.e. arcs, lines, etc.) usually ends up in a big slowdown -- and a big increase in memory usage and crashes. It is mostly worth only for when you do pure texture manipulation like scaling, rotating, etc. i.e. final compositing or layering. And, if, in addition to the above, I ignore the browser, and set the corresponding Qt flag, then _all programs_ in my system render using X rendering. Easily tested because the performance difference is abysmal when using NX.