kdrive/fbdev: Various glamor fixes and improvements

[stefan11111]

kdrive/fbdev: Allow forcing glamor to create GL/GLES contexts

This brings Xfbdev's glamor code in line with glamor/glamor_egl.c

This patch also fixes #1832 (comment)

[stefan11111]

@metux @cepelinas9000 @notbabaisyou @X11Libre/dev
Now that I was finally able to fix #1832 (comment) , I wonder what the defaults for glamor egl should be.

With glamor egl, even if hw accelerated, in some cases it will end up slower that with just llvmpipe with the dri glx backend.

However, with glamor egl, I get better performance in games (even if not for general desktop use), and I can get vulkan working (no Idea how that works, there is no DRI3 here, but it does).

Should we just always enable glamor egl, and let the user switch it off with -dumb?
Should we do what glamor/glamor_egl.c does? Refuse to initialize on top of softpipe/llvmpipe?
Should we always default to not using glamor, unless that's the only way to get glx working?
Should we do something else?

[metux]

With glamor egl, even if hw accelerated, in some cases it will end up slower that with just llvmpipe with the dri glx backend.

How does that happen ?
IMHO, main advantage of glamor is for 2D operations - just using existing 3D pipeline instead of explicit per-driver implementation. Maybe there are some GPUs that slower on certain operations that today's CPUs ? Perhaps some GPUs need special optimized code for certain operations ? (maybe that's the case for Intel ?)

Haven't checked the exact relation between glamor and GLX yet.

I can imagine that when using GLX & glamor, both might somehow getting in conflict into each other, stalling each other down.

However, with glamor egl, I get better performance in games (even if not for general desktop use), and I can get vulkan working (no Idea how that works, there is no DRI3 here, but it does).

Why should Vulkan depend on DRI3 ?

Should we just always enable glamor egl, and let the user switch it off with -dumb? Should we do what glamor/glamor_egl.c does? Refuse to initialize on top of softpipe/llvmpipe? Should we always default to not using glamor, unless that's the only way to get glx working? Should we do something else?

Running 2D ops ontop of softpipe probably is slower, so perhaps fall back to optimized CPU code here.

[stefan11111]

With glamor egl, even if hw accelerated, in some cases it will end up slower that with just llvmpipe with the dri glx backend.

How does that happen ? IMHO, main advantage of glamor is for 2D operations - just using existing 3D pipeline instead of explicit per-driver implementation. Maybe there are some GPUs that slower on certain operations that today's CPUs ? Perhaps some GPUs need special optimized code for certain operations ?

My guess is that it's because gpu's usually draw into tiled buffers (when using drm), while a framebuffer is linear (in the ideal case).

From my testing, I get lower fps in glxgears when using nvidia's gl through glamor egl, but I get better performance in games, compared to just running llvmpipe with the dri glx backends. (softpipe is abysmally slow)

(maybe that's the case for Intel ?)

Ironically, despite all of nvidia's problems regarding rendering with egl to linear buffers, I couldn't get intel's gl from mesa working with this. I was only able to get nvidia's gl working, and use that for intel.

Haven't checked the exact relation between glamor and GLX yet.

I can imagine that when using GLX & glamor, both might somehow getting in conflict into each other, stalling each other down.

I doubt that is the case.
As I understand it, glamor is used for accelerating the X server's 2D rendering, while glx is used by X clients to accelerate their own rendering.
Glamor also provides a glx provider that, when glamor is used (or at least partially initialized? haven't looked to deeply into this). This provider can be used top accelerate X clients through egl.
I'd expect we'd see a lot more problems with xfree86's modesetting if glx was somehow slower when run through glamor.

However, with glamor egl, I get better performance in games (even if not for general desktop use), and I can get vulkan working (no Idea how that works, there is no DRI3 here, but it does).

Why should Vulkan depend on DRI3 ?

This is what happens when trying to run vkgears on top of llvmpipe.
I assumed other vulkan vendors have similar restrictions.

$ DISPLAY=:1 vkgears
MESA: info: vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
Vulkan not supported on given XCB surface
Failed to create surface!

Should we just always enable glamor egl, and let the user switch it off with -dumb? Should we do what glamor/glamor_egl.c does? Refuse to initialize on top of softpipe/llvmpipe? Should we always default to not using glamor, unless that's the only way to get glx working? Should we do something else?

Running 2D ops ontop of softpipe probably is slower, so perhaps fall back to optimized CPU code here.

So we should do it like in glamor/glamor_egl.c?
Should we also add a switch for forcing glamor in these cases?

[notbabaisyou]

Why should Vulkan depend on DRI3 ?

Mesa has a hard requirement for DRI3, refusing to use their X11 WSI backend if it isn't available.

Haven't checked the exact relation between glamor and GLX yet.

GLAMOR has a GLX provider that replaces Mesa's DRIL for providing DRI2 setup and GLX FBconfig's.

@stefan11111 You could try patching the GLX provider to refuse setup on FBDEV through a custom GLAMOR flag in glamor_init, Xorg should fallback to DRISWRAST, which might help

My guess is that it's because gpu's usually draw into tiled buffers (when using drm), while a framebuffer is linear (in the ideal case).

GPUs tile everything possible to reduce memory bandwidth demands....

[stefan11111]

GLAMOR has a GLX provider that replaces Mesa's DRIL for providing DRI2 setup and GLX FBconfig's.

@stefan11111 You could try patching the GLX provider to refuse setup on FBDEV through a custom GLAMOR flag in glamor_init, Xorg should fallback to DRISWRAST, which might help

What would that achieve?
The glamor glx provider has to be explicitly initialized after glamor is initialized.
If we wanted to not use it, we should just not initialize it, but why would we want that?

[notbabaisyou]

Hmph, was thinking that it was a GLX/DRI2 issue. Probably isn't it.

[stefan11111]

@stefan11111 You could try patching the GLX provider to refuse setup on FBDEV through a custom GLAMOR flag in glamor_init, Xorg should fallback to DRISWRAST, which might help

I ended up doing this the other way around.
I added a flag that makes glamor_init just initialize the bits required for the glx provider, and leaves the X server's rendering unaccelerated.

In fb_glamor.c, I added checks for when this flag should be added like in glamor/glamor_egl.c, with command-line overrides.

[stefan11111]

@metux @notbabaisyou @X11Libre/dev
Any concerns on this one?
The toplevel glamor changes are mostly whitespace changes, you can check with https://github.com/X11Libre/xserver/pull/1840/files?w=1