Trend Micro Uncovers Yet Another X.Org Server Vulnerability: CVE-2023-1393

[oiaohm]

All of them, everywhere, all of the time, for years?

So you should be able to find one that shows that fig then that recent. That video did not show AMD stalling in CPU on Linux. There is a big difference between open source AMD drivers and AMD drivers on Windows.

And even no GPU. point?

No iGPU and APU is why AMD and Intel would develop something different to Nvidia who normally does not develop those..

AMD and Intel GPUs have MMU units that understand multi process<< This includes their DGPUs.

for 15fps on a $1000 GPU? no thanks.

Does not matter if it not cost effective. The fact it can work says Wayland VR can work like it or not.

https://forums.developer.nvidia.com/t/steamvr-drm-display-leasing-support-on-wayland/252272

The reason why VR does not work with Nvidia under Wayland is the fact that Nvidia drivers don't support DRM leasing yet including under X11. So when you VR on Nvidia hardware on Linux you have having to put up with X11 overhead you should not be putting up with as well.

There are quite a few Linux native VR programs that refuse to run at all without drm leasing as well used in specialist fields.

why do I care? will answering it make wayland not shit? If so, why doesn't someone who is involved in trying to make wayland not shit not just answer it but actually write the code to implement it?

mSparks good question here how do you know that a block of cpu memory is truly not used on a system. Remember this block of CPU memory could be a block of mapped to CPU memory VRAM.

You need to answer it. Once you do it starts explaining things.

Never crossed your mind that AMD/Intel might be doing something right but it costs some CPU time. Nvidia GPU can suffer from VRAM leaks that don't go away when you terminate the process that allocated it if not that suffer from terminating application freeing VRAM another application has allocation to.

Use of DMABUF based memory system for GPU makes correct memory accounting so that when all application have freed usage of VRAM it will free and that one application freeing VRAM does not rug pull a different one.

Nvidia drivers do have issues with multi process applications under Linux sharing buffers this is not just restricted to Wayland.

Nvidia GPU memory management system is broken and when it forced to be correct takes a high performance hit. Why did iGPU/APU/Intel DGPU/AMD DGPU add specialist hardware to deal with application memory freeing. Yes with anything AMD/Intel scheduler terminating applications send message to GPU to say hey this application code has terminated please free all it unique memory and tell me when I can free/reallocate all of the assigned unique maps of that application to something else.

How does Nvidia driver know when VRAM is truly no longer used when it does not have correct OS scheduler interactions?????? Yes guess method Nvidia uses can get high performance at the risk to data security/stability.

[mSparks]

Some how those CSGO claims don't make sense with 3-15ms and 30ms waits where your benchmark show those..

All of them, everywhere, all of the time, for years?
e.g.

https://www.youtube.com/watch?v=uXepIWi4SgM

That is exactly what always happens with igpu and APUs.

And even no GPU. point?

Try again this time with no opengl addons on AMD.

for 15fps on a $1000 GPU? no thanks.

mSparks good question here how do you know that a block of cpu memory is truly not used on a system. Remember this block of CPU memory could be a block of mapped to CPU memory VRAM.

why do I care? will answering it make wayland not shit? If so, why doesn't someone who is involved in trying to make wayland not shit not just answer it but actually write the code to implement it?

Oh yeah, that's right, all to busy copy pasting code and critical vulnerabilities out of x-org server.

[oiaohm]

xplane wont even start on wayland VR.

Try again this time with no opengl addons on AMD. I have something for you it does in fact load and run so claim that xplane will not start on Wayland VR is not right it starts on Xwayland.

you were the one raving about how great DMABUF was.
Like using CPU RAM for graphics and GPU VRAM for the CPU is a good thing.

That is exactly what always happens with igpu and APUs.

AMD and Intel GPUs have MMU units that understand multi process.

DMABUF allows CPU side to pass around VRAM allocations and map them into processes as required without causing issues.

You map VRAM into cpu ram so application running in CPU can write some graphics data.

mSparks good question here how do you know that a block of cpu memory is truly not used on a system. Remember this block of CPU memory could be a block of mapped to CPU memory VRAM.

There is a need for the CPU RAM management system and the VRAM management system to work cooperatively with each other if you don't do this you have odd stuff happen. Like the race condition switching between text based framebuffer and X11 with Nvidia resulting in Nvidia kernel driver kernel panicking it still a random event to happen in the prior to Nvidia starting the open sourcing of their driver process.. There is has been on going issues with Nvidia on Linux and kernel panics.

https://www.youtube.com/watch?v=HEZKGextuy8

Some how those CSGO claims don't make sense with 3-15ms and 30ms waits where your benchmark show those..

[mSparks]

Question how much do you think bare metal X11 adds.

absolutely nothing
1/50,000 = 20uS

Once you have something breaking opengl/vulkan standards

Utter bullshit of the highest order.

broken application X-plane

lol, wot.

X-plane to form your idea how wayland is broken.

Actually that was CSGO, xplane wont even start on wayland VR.

is another way to trigger excess CPU usage.

lol wot.
you were the one raving about how great DMABUF was.
Like using CPU RAM for graphics and GPU VRAM for the CPU is a good thing.

as you said you don't see this with AMD

indeed, I have never seen AMD manage 1ms CPU wait times in the driver, for openGL its in the order of 30ms, vulkan is generally down to 3-15ms, depending on what features its using and how badly the memory leaks hit.

[oiaohm]

rough figures, the wayland compositor is adding 1ms of time to complete cpu tasks.

I have already quoted exact figures that were measured on that one. Question how much do you think bare metal X11 adds. How much overhead do you think turning on Nvidia tear free with X11 causes.

Nothing you wrote in fact lines up with the benchmark results.

or sake of example, turning a 11ms cpu wait task + 3ms gpu wait task (71fps) into a 10ms cpu wait task and 3ms gpu wait task (77fps)
but if AMD fixed the driver to nvidia standards that would just be a 3ms gpu task and 333fps X11 and 1ms cpu and 3ms gpu for 250fps on wayland.

No this is you doing a wild guess.

Then how do you explain tomb raider 30% faster on zink than Nvidia own Opengl. Nothing says if AMD fixed their driver to Nvidia standards that it would be faster. Zink numbers benchmarks where it zink vs nvidia opengl say to Nvidia standard could be horrible.

this is why something like xplane - linux native with tons of tools for reporting both cpu time and gpu time is perfect for benchmarking it.

Xplane is useless. Totally useless. Once you have something breaking opengl/vulkan standards going into undefined behavior this is classed as using routes that do not have to be optimized this will see increased CPU usage or not work correctly on anything built to the standard exactly.

The AMD driver is already bottlenecked on the CPU. << I guess you have drawn this idea from useless Xplane data.

And once again, none of that is an issue or actually matters, what is faaaaar more significant on wayland is the latency issue, the fact everything is lagged by very noticiable amounts of time, presumably sat in various buffers wayland introduces waiting to be processed.

Not for AMD and Intel users. You just wrote up stack of garbage. I guess I know why you have used a broken application X-plane to form your idea how wayland is broken.

Yes having the GPU trigger watch dogs and restest self increases CPU usage. Increase number of buffers you see and increases number latency. How to trigger this with AMD and Intel stupidity use opengl/vulkan in one process.

Nvidia use items Nvidia has not correctly implemented yet is another way to trigger excess CPU usage.


pretty sure if you look at all the nvidia benchmarks it will be a fairly consistent 0.8-1ms increase in frame time. << as you said you don't see this with AMD. Also interesting eglstreams weston does not show this only DMABUF using Nvidia shows this.

(ignoring the 10+ms latency on time to receive input tasks which is far more of a problem)

Lets shatter you here. When using x.org bare metal you are using libinput by the way but you are also running X11 input driver stack something that Xwayland removes completely. Welcome to a horrible catch. You measure a fake input generated on uinput getting to Wayland application or X11 application guess what order of delivery.
1) Wayland native.
2) Xwayland
3) X11 bare metal.
Yes that order. X11 bare metal is slower all because of the X11 input driver stack its a horrible mess of lost performance.

[mSparks]

Please explain how if wayland compositor caused problem how on AMD hardware is able to isolate itself to 2 benchmarks??? This is why looking at the average makes no sense.

bottlenecks is the term generally used.
The AMD driver is already bottlenecked on the CPU.
Nvidia driver becomes bottlenecked on the CPU since the compositor is running on the cpu.

this is why something like xplane - linux native with tons of tools for reporting both cpu time and gpu time is perfect for benchmarking it.

rough figures, the wayland compositor is adding 1ms of time to complete cpu tasks. (ignoring the 10+ms latency on time to receive input tasks which is far more of a problem)

that turns a 5ms gpu task (200fps) into a 6ms gpu+cpu task (170fps)
pretty sure if you look at all the nvidia benchmarks it will be a fairly consistent 0.8-1ms increase in frame time.
e.g.
70fps to 66fps quakes2 rtx or 200fps to 170fps

But on AMD, wayland mostly just replaces the stuff the driver is already doing on the CPU, so unless it takes significantly longer (such as in the case of dirt rally) to do the same thing, it doesnt have the same impact.

for sake of example, turning a 11ms cpu wait task + 3ms gpu wait task (71fps) into a 10ms cpu wait task and 3ms gpu wait task (77fps)
but if AMD fixed the driver to nvidia standards that would just be a 3ms gpu task and 333fps X11 and 1ms cpu and 3ms gpu for 250fps on wayland.

And once again, none of that is an issue or actually matters, what is faaaaar more significant on wayland is the latency issue, the fact everything is lagged by very noticiable amounts of time, presumably sat in various buffers wayland introduces waiting to be processed.

[oiaohm]

That difference in average is the difference having the compositor turned on makes.

Except that wrong. All the full screen benchmarks are X11 compositor disabled.

Please explain how if wayland compositor caused problem how on AMD hardware is able to isolate itself to 2 benchmarks??? This is why looking at the average makes no sense.

The 7900XTX would perform even better on X11 if its drivers weren't broken, potentially double based on the actual hardware specs and energy use.

I would not say double.

https://www.phoronix.com/review/radeon2022-windows-linux/2

https://www.phoronix.com/review/wayland-nv-amd-2023/3

AMD drivers are improving and is improvement slightly faster on Wayland than X11.

This claim that AMD drivers are broken means you are ignoring the data on AMD hardware. If it Wayland compositor overhead that the problem that still would be there no matter how bad the driver is.

There are also GPU drivers issues to be resolved, which hit some applications worse than others.
None of those benchmarks are linux applications, there is no way to modify them for any linux specific issues.

X-Plane graphics issue is X-Plane disobeying Vulkan and Opengl specifications. AMD and Intel you have the option of forcing particular driver versions per application under Linux. Nvidia drivers and Mesa3d linux native drivers can detect application running inside wine and apply quirks correction.

Please note Linux you have host and dmabuf. Window you have host/win32 with opengl and vulkan. Guess what win32 only offers protection that it works if you cross processes.. X-Plane had issues under windows as well with AMD so not Linux problem. They blamed it on AMD drivers without in fact noticing what they were hitting was a opengl/vulkan specification issue with host memory protection(ie per application memory) that said what they had happening was exactly to specification.

Or could could just chose nvidia on X11 and not have any problems...

Why was Nvidia avoiding DMABUF as much as possible where they support win32 process to process. Simple DMABUF into core of nvidia kernel driver on Linux would require open sourcing it to be 100 percent compatible since this required working directly with the host kernel CPU memory manager and CPU scheduler.

This is not true there are opengl and vulkan games with Nvidia that on Linux under X11 under-perform vs Windows sometimes due to the lack of DMABUF. Also have crashed under wine because they don't have proper per application memory splits that they had under Windows yes missing DMABUF support under Linux to replicate win32 buffer transfer between processes.

Sorry you have cherry picked your examples to attempt to say AMD is a problem. I could have responded with equal and worse cherry picking showing Nvidia as defective under X11. Driver issues exist they have to be resolved this is status normal. Wayland compositors majority of issue with nvidia is just a sign of a bigger issue of lack of DMABUF support in Nvidia drivers that does effect different X11 applications. You see it in Tome Raider where you use zink opengl and you run rings Nvidia closed source opengl drivers under X11. Tome Raider is one of those fun programs that is multi process.

So the issue to fix up Nvidia X11 tome raider performance will fix up most of Wayland compositors performance problems with Nvidia.

Get of the Nvidia is the best cool aid please. Not all people play games where Nvidia works well.

[mSparks]

The answer is because I am not a idiot who only looks at the final averages.

That difference in average is the difference having the compositor turned on makes.
The 7900XTX would perform even better on X11 if its drivers weren't broken, potentially double based on the actual hardware specs and energy use.

There are selective per application issues to be resolved

There are also GPU drivers issues to be resolved, which hit some applications worse than others.
None of those benchmarks are linux applications, there is no way to modify them for any linux specific issues.

The problem you have is majority of the benchmarks with AMD shows that the Wayland Compositor gives the performance without fully having to remove itself. This is what totally undermines the claim the Wayland compositor need to totally disable.

Or could could just chose nvidia on X11 and not have any problems... but feel free to make problems for yourself, really don't let me stand in your way.
Just don't expect the majority of people to follow your lead.

Like it or not unless you hit some form of bug Wayland compositors match X11 bare metal without compositor in performance.

I'm just fine with it, but I'm still trying to explain to you that this is a shit sales pitch for wayland that makes me not care about it in the slightest.

[oiaohm]

You are going to have to explain how you get from this

To "Wayland performance under AMD is good"

Are you defining less FPS is better or something?

The answer is because I am not a idiot who only looks at the final averages.

Look at every other number on that page. Wayland either matches or better than X11 on AMD hardware. Page before that the same.

There is exactly two benchmarks out the complete list of tests that work on AMD that under performed. Dirt Rally 2.0 a benchmark that the maker of game admits is bugged.

Metro Last Light Redux but that loss is inside that benchmarks run to run error rate so run the benchmarks again and that one might flip.

That 6 percent down in the average does not support you claim

"Waylands performance issue will last as long as you can't disable the compositor.."

Remember every benchmark had the Wayland compositor enabled and it only 6 percent down on average but that 6 percent majority comes from 1 benchmark totally went wrong and that benchmark has gone totally wrong for those bench-marking on windows with Nvidia hardware at times.

The reality if the Wayland compositor was causing performance problem generically to the point it need to be disabled majority of the AMD benchmarks should be adversely effected and that not the case.

There are selective per application issues to be resolved.

Please note X-Plane 12 is in those benchmarks the benchmark of X-Plane 12 is pure vulkan no opengl plugins so works perfectly fine with AMD. Guess what on AMD X-plane 12 benchmark is slightly faster.with wayland than X11. So zink sort out opengl/vulkan issue and X-Plane 12 will be looking good on AMD to use Wayland for X-Plane over X11.

mSpark explain to me how in heck the thing you quoted proved a generic issue with the Wayland compositor. Attempt it if you want to prove you are fool. This time look at all the benchmarks not just the averages when you do it does not say there is a generic problem. Instead benchmarks show a per application issues here and there with Wayland Compositors.

Really I have told you this more than once that you cannot use that average to back your claim.

Like it or not unless you hit some form of bug Wayland compositors match X11 bare metal without compositor in performance. Yes it is possible for me to pull up different benchmarks that are hitting bugs in X11 x.org server bare metal that don't have that problem under Xwayland or as native wayland and claim a false advantage as well.

mSpark Nvidia across all the different benchmarks are down on Wayland and that cause is known it the need to get the DMABUF items optimized. Yes if AMD/Intel GPU was showing the same kinds of performance defect as Nvidia then it would be possible that it the Wayland compositor to blame for the low performance..

The problem you have is majority of the benchmarks with AMD shows that the Wayland Compositor gives the performance without fully having to remove itself. This is what totally undermines the claim the Wayland compositor need to totally disable.

Wayland compositor for full screen applications using DMAbuf it is able to mostly step out way when this works(that is most of the time with full screen benchmarks and applications) there is either a slight advantage to wayland or equal to X11 bare metal performance this is what happening with AMD and Intel.

Now Nvidia where DMABuf does not work right yet when Wayland compositor does the DMABUF instructions to allow applications buffer to go straight to gpu and straight display(the step out way instructions) this does not happen with Nvidia hardware perfectly right yet so you end up with some Nvidia driver overhead.

[mSparks]

https://www.phoronix.com/review/wayland-nv-amd-2023/5

Not supported by benchmarks. Wayland performance under AMD would not be as good as what it if that was the problem.

You are going to have to explain how you get from this

To "Wayland performance under AMD is good"

Are you defining less FPS is better or something?