xf86-video-amdgpu 21.0.0 Released For Radeon Linux Users Still On X.Org

[bridgman]

You don't need Xorg DDX drivers for XWayland, perhaps it can be said it acts as its own "driver" (not saying nothing is shared with modesetting DDX, no idea about this).

And the article is wrong, as the xf86-video-amdgpu driver for Xorg is still very recommendable by offering VRR in a stable release, has a more stable hardware cursor and automatically offers GPU upscaling resolutions with amdgpu.dc...

Xorg is the only DDX with a module loader.

Xwayland has no drivers, just built-in GBM & EGLStream backends for glamor. Everything else works via the Wayland protocol.

Thanks, and apologies for the bad information.

In my defence, I wasn't 100% sure so checked the Wayland page on FDO:

The server still runs the same 2D driver with the same acceleration code as it does when it runs natively.

https://wayland.freedesktop.org/xserver.html

I guess I must be misinterpreting that but I'm not sure how yet. I did just notice that statement is contradicted further down the page:

The separate X.Org video DDXes are not needed anymore. With this config it will only install the Xwayland binary and few other files:

[DL9220]

@Michael: "these X.Org DDX releases are of little value"

That is ridiculous. Just because X is old and boring from your standpoint doesn't mean maintenance releases are of little value. Slanted "journalism".

Besides, I haven't seen anybody proving Wayland would be 'more' . Just a case of changing to change, because we can.

[binarybanana]

and those sticking to X.Org most often just using the generic xf86-video-modesetting driver

The switch to the modesetting driver has been one of the worst meme driven decisions in the history of the Linux desktop. It has been pushed by basically every distribution even though there are major downsides in terms of performance and features. It doesn't and can't take any advantage of hardware specific functionality like the 2D acceleration engine on Intel hardware, but emulates it through OpenGL with GLAMOR. That's nice as a fallback if you have nothing else, but can't compete with special purpose silicon.

It also lacks some major must-have's like TearFree. All the complaints about tearing on X wouldn't have been a thing if distributions shipped a real driver that knows how to prevent tearing. And no, an application level compositor won't fix it if you have multiple monitors with different refresh rates, or rotation and other transformations applied to the output.

In theory the present extension makes the necessary machinery available. It allows syncing frame presentation to specific crtcs (outputs) and you can have different frames sync to different outputs by specifying the respective crtc the output belongs to as an argument when calling XPresent() on your frame. That mechanism allows dynamically changing vsync when moving windows around different monitors just like on Wayland. Curiously mesa actually uses present to put frames on the screen! But it doesn't seem to have any way to change which monitor to sync to, not even as a environment variable like nvidia. And it sure isn't just doing the right thing by checking where the window is displayed. That can probably be fixed with a small shim through LD_PRELOAD that allows configuring and/or automating it. I've been planning to look into that at some point...

This situation is similar to the mixed DPI case where the foot people refuse to support something on Xorg just because they want to push their own half baked crap on everyone. In reality Xorg makes all the necessary information (display size, resolution and arrangement) available through the randr extension. Qt can actually make use of it and not only that, it does it better than GTK does on Wayland! Unlike GTK it actually changes the resolution things get rendered at, even for fractions. Meanwhile the foot people consider scaling things down from some integer multiple a satisfying solution. Maybe KDE inherited that functionality, but I'm not sure.

BTW, you can get something equivalent in quality to the Wayland solution to this problem by applying a transformation on the scanout buffer. The simplest way to make it work is to run xrandr --output $LOWDPI --scale-from $VIRTUALRES, where $VIRTUALRES is whatever resolution that monitor would have if it was the same DPI as the high DPI monitor. Now your low DPI monitor has the same "virtual DPI" as the other monitor and things are the same size. Of course it's using bilinear scaling so it's gonna be blurry, but Wayland devs and fans consider this perfectly acceptable. I guess it's better than upscaling on the high DPI monitor at least.

[evil_core]

The switch to the modesetting driver has been one of the worst meme driven decisions in the history of the Linux desktop. It has been pushed by basically every distribution even though there are major downsides in terms of performance and features. It doesn't and can't take any advantage of hardware specific functionality like the 2D acceleration engine on Intel hardware, but emulates it through OpenGL with GLAMOR. That's nice as a fallback if you have nothing else, but can't compete with special purpose silicon.

"Modern Silicon" don't have 2D engine(except framebuffer and blitter), so it was necessity to accelerate primitives drawing, using 3D engine (which is pretty powerful on "modern silicons"). It's not related at all to modesetting/KMS in kernel.
There are KMS/modesetting drivers for vintage hardware with proper 2d acceleration.
And you are using dedicated DDX Xorg drivers over kernel modesetting/KMS driver for Intel and radeon.

I guess you don't know that there's difference between kernel-space modesetting(KMS based) drivers and userspace DDX(Xorg driver), also called 'modesetting' (generic/universal driver, so it has to use 3d engine, because it's the only accelerated drawing path[except blitter] on modern GPUs. But you are free to use intel/radeon/amdgpu if you wish for Xorg. For legacy hardware [without 3d accel] you are forced to use native DDX, because of GLAMOR path in userspace 'modesetting'. And Wayland is not suitable for them, because all DE/WMs use OpenGL or Vulkan to render BTW.)

[MrCooper]

In my defence, I wasn't 100% sure so checked the Wayland page on FDO:

https://wayland.freedesktop.org/xserver.html

I guess I must be misinterpreting that but I'm not sure how yet. I did just notice that statement is contradicted further down the page:

Yeah, the first paragraph looks like a leftover from when the plan was to use Xorg on Wayland, with special support in each driver. Per the "X Server" paragraph below, instead the separate Xwayland DDX landed in xserver Git master over 7 years ago and was first released with xserver 1.16.

[binarybanana]

"Modern Silicon" don't have 2D engine(except framebuffer and blitter), so it was necessity to accelerate primitives drawing, using 3D engine (which is pretty powerful on "modern silicons"). It's not related at all to modesetting/KMS in kernel.
There are KMS/modesetting drivers for vintage hardware with proper 2d acceleration.
And you are using dedicated DDX Xorg drivers over kernel modesetting/KMS driver for Intel and radeon.

Look here: https://01.org/sites/default/files/d...pyengine_0.pdf

Every Intel GPU ships with that and it's quite a bit more powerful than a pure memory copying engine. Most of the drawing done on a desktop can be done using that instead, which is both faster and more efficient than firming up the 3D block. That's why the Intel driver is so fast with SNA.

Not mentioned in there are what Intel calls "GD-accelleration". Intel GPUs can draw anti aliased lines, do color space conversations and alpha blending, all on their 2D engine. I don't think any of that is usable through the purely generic KMS interfaces.