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

[oiaohm]

Only on Wayland, where it has never worked.
Still works fine on X11, terrible CPU perf excluded.

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

Try again GTA V is busted be it wayland or X11 with AMD at the moment.. There are old X11 vs Wayland were GTA V works on Wayland and X11 with AMD but that has not been the case for a while..
This is why you have to be careful with the combination of benchmarks on the open benchmarking site because total failures are not logged.

Asking for a recent GTA V benchmark on AMD hardware with current drivers on Linux with X11 or Wayland you are screwed. You asked for the impossible and from your responses so far you did not know you asked for the impossible..

https://www.phoronix.com/news/RADV-Gfx-Srates-Optimizations

https://github.com/zmike/vkoverhead

For those who don't know vkoverhead used in that test report runs without X11 loaded. vkoverhead on Linux clean running the tests are done without X11 or Wayland compositor. So that work is a general improvement not X11 particular.

The RADV developer there works for Valve that work is not X11 focused.

vkoverhead is not in fact designed for testing overhead under X11 or Wayland it designed as something that can be up on the mesa automated test servers to detect issues with very min setup and prep.

[mSparks]

Here is the benchmark inside the last couple of days. GTA V does not run at the moment on open source AMD.

Only on Wayland, where it has never worked.
Still works fine on X11, terrible CPU perf excluded.

There is actually a merge request to start to address that on X11 vulkan also accepted in the last couple of days

https://www.phoronix.com/news/RADV-Gfx-Srates-Optimizations

[oiaohm]

Wayland.
https://openbenchmarking.org/test/pts/gta5

19 November 2022 with the latest data as of 16 May 2023.

Please find date of AMD benchmarks. " , like from a couple of days ago" is what you asked for the benchmarks those are not from the last couple of days..

https://www.phoronix.com/review/may-2023-linux-gpus/4

Here is the benchmark inside the last couple of days. GTA V does not run at the moment on open source AMD. Fun point open source drivers just implemented some of the optional features that should improve performance of GTA V since it not all that GTA V need to perform well the result is it does not run. Normal failure that happened before.

More like you having to go all the way back to 8 years ago to find an issue with nvidia, that was fixed in days, rather than lingering for months and years.

The race condition bug switching between text based terminal and X11/Wayland that Nvidia suffers from that has not been fixed in decades first appeared 2002. There are quite a few bugs with Nvidia on Linux that have stuck around for decades this is the reason why Redhat and others would like to write their own drivers for AMD and Nvidia and Intel hardware all 3 vendors are slow to address Linux issues like it or not.

Open source drivers have just hit the same fault with GTA V that Nvidia hit 8 years ago when they implemented the same extensions. Don't know what opengl implementation GTA V developers used but it was not AMD or Nvidia by the expected behaviors by GTA V maybe the Intel opengl/dx12 for Xeon Phi yes that a different opengl/dx12 to what intel igpus use or something custom console.

GTA V performance is not wayland problem but there is a interesting issue there.

[mSparks]

I did not say AMD could not do better.

huh.

GTA-V fails for a completely different reason.

Wayland.

https://openbenchmarking.org/test/pts/gta5

Basically here is you cherry picking the failures again.
https://linustechtips.com/topic/362071-games-wont-start-with-nvidia-gpu/

More like you having to go all the way back to 8 years ago to find an issue with nvidia, that was fixed in days, rather than lingering for months and years.

All graphics drivers are some form of buggy.

Never said they weren't.
I'm just making a distinction between
hardware/software rife with huge bugs that have hung around for decades. Like Windows, AMD GPUs and Wayland
and
hardware/software with very few bugs, that are very often rapidly fixed no matter how obscure, like Linux, X11/org-server and Nvidia.

plus saying the former isn't recommended or a future anyone will tolerate much longer. But hey, some people believe in windows phone, and I'm not going to stand in their way if they want to bet their house investing in developing for it, maybe it will work out for them.

[oiaohm]

If you want to claim AMD can do better than the evidence I already presented shows, you are the one who needs to present the evidence of it doing better, e.g. a benchmark of a popular application people use of it doing better.
Try GTA V, it doesn't get more popular than that.

I did not say AMD could not do better. GTA-V fails for a completely different reason. Basically here is you cherry picking the failures again.

https://linustechtips.com/topic/362071-games-wont-start-with-nvidia-gpu/

Issues of games not firing up on different GPUs is not even a Linux or AMD exclusive thing. Just because you have a Nvidia GPU does not mean GTA-V will always work there longest time frame GTA-V refused to fire up on Nvidia was a half a year that was a while back.

https://store.steampowered.com/charts/mostplayed

Yes wallpaper engine being number 7 at the moment but it daily its 4 after GTA V does start you wondering how much people do play games. Yes in a game focused store you see non gaming things come to the top. The non gaming use case is kind of important. The area Wayland developers talked about increased performance is the non gaming area.

Yes I would say the open source drivers are broken for GTA V with AMD and Intel at the moment. Failure caused by AMD and Intel direct to hardware opengl drivers having particular optional features disabled. Would be interesting to run GTA V with Zink.

Yes the opengl standard says particular things are allowed to be optional as well and by standard you are meant to include code to work around optional parts being missing.

Some of the reason why Valve funds zink development is they will need zink to run older opengl games on Nvidia cards for the same reason GTA V does not work with Mesa AMD and Intel drivers at the moment missing optional opengl extensions.

Nvidia and AMD both have issues of games not working for optional opengl extensions being missing. Yes that on Windows and Linux. AMD has more highly popular games in the top 25. but Nvidia has a quite a few in the top 100 games that don't work as well by the top 300 number of failures have leveled out between AMD and Nvidia caused by missing optional extensions.

So GTA V is you just attempting to win by cherry picking again.

X-plane is 1 particular problem.
Dirt Rally is a different particular problem most likely caused by being close to Opengl specification and having work around for missing extensions and so on and the work around stuff being buggy.
GTA V is simple failure to run if optional extension does not exist problem that generic between AMD and Nvidia and closed and open source drivers.

There is nothing here that says AMD or open source drivers are particularly bad just someone cherry picking attempting to say that.

Nvidia case with Wayland Nvidia says that the DMABUF support is buggy and since Wayland compositors depends on that you expect crap performance with Nvidia until it fixed.

All graphics drivers are some form of buggy. Not helped that programs/games do thing against specifications.

[mSparks]

Where you evidence you don't have any.

If you want to claim AMD can do better than the evidence I already presented shows, you are the one who needs to present the evidence of it doing better, e.g. a benchmark of a popular application people use of it doing better.
Try GTA V, it doesn't get more popular than that.

something recent, like from a couple of days ago

[oiaohm]

Dirt rally is very likely the only one of those benchmarks accurately reporting how many frames completed.

Where you evidence you don't have any.

https://answers.ea.com/t5/DiRT-Rally-2-0/FPS-amp-Stuttering-PC-non-VR/td-p/11564754

Dirt Rally doing the same thing with Nvidia under Windows at random. Dirt rally seams to screw up it shaders some how and when it happens the result is absolutely wrecked performance..

when dirt rally is screwing up people have recorded with nsight with AMD and Nvidia graphics. Yes nsight works under Linux with AMD... The traces of Nvidia on Windows screw up align to the traces of Dirt Rally being totally shot on with AMD under Linux.

There is some bug in Dirt Rally that causes it to send incorrect stuff to GPU suspected triggered by how ever the GPU describes its currently available resources.

Zink developer has also found that DiRT Rally 2.0 is problem child with different rendering issues because caused by reporting that particular amounts of vram are free.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/8077

mSparks differerent parties have looked into the Dirt Rally issue. There is zero evidence of CPU stall as cause. In fact there is evidence that its not that. The dirt rally is doing things that stall the process out on the GPU side.

Yes ARC vs AMD here is much more interesting because weaker arc is beating more powerful AMD GPU with Dirt Rally. Both have the same CPU usage patterns. There is going to need to be a quirk for Dirt Rally 2.0 or some update of Dirt Rally 2.0 magically fixes what ever this strangeness is.

Yes running under Wayland the GPU reporting data on itself is slightly different and this is possible causing Dirt Rally to go what the hell. Yes people running Nvidia Beta drivers under Windows have higher odds of Dirt Rally 2.0 going stupid. This seams to be issue with game detecting GPU and then attempting to optimize to suite and when it gets something it does not know falls back on really poor performing believed to be dependable code.

Xplane 12 pure vulkan does not have stalling. Mixing opengl/vulkan in the same process causes big problems with AMD and that is allowed by opengl and vulkan specifications.

mSparks sorry Dirt Rally and Xplane don't hold up as examples.

Dirt Rally is in GPU stalling due to deciding to do some horrible things. Xplane is stalling due to changing GPU from being configured opengl to vulkan and back causing CPU stall. So two different problems.

mSparks you are not using evidence. Instead you are taking since Xplane has huge stalled due to opengl/vulkan introp issue then dirt rally performance problem has to be the same. Big problem Dirt Rally and Xplane issues are truly independent. Both have something in common the developer of those programs has done something wrong.

[mSparks]

The Phoronix Dirt Rally low performance with AMD has to be taken with a serous grain of salt
.

rofl
90fps at ultra settings is not low performance.
Its just the best you can do when the driver regularly stalls the cpu for 11ms give or take and you are in a sim such as dirt rally or xplane that reports true, unique frames per second, rather than the multiple counting of identical frames you get in games with fully async graphics and physics.

Dirt rally is very likely the only one of those benchmarks accurately reporting how many frames completed.
the same frame 500 times a second does not a good GPU driver/desktop experience make, no matter how amazed you are by your 500fps stutterfest..

[oiaohm]

Sure, Phoronix just dropped another one yesterday, recent enough for you?

https://answers.ea.com/t5/DiRT-Rally-2-0/FPS-amp-Stuttering-PC-non-VR/td-p/11564754

Lets ignore for one min that Dirt Rally is coming random-ally unplayable on Windows users yes Nvidia and AMD windows users equally.

Linux users with AMD have a 100 percent repeatable way of generating the bug.

The Phoronix Dirt Rally low performance with AMD has to be taken with a serous grain of salt when the program is not performing correctly on its native Windows all the time.

Using system ram for GPU tasks adds a ton of latency, it should be an absolute last resort when there is no other option, not a default design choice.

CPU applications code need to get data to GPU has to have sharing method.

DMABUF is about tracking allocations. So when CPU process will never use some vram again the GPU can know so it can free this up to use for GPU tasks.

You are right you don't want to be using CPU ram for GPU tasks. But what happens if you run out of vram because the GPU is holding on to the vram because GPU thinks CPU process still wants it that no existing that right using CPU ram instead of VRAM and your performance absolutely tanks.

This is one of the catches. AMD has some extra CPU usage for memory accounting due to DMABUF and their equal under windows but this prevents the case of application being terminated and its vram allocation being left on the GPU locked from usage because in case of application terminated memory will be freed if no other process is using it...

[QUOTE=mSparks;n1388372And that's why the crypto miners all buy AMD...
Oh wait, that's absolute bullshit.[/QUOTE]

https://www.ebay.com/b/AMD-Virtual-Currency-Miners/179171/bn_72700459

AMD was able to control purchases better. Crypto mining with Nvidia happens to use custom drivers with custom firmware if you use the general user firmware and drivers stuff don't work right. AMD on the other hand Crypto mining use the consumer drivers and firmware.

The memory management problem of Nvidia hits crypto hard just like nvidia rate limiting...

That's easy

How does Nvidia driver know when VRAM is truly no longer used <<

That what I asked. Not that you would load up a tool like valgrind as you answered. So try again.

https://gpuopen.com/rmv/ AMD does have tools like nsight but they don't have to detect for processes that have terminated still holding GPU memory because that does not happen with AMD cards. Also you don't have crashs with AMD because one application terminates and another application using a buffer that has buffer disappeared causing application to crash as have with Nvidia drivers as well. There is a price to pay for this difference either way. AMD slightly higher CPU usage due to doing accounting on allocations CPU applications believe they need on GPU side.

The correct answer is Nvidia driver does not correctly know when VRAM is truly no longer used so depends on application doing the right thing this is why you need valgrind like tool. AMD drivers do know when VRAM is truly no longer used don't depend on applications doing the right thing in this department at the cost of slightly higher CPU usage performing the accounting to know this.

[mSparks]

So you should be able to find one that shows that fig then that recent.

Sure, Phoronix just dropped another one yesterday, recent enough for you?

Use of DMABUF based memory system for GPU

Using system ram for GPU tasks adds a ton of latency, it should be an absolute last resort when there is no other option, not a default design choice.

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

And that's why the crypto miners all buy AMD...
Oh wait, that's absolute bullshit.

Never crossed your mind that AMD/Intel might be doing something right but it costs some CPU time.

AMD only cares about consoles when it comes to gfx, don't think even Intel knows what Intel is doing right now, the last few years have not been kind to them
https://www.google.com/finance/quote/INTC:NASDAQ?sa=X&ved=2ahUKEwjnz4jaroP_AhUWR_EDHVMw BH8Q3ecFegQIIBAh&window=5Y

How does Nvidia driver know when VRAM is truly no longer used

That's easy

https://developer.nvidia.com/nsight-graphics

or

https://developer.nvidia.com/nsight-aftermath

Equivalent for AMD?