Re: First results from the GZDoom 4.2.0 survey

Sun Aug 18, 2019 11:30 am

These days that's still a decently supported graphics card, albeit low end. We still got reports in the survey with older hardware. But try something a few years older and you may discover the problems that may develop...

Re: First results from the GZDoom 4.2.0 survey

Thu Aug 22, 2019 2:09 pm

Graf Zahl wrote:Apple is a textbook example of a company that has mostly lost touch with the type of customer that has made them great in the first place.

I can say same for most companies nowadays. Looks like approaching international crysis would be not only financial but also......intellectual :)

Re: First results from the GZDoom 4.2.0 survey

Fri Aug 23, 2019 12:59 am

With now 6500 reports the numbers starting to solidify. Aside from a query mistake that wrongly attributed some OpenGL hardware with full features and Vulkan to the legacy slot there hasn't been much change, here's the current results, in parentheses the GZDoom 3.5 survey's percentage.

77.2% (67%) use Vulkan compatible hardware, 2.5% of users actually use Vulkan.
13.6% (17%) use hardware which can run OpenGL with all features enabled but cannot run Vulkan.
10.0% (12.6%) use legacy hardware which requires fallback solutions in the renderer and only has limited support for some features.

1.47% (3.3%) use a real 32 bit system.
2.5% (2.7%) macOS
6.0% (6.3%) use Linux, 2 sole users on 32 bit!

63.3% have NVidia hardware
19.5% have AMD hardware
17.2% have Intel hardware

70% use a system with 4 CPU cores and more - among the Vulkan compatible systems this is 82%.

So not much change compared to the first post, the 32 bit number is still low enough that a single report can shift the percentage noticably, but it has started to settle down around 1.5% - the total number of 32 bit reports as of right now stands at 96. So much just for highlighting how irrelevant 32 bit has already become.

Re: First results from the GZDoom 4.2.0 survey

Fri Aug 23, 2019 5:13 am

> 70% use a system with 4 CPU cores and more
Are they real cores or SMT/HT ? Can GZDoom even detect if they are SMT/HT ?

Re: First results from the GZDoom 4.2.0 survey

Fri Aug 23, 2019 6:12 am

Under Windows I can detect it, under Linux I made a compromise check for 6 virtual cores, in the hope that this will evenly distribute the error.
But with 92% of all users being on Windows, I think the number is representative.

Re: First results from the GZDoom 4.2.0 survey

Fri Aug 23, 2019 7:46 am

Code:
[redneck@pylesos ~]$ grep "cpu cores" /proc/cpuinfo
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6
cpu cores       : 6

My CPU is Ryzen 5 2600 with 6 cores and 12 SMT threads, and
Code:
grep "cpu cores" /proc/cpuinfo
prints "cpu cores: 6" 12 times. Can somebody tell us if it's a reliable way to detect a number of cores and SMTs on Linux?

Re: First results from the GZDoom 4.2.0 survey

Fri Aug 23, 2019 7:48 am

Also:
Code:
[redneck@pylesos ~]$ grep "siblings" /proc/cpuinfo
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12
siblings        : 12

Are these "siblings" SMTs?

Re: First results from the GZDoom 4.2.0 survey

Mon Aug 26, 2019 6:12 pm

The interesting statistic to me is that 77% of users could use Vulkan but only 2.5% actually do. Why is that? I reckon it's cause Vulkan is in a different section of the menu from the actual rendered, so it's not clear that Vulkan is actually supported. Should the Vulkan options be placed in the video modes section?

Re: First results from the GZDoom 4.2.0 survey

Mon Aug 26, 2019 7:08 pm

It's likely because Vulkan is not enabled by default.

And in order to do that the CVAR will have to be renamed again, anyhow, because it is in archive state and changing the default will have no effect on like 90% of users.

Re: First results from the GZDoom 4.2.0 survey

Mon Aug 26, 2019 7:26 pm

Would it not make sense to move it into the video mode options, where you select OpenGL, polysoft, etc? That seems a much more logical spot to put it then hidden in a sub menu in display options.

Re: First results from the GZDoom 4.2.0 survey

Mon Aug 26, 2019 7:32 pm

In addition to moving the option to some place more visible, there needs to be a blog post advertising it in an official way. I have talked to people first-hand that don't even know the Vulkan renderer exists and they've been updating their copies of GZDoom.

Re: First results from the GZDoom 4.2.0 survey

Mon Aug 26, 2019 7:47 pm

Yeah, the UI involving Vulkan seems to come from when it was experimental (I think it even still says experimental). Now that it isnt experimental, it needs to be updated accordingly.

Re: First results from the GZDoom 4.2.0 survey

Tue Aug 27, 2019 12:10 am

The main problem is that the Vulkan renderer still has a few hiccups, e.g. it has a finite amount of storage for geometry data and may abort on excessively large maps. Some users are still reporting stability issues, once we are reasonably convinced it will be enabled by default on compatible hardware and the menu be tuned a bit.

Re: First results from the GZDoom 4.2.0 survey

Wed Aug 28, 2019 4:12 am

32 bit has seen a minor uptick, currently standing at 1.57% - but even only counting the reports from last week it is merely at 1.64% - that was enough to slightly bump its percentage but isn't much higher than it was before.

Aside from that, not much has changed - the numbers have mostly stabilized, so once a new release is due, the survey can be disabled again.

Re: First results from the GZDoom 4.2.0 survey

Sat Aug 31, 2019 12:22 pm

Graf Zahl wrote:The main problem is that the Vulkan renderer still has a few hiccups, e.g. it has a finite amount of storage for geometry data and may abort on excessively large maps. Some users are still reporting stability issues, once we are reasonably convinced it will be enabled by default on compatible hardware and the menu be tuned a bit.


Large mods can also cause do this. Even worse, on NVidia cards like my own, the abort fails so badly that it can't even get to console and print the information. That had me thinking at first, maybe I might have an infinite loop issue. Turns out that wasn't the case.

So it's not ready to have the "experimental" tag taken off just yet.